Tonn.io • Innovation & Experience Design

VOM NUTZERBEDÜRFNIS ZUR PLATtFORM

CASE STUDY ÜBER NUTZERZENTRIERTE PRODUKTENTWICKLUNG 

ac33ac18-9ff3-48f6-bc13-a244b4fb5e19_rw_1920.jpg
 

AUSGANGSLAGE

Als Projektmitglied eines IT-Beratungshauses, wurden wir beauftragt, ein Analyseportal für E-Auto-Ladestationen zu entwickeln. Das Portal diente als Service-Schnittstelle erweiternd zum eigentlichen Angebot, das Full-Service leasen von E-Auto-Ladestationen. In der Gesamtheit bietet das Leasing-Angebot Wartung, Abrechnung, Installation, Hardware, die digitale Verwaltung und Analyse von Verbräuchen all-inclusive zu einem überzeugenden monatlichen Preis. Das Value Proposition aus dem Angebot ist das sorglose versorgen der E-Autos ohne sich mit der nötigen Infrastruktur und den technischen Herausforderungen auseinander setzen zu müssen. 

Der Ausgangspunkt des Projektes war ein Lastenheft mit unterschiedlichsten Anforderungen, gewünschten Funktionen und Datensichten. Solche Lastenhefte sind das tägliche Brot von IT-Beratungshäusern. Je nach strategischer Ausrichtung ist der eigentliche Beratungsteil nicht zu hoch und wird als ausführende Kraft für Entwicklung und IT-Infrastruktur wahrgenommen. Dieses drückt sich meist in Lastenhefte aus. Die Begegnung auf Augenhöhe und das Hinterfragen von Anforderungen ist eigentlicher Teil einer beratenden Tätigkeit. Eine Bedarfsanalyse aus Nutzerperspektive war für beide Parteien Neuland. Eine spannende Herausforderung in einem wachsenden Marktsegment!

KICK-START

Dank eines modernen und aufgeschlossenen Teams, waren die Ansätze von nutzerzentriertem Design wohlwollend angenommen worden. Das ermöglichte den Weg effizienter und nutzerzentrierter Produktentwicklung zu beschreiten. Als Grundlage nutzten wir das Double-Diamond-Process-Framework. Es kombiniert Ansätze wie Design-Thinking, Human-Centered-Design und Lean Startup.   

a443e044-eaf7-4cb9-9393-249371992605_rw_1920.png

Bei der Produktentwicklung in neue Marktfelder geht es vorerst nicht darum, „es richtig zu tun“, sondern zu identifizieren „was das Richtige ist“. Öffne den Blick über das Lastenheft hinaus und identifiziert die unterliegenden Bedürfnisse und Anforderungen. Am wichtigsten sind dabei unausgesprochene Hypothesen und Spannungsfelder. Als Kick-off führten wir ein De-Brief-Meeting mit den Stakeholdern durch. Ich nenne das gerne RIP-the-Brief, da die gewonnenen Erkenntnisse weit über das anfängliche Briefing hinausgehen. Wenn die formulierten Anforderungen hinterfragt werden, erfährt viel über die angestrebte Strategie und baut im Dialog ein tiefgreifendes Verständnis für den Kunden und seine Herausforderungen auf.

Wichtige Take-Away’s waren das Eingrenzen der Zielgruppe auf die Business-Segmente „Unternehmen mit E-Mobilität-Ambitionen“ sowie „Gastro- und Hotelgewerbe“. Der zweite Aspekt war die Erkenntnis, dass hinter den anfänglich formulierten Anforderungen noch viele Fragen offen waren. Es war nicht ganz klar, was der Endkunde eigentlich braucht. Daher gab es viel Rückhalt für die angestrebte Research-Phase.  


RESEARCH PHASE

Ausgestattet mit den Erkenntnissen aus dem RIP-the-Brief, deren Hypothesen und Spannungsfelder starteten wir in die Research-Phase, um die nötigen Antworten zu finden. Eine Herausforderung war das Gewinnen von Interview-Teilnehmern, welche bereits aktiv im Rahmen von E-Mobilität waren. Ziel waren 5 Probanden für Hotel oder Gastronomie-Betriebe und 5 Teilnehmer für Unternehmen mit E-Fuhrparks oder E-Autos von Mitarbeitern. Wir benötigten Personen, welche in den Verwaltungs- und Geschäftsprozessen rund um Fuhrpark, Abrechnung, Mitarbeiter oder Kundeninteraktion integriert waren.

Die Anzahl 5 Teilnehmer pro Zielgruppen-Segment klingt etwas zufällig, ist aber fundiert auf viele User Experience Studien von Don Norman. Dieser fand heraus, dass ab einer Anzahl von 5 Testpersonen, Erkenntnisse stark abnehmen.  

d3ca9548-c1a0-4670-9691-305b0355d2c9_rw_1920.jpg

Selbst das Gewinnen von 10 Teilnehmern aus den Kontakten unseres Auftraggebers gestaltete sich schwierig. Diese waren nicht so ergiebig und Reaktionen auf die Anfragen gab es nur schleppend. Daher hatten wir uns entschlossen einen öffentlichen Aufruf zu machen, intern als auch extern. Als Beispiel kam über einen Twitter-Post ein Kontakt mit einem Hamburger Hotelier zustande, welcher schon E-Auto-Ladestationen in seinen Hotels im Einsatz hatte. Es entstand ein Dialog, der viele Insights aufgezeigte und sehr aufschlussreich gewesen ist. Meiner Erfahrung nach sind Menschen im Allgemeinen sehr hilfsbereit und nehmen sich Zeit mit einem ins Gespräch zu kommen, auch ohne dafür entlohnt zu werden. Dieser Fall war das beste Beispiel dafür.

9d3f7790-54ae-4602-a82b-b469afafebdf_rw_1920.png

Meine Empfehlung ist das Recruiting immer selber zu machen, anstatt auf einen Recruiting-Service zurückzugreifen. Es selber durchzuführen benötigt zwar den Einsatz der eigenen Zeit, hat aber einige Vorteile: Es ist schneller, da man innerhalb weniger Tage bereits erste Kontakte generiert hat und direkt in die ersten Interviews starten kann. Es bietet mehr Kontrolle vor, während und nach den Interviews über den Kontakt. Sollten sich Rückfragen ergeben, würde man bei einem Recruiting-Service ein weiteres Mal bezahlen müssen. Die Beziehung zu den Probanden wird nicht von einem selber kontrolliert. Vor allem ist es günstiger! Es muss nur etwas Zeit investiert werden und evtl. eine Entlohnung z.B. mit einem 50€ Amazon-Gutschein. Das Rekrutieren von 10 Interview-Teilnehmern durch einen Service wie testingtime.com geht bei 350 Euro los und das Rekrutieren mit speziellen Eigenschaften liegt bei rund 900 Euro.

Wir hatten uns ein Zeitfenster von 4 Wochen gesetzt, um die Research-Phase abzuschließen. Das war ein sportlicher Zeitrahmen aber durchaus machbar. Für beide Zielgruppen haben wir individuelle Interviewleitfäden erstellt, um den unterschiedlichen Anforderungen der Zielgruppe an ein solches System gerecht zu werden.

Wir planten 10 Interviews, wovon wir 8 erfolgreich durchführten. Ein Interview davon war ein Stück für die Kuriositätensammlung: Der Teilnehmer, mit dem ich den Termin vereinbart hatte, war im Nachhinein betrachtet wohl dazu verdonnert worden. Dementsprechend verlief auch der Dialog! Der Teilnehmer unterbrach den Ablauf direkt am Anfang, ließ kein Intro, keine Kontextanalyse zu und betete genervt seine Top 5 Features runter. Ich konnte zwar noch zwei Rückfragen stellen, dann war aber auch schon Schluss. Ich bedankte mich dennoch für seine Zeit und das geteilte Wissen.

Egal ob jetzt in diesem speziellen Fall oder allen anderen Interviews, falls es sich einrichten ließ, hatte ich die Stakeholder eingeladen passiv an den Interviews teilzunehmen. Ein kurzes Briefing und die Interviews liefen reibungslos. Die gewonnenen Erkenntnisse waren nicht nur für die Analyse-Plattform wichtig. Zum Beispiel stellte sich schnell heraus, dass das Gastro- und Hotelgewerbe grundlegende andere Anforderungen an das Business-Modell stellten als angeboten. Dies sorgte dafür, dass wir nicht alle Interviews durchführten. 

Das Beispiel zeigt leider, dass Entscheidungen aus Fachabteilungen oder Projektteams rein aus dem Bauch heraus, den Erfahrungswerten oder der Teamdynamik getroffen werden. Wir alle haben Beispiele im Kopf von Entscheidungen die in Meetings oder vom Chef getroffen worden. Dabei ist es längst erwiesen, dass die erfolgreichsten Unternehmen dafür sorgen, dass die Projektteams so häufig und intensiv wie möglich mit ihrer Zielgruppe interagieren. Dieser konstante Fluss an Informationen und Strömungen bilden dann die Grundlage für Entscheidungen. Anyway …  

Die gewonnen Erkenntnisse von der Zielgruppe „Unternehmer“ wurden konsolidiert, strukturiert und in leicht verständliche Formate umgewandelt. Mit diesem Input sind wir in den Design-Workshop gestartet.


USER EXPERIENCE DESIGN

Der Design-Workshop stellt einen Wechselpunkt dar. Das Team wechselte vom Problem-Space in den Solution-Space. Die Ergebnisse der Research Phase stellten sicher, dass wir das Richtige tun! Es ging jetzt darum diesen Input in die richtige Lösung umzuwandeln.

fd97628f-3f47-4fa6-8125-0f2aa3d0954c_rw_1920.jpg

Der Workshop startete, indem ich das Interdisziplinäre Team durch die Lebensrealität einzelner Interview-Teilnehmer führte. Dabei halfen Personas, Visualisierungen und Skizzen von Anwendungsszenarien. Aufgeladen mit Empathie über die Zielgruppe, haben wir unsere Aufmerksamkeit auf die Anforderungen der Nutzer gerichtet. Diese hatten wir in How Might We Statements umgewandelt und auf einzelne DIN A4 Zettel platziert. Diese waren grob priorisiert und wurden gemeinsam besprochen sowie in Kontext der Lebensrealität der Anwender gesetzt.

Wie können wir für die Mitarbeiter Fahrzeuge, den Mitarbeitern eine automatische Abrechnung erstellen?

How Might We Beispiel

Die Stakeholder hatten bei jeder Story die Möglichkeit strategische oder technische Bedenken zu äußern und die Statements aus dem Projekt zu nehmen oder in einen Backlog zurück zu legen. Bei all den Stories, welche es in die Designphase schafften, entstand ein gemeinsames Verständnis für die Nutzerperspektive.

Wie können wir den Betreiber visualisieren, wieviel Strom aus der Eigenproduktion geladen worden ist und wie diese sich in die Gesamtkosten widerspiegeln?

How Might We Beispiel

Solche und ähnliche How Might We Statements dienten als Grundlage, um gemeinsam Lösungsansätze zu finden. Um möglichst viele unterschiedliche Ideen zu generieren, nutzten wir das „Gemeinsam-Einsam-Zeichnen“. Jeder Teilnehmer zeichnete schemenhaft seine Ideen für das jeweilige Statement. Diese wurden nachfolgend vorgestellt und gemeinsam bewertet. Das hat den Charme, dass alle Ideen auf den Tisch kommen und sich gegenseitig ergänzen, ohne das sich die Teilnehmer auf dem Weg dorthin in Diskussionen verlieren.Nach etwa 4 Stunden Workshop hatten wir alle Stories durchgearbeitet und es existierte ein relativ klares Bild über den Scope und ein vielfältiges Set an Lösungsansätzen auf Basis von Teamkonsens.

0f8e57b8-ba9c-461b-bed4-415733c7780b_rw_1920.jpg

Ausgestattet mit dem Input aus dem Design-Workshop machte ich mich an das Interaktion-Design. Zu jeder Story gab es lose und unstrukturierte Ideen, welche in eine verständliche, logische und in sich geschlossene Form gebracht werden mussten. Es entstand eine Informationsarchitektur und die wichtigsten Screens als Mockups. Das Schöne war, jedem Element auf den Mockups Statements zuordnen zu können.

d518299f-7deb-4696-843d-d8dea2baea67_rw_1920.jpg

Wir hatten noch empfohlen die Mockups in einem simplen Klick-Prototyp umzuwandeln und mit einzelnen Interview-Teilnehmern noch einmal gegen zu prüfen, wozu ich aber leider nicht mehr gekommen bin.


TAKE AWAY

Die Schlüsselerkenntnis aus diesem Projekt ist für mich, dass Fachabteilungen geholfen werden muss aus ihren Silos zu kommen. Sich der Zielgruppe nähern und von diesem Ausgangspunkt Projekte und technologische Aktivitäten planen, anstatt sich direkt den Lösungen zuzuwenden.

Sinnbildlich hierfür sind die Wireframe, welche auf Basis der Anforderungen und Skizzen im Rahmen der Ausschreibung entstanden sind. Diese haben mit dem nutzerzentrierten Endergebnis relativ wenig zu tun. Was der Nutzer wirklich benötigt, haben wir auf dem Weg herausgefunden.

993c5567-3b24-411a-a776-1bd5e48d73a9_rw_1920.jpg


Don't solve the problem given to you. Solve the true underlying problem.

Don Norman