Deep Tech trifft Nutzerzentrierung: zwei griffige Methoden zum Durchstarten

Die konsequente Fokussierung auf die Nutzer*innen spielt nicht erst bei der Entwicklung eines digitalen Produkts eine Rolle. Schon bei der Suche nach einem Geschäftsmodell ist sie ein wichtiges Grundprinzip, auch und besonders bei komplexer Enterprise Software. Warum Start-ups durch eine menschzentrierte Herangehensweise die besten Voraussetzungen für Ruhm und Ehre – und glückliche Nutzer*innen – haben, möchten wir mit diesem Artikel zeigen. Am Beispiel des Start-ups steadybit erfährst du, mit welcher Methodik du Nutzerzentrierung von Anfang an integrierst und so Produkte schaffst, die echte Probleme lösen.

Ganz kurz, wer ist steadybit?

steadybit ist ein Deep-Tech-Start-up, das sich mit Chaos Engineering beschäftigt. Dieses sorgt dafür, dass auch Systeme, die aus vielen verschiedenen Microservices und verteilten Architekturen bestehen, robust sind und bei Ausfällen einzelner Bereiche ihre Funktionalität aufrechterhalten. 

Auf der Suche nach dem Sweet Spot of Innovation

Bei der Gründung von steadybit gab es eine grobe Ahnung von einem Problem, daraus entstand die erste Produktvision: "Wir wollen Schwachstellen in Systemen finden und bekämpfen, bevor sie Schaden anrichten können." Diese Vision war zunächst nur eine unbestätigte Hypothese. Jetzt hieß es: prüfen, lernen, verstehen – lange bevor das Konzept Skalieren überhaupt irgendwo Platz im Kopf findet. Doch wie geht es konkret los? Hier kamen UX&I als UX-Experten mit an Bord. 

Die ersten beiden Aspekte waren bei steadybit abgedeckt, Spitzenentwickler*innen standen bereit und die Finanzierung war für den Moment gesichert. Für die Desirability brauchten wir nun die UX-Brille – und damit die Ausrichtung an den Nutzer*innen. Sie sind es, die uns bei der Problemfindung helfen und uns verraten können, wie die Lösung für sie attraktiv wird. Aber wie kommen wir an sie ran?

Runter von der Couch

Nutzerbedürfnisse erfassen und verstehen

Unsere Regel Nummer 1: Du bist nicht der/die Nutzer*in. Und: Erkenntnisse über Nutzer*innen, Markt, Kundensegment oder über die Branche findest du nicht auf deiner verdammt gemütlichen Couch. Das können wir so klar formulieren, da wir bei steadybit auch erstmal brav Value Propositions, User Journeys, Product Vision und Personas definiert hatten. Auf der gemütlichen Couch. Bis wir merkten, wir drehen uns im Kreis, jetzt muss was passieren. Nur durch Research im Kontext können wir Bedürfnisse, Ziele und Probleme von Menschen entdecken und verstehen.

Wie viel Research darf’s denn sein?

Da Research mit Aufwand und Kosten verbunden ist, wird uns oft die Frage gestellt: Wie viel Research brauchen wir unbedingt? Darauf gibt es keine klare Antwort, aber eine Wahrheit: null Menschen, null Erkenntnisse (Eric Ries: “The Audacity of Zero”). Deshalb: Raus gehen, potenzielle Nutzer*innen fragen, es lohnt sich immer.

Verständnisebenen

Grundlegend solltest du dir immer über drei Verständnisebenen im Klaren sein:

• Warum benutzt der/die Nutzer*in das System überhaupt? Welche Bedürfnisse stecken dahinter?
• Was will er oder sie mit der Software erreichen, welche Ziele und Aufgaben stehen im Vordergrund?
• Wie verhält sich der/die Nutzer*in auf operativer Ebene, wie wird die Software bedient?

Ein Beispiel: 

Warum: Ich vermisse gerade meine Freundin und habe das Bedürfnis, sie mal wieder zu sehen.

Was: Ich möchte gern mit ihr sprechen.

Wie: Ich bediene mein Handy so, dass ein Gespräch mit ihr aufgebaut wird.

Merke: Probleme, die auf der Warum-Ebene stattfinden, kannst du nicht auf der Wie-Ebene lösen. Wenn es in den Motiven Unstimmigkeiten oder Unklarheiten gibt, kann das Interface noch so gut sein, es wird nicht genutzt. Zu den Motiven und Grundbedürfnissen, die in der digitalen Produktentwicklung relevant sind, zählen z. B. Zugehörigkeit, Autonomie und Kompetenz (vgl. Aktivitätstheorie von Diefenbach und Hassenzahl).

Hypothesen sammeln

Um möglichst gezielt vorzugehen, halten wir uns an vier Kernthemen, die wir verstehen möchten. 

1. Benutzer und Benutzergruppen
2. Motive, Ziele und Aufgaben
3. Arbeitsmittel
4. Soziale, physische und technische Umsetzung

Jedem dieser vier Bereiche ordnen wir die zu untersuchenden Hypothesen zu. Im Fall von steadybit sah das so aus:

Rein in den Dialog

Wir wissen nun, was wir fragen wollen, doch wie machen wir das am besten? Mittlerweile gibt es eine große Auswahl von Research-Methoden, jede mit eigenen Stärken in unterschiedlichen Kontexten. Bevor du dich für eine Methode entscheidest, solltest du dir vor allem zwei Fragen stellen: Benötigst du qualitative oder quantitative Ergebnisse und möchtest du eher etwas über das Verhalten herausfinden (die Verständnisebene “Wie”) oder über Einstellungen und Ziele (Verständnisebenen “Warum und Was”)?

Für uns war schnell klar, dass Interviews die passende Methode für den primären Research sind, wir haben aber parallel auch Remote Usability Tests und Umfragen für spezielle Fragestellungen durchgeführt. 

Wir haben also unsere Komfortzone verlassen, unser Netzwerk aktiviert und potenzielle Nutzer*innen und Entscheider*innen um Gespräche gebeten. Wir haben gut zugehört, nachgebohrt und sind im Problemraum geblieben. Das heißt, wir wollten nie steadybit verkaufen, sondern erfahren, welche Probleme die Menschen heute haben und wie sie aktuell damit umgehen.

Was passiert mit den Research-Ergebnissen?

Nach den Interviews waren alle stolz. Wir hatten tolle Gespräche geführt, viel erfahren – und unglaublich viele Informationen gewonnen. Aber: Wer soll das alles lesen? Was bedeuten die Erkenntnisse für unser Produkt? Wir brauchten einen Weg, den riesigen Wissensberg zu verdichten, zu teilen und zu nutzen. 

Affinity Mapping

Eine hilfreiche Methode zur Analyse von Interview-Notizen haben Karen Holtzblatt & Hugh Beyer entwickelt. Ziel des Affinity Mapping ist ein strukturiertes Kondensat aller gesammelten Erkenntnisse. Es geht vor allem darum, die Stimme der Nutzer*innen aufmerksam wahrzunehmen und zu verstehen. Alles, was du brauchst, um diese Methode selbst auszuprobieren, ist ein Raum (bzw. Miro-Board), zwei bis sechs Teilnehmer*innen und Stickies in vier Farben. Kern des Vorgehens ist es, dass das Team die Aussagen der Interviewten in eigene Stories und Interpretationen umwandelt. Diese Stories werden gemeinsam immer mehr geclustert, bis schließlich einige wenige Core-Stories übrigbleiben – Kondensate, über die nun ganz konkret gesprochen werden kann und aus denen klare Erkenntnisse für die weitere Produktentwicklung abgeleitet werden können.

Ganz wichtig dabei: Es muss immer aus der Nutzerperspektive argumentiert werden und der Problemraum darf nicht verlassen werden. Lösungsansätze sind hier tabu. Eine detaillierte Schritt-für-Schritt-Anleitung mit allen Regeln haben wir dir vorbereitet: Cheat Sheet: Affinity Mapping.

Was haben wir bei steadybit aus dem Affinity Mapping gelernt? Beispielsweise die zentrale Erkenntnis, das Nutzer*innen Angst haben, mit Chaos Engineering etwas kaputt zu machen. Auch für unsere Hypothesen ergaben sich überraschende Einsichten – zum Beispiel, dass Entwickler nicht unbedingt zu unserer Zielgruppe dazugehören, da Chaos Engineering gar nicht in ihrem Territorium liegt. Wir haben neue Probleme entdeckt und gemerkt, wo wir noch tiefer nachbohren müssen und welche weiteren Hypothesen wir testen sollten. Unser Entwicklungs-Backlog konnten wir entsprechend priorisieren und festlegen, was wir als Nächstes bauen und ausprobieren wollen. Außerdem konnten wir auch schon eindeutige Gestaltungs- und Kommunikationsprinzipien für unser Produkt ableiten.

Das Problem ist erkannt – ran an die Lösung

Es ist vollbracht, unsere Hypothesen sind überprüft, zum Thema Desirability als Kernaspekt des Sweet Spot of Innovation haben wir jede Menge gelernt. Diese Erkenntnisse über das Problem müssen nun in den Lösungsraum überführt werden, wir beschäftigen uns mit der Feasibility: Wie können wir etwas Gutes bauen? Aber: Es ist nicht immer einfach, eine gemeinsame Lösung zu entwickeln. 

Design Studio Workshop (aka Crazy 8 oder Crazy 6)

Um ein einheitliches Verständnis und eine gemeinsame Sprache zu finden, hilft die Methode Design Studio Workshop. Sie ermöglicht es, in kurzer Zeit viele Ideen zu erzeugen, zu iterieren und zu schärfen – durch gemeinsames Denken, Scribbeln und Diskutieren. Und sie macht auch noch richtig Spaß. In der Regel steht am Ende ein Prototyp oder ein Layout. Am besten funktioniert die Methode in drei Iterationen mit drei bis sechs Teilnehmer*innen. Essenziell ist, dass es bereits eine konkrete Fragestellung und damit einen Rahmen gibt, z. B. in Form einer User Story oder Job Story (bei steadybit war dies unter anderem: “Als Nutzer*in möchte ich schnell und einfach mein Target definieren und sicher sein, dass ich auch das Richtige attackiere, damit nichts kaputt geht, was nicht kaputt gehen soll.”)

Wie funktioniert die Methode? Jedes Teammitglied faltet ein Din-A-4-Blatt in sechs oder acht Rechtecke und scribbelt in jedes Rechteck eine Lösungsidee. Im Anschluss pitcht jede*r Einzelne dem Team seine oder ihre Ideen und erhält Feedback aus dem Team. In der zweiten Iteration wird geklaut: Aus allen Ideen darf bunt gemischt werden, aus den besten Ansatzpunkten werden neue Ideen gescribbelt. Schließlich wird ein Best-of gezeichnet oder modelliert: Ein Driver leitet an und alle machen mit. Auch für diese Methode haben wir ein  Kochrezept für dich zum Herunterladen: Cheat Sheet: Design Studio Workshop.

Fazit

Durch Nutzerzentrierung und die passende UX-Methodik konnte steadybit von Anfang an durchstarten und Hürden überspringen. Unsere Key-Learnings aus dem Prozess:

• Wichtige Erkenntnisse finden wir nur außerhalb unseres Gebäudes Zoom-Raums.
• Lernen ist nie zu Ende und findet außerhalb der Komfortzone statt.
• Pivotieren und validiertes Lernen ist nicht schwer, man muss es aber machen (wollen und dürfen).
• Das richtige Produkt gut bauen geht nur interdisziplinär.

Wenn du mehr erfahren willst, steadybit erklärt in einem separaten Artikel (auf Englisch), wie das Tech-Start-up den Grundstein für seine Produktvision gelegt hat. Zusätzlich können wir dir folgende Artikel und Bücher zum Thema empfehlen: 

• Lean UX von Jeff Gothelf und Josh Seiden
• Lean Startup von Eric Ries
• Game Storming von Dave Gray, Sunni Brown und James Macanufo
• UX for lean startups von Laura Klein
• Testing Business Ideas von David J. Bland und Alex Osterwalder