Prototyping – ich male mir ein Mock-up

Malen ist ein Wort, das eher mit dem Spiel von Kindern assoziiert wird als mit professioneller Arbeit. Aber die Arbeit mit Prototypen darf durchaus etwas Spielerisches haben, man darf ausprobieren, man darf in Sackgassen laufen, alles wegwerfen und komplett neu beginnen – und deshalb trifft der Ausdruck "malen“ es doch sehr gut.

Wozu das Ganze?

Prototypen oder Mock-ups können ganz unterschiedliche Ausprägungen haben. Schon die erste grobe Papierskizze, welche Elemente der zukünftigen App oder Website man auf der Oberfläche wo platzieren könnte, ist streng genommen bereits ein Prototyp, wenn auch ein sehr rudimentärer. Von Papierkritzelei bis zum programmierten Prototyp, der schon fast aussieht wie das fertige Produkt, ist alles möglich.

Wichtig ist, dass schon früh im Entwicklungsprozess erste Prototypen zum Einsatz kommen. Sie ermöglichen es zu konkretisieren, worüber man redet und ob das, was man sich vorstellt, funktionieren kann. Statt nur zu sagen „Wir könnten die Menüleiste auch oben horizontal einbauen statt links auf der Seite“ kann eine schnelle Skizze auf Papier oder am Whiteboard schon einen guten ersten Eindruck liefern. Passt das? Sollten da nicht andere Elemente hin? Wird das zu überladen? Passt das zur Corporate Identity? Was meint der Kunde und was der Entwickler? Wenn irgendetwas dagegen spricht, ist der Entwurf mit einem Wisch wieder fort und die Entscheidung, dass das Menü links steht ist gefallen. Sollte die Website schon fast fertig sein und jemand kommt auf die Idee „Schieb das Menü doch mal da oben hin!“, kostet es ungleich mehr Zeit das gesamte Layout der Seite zu ändern – nur um dann am Ende herauszufinden, dass es doch nicht gut aussieht.

Früher Prototyp

Keep it ugly

Prototypen dürfen „hässlich“, das heißt nicht schön ausgestaltet sein. Dieser Grundsatz sorgt dafür, dass man sich nicht zu früh in Details der Gestaltung verliert, sondern zunächst das grundlegende Konzept hinterfragt. Natürlich kann man mit Photoshop einen vollendeten prototypischen „Screenshot“ der angedachten Website erstellen, mit passenden Farben und Schriftarten und schönen Bildern. Doch legt man diese dem Auftraggeber oder Kunden vor, so bekommt man schnell Kommentare wie:

„Die Schrift ist aber etwas klein, die sollte größer sein.“

„Das Blau ist zu grünstichig.“

„Diese Überschrift sollte nicht kursiv sein, fett sähe besser aus.“

Ein solches Feedback ist wichtig, wenn es um den letzten Feinschliff geht. Aber sie bringen dem Entwickler einer Seite wenig, wenn er nur wissen wollte, ob die Benennung der Menüpunkte verständlich ist und man die Suchfunktion schnell findet.

Deshalb: keep it ugly. Schwarz-weiß reicht in der Regel völlig aus. Falls an einzelnen Stellen wirklich ein Farbfleck nötig ist, sollte der nicht nur dekorativ sein, sondern auch „sinntragend“. Beispielsweise indem er die sehr prominente Platzierung eines Buttons hervor hebt, die auch später so ähnlich umgesetzt werden soll. Eine einzige Standard-Schriftart, Bilder nur als Platzhalter und keinerlei zierende Elemente: Mit einem solchen Prototypen haben Entwickler die Möglichkeit, den Grundaufbau der Anwendung oder Website und die grundlegenden Funktionen zu hinterfragen, ohne sich in Feinheiten zu verrennen. Versteht man, was sich hinter den Menüpunkten verbirgt? Ist auf einer Maske klar, was man hier tun kann und mit welchem Button man weiter kommt? Ist das Suchfeld zu versteckt und sollte besser prominenter platziert werden? Benötigt man Funktion XYZ überhaupt, oder kann man sie einsparen?

Unendliche Möglichkeiten zur Umsetzung

Daher wurde der Begriff „malen“ verwendet. Frühe Prototypen sollen schnell gemacht sein, damit es nicht weh tut, wenn sie verworfen werden. Eine einfache Papierskizze ist ebenso möglich wie das digitale Entwerfen, indem mit Hilfe von speziellen Programmen einzelne Bedienelemente zusammen geklickt werden oder die Oberfläche schon tatsächlich programmiert wird.

Ganz einfach und simpel ist das gute alte Papier. Ein paar Linien und Beschriftungen, fertig ist der Prototyp. Kombiniert mit mündlichen Erklärungen kann man damit schon eine ganze Menge machen. Falls nötig, kann man auch mit Schere und Kleber weiter basteln, um dynamische Effekte besser verständlich zu machen. Aber wieder gilt: Lieber noch nicht zu viel Liebe ins Detail hinein stecken. Am Ende landet doch alles ganz schnell im Mülleimer.

Auch digital bieten sich vielfältige Möglichkeiten. Mit Microsoft Powerpoint kann man schnell ein paar Rechtecke und Textfelder zu einem Prototyp zusammen klicken. Falls gewünscht, kann man einzelne Elemente klickbar machen und so einen Seitenwechsel oder Ablauf demonstrieren, z.B. bei einem Bestellprozess. Es gibt auch spezielle Programme für Prototyping, beispielsweise Balsamiq oder OmniGraffle. Sie bieten vorgefertigte Elemente wie Browserfenster, diverse Eingabefelder, Buttons und Icons und fast jedes dieser Elemente kann man verlinken, um den Screenflow erkennbar zu machen. Das Design der Elemente ist dabei bewusst skizzenhaft gehalten, durch nicht ganz saubere Linien und einem gewissen Handschriftcharakter. Gerade das macht die etwa mit Balsamiq erstellten Mockups sympathisch und sorgt dafür, dass es nicht zu „designed“, sondern wirklich nur nach Entwurf aussieht. Eben: Keep it ugly.

Auch mit HTML und CSS lassen sich Prototypen entwickeln, allerdings kommen diese meist eher spät zum Einsatz. Entwirft man die komplette Seite, so sieht es dann schon deutlich mehr nach einer fertigen Website oder App aus. Hier muss man selbst darauf achten, dass man nicht schon zu sehr Richtung dekorativem Design geht, sondern es bewusst so spartanisch hält, wie es gewünscht ist. Wird Responsive Design angestrebt, so empfiehlt es sich schon recht früh, einzelne Elemente der Seite mit HTML umzusetzen: Nur so kann man wirklich gut beurteilen, ob Elemente sich so verhalten (können) wie beabsichtigt. Selbstverständlich spricht nichts dagegen, dass auch Designfragen mittels Prototypen geklärt werden, sobald der grundlegende Aufbau der Oberfläche fest steht. Denn dann geht es wirklich um die Schriftart, -größe und Farbschemata. Aber zu Beginn sollte das erst mal nicht relevant sein.

Bild

Vertikal und horizontal

Neben dem grundlegenden Aufbau kann man auch einzelne Funktionen mittels Prototypen genauer ausarbeiten. Man unterscheidet insgesamt zwischen horizontalen und vertikalen Prototypen.

Horizontale Prototypen zeigen viele Funktionen des späteren Produkts, aber diese jeweils nur sehr rudimentär – ggf. lediglich durch eine Überschrift auf einem Menüpunkt. Man bekommt somit einen Überblick, was alles mit dem Produkt möglich sein soll, ob die Struktur passt und ob die Funktionen sinnvoll angeordnet sind.

Vertikale Prototypen stellen eine einzelne Funktion in den Vordergrund und zeigen detailliert auf, wie diese verwendet werden kann. Bei komplexen oder besonders wichtigen Funktionen ist dies eine gute Möglichkeit der Konzeption. Eine Suchfunktion mit Filtermöglichkeiten, die sich je nach Kontext unterscheiden, könnte man so beispielsweise genauer ausarbeiten. Oder man beschreibt einen komplexen Bestellprozess mit vielen wichtigen Details und Upselling-Optionen Maske für Maske, um sicher zu gehen, dass nichts vergessen oder falsch platziert wird.

Wie dann jeweils ein horizontaler oder vertikaler Prototyp umgesetzt wird, ist selbstverständlich völlig frei wählbar – die gesamte Palette von Papier bis nahezu fertig programmiertem Produkt ist möglich. Wichtig ist vor allem, nicht zu früh im Entwicklungsprozess allzu viele Details auszufeilen und keine Hemmungen zu haben, etwas wieder zu verwerfen.

Weiterführende Links

Überblick über Prototypen in der Softwareentwicklung: enzyklopaedie-der-wirtschaftsinformatik.de

Verschiedene Tools um Mock-ups zu erstellen: 1stwebdesigner.com

Kurze Vorstellung des User Centered Design Process, in dem Prototypen eine wichtige Rolle spielen: w3c.org