Blog

Sie sind Entwickler? Dann sind Sie UX Designer.

Martin Hesseler
Martin Hesseler
25. Februar 2015

Der Begriff UX Design wird heutzutage oft verwendet. In den meisten Fällen verbirgt sich dahinter aber entweder ein Synonym für Interaction Designer, Usability Professional oder einer ähnliche Branchenbezeichnung, oder ein Konglomerat aus all diesen Disziplinen. Richtigerweise wird darauf hingewiesen, dass UX Design nicht mehr nur eine Phase eines Projektes ist, sondern projektbegleitend über das gesamte Projekt stattfinden sollte. Für mich sind die Grenzen dieses Begriffs aber noch zu eng gesteckt. Alle, die an der Entstehung des Produkts beteiligt sind, haben erheblichen Einfluss auf die resultierende UX. Usability Engineers, Interaction Designer, visuelle Designer, Design Engineers, Project Owner und Entwickler.

Ja, auch Entwickler sind UX Designer[1]. Denn schließlich haben sie auch einige Designentscheidungen zu treffen: Welche Architektur wird zugrunde gelegt? Kann die Hardware optimal ausgenutzt werden? Können die Konzepte mit der Zielhardware performant umgesetzt werden oder müssen Abstriche gemacht werden? Können die Konzepte mit absehbarem Aufwand umgesetzt werden oder müssen auch hier Abstriche gemacht werden?

Entwickler haben einen erheblichen Anteil an der resultierenden UX. Für mich als Interaktionsdesigner bedeutet das, die Schnittstelle zu den Entwicklern zu pflegen und sie bereits in der Konzeptionsphase stärker mit in die Kommunikation einzubinden.

Beispiel aus der Praxis: Multitouch-Gesten

Vor einiger Zeit haben wir in einem Projekt das Konzept für die Gestensteuerung eines Multitouch-Displays von Grund auf neu gestaltet, denn so etwas gibt es nicht vorgefertigt im Verkaufsregal. Nach der Grobkonzeption und der Analyse von bestehenden Ansätzen – denn wer möchte Multitouch-Gesten im Zeitalter von iPhone und iPad neu erfinden? – wurde die Feinkonzeption angegangen. Ein wichtiges Detail für dieses Konzept ist, dass die nächste Disziplin, die nach der Konzeptphase an der Reihe ist, nicht wie üblich eine Design-Disziplin, sondern direkt die Entwicklung ist. D.h. die Zusammenarbeit findet hier hauptsächlich zwischen dem Interaktionsdesign und der Entwicklung statt.

Kooperation zwischen Design und Entwicklung

Und genau an dieser Stelle scheint ein wunder Punkt zu sein, was meine Erfahrung aus jüngster Vergangenheit zeigt: Auf UX-Konferenzen trifft man immer mehr reine Entwickler, die versuchen, sich für das Thema zu sensibilisieren, weil sie selber merken, dass an der Stelle zwischen den Design-Disziplinen und der Entwicklung üblicherweise ein Bruch entsteht.

Alle reden immer von der Integration von UX-/Design-Prozessen in den Entwicklungsprozess, es scheint mir aber so, als praktiziere es kaum jemand wirklich. Aber was bedeutet diese Integration eigentlich? Für mich bedeutet es Zusammenarbeit und nicht „Nebeneinanderarbeit“. Nicht Kommunikation zwischen den Teams, sondern Kommunikation im Team. Denn wir sind ein Team. Ähnlich einer Fußballmannschaft mit verschiedenen Positionen.

Ein Projektteam kann mit einer Fußballmannschaft verglichen werden: Verschiedene Aufgaben auf verschiedenen Positionen.

Eine Fußballmannschaft aus UX Designern: Usability Engineers als Aufbau, Interaction Designer als Überbrückung des Mittelfeldes und Entwickler als Stürmer.

Das Team muss zusammen funktionieren, zusammen kommunizieren und eine Sprache sprechen. Damit das funktioniert muss man aufeinander zugehen. Und um den Entwicklern entgegenzukommen: Was lieben diese mehr als 2er-Potenzen und Zahlenreihen, die bei 0 und nicht bei 1 anfangen? Richtig: Statecharts.

Entwickler lieben Statecharts

Ich habe Statecharts kennengelernt als (unnötige) Form zu beschreiben, ob aus einem Getränkeautomaten Cola oder Wasser herauskommt wenn man ein paar Münzen hineinschmeißt.

Alle Zustände, von „idle“ (Automat bereit) über „counting coins“ (Münzen zählen) bis zu „give change“ (Wechselgeld ausgeben), werden aufgeführt und systematisch mit ihren Folgezuständen verbunden.

Ein Mittel, um die Kommunikation zwischen Entwicklern und Interaction Designern zu verbessern: Statecharts

Statecharts stellen eine gute Möglichkeit dar, Prozesse abzubilden. Ob man das für Getränke-Automaten tun muss, darf jeder gerne selbst entscheiden.

Während meiner Arbeit als Interaktionsdesigner habe ich Statecharts allerdings als Mittel der Gestaltung und Beschreibung von Konzepten kennen und schätzen gelernt. Bei der Erarbeitung eines Konzeptes ist es nie einfach, es vollständig und genau zu erfassen. Und spätestens bei der Umsetzung fallen Unvollständigkeiten oder Ungenauigkeiten auf. Statecharts helfen hierbei, indem bei ihrer Erstellung strukturiert vorgegangen wird. Dadurch fällt es leichter sich alle Interaktionsmöglichkeiten und –reihenfolgen zu überlegen, da man diese systematisch erarbeiten kann. Im Endeffekt sind dann auch die Entwickler glücklich, da die Konzeptbeschreibung einerseits weniger lückenhaft ist und sie andererseits ihr Statechart haben.

Im Fall der Multitouch-Gesten hat sich das Statechart als hervorragendes Mittel dieses Konzept zu beschreiben herausgestellt. Dadurch hatten wir eine gute Kommunikations- und Entwicklungsgrundlage, wodurch der Grundgedanke gut erklärt und gemeinsam mit den Entwicklern weiter verbessert werden konnte. Die ursprüngliche Konzeptidee ging also ein paar mal im Team hin und her, bis eine Version herauskam, mit der alle zufrieden waren.

Das beste Tool für die Einbindung von UX in den Entwicklungsprozess: Kommunikation

Ein weiterer wichtiger Punkt bei einer gemeinsamen Arbeit und Sprache ist ein übergreifendes Tool, damit man an gemeinsamen Dokumenten arbeiten kann. Und so haben wir uns im Fall des Statecharts der Multitouch-Gesten für das bei mir unbeliebte Tool Microsoft Visio entschieden. Nicht schön. Aber förderlich für die Zusammenarbeit. Und so entwickelte sich unser Visio-Statechart zu einem „schönen“ und übersichtlichen Diagramm (das „schön“ war allerdings nur bedingt möglich, da Visio sich als „Hard to Master“ herausstellte und man sich einige Workarounds einfallen lassen musste, damit die Verbindungslinien zwischen den einzelnen Zuständen nicht totales Chaos auslösen).

Alle Dinge konnten wir aber auch nicht mit Visio oder in Form von Statecharts gestalten. Wenn es ans Mikro-Mikro-Interaktionsdesign geht, müssen Dinge auch einfach ausprobiert werden. Kein wissenschaftlicher aber pragmatischer Ansatz. Die einzelnen Parameter für die Gestensteuerung (Bewegungs-Thresholds[2], Hold-Timer[3], usw.) im Vorhinein festzulegen ist aber kaum möglich, denn hier spielt auch die Zielhardware eine entscheidende Rolle. Um solche Dinge im Team abzustimmen hilft meist kein Tool. Der beste Weg ist hier – ganz klassisch – sich zusammenzusetzen. Also trafen wir uns zu einem Workshop. Dabei konnten wir dann Konzeptdetails und deren technische Umsetzung besprechen: Was geht? Was geht nicht? Wie wird’s gemacht? Und was brauchen wir noch?

Testen für den Feinschliff

Im Fall der Parameter der Gestensteuerung einigten wir uns darauf, dass sie in einer Testanwendung zugänglich und einstellbar gemacht werden, sodass wir sie in einem weiteren Schritt auf verschiedener Hardware testen und einstellen konnten.

Auf dieser Grundlage konnten die Entwickler dann die Architektur der Umsetzung der Gestensteuerung festlegen. Das erwies sich als nicht einfach, denn Microsoft hatte nicht nur bei Visio herausfordernde Aufgaben eingebaut. Auch Windows Presentation Foundation (WPF) war, was die Verarbeitung von Gesten anging, nicht immer gutmütig. In dem vorhandenen Rahmen fanden die Entwickler aber eine Lösung, die es ermöglichte die angedachten Konzepte zu verwirklichen und auch den Umsetzungsaufwand in einem vertretbaren Rahmen zu halten. Dabei stellte sich auch die Hardware als Flaschenhals heraus. Es wurde viel ausprobiert und getestet (Paint funktioniert übrigens super mit Multitouch-Gesten), sodass letztendlich alles aus der aktuellen Generation an Industrie-PCs und Multitouch-Panels herausgeholt werden konnte.

Das Endergebnis kann sich sehen lassen. Zumindest wenn die Hardware mitspielt. Das Team dahinter kann sich aber immerhin sagen: wir haben gemeinsam gute Arbeit geleistet.

Fazit

Alle, die an der Entstehung eines Produktes beteiligt sind, haben Einfluss darauf. Und deshalb ist die Zusammenarbeit von allen Beteiligten auch so wichtig. Denn alle sind UX Designer. Eine gemeinsame Sprache innerhalb des Teams ist unerlässlich. Und bezogen auf die Schnittstelle zwischen Interaktionsdesign und Entwicklung eignen sich Statecharts hervorragend für die Kommunikation. Wenn man dies alles beherzigt ist man übrigens auch nicht weit davon entfernt, eine UX Kultur im Unternehmen aufzubauen, was ein lohnendes Thema für Fortgeschrittene ist.

Fußnoten

[1] Der Begriff „UX Designer“ soll eine Referenz zu der heutzutage häufig verwendeten Begriffskomposition aus „UX“ und „Designer“ sein, im Wissen, dass man die Wahrnehmungen und Reaktionen einer anderen Person, wie die User Experience in der DIN EN ISO 9241 definiert ist, nicht gestalten kann

[2] Grenzwert, bei dessen Erreichen eine Bewegung erkannt wird

[3] Zeit, ab der ein Gedrückthalten erkannt wird

Microsoft Visio, Microsoft, Windows Presentation Foundation und Paint sind Marken oder eingetragene Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
iPhone und iPad sind Marken oder eingetragene Marken der Apple Inc. in den USA und/oder anderen Ländern.

Möchten Sie mehr zu unseren Leistungen, Produkten oder zu unserem UX-Prozess erfahren?
Wir sind gespannt auf Ihre Anfrage.

Corporate Experience Manager
+49 681 959 3110

Bitte bestätigen Sie vor dem Versand Ihrer Anfrage über die obige Checkbox, dass wir Sie kontaktieren dürfen.