Ein UX Designer redet mit den Leuten, die täglich damit arbeiten, bevor irgendetwas gezeichnet wird.

UX Designer steht auf unserer Teamseite in der Disziplin Design und Research, neben UI Designer, UX Researcher und UX Copywriter. Gefragt werden wir nach der Rolle meistens dann, wenn eine Anwendung fertig ist und niemand sie gern benutzt. Die Vermutung lautet in diesem Moment fast immer, es fehle etwas am Aussehen. Meistens fehlt etwas am Ablauf und der Ablauf wird nicht gezeichnet, sondern entschieden, bevor jemand zeichnet. Wir erklären, was die Rolle tut, worin sie sich vom UI Designer unterscheidet, was Research konkret heisst und warum das Weglassen dieses Teils die Ersparnis ist, die in einem Projekt am meisten kostet.

Ein UX Designer entscheidet den Ablauf, ein UI Designer die Oberfläche.

Die Abgrenzung ist einfacher, als die beiden Begriffe vermuten lassen. UX ist die Frage, in welcher Reihenfolge jemand was tut, was das System dabei schon weiss und was es nachfragen muss. UI ist die Frage, wie das Ergebnis aussieht: Raster, Schrift, Farbe, Abstände, die Zustände einer Schaltfläche.

Ein Beispiel aus einer Auftragserfassung. Der UX Teil ist der Entscheid, dass die Adresse aus dem Kundenstamm kommt und nicht abgetippt wird, dass ein Auftrag auch ohne Ansprechpartner gespeichert werden darf und die Rückfrage später kommt und dass der Monteur auf dem Handy drei Felder sieht statt vierzig. Der UI Teil ist, dass diese drei Felder auf einem Baustellenhandy bei Sonne lesbar sind. Beides braucht es. Wer nur das zweite bestellt, bekommt eine saubere Maske für einen Ablauf, den so niemand arbeitet.

In einem kleinen Projekt macht dieselbe Person beides und das ist in Ordnung. Nicht in Ordnung ist, wenn nur die Oberfläche bestellt wird, weil sie der Teil ist, den man auf einer Offerte sieht und in einer Sitzung zeigen kann.

Research heisst zuschauen, wie die Arbeit heute wirklich läuft.

Research klingt nach Studie, Labor und einem Bericht, den niemand liest. In einem KMU Projekt ist es etwas Unspektakuläres: fünf bis acht Gespräche von je einer Stunde mit den Leuten, die den Ablauf täglich machen und wo es möglich ist eine halbe Stunde danebensitzen und zuschauen.

Das Zuschauen bringt mehr als das Fragen, weil die Antwort auf die Frage, wie ihr das macht, den offiziellen Ablauf beschreibt und das Zuschauen den echten zeigt. Dazwischen liegt in fast jedem Betrieb eine Excel Datei, die im Gespräch niemand erwähnt hat, ein Ordner mit abfotografierten Rapporten oder eine Person, die alle anrufen, wenn etwas unklar ist. Genau diese drei Dinge entscheiden später, ob eine Anwendung benutzt wird.

Fünf bis acht Gespräche klingen nach wenig. Sie reichen, weil sich die Muster früh wiederholen: Ab dem vierten oder fünften Gespräch hört man vor allem Dinge, die man schon gehört hat. Wer stattdessen dreissig Leute befragt, bekommt keine besseren Erkenntnisse, sondern ein Dokument und zwei Wochen Verzug.

Abgeliefert wird ein entschiedener Ablauf, nicht eine Zeichnung.

Am Ende dieses Teils steht selten ein Design und immer ein Entscheid. Brauchbar ist das Ergebnis, wenn es aus drei Dingen besteht: den Aufgaben, die das System unterstützen muss, in der Reihenfolge ihrer Häufigkeit; dem Ablauf für die zwei oder drei häufigsten davon, so grob gezeichnet, dass man ihn noch gern ändert; und der Liste der seltenen Fälle, die trotzdem funktionieren müssen, weil sonst für jeden von ihnen eine Excel Datei entsteht.

Getestet wird das mit denselben Leuten, mit denen gesprochen wurde, an einem Klickmodell, das nichts kann ausser klicken. Eine Stunde pro Person, fünf Personen und man weiss, ob der Ablauf trägt. Diese fünf Stunden sind der Unterschied zwischen einer Annahme und einer Information und sie fallen an, solange eine Änderung nichts kostet.

Wer im Projekt dafür sorgt, dass diese Entscheide tatsächlich getroffen werden, ist nicht der Designer. Das ist die Aufgabe der Rolle, die dafür sorgt, dass Entscheide fallen und nicht dass alle zufrieden sind. Ein Ablauf, den niemand freigibt, ist ein Vorschlag und Vorschläge werden in der Umsetzung überstimmt.

Der Ablauf ist ein Architekturentscheid, auch wenn er nach Design aussieht.

Wer festlegt, dass ein Auftrag ohne Ansprechpartner gespeichert werden darf, hat das Datenmodell mitentschieden. Wer festlegt, dass der Monteur offline arbeitet und später abgleicht, hat die halbe Systemarchitektur bestellt. Deshalb gehört die Rolle an denselben Tisch wie die, die die Entscheide trifft, die man später nicht mehr billig ändern kann. Passiert das nicht, wird der Ablauf zweimal entschieden: einmal im Entwurf und einmal in der Umsetzung, wenn auffällt, dass er so nicht gebaut werden kann.

Dasselbe gilt beim Kaufen. Mit einer Standardlösung übernimmt man den Ablauf des Anbieters und das ist ein guter Handel, solange der Betrieb ohnehin so arbeitet. Eigene Software rechnet sich erst, wenn der Unterschied das Geschäft betrifft und ob er es betrifft, sieht man erst, wenn der echte Ablauf beschrieben ist. Research ist deshalb beim Kaufen genauso nützlich wie beim Bauen: Sie liefert die Grundlage für den Entscheid, welche Abweichung vom Standard man den Leuten zumutet und welche nicht.

Das Weglassen dieses Teils ist die Ersparnis, die am meisten kostet.

Der Posten ist überschaubar. Gespräche, Ablauf und ein getestetes Klickmodell sind in einem KMU Projekt drei bis fünf Tage, bei einem Vorhaben zwischen CHF 10'000 und CHF 30'000 also rund zehn Prozent des Budgets. Gestrichen wird er trotzdem oft als Erstes, weil er nichts hervorbringt, das man vorzeigen kann und weil alle im Raum überzeugt sind, den Ablauf zu kennen.

Der teure Fall ist dabei nicht der, in dem die Anwendung falsch ist und umgebaut wird. Umbauen kostet zwei bis vier Wochen, es ist unangenehm und irgendwann fertig. Der teure Fall ist der, in dem alles bleibt, wie es ist und die Leute daneben weiterarbeiten: mit einer Excel Datei für den Fall, den das System nicht kennt, mit einem Anruf statt einem Eintrag, mit einer Person, die abends nachträgt, was tagsüber nicht erfasst wurde.

Diese Kosten stehen in keiner Rechnung und deshalb werden sie nie verglichen. Sie fallen jeden Tag an, bei jeder Person. Zehn Minuten pro Person und Tag sind bei fünfzehn Leuten über ein Jahr mehr als fünfhundert Stunden und niemand kann sagen, wo sie geblieben sind. Dagegen sind fünf Tage am Anfang billig. Ich sage das auch dort, wo es gegen uns spricht: Wenn dieser Teil im Budget nicht drin ist, ist die Anwendung nicht günstiger geworden, sondern das Risiko ist von der Offerte in den Betrieb gewandert.

Für ein KMU sind das drei bis fünf Tage und sie fallen vor der ersten Zeile Code an.

Nicht jedes Vorhaben braucht die Rolle. Wer ein Standardprodukt einführt, das im Betrieb ohnehin so genutzt wird wie in tausend anderen Firmen, kommt ohne aus. Gebraucht wird sie in drei Fällen: Es wird eigene Software gebaut. Eine Standardlösung greift tief in bestehende Abläufe ein. Oder es gibt einen Ablauf, den heute niemand vollständig beschreiben kann, weil er in Köpfen und in Excel Dateien liegt.

Danach ist der Aufwand klein: ein halber Tag pro Monat, solange gebaut wird, damit die Entscheide beim ersten Widerstand nicht still zurückgenommen werden. Eine eigene Stelle wird die Rolle erst, wenn ein Unternehmen laufend an eigenen Anwendungen arbeitet. Vorher ist es ein Auftrag.

Bei uay gehört UX Designer zur Disziplin Design und Research, neben UI Designer, UX Researcher und UX Copywriter. Bei jedem Problem schauen wir zuerst, welche Rollen es braucht. Bei einer eigenen Anwendung und bei jeder Software, die in einen bestehenden Ablauf eingreift, ist diese fast immer dabei. Sie muss nicht bei uns liegen: Wenn der Entwicklungspartner mit den Leuten redet, bevor gezeichnet wird und den Ablauf freigeben lässt, ist das der einfachere Weg. Wenn niemand zuständig ist, übernehmen wir es, mit Aufwand und Preis in der Offerte und bleiben gegenüber dem Kunden verantwortlich.