"Schließlich haben wir aufgehört, unsere Entwürfe zu zeigen, indem wir sie von einem Desktop-Rechner aus an die Wand projizieren." So hat Ethan Marcotte den Prozess hinter einem der ersten großen Responsive-Design-Projekte beschrieben, der neuen Website des Boston Globe. "Stattdessen haben wir eine große Tasche voll mit Endgeräten mitgebracht und jeden unsere Ideen in die Hand nehmen lassen."
Dadurch, dass die Design-Entwürfe auf diversen Geräten verfügbar waren, konnten Ethan und die anderen von der Filament Group ihrem Kunden vom Boston Globe zeigen, wie das Nutzererlebnis über die verschiedenen Endgeräte hinweg sein würde. "Keine zwei Leute im Raum hatten dasselbe Nutzererlebnis."
Diese wiederholte Demonstration half Ethan und seinem Team, die Wichtigkeit, diverse Geräte zu unterstützen, ein für allemal klarzumachen. Dafür hatten sie nicht jede Menge Technologie bauen müssen.
Stattdessen erstellten sie einige schnelle Skizzen von ihren Vorstellungen davon, wie die neue Website funktionieren sollte. Das Team vom Globe konnte ihnen konstruktives Feedback geben und interessante Fragen stellen. Sie konnten das UX-Design über die verschiedenen Endgeräte hinweg vergleichen, von Blackberrys bis hin zu Feature-Phones. Sie konnten aus erster Hand sehen, wie die Nutzererlebnisse sein würden.
Ein wesentlicher Bestandteil des plattformübergreifenden Designs
Unsere UX-Designs fließen und sind in Bewegung. Mit einer statischen Skizze ist es schwierig, die Feinheiten und Nuancen des Designs auszudrücken, die uns vorschweben. Mikrointeraktionen sind essenziell für ein gutes Nutzererlebnis, aber man kann sie sich nur schwer vorzustellen, wenn man einfach auf eine Zeichnung schaut.
Erschwerend kommt hinzu, dass wir ausdrücken wollen, wie sich das UX-Design ändert, wenn wir uns über die Plattformen hinweg bewegen. Wir müssen sehen können, ob wir etwas zu kompliziert gemacht haben. Vielleicht haben wir etwas Wichtiges weggelassen? Vielleicht ist etwas zu klobig, wenn man keine Tastatur hat?
Das gesamte UX-Design zu bauen, um eine wichtige Schwachstelle aufzudecken, ist ein zeitraubender und teurer Prozess. Wir wollen unsere Ideen nach außen tragen, um sie zu bewerten und zu reflektieren. Wie können wir das einfach und kosteneffektiv tun?
Beispiel: Interaktive Sitemap
Bei ihrem jüngsten UX-Thursday-Vortrag hat Melinda Baker von der American Cancer Society über die Neuorganisation der Fachinhalte auf einer Non-Profit-Website gesprochen. Nachdem einige Versuche, dies den Stakeholdern der Organisation zu erklären, gescheitert waren, führte sie eine interaktive Sitemap vor, die ihr Team zusammengeschustert hatte. Rasch waren alle auf derselben Seite dahingehend, wie sich das Team die Content-Organisation vorstellte.
In der Vergangenheit hätte eine statische Sitemap auf Papier ausgereicht. Allerdings ist auf einer statischen Sitemap die gesamte Hierarchie immer sichtbar. Es ist nicht einfach festzustellen, wo Bezeichnungen außerhalb des Kontextes dessen, was sich hinter ihnen verbirgt, nicht sinnvoll sein würden.
Durch den Einsatz einfacher Coding-Techniken entwickelte Melindas Team eine Sitemap, die aus- und eingeklappt werden konnte. Melinda konnte die komplette Hierarchie zeigen, sich auf nur ein Top-Level beschränken oder einen Pfad darstellen, den ein Nutzer wahrscheinlich nehmen würde.
Die Stakeholder konnten mit der Sitemap spielen und sehen, was sich natürlich und was sich gezwungen anfühlte. Aus dieser Interaktion heraus erhielt das Team viel reicherhaltiges Feedback und kam schnell zu einer Informationsarchitektur, die für alle einleuchtend war.
UX-Design durch die Augen der Stakeholder sehen
Beim Boston-Globe-Projekt war es für Ethan und seine Filament Group kein Problem, ein bisschen Code zusammenzuwürfeln. Sie glaubten, etwas machen zu können, das vortäuschte, auf diversen Endgeräten zu funktionieren. Sie konnten den Globe-Stakeholdern und -Führungskräften zeigen, wie ein plattformübergreifendes UX-Design sein könnte.
Dann bekamen Ethan und das Team das Design durch die Augen der Globe-Manager zu Gesicht. Es war einfach zu sehen, was über alle Geräte hinweg funktionierte und was noch verbessert werden musste.
Dieses Feedback frühzeitig im Projekt zu erhalten, gab den UX-Designern eine enorme Flexibilität. Sie konnten gewaltige Richtungswechsel vollziehen. Sie konnten mit einer Vielzahl von Ansätzen experimentieren. Jedes Mal bekamen sie mehr Feedback und lernten mehr darüber, wie das Design sein wollte.
So funktioniert eine Skizze. Eine Code-Skizze ist nichts anderes als eine statische Skizze auf einer Serviette oder einem Whiteboard, außer dass sie diese interaktiven Elemente zeigt. Sie stattet das Team mit einem Weg aus, konstruktive und positive Rückmeldungen von den Kunden und Stakeholdern zu sammeln.
Beispiel: Die Mikrointeraktion der Aktualisierung
Zu einem UX-Design für eine Mikrointeraktion wie die Aktualisierung einer App zu kommen, ist wirklich knifflig. Es ist schwer, es richtig hinzukriegen.
Es gibt immer tonnenweise Fragen: Was ist der beste Weg, den Nutzer auf das Vorhandensein der Funktion hinzuweisen? Wie weit muss der User sie runterziehen? Wie schnell schnappt sie zurück? Gibt es ein rotierendes Rad während des Aktualisierungsprozesses? Ist er asynchron oder muss der Nutzer warten, bis er beendet ist? Was macht die App, wenn es einen Fehler bei der Kommunikation mit dem Server gibt? Gibt sie einen Dialog aus, den der User bestätigen muss? Oder eine Meldung, die nur einen Moment lang erscheint? Wie lang ist lange genug für diese Meldung?
All diese Fragen können nicht einfach mit einer statischen Skizze beantwortet werden. Aber man kann kleine Simulatoren bauen, um ins Herz der einzelnen Fragen vorzudringen. Hinter den Kulissen tut eine interaktive Skizze gar nichts. Es gibt keine echte Aktualisierung. Es gibt keine Kommunikation mit einem Server, die plötzlich abreißen kann.
Doch dem Nutzer gibt man die Illusion, dass all diese Dinge passieren. Und deshalb bekommt man zu sehen, ob das UX-Design funktionieren wird. Es entstehen vielleicht sogar Inspirationen, etwas anderes auszuprobieren, um alternative Ansätze zu erkunden.
Und hier entstehen die wirklichen Einsichten und Innovationen. Wer das Erstellen von Code-Skizzen beherrscht, kann diese Ideen austesten.
Die Angst vor Code überwinden
Man sieht häufig, wie ein UX-Designer einen Stift nimmt und eine Idee ausskizziert. Das gehört seit einer Weile zu den Kernkompetenzen der UX-Designer. Viele tragen Notizbücher mit sich herum, die mit ihren Ideen und Variationen der Möglichkeiten gefüllt sind.
Aber es gibt keinen schnelleren Weg, ein paar UX-Designer einzufrieren, als sie zu fragen, ob sie nicht ein bisschen programmieren lernen wollen, um ihre Ideen auszudrücken. Dabei ist es ziemlich einfach, die Programmierfähigkeiten für eine simple Benutzeroberfläche zu erwerben.
Zumeist dauert das nicht länger als zwölf Stunden. Es ist eine Kombination aus grundlegendem HTML, CSS, JavaScript und jQuery. (Auf unseren Konferenzen lehren wir JavaScript- und jQuery-Stückchen in weniger als sechs Stunden.)
Wir brauchen kein Tiefenstudium. Wir brauchen genug, um hässlichen, aber funktionierenden Code zu produzieren.
Vielleicht kommt daher die Angst? Dass die UX-Designer fürchten, sie würden nach der Qualität ihres Codes beurteilt? Doch genau dieselben Designer haben keine Bedenken, was den artistischen Stil ihrer Servietten- oder Whiteboard-Skizzen betrifft.
Skizzen müssen die Idee kommunizieren, ob auf Papier oder als Code. Das ist alles.
Übung macht den Meister
Jeder, der anfängt, Code zu schreiben, fühlt sich erstmal unwohl. Aber das vergeht mit der Übung. (Genau dieselben UX-Designer haben sich wahrscheinlich zunächst unwohl beim Skizzieren auf Papier gefühlt, aber Jahre der Übung haben dieses Unbehagen weggeschliffen.)
Übung ist anders als Projektarbeit. Wenn wir üben, fokussieren wir uns auf den Prozess, nicht auf die Ergebnisse.
Um Code-Skizzen zu üben, müssen wir damit anfangen, die grundlegenden Programmiertechniken zu beherrschen. Mit anderen Wegen ankommen, um Ideen auszudrücken. Den Quellcode von Kollegen anschauen und sehen, was sie anders machen. Ständig versuchen, die Fähigkeiten zu erweitern.
Übung kann effektiver sein, wenn wir zusammen mit anderen üben. Wir können sehen, wie sie dieselbe Idee angehen, aber unterschiedliche Ansätze verfolgen. Wenn wir festhängen, können sie uns unterstützen. Wenn sie festhängen, hilft uns unsere Unterstützung, die zugrunde liegenden Konzepte besser zu verstehen. (Man lernt etwas nicht wirklich gut, ehe man nicht andere darin gelehrt hat.)
Das Bauen von Code-Skizzen ist kein angeborenes Talent, nichts, in dem nur einige Wenige jemals effektiv werden. Es ist eine einfache Fähigkeit, die Übung erfordert, um sie zu beherrschen.
Wenn die Basistechniken erstmal sitzen, haben Sie ein weiteres Werkzeug in der Kiste, um Ideen zu teilen. Und Ideen auszudrücken, um auf sie zurückzublicken, ist der beste Weg zu wunderbaren UX-Designs.
Dieser Artikel wurde im Original am 5. März 2014 unter dem Titel Code Sketching - A Stretch Goal for Your Design Superpower
