Mitte September haben Steffen Hartmann und ich den Workshop „Lean UX für Startups“ gehalten. Dabei fiel mir auf, dass sich das von Lean UX vorgeschlagene Arbeiten mit Prototypen stark mit der Arbeitsweise deckt, die sich in meinem aktuellen Projekt-Team entwickelt hat. Das war mir bis dahin weder klar, noch haben wir im Team die Nähe zu Lean UX forciert.
Eine Facette dieser Arbeitsweise ist das Arbeiten mit Prototypen. Dazu gehört besonders das Diskutieren im Team über erstellte Prototypen und die dahinter liegenden Konzepte, um ein gemeinsames Verständnis bezüglich der Stärken, aber auch der Schwächen der skizzierten Lösung zu schaffen. Mit diesem Vorgehen konnte unser Team bisher alle Features bis zur finalen Implementierung im Produkt entwickeln.
Die Ausgangssituation
Dazu sei gesagt, dass wir eine Single Page Application auf Basis von React entwickeln. Das Styling übernimmt zu sehr großen Teilen (80 bis 90 Prozent) die Komponenten-Bibliothek, mit der wir arbeiten.
Da wir für unseren Kunden eine Haus-interne Anwendung mit vielen Formularen entwickeln, haben wir uns für eine „off the shelf“-Design-Lösung entschieden. Konsistenz und Geschwindigkeit haben im Projekt einen höheren Stellenwert als individuelles Styling.
Wir verzichten auf (pixel-perfekte) Layouts, die außerhalb des Teams entwickelt werden. Damit entfällt die Übergabe von Layouts an das Team genauso wie deren Erläuterungen durch die Design-Agentur. Diese Übergabe ist sehr oft ein Punkt im Entwicklungsprozess, an dem Unklarheiten und Missverständnisse entstehen oder Lücken in der vorgeschlagenen Lösung unentdeckt bleiben – ich habe das oft genug selbst miterlebt.
Wie funktioniert nun das Arbeiten mit Protoypen im Team?
(Low-fidelity-)Prototypen für gemeinsames Verständnis
Wenn wir beispielsweise über die Implementierung komplexer Eingabemasken sprechen, steht oft ein Teammitglied auf und skizziert eine im Raum stehende Lösungsmöglichkeit auf ein Whiteboard / Flipchart / Papier (was eben gerade zur Verfügung steht).
Diese Skizze dient als Anker für die anschließende Diskussion und stellt sicher, dass alle an der Diskussion beteiligten Personen ein gemeinsames Verständnis des Sachverhalts haben. Häufig wird die Skizze erweitert, ergänzt oder in einer anderen Version neu gezeichnet. So lange, bis alle Beteiligten ein klares Bild davon haben, wie die Implementierung angegangen werden soll.
Die Skizze (= der low-fidelity-Prototyp) hat damit in der Regel ihren Zweck erfüllt. Das „Geschmier“ für eine weitere Verwendung aufzuheben, ergibt allenfalls als Gedankenstütze Sinn. Wichtig ist das gemeinsame Verständnis, das in den Köpfen der Teammitglieder durch die Arbeit am Prototyp entstanden ist.
Es kann sinnvoll sein, eine „Reinzeichnung“ der Konzept-Skizze zu machen, wenn sie Probanden, Stakeholdern oder anderen Menschen, die bei der Diskussion nicht dabei waren, zur Validierung gezeigt werden soll.
(High-fidelity-)Prototypen zur Validierung
Möchte man Feedback auf Basis der oben beschriebenen low-fidelity-Prototypen einholen, braucht es in der Regel einige Erläuterungen dazu:
- Was zeigt die Skizze?
- In welchem Kontext ist sie zu sehen?
- …
Das Gegenüber hat nichts „zum Anfassen“ und kann das Konzept nicht selbst ausprobieren.
In unserem Projekt folgt daher in der Regel ein programmierter Prototyp basierend auf der zuvor gescribbelten und diskutierten Lösung. Damit können früh eventuelle Lücken im Konzept aufgedeckt werden, die sich erst dann zeigen, wenn das Konzept in das bisherige Produkt integriert wird.
Vielleicht wichtiger ist aber, dass unser Kunde eine benutzbare / klickbare Version der Lösungsvariante bekommt. Auf deren Basis kann er Bedienbarkeit, Funktionsweise und Look-and-Feel bewerten und uns fundiertes Feedback dazu geben.
Sollte sich an dieser Stelle heraus stellen, dass die Lösung nicht tragfähig ist, können leicht Anpassungen vorgenommen werden: „fail early, learn often“.
Benutzbare (= high-fidelity-)Prototypen eignen sich zudem sehr gut für „echte“ Nutzertests, da sie im User Interface kaum von der finalen Implementierung abweichen. Man kann vor der vollumfänglichen Implementierung das Feedback echter Nutzer einholen, um es in die finale Feature-Version mit einzuarbeiten.
Design als Team-Aufgabe
Design (Konzept und User-Interface-Gestaltung) wird durch das Arbeiten mit Prototypen zur Team-Aufgabe. Jeder im Team kann Einfluß auf die Prototypen nehmen und sich an deren Entstehung beteiligen. Design ist keine Blackbox mehr. Nichts, was man einer externe Stelle überlässt. Das Projekt-Team übernimmt Verantwortung für das User Interface.
Vorteilhaft ist natürlich, wenn es im Team Mitglieder mit Kompetenzen im Bereich Design gibt. Aber auch wenn das nicht der Fall ist, kann das Team Prototypen bis zu einem Reifegrad entwickeln, der das Konzept und die benötigten Elemente für das User Interface erkennbar macht. Kommt ein Team an dieser Stelle nicht weiter, sollte selbstverständlich ein Designer / Layouter hinzugezogen werden, um das Design abzurunden und reif für die finale Integration im Produkt zu machen.
Die Gefahr, dass der Designer / Layouter an diesem Punkt etwas gestaltet, das unpassend ist bzw. vom Team nicht verstanden oder missverstanden wird, besteht kaum. Das Konzept und mögliche Interface-Elemente wurden bereits erprobt und evaluiert. Ganz im Sinne von Lean UX wird nur das gelayoutet, was auch wirklich gebraucht wird.
Gestylte Pixel: ab in den Styleguide
Die eben beschriebenen, neu erstellten Layout-Elemente werden natürlich für das betreffende Feature benutzt. Zudem ergibt es Sinn, sie in einem sogenannten „Live“ Styleguide (aus Lean UX, oft auch Living Styleguide genannt) zu hinterlegen. Dieser Live Styleguide ist eine Art Design-Bibliothek des Projekts, in dem alle User-Interface-Elemente gesammelt werden. Der Styleguide besteht „aus Code“ und kann im Browser / Ziel-Device angesehen und benutzt werden.
Der große Vorteil eines solchen kontinuierlich wachsenden Live Styleguides ist, dass die sukzessive entstehende Design-Bibliothek eine Quelle für User-Interface-Elemente ist, aus der sich das Team bedienen kann. Sind benötigte Elemente noch nicht im Styleguide enthalten (z. B. für ein neues Feature), können sie oftmals aus dem bestehenden „Design-Alphabet“ abgeleitet werden, ohne einen externen Designer / Layouter beauftragen zu müssen.
In meinem aktuellen Projekt ist wie eingangs schon beschrieben die verwendete Komponenten-Bibliothek quasi der Live Styleguide. Wir können dieser Bibliothek zwar keine Elemente hinzufügen, es existieren aber trotzdem einige Custom-Komponenten.
Custom-Komponenten im Einsatz
Custom-Komponenten können spezialisierte Varianten vorhandener Bibliotheks-Elemente oder Kombinationen von Bibliotheks-Elementen sein.
Ein Beispiel für eine spezialisierte Element-Variante unseres Projekts ist ein Eingabefeld, welches nur Zahlen akzeptiert und beim Verlassen des Feldes die Zahl mit einem „tausender-Punkt“ versieht. Das Eingabefeld inklusive Styling und Verhalten kommt von der Bibliothek, während die Einschränkung auf Zahlen und das nachträgliche Formatieren der Zahl selbst implementiert sind.
Das Team achtet beim Erstellen solcher Custom-Komponenten sehr darauf, dass sie im Look-and-Feel der benutzten Bibliothek bleiben und sauber gekapselt sind. Damit ist gewährleistet, dass sie ohne weiteres benötigtes Wissen analog zu den Komponenten aus der Bibliothek verwendet werden können.
Fazit
Das Arbeiten mit Prototypen im Team erfordert etwas Übung und auch Offenheit. Aus meiner Erfahrung kann ich sagen, dass sich diese Art der gemeinsamen Arbeit am User Interface sehr natürlich anfühlt und bei allen Team-Mitgliedern zu einer Sensibilisierung bezüglich der Arbeit am User Interface geführt hat. Dabei muss nicht jeder scribbeln oder schnell etwas Klickbares zusammenstecken können. An der Diskussion können sich in jedem Fall alle beteiligen. Jeder kann seine Erfahrungen und Ideen einbringen. Die Kommunikation im Team und das gemeinsame Verständnis werden dadurch deutlich verbessert.
Das Anlegen und besonders das Pflegen eines Live Styleguides benötigt eine gewisse Disziplin. Für Entwickler fühlt sich das anfangs teilweise nach doppelte Arbeit an. Sobald das Team aufgrund der im Styleguide vorhandenen Elemente selbst ein neues Feature ohne die Hilfe eines Designers umsetzen konnte, wird der Wert des Styleguides aber schnell klar.
Layouts sind mitnichten überflüssig! Es geht lediglich darum zu verhindern, dass prophylaktisch für jedes User-Interface-Element oder Feature Layouts angefertigt werden, die dann in der Tonne landen. Weil z. B. das Konzept nicht tragfähig ist, das Feature (warum auch immer) verworfen wird, oder, oder, oder …
Alignment und Kommunikation im Team, Übernehmen von Design-Verantwortung, nur das Layouten, was auch sicher den Weg ins Produkt findet – all das zielt darauf ab, nur Dinge zu tun, die wirklich Wert erzeugen. Es geht schlicht um die Vermeidung von „Waste“.
Schreibe einen Kommentar