Sturzflug-und-Möwenmist-Attacken von Managern mit UX-Design-Sprints vorbeugen (Teil 1)

Wir haben ihn alle erlebt. Diesen Moment, in dem ein hochgestellter, einflussreicher Manager plötzlich unser UX-Design-Projekt zum Entgleisen bringt. Er stürmt herein mit seinen Ideen und verkündet, für wen das Design in seinen Augen gedacht ist und wie es sein sollte.

Es spielt keine Rolle, wie hart das UX-Team an seinem Design gearbeitet hat. Es ist egal, welche Nutzerforschung es unternommen hat. Die Highest Paid Person im Raum hat einen besseren Ansatz und das ist alles, was zählt.

Das Team hat gerade eine weitere Sturzflug-und-Möwenmist-Operation eines Managers erlebt. Wie eine Möwe beim Angriff ist der Manager im Sturzflug in das Projekt geplatzt und hat seine Hinterlassenschaften überall auf das UX-Design gekleckst. Dann ist er so schnell, wie er gekommen ist, wieder weggeflogen – Gemetzel und Trümmer hinterlassend.

Symptom eines größeren Problems: Kein gemeinsames Verständnis

Es gibt zwar den bösartigen Manager-Schurken, der in großen Organisationen herumfliegt und sich seinen Pfad der Zerstörung bahnt, aber zumeist ist ein Vorgang wie der oben beschriebene ein Symptom eines größeren Problems. Es kommt davon, dass das Team nicht die Basis geschaffen hat, alle wichtigen Beeinflusser auf dieselbe Seite im Hinblick auf das UX-Design zu bringen.

Es kann noch andere Leute ohne gemeinsames Verständnis geben. Sie kommen in der Mitte des Projekts rein und haben andere Erwartungen. In den meisten Fällen kann das Team die Zweifel dieser Personen ausräumen. Wenn allerdings jemand mit einer substanziellen Machtposition (wie ein Manager) und einer anderen Sichtweise auf das Projekt hereinmarschiert, kann man das schwerlich ignorieren. Sturzflug und Möwenmist.

Die gute Nachricht ist, dass man Sturzflügen und Möwenmist vorbeugen kann. Design-Sprints bilden einen beliebten Prozess, um das Team inklusive wichtiger Beeinflusser früh im Design-Lebenszyklus auf dieselbe Seite zu bringen.

Durch eine Reihe strukturierter Übungen identifiziert das Team kritische Annahmen, erstellt einen Prototypen und validiert seine Ideen – alles innerhalb einer Woche. Das Ergebnis ist ein gemeinsames Verständnis davon, was das Team entwickelt und warum.

Ein typischer Design-Sprint dauert ungefähr eine Woche, wobei einige Teams sie auch länger ausdehnen und andere wiederum herausgefunden haben, wie sie kleinere Versionen in kürzerer Zeit durchführen. Ein Team ist aus unterschiedlichen Rollen und Perspektiven innerhalb des Unternehmens zusammengesetzt. Sie definieren und dekomprimieren ein Problem, das gelöst werden muss. Sie generieren Ideen und entscheiden, welche durch Tests weiterverfolgt werden sollen. Sie erstellen Prototypen ihrer Ideen und validieren dann ihre Annahmen, indem sie Leute bei der Nutzung beobachten.

In dieser Woche tauchen sie tief in ein Problem ein und validieren Schlüsselideen zur Lösung. Noch wichtiger: Diese Crew hat nun ein gemeinsames Verständnis, das auf echten Daten basiert, die von echten Usern kommen. Sie können dieses Verständnis überall im Unternehmen verbreiten, indem sie die Einsichten kommunzieren, die sie gewonnen haben – auch bei künftigen Sturzflüglern und Möwenmist-Klecksern.

Es gibt Variationsmöglichkeiten bei der Durchführung von Design-Sprints, aber sie haben fünf Phasen gemeinsam:

Verstehensphase: Wir beantworten die wichtigen Fragen und bringen unsere Annahmen an die Oberfläche. Was ist das Problem, das wir zu lösen versuchen? Von welchen Annahmen gehen wir aus? Für wen lösen wir das Problem?

Brainstorming-Phase: Wir generieren so viele potenzielle Lösungen, wie wir können, indem wir in diesem Prozess die unterschiedlichen Dimensionen des Problems erkunden.

Entscheidungsphase: Wir richten uns auf die besten Ideen aus und vertiefen unser Verständnis davon, für wen wir das UX-Design umsetzen und warum.

Prototyping-Phase: Wir übertragen die besten Ideen in eine Arbeitsversion eines plausiblen Designs (selbst wenn es einfach ein Mockup auf Papier ist), um unsere Annahmen zu testen.

Validierungsphase: Wir setzen unseren Prototypen echten Nutzern vor und beobachten, wie sie damit umgehen. Wir validieren unsere Annahmen und lernen noch mehr über ihre Bedürfnisse.

Die Natur der Design-Sprints liegt darin, dass diese Phasen sehr schnell ablaufen, und zwar im Rahmen einer Reihe von Aktivitäten, die von einem erfahrenen Moderator geleitet werden. Diese Aktivitäten selbst machen Spaß und sind produktiv, aber die wirklichen Werte entstehen aus ihren inhärenten Qualitäten, die zu einem gemeinsamen Verständnis führen. Es sind diese kritischen Qualitäten, die uns helfen, künftig Sturzflüge und Möwenmist von Managern zu vermeiden.

Vom Self-Design zum aktivitätsfokussierten Design

Self-Design ist ein Stil der Entscheidungsfindung, bei dem eine Person eine Wahl darauf basierend trifft, wie sie selbst das UX-Design gerne hätte. Dieser Stil ist unter Leuten verbreitet, die noch nicht viel Erfahrung im Design-Betreiben haben. Auch erfahrene UX-Designer greifen auf ihn zurück, wenn sie nicht viele Informationen haben, mit denen sie arbeiten können. Sie versetzen sich selbst in die Rolle des Nutzers und fragen: "Wie sollte das Design aus meiner Sicht funktionieren?"

Ein Manager ohne jede Information geht an ein UX-Design oftmals ebenso heran. Wenn das, was das Team präsentiert hat, nicht seinen eigenen Vorstellungen entspricht, stellt er die getroffenen Entscheidungen infrage und schlägt seine eigenen Alternativen vor.

Wenn ein Manager das Team auf diese Weise stört, geschieht das häufig deshalb, weil das Team selbst den Self-Design-Ansatz verfolgt hat, um das aktuelle UX-Design zu entwickeln. (Oder schlimmer: Sie haben noch einen anderen Stil genutzt – unbeabsichtigtes Design. In diesem Fall haben sie an das UX-Design grundsätzlich nicht viele Gedanken verschwendet.)

Hier hilft ein Design-Sprint. Seine Struktur treibt das Team weg von Ansätzen wie dem Self-Design oder dem unbeabsichtigten Design. Stattdessen widmet sich das Team einem aktivitätsfokussierten Design, bei dem die Entscheidungen auf untersuchten Nutzeraktivitäten basieren. Wenn das Team echte User dazu einlädt, einen Prototypen auszuprobieren, sammelt es Daten darüber, was die Nutzer brauchen, und das bildet wiederum eine solidere Grundlage dahingehend, wie das Design sein sollte.

Wenn der Manager auftaucht, kann das Team ihm diese Daten zusammen mit dem UX-Design, das auf ihnen basiert, zeigen. Wenn echte Daten hinter den Design-Entscheidungen stehen, reduziert sich der Einfluss, den der Manager ausüben kann, und kluge Manager werden diesen Ansatz gerne annehmen.

Im zweiten Teil des Artikels diskutiert der Autor weitere Vorteile von UX-Design-Sprints.

Dieser Artikel wurde im Original am 6. Januar 2016 unter dem Titel Preventing the Executive Swoop and Poop with Design Sprints von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden User-Experience-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im UX-Special von //SEIBERT/MEDIA.