Steig in die Zeitmaschine, Sherman, und stelle das Jahr 1994 ein. Man wird mich in einem Konferenzraum finden, wo ich Entwicklern und Product Ownern (in jener Zeit nannten wir Product Owner entweder Produktmanager oder Business-Analysten) erklärte, wie wir das UX-Design ihres neuen Produkts in weniger als einer Woche entwickeln würden. Der Ausdruck auf ihren Gesichtern wird dann ungefähr aussagen: OMG! Der ist verrückt, Alter! (Wenngleich OMG und Alter noch lange Zeit nicht zum allgemeinen Sprachgebrauch gehören sollten.)
Jetzt sehen wir uns Papier-Prototypen an und denken: Wie romantisch. Doch damals im Jahr 1994 war das eine radikale Abkehr von der etablierten Praxis. In diesen alten Zeiten wurde es nicht so gemacht, wie wir es heute tun.
Stattdessen hatte jedes Projekt eine Phase der Anforderungsdefinition, in der der Product Owner jedes kleine Detail definierte, das im UX-Design umzusetzen ist. Entwickler hatten in diesem Prozess nicht viel zu sagen. Ihre einzige Waffe war die alte Dreieckslogik Funktionen, Preis, Zeit - Nimm zwei. Häufe eine Menge Features in den Anforderungen an und du musst mehr Geld zahlen, speziell wenn eine bestimmte Deadline eingehalten werden soll.
1994: Die unglaubliche Superkraft des Paper-Prototypings
Paper-Prototyping war radikal, weil es die Zukunft vorhersagte. Mit Papier-Prototypen konnten Sie demonstrieren, wie es sein würde, das UX-Design zu nutzen, das man zu umzusetzen gedachte.
Unser typisches Paper-Prototyping-Projekt würde eine Woche dauern. Am Montag und am Dienstag würden wir die Prototypen der beweglichen Teile entwickeln. Jede kleine Mitteilung und jeder Dialog würde auf einem kleinen Blatt Papier festgehalten. Wir wollen ein Pull-down-Menü? Ein weiteres Blatt Papier. Wir wollen, dass sich eine Systemmeldung ändert? Noch ein Blatt Papier.
Am Mittwoch und Donnerstag würden wir User bei uns zu Gast haben, die mit dem Schein-Computer aus Papier arbeiten. Sie würden den Finger als Maus nutzen, auf Objekte "klicken" und mit dem UX-Design interagieren. Die meisten würden an irgendeiner Stelle anhalten, erstaunt gucken und dann erklären, inwiefern das Design sie verwirrt hat. Wir würden zwischen den Sessions jeweils ein paar Stunden einplanen, in denen das Team Änderungen vornimmt, um Verwirrung zu eliminieren und den Fluss des UX-Designs zu optimieren.
Am Freitagmorgen hätten wir ein UX-Design, das mindestens ein Dutzend User getestet haben und aus dem die Hauptprobleme entfernt und durch einfachere, direktere Flows ersetzt worden sind. Den Rest des Tages würden wir damit verbringen, das Design zu dokumentieren (Gott sei dank für Fotokopierer!) und unsere aufregenden Learnings dem Führungsstab zu kommunizieren, der das Projekt ins Leben gerufen hat.
Wir schafften in fünf Tagen, was Teams zuvor mindestens sechs Wochen gekostet hätte, und das mit besseren Ergebnissen. Wir hatten das Design einem Dutzend oder mehr Iterationen unterzogen und tonnenweise Wissen darüber gesammelt, was funktionierte und was nicht.
Noch wichtiger: Wir hatten etwas gemacht. Wir hatten eine voll funktionsfähige Version des UX-Designs entwickelt. Das Design den Usern vorzulegen, zeigte uns, wie das Nutzererlebnis war, und lieferte Hinweise darauf, wie es sein könnte. Keine noch so umfangreiche Vorausplanung könnte so etwas liefern.
Etwas zu machen, änderte alles. Zum ersten Mal wurde UX-Design ernstgenommen.
2004: Eine neue Welt der Agilität
Spulen wir zehn Jahre vor. Entwickler, frustriert von überspezifizierten Projekten, waren bereit, die neue agile Methodik zu adaptieren.
Agile versprach bessere Software. Entwickler dachten, sie könnten es durch schnelles Iterieren besser machen, statt zu versuchen, das gesamte Projekt im Vorfeld zu planen. Und in vielen Fällen funktionierte es.
Funktionierende Software über Dokumentation, deklarierte das Agile Manifest. Durch das Experimentieren mit schnellen Iterationen konnten Entwickler sehen, wie die Software sich entfaltete.
Iterationen vs. springende Lachse
Diese schnellen Iterationen bedeuteten, dass das Team durch das Bauen der Anwendung lernen konnte, was diese brauchte. In vielerlei Hinsicht entsprach Agile dem, was wir mit den Papier-Prototypen gemacht hatten.
Bei beiden Ansätzen lernen Teams durch Iterationen. Beim Paper-Prototyping lernen sie, welches Nutzererlebnis das richtige ist. In der agilen Entwicklung lernen sie, welche Architektur und welcher Weg richtig sind, damit das Programm funktioniert.
Das war eine komplette Veränderung gegenüber dem, was zuvor passiert war. Im Entwicklungsprozess nach dem Wasserfallmodell erforderte jedes Lernen, dass man den Wasserfall wieder hoch springt – wie ein Lachs, der versucht, zu seinem Laichgrund zurückzukommen. Die Macht des Weitermachens war oft siegreich; sie unterband jede Veränderung, obwohl jeder wusste, dass es nicht funktionieren würde.
Eine Ausrichtung aufs Machen
Der Wasserfall war eine Ausrichtung aufs Planen. Wenn ein Projekt nicht gut lief, würde das Team versuchen, noch stärker zu spezifizieren. Sie kämen mit noch mehr Review-Checkpoints und noch mehr Arten von Dokumenten daher – alles, um es beim ersten Versuch richtig hinzubekommen.
Teams, die Papier-Prototypen und agile Entwicklungsmethoden anwenden, legen eine Ausrichtung aufs Machen an den Tag. Statt auf einen Plan zu warten, fangen sie an, etwas zu bauen. Sie wissen, dass das, was sie machen, wahrscheinlich nicht das Richtige ist, aber das hält sie nicht auf.
Eine Ausrichtung aufs Machen heißt nicht, dass Teams niemals planen. Doch Planungen gehen fließend aus dem gesamten Designprozess hervor. Der Unterschied ist der, dass sie sich weiterentwickeln, wenn sie aus dem Prozess des Machens lernen.
2014: Responsive Design drängt
Bevor es all diese Endgeräte und unterschiedlichen Bildschirmgrößen gab, war es einfach zu spezifizieren, wie das UX-Design aussehen sollte. Vor der neuen Welt der Oberflächen mit Gesten- und Berührungssteuerung war es einfach, eine kleine Sammlung von Interaktionsmustern zu nutzen, um alles zu erreichen, was wir brauchten.
Der Angriff neuer Technologien hat das alles verändert. Die Chancen sind sehr gering, dass ein im Vorfeld entwickeltes UX-Design so funktioniert, wie wir uns das gewünscht haben.
Responsive Design macht unverhohlen offensichtlich, dass es bei neuen UX-Designs nicht klappt, sie einfach zu bauen und sich dann aus dem Projekt zu verabschieden. Dies ist eine Zeit, in der Nutzererlebnisse Spitzenleistungen brauchen.
Nochmals: UX-Designer und Entwickler wenden sich schnellen Iterationen zu, um zu lernen, was sie entwickeln sollten. Sie haben eine Ausrichtung aufs Machen.
Indem sie schnelle Prototypen bauen und mit ihnen spielen, können sie lernen, wie das Nutzererlebnis sein muss. Sie lernen auch, die Architektur darunter zu verstehen. Ihre darauf folgende Planung ist davon geprägt, was sie gemacht haben.
Ein neues Zeitalter der Zusammenarbeit
Wir sind mit schlechter Zusammenarbeit zwischen Entwicklern und UX-Designern davongekommen, als Unternehmen noch akzeptiert haben, Produkte mit schlechten Nutzererlebnissen auszuliefern. Im Gegensatz zu früher nehmen unsere Nutzer und Kunden solche Ergebnisse heute nicht mehr hin.
UX-Designer und Entwickler müssen auf eine Weise zusammenarbeiten, die wir nie zuvor gekannt haben. Sie brauchen ein gemeinsames Verständnis von der Intention ihrer UX-Designs. Sie müssen lernen, wie der jeweils andere arbeitet. Sie müssen lernen, eine gemeinsame Sprache zu sprechen.
Entwickler müssen nicht nur sehen können, wie das UX-Design sein soll; sie müssen verstehen, warum es so sein soll. Sie müssen sehen, wie die UX-Designer zu ihren Entscheidungen kommen. Indem sie die Intention der Designer und die zugrundeliegenden Prinzipien verstehen, können sie helfen, schneller zu einem besseren UX-Design zu kommen.
Ebenso müssen die UX-Designer die zugrundeliegende Architektur des Systems verstehen. Sie müssen wissen, wie das Datenmodell funktioniert. Sie müssen wissen, wie dieses Modell ins System eingepasst wird. Und sie müssen die Programmbibliotheken kennen, mit denen die Entwickler arbeiten.
Die richtige Ausrichtung adaptieren
Bei einer Ausrichtung aufs Machen besteht der beste Weg zu lernen darin, etwas zu bauen und dann zu dekonstruieren, was man gemacht hat. Dadurch, dass sie sehen, was funktioniert und was fehlschlägt, kommen Designer-Entwickler-Teams zu einem gemeinsamen Verständnis davon, was sie einem besseren UX-Design näher bringt.
Aus dieser Zusammenarbeit entsteht die wirkliche Fähigkeit zu planen. Bewaffnet mit all dem Wissen, das durch die Erfahrung des Machens gefüttert wird, ist das Team nun besser darin, Ergebnisse zu planen.
Teams mit einer Ausrichtung aufs Machen produzieren am Ende bessere UX-Designs als jene Teams mit einer Ausrichtung aufs Planen. Sie sind besser darüber informiert, wie sie entwickeln und welche Möglichkeiten sie haben.
Wenn Sie das nächste Mal denken, ein UX-Design planen zu müssen, fragen Sie sich mal: "Ließe sich nicht besser planen, was wir lernen könnten, wenn wir einfach anfangen, etwas zu machen?" Die Antwort könnte Sie überraschen.
Dieser Artikel wurde im Original am 5. Februar 2014 unter dem Titel A Bias For Making
