Für eine Oberfläche ist es eine lange Reise von der ersten Idee bis zur endgültigen Implementierung, und auf diesem Weg sind viele Leute involviert. Die größte Herausforderung, der wir uns gegenübersehen, besteht darin, ein gemeinsames Verständnis vom anvisierten Endergebnis zu entwickeln.
Ich erinnere mich an einen Architekten, der über seine besten Projekte sprach. Er erzählte, wie er zum ersten Mal durch das fertige Gebäude spazierte und sich sofort heimisch fühlte, da das Ergebnis exakt dem entsprach, was er sich Jahre zuvor vorgestellt hatte. Seine Intention hatte den gesamten Weg durch den Implementierungsprozess genommen.
Es ist aufregend zu sehen, wenn unsere Designs sich exakt so entwickeln, wie wir es uns ausgemalt haben. Und es ist frustrierend, wenn sich herausstellt, dass sie nicht so implementiert werden, wie es eigentlich geplant ist.
Wenn wir untersuchen, was Entwicklungsteams erfolgreich macht, sprudelt das gemeinsame Verständnis stets an die Spitze unserer Liste. Teams, die eine solche Vision teilen, haben viel bessere Chancen auf hervorragende Ergebnisse als jene, die es nicht schaffen, ein gemeinsames Verständnis von den Projektzielen und -resultaten zu entwickeln.
Obwohl es ganz natürlich erscheint, arbeiten Teams in vielen Design-Prozessen nicht explizit auf das Ziel eines gemeinsamen Verständnisses hin. Es ist fast so, als würden die Teammitglieder voraussetzen, dass es sich irgendwann schon einstellt. Oft reicht schon ein solcher Hinweis aus, um etwas zu ändern – zumindest vorübergehend. (Man fällt schnell zurück in alte Verhaltensweisen, wenn man nicht aufpasst.)
Wenn das Team aber nun tatsächlich das Ziel hat, ein gemeinsames Verständnis zu erlangen, sieht es sich mit zwei konkurrierenden Ansätzen konfrontiert: dem vertragsgemäßen und dem kollaborativen Verständnis.
Vertragsgemäßes gemeinsames Verständnis
Viele Jahre haben UX-Designer auf Wireframes, Design-Guidelines und Oberflächenspezifikationen gesetzt, um ihre Intention auszudrücken. Sie entwickelten diese dicken, nervtötenden Schinken im Bestreben, jedes noch so winzige Design-Detail zu kommunizieren.
In diesen Dokumenten geht es darum, den Design-Anteil von der Implementierung zu trennen und ein Rezept zu erstellen, wie die Oberfläche zu kochen ist. Je spezifischer das Rezept, desto größer die Chancen, dass am Ende das Richtige serviert wird.
Die Dokumente werden zu Verträgen zwischen UX- und Design-Team auf der einen und Entwicklungsteam auf der anderen Seite. Die Designer sagen, was sie wollen, und die Entwickler sagen zu, genau das zu liefern. Es ist ein Verhandlungsprozess, der in etwas resultiert, das für alle wie eine felsenfeste Vereinbarung aussieht.
Der vertragsgemäße Ansatz hat einen großen Vorteil, dass klare Aussagen über das Ergebnis getroffen werden und der Aufwand sich gut beschätzen lässt. Erfahrene Entwickler können die Kosten akkurat beziffern und die Aktivitäten für jedes Element der Spezifikation genau planen. Das Management ist glücklich, weil es weiß, was zu erwarten ist und wann.
Leider hat diese juristische Präzision ihren Preis. Erstens dauert es lange, solche Dokumente zu erstellen. Zwar helfen uns moderne Tools, Spezifikationen mit grafischen Erläuterungen der Details schneller denn je zu entwickeln, aber es kostet immer noch Zeit. Jede Kleinigkeit eines Designs präzise festzuhalten, ist harte Arbeit.
Bleibt bei einem Detail Interpretationsspielraum offen, eröffnen sich Potenziale für Diskrepanzen zwischen der Intention und den Ergebnissen nach der Implementierung. Teams, die sich für den vertragsgemäßen Ansatz entscheiden, lernen die Spezifikation in Perfektion – und bremsen sich gleichzeitig aus: Es dauert sehr lange, neue Features und Ideen zu produzieren.
Darüber hinaus ist ein statisches Dokument zur Abbildung interaktiver Prozesse nicht optimal. Wir nutzen Wörter, um Verhalten auszudrücken – Das ist sehr schwierig. Sprechen über Design und Nutzererlebnisse ist wie Ausdruckstanz über Architektur.
Ein anderes großes Problem dieses Ansatzes ist die Inflexibilität, Dinge aufzugreifen, die nach "Vertragsabschluss" noch an die Oberfläche kommen. Wenn sich im Umfeld etwas verändert oder das Team neue Erkenntnisse über die Anforderungen der User gewinnt, ist es sehr schwer, die Dokumente nachzurüsten und den Verständigungsprozess erneut zu durchlaufen.
Der vertragsgemäße Ansatz lässt drei mögliche Resultate zu. Im Idealfall funktioniert die Oberfläche für die Nutzer perfekt. Alternativ funktioniert sie nicht, weil die Entwickler den Vertragsinhalt nicht korrekt umgesetzt haben. Oder sie funktioniert nicht, weil sie nicht den Bedürfnissen der User entspricht, obwohl sie korrekt implementiert wurde. Es sind die beiden letzteren Ergebnisse, die wir am häufigsten sehen, wenn Teams dem vertragsgemäßen Ansatz folgen.
Kollaboratives gemeinsames Verständnis
Bei Verträgen geht es um Buchstaben und nicht um Geist. Der kollaborative Ansatz zum Erreichen eines gemeinsamen Verständnisses fokussiert sich mehr auf die Seele dessen, was dem Team vorschwebt.
Hier drehen sich die Techniken nicht um Dokumentation und Verträge, sondern um Erforschen, Experimentieren und – nennen wir es mal Erleuchtung. Wir versuchen, an einen Punkt zu kommen, an dem sich das Design uns offenbart – eine Erscheinung, die alles klar werden lässt.
Um das zu erreichen, stehen uns zwei Techniken zur Verfügung: Prototyping und Paired Design.
Prototyping
Beim Prototyping nehmen wir Ideen und lassen sie reifen, wir bringen Konzepte in den Vordergrund und lassen die detaillierte Implementierung im Gepäck. Die einfachste Form des Prototypings ist die Skizze. Ob auf Papier oder an einem Whiteboard: Die lebhafte Diskussion angesichts einer Skizze bringt neue Form in die Ideen. In gewisser Weise beschwört das Gekrakel den Geist im Raum herauf, der allen ein tieferes Verständnis verleiht.
Seit Jahren schulen wir Teams in Sachen Paper-Prototyping. Das gesamte Team steht um das Design herum und ein User kann Aufgaben und Aktionen durchlaufen. Wir lieben diese Technik im Interaktions-Design, denn aus Papier können so unglaublich viele Feinheiten der Interaktion heraussprudeln.
Und es ist schnell. Wirklich schnell. Wenn es zusammenarbeitet, kann ein Team ein kompliziertes Set an Interaktionen in ein paar Minuten erstellen – mit Werkzeugen und Techniken, die man im Kindergarten erlernt hat.
Das schließt das gesamte Team mit ein, an der Konstruktion beteiligen sich nicht nur die Design- und UX-Experten. Es ist eine Art taktiler Manipulation, die das Verstehen beschleunigt. Der Akt des Paper-Prototypings trägt zur Herausbildung eines gemeinsamen Verständnisses fast in einem Maße bei wie der finale Prototyp in Aktion.
Paired Design
Dank des Aufkommens einfach zu nutzender, schneller Implementierungs-Tools wie JQuery oder Ruby on Rails können Teams ihre Ideen heute rasch in digitale Versionen übersetzen. Schon klickbare PDFs entfalten eine beachtliche Realitätsnähe, die dem Team zu verstehen hilft, was es da umzusetzen versucht.
Vorgefertigte Plugins und Built-in-Operatoren machen die Produktion interaktiver Funktionen einfach, dennoch sind manchmal erweiterte Programmierkenntnisse nötig, um zu sehen, wie eine komplexe Interaktion wirklich funktioniert. Hier kommt Pair Design ins Spiel.
Bei diesem Vorgehen tun sich ein Designer und ein Entwickler zusammen. Sie sitzen am selben Tisch und arbeiten parallel an der Oberfläche. Der Designer zeigt dem Programmierer ständig Skizzen, und dieser realisiert die Ideen geschwind in Form von Code. Dieser Code ist unsauber und längst nicht auslieferbar, aber er tut seinen Job, indem er allen die Ideen vor Augen führt.
Das Resultat von Paired Design ist eine Qualität der Kommunikation über die Intention, die über das, was Prototyping leisten kann, noch hinausgeht. Später, wenn die Entwickler ohne die Designer an den Details weiterarbeiten, haben sie genug Verständnis vom Geist des Designs, um gute Entscheidungen zu treffen.
Es gibt zwei gravierende Nachteile dieses Ansatzes. Erstens ist es schwer zu schätzen, was umgesetzt wird und wie lange es dauert – das liegt in der iterativen Natur dieses Konzepts. Teams, die mit dem klaren Beschätzungsprozess des vertragsgemäßen Vorgehens groß geworden sind, haben häufig Probleme damit, auf den kollaborativen Ansatz umzusatteln, weil sich Budgets und Zeiten nicht so ohne weiteres planen lassen. (Je nach Geschäftsmodell und Agenturalltag kann der kollaborative Ansatz auch gänzlich zum Scheitern verurteilt sein, wenn Kunden beispielsweise Festpreisprojekte haben wollen.)
Zweitens ist das kollaborative Vorgehen eine ziemlich intensive und persönliche Sache, und zwar über einen langen Zeitraum hinweg. Wenn man Erfolg haben will, müssen Designer und Entwickler nah beieinander sein und sich quasi mit der laufenden Arbeit umgeben. Für verteilte Teams, die während des Projekts nicht das Glück haben, an einem Ort zusammen zu sein, ist das natürlich sehr schwierig.
Unsere Untersuchungen zeigen, dass es trotz dieser Nachteile einfacher ist, tolle Oberflächen zu entwickeln, wenn man den kollaborativen Ansätzen zum Erreichen eines gemeinsamen Verständnisses folgt. Der beste Weg zu hervorragenden Software-Produkten ist der, Ihre Teams auf die beschriebene Weise zu strukturieren und immer darauf zu achten, dass alle verstehen, worum es geht.
Dieser Artikel wurde im Original am 18. Januar 2012 unter dem Titel Attaining a Collaborative Shared Understanding
