Hier ist ein Vorschlag: Beginnen wir, die Begriffe Prototyp und Mockup für zwei unterschiedliche Dinge zu verwenden. Meiner Meinung nach beschreiben sie verschiedene Enden des Problems.
Ein Mockup zeigt uns eine mögliche Lösung. Es stellt die Frage: "Was denkst du über diese Richtung des Interaktionsdesigns?" Ob das Mockup eine Skizze oder ein komplett gerendertes Nutzererlebnis ist – wenn man es sich anschaut, sieht es so aus, als könnte die Idee dahinter eine gute Lösung sein.
Prototypen sind anders als Mockups. Sie fokussieren sich nicht auf die Lösung, sondern auf das Verständnis des Problems. Sie stellen die Frage: "Was passiert, wenn wir das hier versuchen?" Vielleicht lernen wir, dass es die richtige Idee ist, aber es ist wahrscheinlicher, dass wir etwas über das Problem erfahren, was wir zuvor nicht wussten.
Tolle Interaktionsdesigner fokussieren sich vor der Lösung auf das Problem
Im Rahmen unserer Untersuchungen dahingehend, was großartige von guten Interaktionsdesignern unterscheidet, haben wir gesehen, dass erstere weitaus mehr Zeit damit verbringen, das Problem zu verstehen. Sie dringen wirklich in die Tiefe vor und konzentrieren sich dabei auf alle Aspekte im Hinblick auf die mögliche Nutzung des Designs und die Einschränkungen und Komplikationen.
Beim Interaktionsdesign dreht sich alles um Kompromisse. Zu lernen, welche Auswirkungen jeder Kompromiss hat, ist das Herzstück.
Eine Sache, die wir bei den besten Interaktionsdesignern gesehen haben, ist die Arbeit mit Prototypen, um das Problem auszukundschaften. Der Prototyp ist das Instrument, das sie nutzen, um zuvor verborgene Einschränkungen aufzudecken und nachzusehen, welche Folgen diese für das Design haben.
Vier Phasen: Planung, Implementierung, Einschätzung, Lernen
Gute Prototypen sind in schnelle Iterationen mit vier Phasen eingebettet. Phase eins der Iteration ist die Planungsphase, in der der Interaktionsdesigner darüber nachdenkt, was er über das Problem lernen will und wie er die Sache in Angriff nehmen könnte. Diese Phase ist kurz (und dauert in manchen Fällen keine fünf Minuten), denn es geht hier wirklich nur darum, die Iteration zu planen.
Dann kommt die zweite Phase – die Implementierung. Hier geht es darum, den Prototypen zu bauen. Dabei kann es sich um eine schnelle Skizze handeln oder auch um HTML-Code, der aussieht und sich anfühlt wie eine funktionierende Anwendung. Im Kern geht es um etwas, aus dem das Team etwas lernen kann.
Was uns zur dritten Phase bringt – der Einschätzung. Hier sammelt das Team nützliche Informationen aus dem Prototypen. Das können quantitative (Können die Server die Belastung handhaben, wenn alle gleichzeitig eine Anfrage stellen?) oder eher qualitative Informationen sein (In welcher Form wird dieser Workflow der Buchhaltung Probleme bereiten, speziell am Quartalsende, wenn alle versuchen, ihre Bestellungen ins System zu kriegen?). Unabhängig von der quantitativen oder qualitativen Natur sammelt das Team Informationen, die bei künftigen Entscheidungen leiten sollen.
Die letzte Phase ist die des Lernens. Das Team geht einen Schritt zurück und fragt: "Was haben wir aus diesem Prototypen gelernt?" Hier besprechen sie, wie die neuen Informationen in eine Richtung führen können, die das Interaktionsdesign voranbringt. Auch diese Phase kann sehr kurz sein, aber sie ist zu wichtig, um sie wegzulassen.
Genauso viel Zeit für die Einschätzung wie für die Implementierung
Viele gute Interaktionsdesigner bauen Prototypen. Doch die großartigen durchlaufen alle vier Stadien und verbringen genauso viel Zeit mit der Einschätzung wie mit der Implementierung. Sie haben Klarheit darüber, was sie gelernt haben.
Ein Team hatte an der Automatisierung des papierbasierten Berichtswesens kritischer Vorfälle bei klinischen Medikamententests gearbeitet. Sie erstellten eine Karte mit den administrativen Abteilungen im Gebäude, legten dann darüber, welchen Weg die gedruckten Berichte über kritische Vorfälle durchs Gebäude nehmen, wer sie anfasst und was mit ihnen passiert, ehe sie zur nächsten Person weitergereicht werden. Die Karte zeigte schließlich, dass jeder Bericht im Durchschnitt auf den Tischen von 17 Leuten landete. 14 davon fertigten eine Kopie für den eigenen Aktenschrank an, ehe sie den Bericht an die nächste Person weitergaben.
Die Analyse der Karte war so wichtig wie die Erstellung selbst. Aus ihr ging hervor, welche Arbeiten jede Person mit dem Bericht zu erledigen hatte und wie die darin enthaltenen Daten zu lesen sind. Interviews mit 17 verschiedenen Personen zeigten, dass es bei der Arbeit eine Menge Überlappungen gab, weil sie nicht wussten, was andere Leute zu tun hatten, um den Bericht weitergeben zu können.
Bei unseren Untersuchungen haben wir gesehen, dass Teams, die keine Zeit mit der Einschätzung verbringen, in Schwierigkeiten geraten, wenn sie den Mehrwert beschreiben sollen, den der Prototyping-Prozess ihnen gebracht hat. Teams, die Zeit in diese Phase investieren, können dagegen leicht erklären, was den Prototypen wertvoll macht und welche Auswirkungen er auf künftige Entscheidungen haben wird.
Die drei Dimensionen des Problemraums
Technologie, Geschäft und die Nutzer sind die drei Dimensionen des Problemraums eines Interaktionsdesigns. Während gute Interaktionsdesigner sich bei ihren Prototypen häufig vor allem auf die Technologie fokussieren und fragen, ob eine bestimmte Implementierung eine praktikable Lösung sein könnte, weiten großartige Vertreter ihrer Zunft die Nutzung von Prototypen auf die anderen Dimensionen aus.
Ein Team, das das Zulassungssystem einer Universität überarbeitete, sah sich genau an, welche Möglichkeiten es gab, den Bewerbungsprozess mit den Systemen für finanzielle Unterstützungsprogramme und Studentendarlehen zu verzahnen. Sie mussten die Potenziale und Grenzen sowohl der vorhandenen Schnittstellen ausloten (was ein technologischer Aspekt war) als auch die Prozesse der Abteilung für finanzielle Unterstützung untersuchen (der Business-Aspekt).
Sie erstellten eine Reihe von Diagrammen, die die aktuellen Workflows der Finanzabteilung widerspiegelten, und nutzten diese, um diejenigen Stellen zu finden, an denen ein automatisiertes System die Abläufe verbessern könnte. Anschließend entwickelte das Team Prototypen aus funktionierendem Code (aber ohne viel Benutzeroberfläche), um die Schnittstellen zu testen und zu sehen, ob die Anpassungen machbar wären.
Anders als ein Mockup, muss ein Prototyp rein gar nicht nach einem finalen Interaktionsdesign aussehen. Das Look and Feel ist egal, solange der Prototyp hilfreich bei der Erkundung des Problems ist.
Die Designs, mit denen die Nutzer heutzutage interagieren, sind perfekte Prototypen, um die Bedürfnisse der User zu erkunden. Indem sie sich den Nutzungskontext genau anschauen, können Teams lernen, welche Entscheidungen vor ihnen liegen. Fasst man in Szenarien zusammen, wie die Nutzer mit den heutigen Interaktionsdesigns arbeiten, entstehen daraus oft zahlreiche Ideen, wie man dem User mit einem anderen Ansatz das Leben leichter machen könnte.
Ein gemeinsames Verständnis des Problemraums
Weil Interaktionsdesign heute ein Teamsport ist, ist es wichtig, dass das gesamte Team das Problem versteht. Die besten Designer erstellen Prototypen nicht nur für sich selbst, sondern damit das gesamte Team etwas aus ihnen lernen kann.
Die Implementierung eines Prototypen, ob nun als Skizze, Workflow-Diagramm oder Code, zeigt klar auf, was da eingeschätzt wird. Die Konzeption eines Prototypen ist ein wichtiger Teil des Prototyping-Prozesses.
Hier spielen die Phasen der Planung und des Lernens eine wichtige Rolle. Das Team kann sich um den Prototypen herum versammeln und all die wichtigen Dinge katalogisieren, die es gelernt hat. Sie können die neuen Fragen zusammentragen, die aufgekommen sind (und es gibt immer neue Fragen, wenn der Prototyp seinen Zweck erfüllt). Sie können brainstormen, wie zukünftige Prototypen womöglich aussehen, die Antworten auf diese Fragen bieten.
Letztlich läuft alles auf die Entwicklung tolle Interaktionsdesigns hinaus. Toll sind sie, wenn sie die beste Schnittmenge zwischen Nutzer-, technologischer und geschäftlicher Dimension finden. Das ist nur möglich, wenn das Team die Landschaft des Problemraums wirklich versteht. Und Prototypen sind effektive Werkzeuge, um diese Landschaft zu erkunden.
Dieser Artikel wurde im Original am 20. September 2012 unter dem Titel Exploring the Problem Space Through Prototyping
