Sieben Menschen, 21 Gespräche: was mir ein Team über das Gestalten eines Produkts beigebracht hat

Wie ein interdisziplinäres Team aus Entwicklung, Art Direction, Marketing und UX ein Produkt formte: woher Ideen kommen und was bei der Abstimmung hilft.

Setz sieben Menschen auf ein Projekt, und du bekommst nicht sieben Kommunikationswege. Du bekommst 21.

Die Rechnung ist einfach: Jeder kann mit jedem anderen sprechen, also hat ein Team aus n Personen n × (n − 1) / 2 mögliche Gespräche. Fred Brooks hat das 1975 in The Mythical Man-Month aufgeschrieben, um zu erklären, warum zusätzliche Leute ein verspätetes Softwareprojekt meist noch später machen (Brooks'sches Gesetz). Drei Menschen teilen sich 3 Gespräche. Sieben teilen sich 21. Jedes davon kann eine Idee tragen, und jedes kann eine fallen lassen.

Zwei Jahre meines Masterstudiums habe ich in diesen 21 Gesprächen gelebt. Das Projekt hieß Pawka, eine mobile App, die Tierfutter scannt und eine unlesbare Zutatenliste in einen Score von 100 übersetzt. Das Team: drei Entwickler, zwei Art Directors, eine Person aus dem Marketing und ich für UX-Research und UI-Design.

Hier kommt der Teil, mit dem ich nicht gerechnet hatte. Die eine Entscheidung, die Pawka funktionieren ließ, kam nicht von mir.

Die beste Idee war nicht meine

Mein Teil des Projekts waren die Nutzer. Die Research hinter Pawka umfasste 12 halbstrukturierte Interviews, drei Beobachtungen im Laden und eine Wettbewerbsanalyse. Wir wussten, dass unsere Nutzer im Schnitt 4 Minuten 20 Sekunden vor dem Tierfutterregal verbrachten und dass 92 % von ihnen ein normales Etikett kaum lesen konnten.

Was ich nicht hatte, war das Geschäftsmodell. Dann kam der Gastmodus von außerhalb der UX-Rolle: Leute fünf Produkte am Tag ganz ohne Konto scannen lassen und erst dann nach einer Registrierung fragen, wenn sie einen Favoriten speichern oder ihren Verlauf sehen wollen. Erst ein kostenloses Angebot, später Premium.

Auf dem Papier klang das nach einer Marketingentscheidung. In der Praxis war es die beste UX-Entscheidung der App.

In der Friction Map der User Journey war „Pflichtregistrierung vor dem ersten Scan“ das einzige Problem mit der Bewertung 5 von 5: Wer Verbindlichkeit verlangt, bevor er irgendeinen Wert zeigt, zerstört die Conversion. Im Test hat es ein Teilnehmer besser gesagt als jedes Diagramm: „Ich konnte mich umsehen, ohne etwas preiszugeben. Das beruhigt jemanden wie mich, der Apps misstraut.“

Research und Geschäftsmodell zeigten also auf dieselbe Tür. Ich hatte den Beleg, wo es wehtat. Ein Teamkollege hatte die Lösung. Keiner von uns hätte sie allein umgesetzt.

Warum interdisziplinäre Teams bessere Ideen haben (wenn sie funktionieren)

Das ist das Versprechen eines interdisziplinären Teams, und die Forschung stützt es.

2010 gaben Anita Woolley und ihre Kollegen Gruppen aus zwei bis fünf Personen ganz unterschiedliche Aufgaben und fanden so etwas wie einen Faktor kollektiver Intelligenz: Manche Gruppen waren durchgehend gut, egal bei welcher Aufgabe. Das ließ sich nicht damit erklären, wie klug das klügste Mitglied war. Es hing mit der sozialen Sensibilität der Mitglieder zusammen und damit, ob alle zu Wort kamen, statt dass ein oder zwei Stimmen den Raum dominierten.

Google fand ein ähnliches Muster, als es im Projekt Aristoteles seine eigenen Teams untersuchte. Von den fünf Dynamiken, die effektive Teams auszeichnen, stand psychologische Sicherheit an erster Stelle: die gemeinsame Überzeugung, dass man vor dem Team ein Risiko eingehen kann, ohne dafür bestraft zu werden. Die Idee geht auf Amy Edmondsons Studie über Arbeitsteams von 1999 zurück, die psychologische Sicherheit damit verknüpfte, wie viel Teams tatsächlich lernen.

Übersetzt auf ein Studienprojekt: Die Idee mit dem Gastmodus landet nur dann auf dem Tisch, wenn die Person, die sie hat, sich traut, eine Business-Idee in eine UX-Diskussion zu bringen. Und sie überlebt nur, wenn die UX-Person ihre Research nicht als Revier behandelt.

Remote-Zusammenarbeit: Der eigentliche Gegner war der Kalender

Ich würde lügen, wenn ich sagte, das Schwierige seien die Ideen gewesen. Das Schwierige war die Zeit.

Sieben Studierende bedeuten sieben Stundenpläne: unterschiedliche Kurse, unterschiedliche Abgaben, verteilt über zwei Jahre. Alle zur selben Zeit verfügbar zu bekommen, war der schwierigste Teil des ganzen Projekts, und ein großer Teil der Abstimmung lief remote.

Die Forschung zur Remote-Arbeit beschreibt genau, was das mit einem Team macht. Als Microsoft 2020 seine gesamte Belegschaft nach Hause schickte, zeigte eine Studie mit über 61.000 Beschäftigten, dass die Zusammenarbeit isolierter und asynchroner wurde: weniger Verbindungen zwischen Gruppen, weniger Live-Calls, mehr E-Mails und Nachrichten. Informationen flossen weiter, nur langsamer und seltener über Disziplingrenzen hinweg.

Genau das ist die Gefahr für ein gemischtes Team. Die Entwickler reden am Ende mit den Entwicklern, die Art Directors mit den Art Directors, und die 21 Gespräche schrumpfen still auf drei.

Zusammengehalten haben Pawka deshalb die Dinge, die man lesen konnte, ohne dass jemand im Raum war.

Ein Designsystem als Vertrag

Wir haben das Designsystem als Vertrag zwischen Design und Entwicklung behandelt. Es folgte Atomic Design: Grundlagen, dann Atome wie Buttons, Badges und Eingabefelder mit allen dokumentierten Zuständen, dann Moleküle wie die Kriterienkarte, dann Organismen wie das komplette Produktblatt. Ein Entwickler, der zu einer anderen Zeit arbeitete als ich, musste mir nicht schreiben, um zu wissen, wie ein deaktivierter Button aussieht. Die Antwort stand schon da.

Dahinter steckt eine alte Regel. 1968 beobachtete Melvin Conway, dass Organisationen Systeme entwerfen, die ihre eigene Kommunikationsstruktur abbilden. Wenn dein Team nur asynchron miteinander reden kann, wird dein Produkt die Form dessen annehmen, was ihr aufgeschrieben habt. Also schreibt die richtigen Dinge auf.

Feedback vor Pixeln

Jedes Wireframe ging durch zwei oder drei Runden internes Feedback, bevor irgendetwas in High Fidelity ging. In dieser Phase waren die Screens absichtlich hässlich, nur Struktur. Das machte sie billig zu kritisieren. Niemand zögert, bei grauen Kästen zu sagen „dieser Ablauf ist verwirrend“, und der Hinweis eines Art Directors zur Hierarchie kostet nichts, solange noch keine einzige Farbe existiert.

Personas als Schiedsrichter

Am Ende hatten wir sieben Profile, darunter zwei Anti-Personas, und jede Designentscheidung musste benennen, welchem sie dient. Das klingt nach Prozess um des Prozesses willen. In einem Team, in dem drei Disziplinen uneins sind, ist es das Gegenteil: Die Diskussion wandert von „ich finde“ zu „Claire, die mit zwei Minuten Zeit vor dem Regal steht, braucht das“.

Das Ergebnis: was die Usability-Tests zeigten

Der Beweis, dass das Team funktioniert hat, steckt in den Tests. 100 % der Teilnehmenden erinnerten sich noch an den Score und seine Farbe, nachdem sie ein Produktblatt fünf Sekunden lang gesehen hatten. Die App erreichte 80 auf der System Usability Scale, Stufe „gut“. Und die eine Aufgabe, die hakte, herauszufinden, wie der Score berechnet wird, kam nur auf 50 % direkten Erfolg. Die Lösung landete direkt ganz oben auf der Roadmap: ein Button „Wie wird das bewertet?“ auf jedem Produktblatt.

Tipps für Teamarbeit in einem neuen Produktteam

• Zählt eure Gespräche. Entscheidet bei sieben Leuten, welche der 21 wirklich live stattfinden müssen, und gebt jedem anderen Austausch einen schriftlichen Ort.
• Lasst die Research entscheiden, nicht das Dienstalter. Eine Persona oder ein Schweregrad beendet eine Diskussion schneller als ein Jobtitel.
• Schreibt jede Entscheidung dorthin, wo die nächste Person nachsieht. Wenn sie nur in einem Chatverlauf oder im Gedächtnis von jemandem existiert, ist sie für die Person, die am Montag dazukommt, nie passiert.
• Macht es sicher, Ideen von außerhalb der eigenen Rolle einzubringen. Unsere beste UX-Entscheidung kam von außerhalb der UX.
• Schützt einen Live-Termin pro Woche. Macht alles andere asynchron, aber behaltet einen Moment, in dem alle Disziplinen gleichzeitig im selben Call sind, damit sich die Silos nicht schließen.
• Nennt Ideen beim Namen ihrer Urheber. Menschen bringen weiter Ideen in Teams ein, in denen man sich daran erinnert, von wem sie kamen.

Fünf kostenlose Scans

Die vollständige Pawka-Fallstudie zeigt alles, von den 12 Interviews über die Testergebnisse bis zum Designsystem.

Aber wenn mich jemand fragt, was mir Teamarbeit beigebracht hat, zeige ich auf den unscheinbarsten Screen der App: fünf kostenlose Scans, kein Konto nötig. Das wirkt wie ein kleines UX-Detail. Es ist die eine Stelle, an der eine Business-Idee, ein Research-Ergebnis und der Satz eines misstrauischen Nutzers genau am selben Punkt gelandet sind.

Ich hatte die Idee nicht. Ich habe geholfen zu beweisen, dass sie richtig war. Genau dafür ist ein Team da.