Frontend-Prototyping für eine bessere Usability

Den Begriff „Rapid-Prototyping“ kennen Sie vielleicht aus der Industrie oder der Software-Entwicklung. Je schneller die Zeit tickt, desto rapider müssen Prototypen erstellt werden – egal, in welchem Bereich. Seien es 3-D-gedruckte Formen oder Oberflächen, die bedient werden wollen. Gerade mobile Apps und Web-Applikationen sollen für Nutzer intuitiv, selbsterklärend und übersichtlich sein. Was speziell mobile Apps mit einfachen Oberflächen vormachen, weil sie sich auf eine Aufgabe konzentrieren, wird auch für Web-Applikationen, Webseiten und alle erdenklichen Oberflächen beliebter. Denn die Aufmerksamkeitsspanne des Menschen ist und bleibt begrenzt – die Interaktionen mit Geräten werden immer kürzer, Geräte kleiner, die Welt lauter und voller. 

Häufig wurde ein „Prototyp“ mit einem Machbarkeitstest verglichen. Die Technik sollte etwas implementieren, damit die Idee überhaupt eine Form bekommt, benutzbar (usable) wird. Doch Programmierung ist teuer und gar nicht der einzige Weg, um etwas Essenzielles herauszufinden. Das Frontend-Prototyping ist eine wunderbare, günstigere Alternative, um eine Idee zu testen und anzufühlen, bevor die kostspielige Schleife der Programmierung beginnt. Es gibt noch andere Vorteile.

Frontend-Prototyping – machen Sie anfühlbar, worüber alle anderen reden 

Zuallererst ist ein Frontend-Prototyp eine sichtbare Motivation für alle Beteiligten im Team. Für den Kunden, für Sie, für die Entwickler und für das Marketing. Alle Seiten können schon etwas anklicken, bekommen Gefühl für das Produkt und ein Bild davon. Genau darum geht’s. Der Prototyp ist die erste Version Ihres Produkts – sei sie auch noch so einfach und flach. Ab da haben Sie das Produkt anfassbar – nicht nur im Kopf – und müssen es „nur“ noch verbessern. 

Der Prototyp kann Ihr Tool für Nutzertests sein. Sie testen mit dem klickbaren, schlicht gestalteten Prototyp den Navigationsfluss, die Verständlichkeit und den Kontext (das ist ein Button, aha, darauf steht „Bestellen“, okay) und ob der Use-Case der Applikation gut herausgearbeitet wurde. Sie testen das Konzept. Die Optik verfeinern Sie später, viel später. Tipp: Trotzdem sollte der Prototyp nicht ranzig, liederlich oder hingerotzt aussehen. Da haben die vorgestellten Tools unterschiedliche Herangehensweisen. Manche brauchen die Anbindung an ein Grafik-Programm (und somit Kenntnisse desselben), andere nicht.

Noch ein Vorteil: Mit einem Prototyp müssen Sie Ihren Programmierern oder dem Dev-Team nicht mehr so viel erklären. Ihr Team kann ihn anklicken und wird gut verstehen, was sich hinter der Applikation und jedem einzelnen Screen verbirgt. Der Prototyp ist wie das zum Leben erwachte Pflichtenheft. So wie der Nutzer sich in seinen Erwartungen an gute Software entwickelt hat, haben sich auch die Methoden zur Software-Entwicklung verändert. „Agil“ (lat: flink, beweglich) ist hier das schon leicht abgegriffene Zauberwort. Gültig ist es trotzdem, und was könnte Agilität besser verkörpern als ein Prototyp im Test und der Entwicklung.

Agil und lean – ein Prototyp erfüllt mehrere Aufgaben in mehreren Bereichen

Er macht eine Applikation realistisch und für das gesamte Team sowie den Kunden benutzbar. Somit dient er als konkrete Diskussionsgrundlage und verlässt das Feld der Annahmen, Idee-Bubbles und idealisierter Wunschvorstellungen.

Ein Prototyp gibt außerdem ein Ausmaß für das Projekt an. Häufig wird Komplexität unterschätzt und gern in Dokumenten von einem Absatz zum anderen verschoben. Ein ernst gemeinter Prototyp ist eine Ernüchterung und eine Chance zugleich. Der Übergang von der ungreifbaren, erhobenen, virtuellen Idee zur handfesten Form ist immer mit Entscheidungen, mit Begrenzung und Reduktion verbunden. Und gleichzeitig rufen Begrenzungen und Reduktion Kreativität hervor. Die Hauptfrage ist: „Wie können wir es dem Nutzer noch einfacher machen?“ Die Lösung gibt den Weg vor – nicht die im Team propagierte Machbarkeit, die möglicherweise auf gewohnten Lösungen basiert. Wie soll etwas Neues entwickelt werden, wenn wir es uns einfacher machen statt dem Nutzer? 

Ist ein Prototyp ansehnlich und liebevoll angelegt, so können mit ihm User-Tests durchgeführt werden. Damit wird die Idee für andere Menschen – zum Beispiel die konkrete Zielgruppe – erfahrbar. Hier kann Risiko minimiert werden, indem ein Konzept geprüft wird, während es in der Entwicklung steckt. Willkommen in der Welt von lean. Schlank denken, noch schlanker ausdrücken und dann noch mal verschlanken auf das Wesentliche. Der Schöpfer des „Kleinen Prinzen“, Saint-Exupéry, meinte: „Perfektion ist, wenn man nichts mehr weglassen kann.“ In Alltagssprech auch: „Weniger ist mehr.“ Nirgends merkt man das so intensiv wie bei der Entwicklung eines eigenen Prototyps. 

Schließlich – oder ganz zu Beginn – kann ein Prototyp für die Argumentation gegenüber Chefs, Geldgebern, Marketing und Akquise genutzt werden. Mithilfe des Prototyps wachsen die Chancen, diese unterschiedlichen Positionen unter einen Hut zu bekommen. Wenn es mehr braucht: Machen Sie Nutzertests und konfrontieren Sie das Entwicklungsteam mit konkreten Ergebnissen. 

Prototypen-Arten

Wenn Sie einen Prototyp entwickeln wollen, sollten Sie zunächst überlegen, zu welchem Zweck Sie ihn brauchen und wem sie ihn zeigen wollen. Ein Prototyp für den technischen Leiter, das Dev-Team, die Marketing-Abteilung oder Test-Kunden hat unterschiedliche Ausprägungen. Hinterfragen Sie davor, wie viel digitales Vorstellungsvermögen die jeweilige Gruppe hat. Beispiel: Für das Dev-Team reicht möglicherweise vornehmlich die Abbildung der Screenabfolge, weil das Team daran interessiert ist zu verstehen, was im Hintergrund passiert. Für Test-Kunden hingegen könnte lediglich interessant sein, welcher Inhalt ihnen im Frontend angezeigt wird. Je flacher ein Prototyp, desto einfacher das Tool dazu und desto mehr Vorstellungsvermögen wird bei den Testern gebraucht. 

Essenzen für das Frontend-Prototyping

Ein gelungenes Interface ist in erster Linie eine Frage der Anordnung und Klarheit. Eine angeordnete und leicht nachvollziehbare Oberfläche ist einfach angenehm. Überblicken zu können, heißt Kontrolle zu behalten. Der Nutzer wünscht sich, Kontrolle über die Website oder Applikation zu haben – Rätselraten raubt mentale Energie und als Schöpfer eines Frontends wissen Sie nie, wie viel Ausdauer jemand mitbringt. Deshalb sollte ein massentaugliches Frontend für diejenigen funktionieren, die am wenigsten bereit sind, Energie aufzubringen, um etwas herauszufinden. Wenn sie diese Menschen in Ihren Tests ernst nehmen und nicht als Störenfriede wahrnehmen, dann können Sie und Ihr digitales Produkt unglaublich davon profitieren. Eine Oberfläche steht zu Diensten und vermittelt dem Nutzer das durch absolute Unkompliziertheit. 

Der Fokus der meisten Applikationen, am besten zu sehen bei mobilen Apps, liegt auf Interaktion, also auf Aktion, nicht auf Information. Ausgenommen sind davon natürlich E-Book-Apps, Newsreader oder ähnliche. Mit der Aktion des Nutzers wird ein klares Ziel verfolgt: Mails checken, Fahrzeit nachsehen, Rechnung stellen, etwas rechnen, anrufen etc. Die Information ist häufig ein begleitendes Element, das sich im Feedback oder einem Ergebnis zeigt – beispielsweise die Ergebnisseite einer Suchanfrage. Die Anfrage selbst, die Aktion, fand jedoch davor statt. Und nur eine vollendete Suchanfrage kann überhaupt Ergebnisse bringen. Fokussieren Sie sich also auf die Aktion des Nutzers.

Die Oberfläche bemüht sich immer, die Aufmerksamkeit des Nutzers zu binden – durch Microinteractions. Allerdings, wie das Wort micro impliziert, kurz. Die Aufmerksamkeit des Nutzers wird an eine kurze Interaktion gebunden, in der er einen Schritt weiterkommt – zum Beispiel das Ausfüllen eines Feldes. Die Oberfläche ermöglicht ihm, dann fortzufahren, wenn eine Teilaufgabe vollendet ist oder der Nutzer wieder Aufmerksamkeit bereitstellt. Der Preis unserer heutigen Mobilität ist die Fragmentierung unseres Alltags in immer kürzere Abschnitte. 

Geben Sie dem Nutzer immer das Gefühl, dass er die Kontrolle hat – auch dafür sind Microinteractions hervorragend geeignet. Als lang empfundenes Warten entzieht sich der Kontrolle des Nutzers genauso wie unerwartetes Verhalten seitens der Applikation. Sehr anstrengend ist es für Menschen, wenn sie auf ein Interaktionselement gedrückt haben, aber nichts passiert. Häufig beginnt dann ein Sturm von wiederholten Eingaben oder Klicks, der nur verursacht, dass das System diesen Fall neben seinem ersten Bug auch noch managen muss. In diesem Fall sind Qualität und Rückmeldung für die Kommunikation mit dem Nutzer essenziell. Ein Beispiel: Ihr Zug kommt zu spät oder fällt aus. Die Bahn gibt Ihnen am Gleis Bescheid: „Der Zug ist verspätet.“ Das haben Sie wahrscheinlich schon selbst bemerkt. Das wertvollere Feedback wäre: „Ein nächster Zug wird in 20 Minuten bereitgestellt.“ Vielleicht ärgern Sie sich, aber für das Problem gibt es bereits eine Lösung. Ihr Vorhaben findet verspätet statt, aber es findet statt – die Kontrolle ist wieder zurück bei Ihnen. 

Das Aussehen der Interaktionselemente verrät etwas über ihre Aufgabe und ihr Verhalten, und das je nach Medium. Ein Beispiel im Kontext mobiler Apps: Sehen Sie sich die Guidelines der Plattform-Anbieter Apple, Google, BlackBerry, Microsoft an, um plattformkonform zu bleiben und das Erlernte aus anderen Apps in Ihrer App wiederzuverwenden – einfaches Beispiel ist das Scrollen. Es wäre eigenartig, wenn man eine Liste in Ihrer App nicht mit dem Finger scrollen könnte, sondern irgendwelche Buttons mit Pfeilen nach oben und unten an der Seite drücken müsste. Auf einem Touch-Screen fassen Menschen Elemente direkt an.