Warum gute Geschichten dabei helfen, großartige Produkte zu entwerfen

Einer der größten Fehler, den Produktteams machen, besteht darin, Designs zu verwirren, die gut aussehen, aber nicht gut funktionieren. Es ist ein einfacher Fehler, der jedoch schwerwiegende Folgen haben kann: Denn wenn Ihr Produkt nicht richtig funktioniert, interessiert es niemanden, wie es aussieht.

Der beste Weg, diese Verwirrung zu umgehen, ist eine Technik namens Story-Centered Design. Die Idee besteht darin, eine Reihe narrativer Anwendungsfälle für Ihr Produkt zu erstellen, die jeden Schritt auf dem Weg des Benutzers durch das Produkt veranschaulichen. Ich habe diese Technik bei Dutzenden von Startups angewendet und sie hilft Teams immer dabei, über die visuellen Details der Oberfläche hinauszugehen, um bessere Entscheidungen darüber zu treffen, worauf es wirklich ankommt: wie ihr Produkt letztendlich funktioniert. 

Entwürfe sollten keine Blaupausen sein

Mir ist aufgefallen, dass Teams UI-Designs oft wie einen Bauplan durchgehen und zeigen, wozu jedes Element gehört. Jeder Bildschirm zeigt, wie das Produkt in einer anderen Situation aussehen könnte, die Bildschirme sind jedoch in keiner Weise miteinander verbunden. Das Problem besteht darin, dass man bei der Präsentation von Designs auf diese Weise nur ein besseres Verständnis dafür entwickelt, wie das Produkt aussieht. Sie konzentrieren sich nicht darauf, wie das Produkt funktioniert, und Sie simulieren nicht, wie Kunden damit interagieren. Wenn Teams also Entwürfe als Blaupausen kritisieren, schränkt dies ihre Fähigkeit, über die Interaktivität des Produkts nachzudenken, erheblich ein.

Die besten Produktdesigner praktizieren Story-fokussiertes Design. Sie beginnen damit, Geschichten zu erstellen, die zeigen, wie Kunden mit einem Produkt interagieren, und erst danach entwerfen sie Bildschirme, um diese Interaktionsgeschichte zu erzählen. 

Der Prozess des Entwerfens nach Geschichte

Beim geschichtenzentrierten Design arbeiten Teams kritisch, indem sie sich Dutzende aufeinanderfolgende Modelle ansehen, die wie Einzelbilder in einem Filmstreifen funktionieren (siehe Foto unten). Designer präsentieren jeden Satz, den der Kunde liest, jede Aktion, die er ausführt, und jeden Bildschirm, den das System als Reaktion darauf generiert. Die Designs begleiten einen Kunden vom ersten Auslöser bis zur Zielerreichung und zeigen, wie das Design jeden Schritt in diesem Ablauf unterstützt. Ich habe viele Startups durch storyorientierte Designübungen gecoacht und diese Techniken haben sich für mobile Apps, Marketing-Websites, analytische Dashboards, Unternehmens-IT und vieles mehr bewährt.

Das dürfte Ingenieuren bekannt vorkommen. Der Kern des storyzentrierten Designs ist derselbe wie die pilotgesteuerte Entwicklung. Nur anstatt Tests zu schreiben, um unseren Code auszuprobieren, erstellen wir Geschichten, um unsere Designs auszuprobieren. Wie die testgetriebene Entwicklung kann auch das storygetriebene Design einen unglaublichen Einfluss auf die Geschwindigkeit und Qualität eines Produkts haben. 

Warum storyzentriertes Design so gut funktioniert

Es simuliert die Benutzererfahrung. Das geschichtenorientierte Design zwingt uns, die Kunden bei jedem Schritt zu begleiten. Dadurch erhält das gesamte Team (Designer, Ingenieure, CEO) ein System, um Designentscheidungen basierend darauf zu treffen, wie die Menschen das Produkt tatsächlich erleben.

Teams erkennen Probleme früher. Da Storys eine zeitliche Dimension hinzufügen, heben sie alle Arten von Designfehlern hervor, die Teams oft übersehen, wenn sie ihr Produkt nur als Ansammlung von Bildschirmen betrachten. Geschichten machen es einfacher zu erkennen, wenn Aufforderungen nicht die richtigen Erwartungen wecken. UI-Abläufe mit unnötigen Schritten und Sackgassen werden schneller erkannt und repariert. All diese kleinen Details tragen zu einer besseren Benutzerfreundlichkeit und Benutzereinbindung bei.

Es klärt Designziele im Voraus. Wenn Teams mit dem Entwerfen von Geschichten beginnen, müssen sich alle auf die Designziele einigen, bevor sie die Details ausarbeiten. Das ist hilfreich, denn nachdem Designer stundenlang an detaillierten UI-Modellen gearbeitet haben, wird sich die Kritik nur darauf konzentrieren, ob die Designs vordefinierte und verstandene Ziele erreichen.

Es ist Wissenschaft! Ja, irgendwie. Das Nachdenken darüber, wie ein Kunde vom ersten Auslöser (z. B. einer E-Mail oder Push-Benachrichtigung) bis zum Ausfüllen einer Zielkarte vorgeht, kommt dem Verhaltensmodell von Auslösern, Motivationen und Fähigkeiten von BJ Fogg ziemlich nahe. Mithilfe von Stories lässt sich leichter überprüfen, ob alle diese Elemente vorhanden sind, um das Benutzerverhalten zu steuern.

Es beschleunigt alles andere. Geschichten können oft von anderen Teilen des Teams wiederverwendet werden. Zur Darstellung einer Geschichte erstellte Modelle können in einen schnell anklickbaren Prototyp für Benutzerstudien umgewandelt werden. Mit derselben Story kann eine Trichteranalyse erstellt werden, die es uns ermöglicht herauszufinden, ob Benutzer die Story im Live-Produkt durchlaufen. Und das QA-Team kann wichtige Geschichten überprüfen, um jede neue Version zu validieren.