KPI-Centered Design

Human-Centered Design (abgekürzt HCD) ist ein Begriff, der schon seit den 1980er Jahren existiert (vgl. Mike Cooley: Architect or Bee?) und dennoch nach wie vor zu den hot topics in der digitalen Branche und insbesondere im e-Commerce gehört. Ein McKinsey-Quarterly-Report aus dem Jahre 2018 ‒ The Business Value of Design ‒ listet user experience (UX) und continuous iteration als zwei der vier Kernkompetenzen von “Überperformern” im Vergleich zum Industriedurchschnitt. Dennoch zeigt der Artikel auf, dass viele Unternehmen einen vernünftigen HCD-Prozess entweder von vornherein nicht betrachten oder nicht effektiv implementieren. In diesem Artikel möchte ich auf eine Form des Letzteren ‒ man denkt, nutzerzentriert zu arbeiten, verfehlt aber den Kern der Sache ‒ näher eingehen.

Bereits seit 2012 bin ich im e-Commerce-Umfeld unterwegs, habe in der Zwischenzeit für ein Start-up gearbeitet und an einer großen amerikanischen Universität geforscht. In dieser Zeit habe ich etliche Konferenzen, Seminare, Roundtables, Meetups und (größtenteils unsägliche) “Networking-Events” besucht und mit einer Vielzahl von anderen Teilnehmern über HCD und UX, aber auch über Themen wie conversion rate optimization (CRO) und growth marketing diskutiert. Dabei sind mir zwei Dinge wieder und wieder aufgefallen:

1. Es kommt häufig zu Verwechslungen zwischen UX, CRO und growth marketing, ein Thema, das ich in meinem Artikel “Growth Marketing Considered Harmful” in der kommenden Ausgabe von i-com aufgreife.
2. Viele, die davon erzählen, dass bei ihnen schon “Human-Centered Design gemacht wird”, betreiben häufig etwas grundlegend Anderes, dem ich den Rest dieses Artikels widmen möchte: KPI-Centered Design.

Die Theorie: Human-Centered Design

Der klassische double diamond (von Johanna Jagow basierend auf dieser Quelle.)

Wenn ich von einem “vernünftigen HCD-Prozess” spreche, was meine ich dann damit? Am liebsten verweise ich auf Don Normans Buch The Design of Everyday Things, in dem der HCD-Prozess unter anderem in Form des double diamond, der durch die Arbeit des British Design Council zusätzliche Berühmtheit erlangt hat, dargestellt wird. Sinn dieser zwei Rauten (bzw. Diamanten) ist, zu verdeutlichen, dass man in einem zweistufigen Prozess erst divergiert und dann wieder konvergiert, um ein Design-Problem zu identifizieren und danach mit dem größtmöglichen Nutzen für den Nutzer zu lösen. Hierbei können (oder sollten) eine Reihe von qualitativen wie quantitativen Forschungsmethoden angewandt werden, um sowohl die persönliche Einstellung von Nutzern (“attitudinal”) als auch deren tatsächliches Verhalten (“behavioral”) zu untersuchen.

Im linken Teil des Prozesses (“Discover & Define”) versucht man mittels eher ergebnisoffener Methoden eine Menge an pain points im Alltag von Nutzern bzw. während der Benutzung eines Produktes offen zu legen (Divergenz), um sich im Folgenden auf ein einzelnes Problem X zu verständigen, das zu lösen besonders erfolgsversprechend ist (Konvergenz). Die vermutlich effektivste und gleichzeitig valideste Methode, um echte Nutzerprobleme zu entdecken ist ethnographische Feldforschung, oder high-tech anthropology, wie Rich Sheridan es in seinem Buch Joy, Inc. im Kontext digitaler Produkte nennt. Da diese Methode aufwendig und ressourcenintensiv ist (insbesondere benötigt man viel Zeit und Geduld), kommt sie in der Industrie vergleichsweise selten zur Anwendung. Stattdessen wird eher auf Methoden wie Card Sorting, Umfragen und Nutzerinterviews gebaut, die wesentlich weniger aufwendig sind, allerdings auch weniger effektiv, da Nutzer nicht in ihrer “natürlichen Umgebung” beobachtet werden können.

Im rechten Teil des Prozesses geht es nun darum, für das identifizierte Problem X erst eine Reihe von möglichen Lösungen ‒ häufig in Form simpler Prototypen ‒ zu gestalten (Divergenz) und sich schlussendlich auf eine durch Nutzertests validierte Lösung festzulegen (Konvergenz). In dieser Phase sind die verwendeten Methoden weniger ergebnisoffen und quantitativer, da der Fokus mehr auf dem messbaren Nutzerverhalten und der Vergleichbarkeit der potentiellen Lösungen liegt. Im Anschluss wird die beste Lösung implementiert und weiter validiert; häufig ergeben sich weitere Iterationen (“Measure & Learn”). Ein HCD-Prozess ist somit eigentlich nie zu Ende, sondern mündet in der von McKinsey angesprochenen continuous iteration.

Die Praxis: KPI-Centered Design

Nach der Theorie schauen wir uns nun die Praxis an. Dazu möchte ich vorab gerne vorsorglich zwei Dinge klarstellen.

Zum Einen: Wenn ich von “der Praxis” sprechen, möchte ich nicht unterstellen, dass niemand einen vernünftigen HCD-Prozess verfolgt, ganz im Gegenteil! Ich beziehe mich hierbei lediglich auf meine Beobachtungen aus einer Vielzahl von Gesprächen, wie in der Einleitung beschrieben. Diese Beobachtungen treffen hoffentlich nicht auf die Mehrheit der Unternehmen zu, haben sich aber derart gehäuft, dass man nicht einfach keinen Artikel darüber schreiben könnte.

Zum Anderen: Ich finde es absolut nicht verwerflich, dass eine gewisse Diskrepanz zwischen Theorie und Praxis besteht. Alles andere wäre Realitätsverleugnung. An dieser Stelle möchte ich daher Al Roth zitieren: “In der Theorie gibt es keinen Unterschied zwischen Theorie und Praxis”. Problematisch wird es nur, wenn die Diskrepanz zu groß wird.

Eine solch große Diskrepanz besteht, wenn man von Human-Centered Design spricht, eigentlich aber lediglich das praktiziert, was ich gerne als KPI-Centered Design bezeichnen möchte. Das meint einen Prozess, der oberflächlich zwar scheint, als würde man sich stark auf den Nutzer fokussieren, weil man testet und iteriert ‒ und damit zumindest am Methodenset des HCD kratzt ‒, im Kern der Sache aber lediglich ein Fokus auf eine (oder mehrere) unternehmenskritische Zielmetriken (key performance indicator oder KPI) besteht. Dies begünstigt stark (aber selbstverständlich nicht ausschließlich) die Implementierung von dark patterns, insbesondere in digitalen Produkten. Ein klassisches Beispiel sind hier aggressiv gestaltete scarcity-Effekte, die durch geschickte Kommunikation eine künstliche Verknappung erzeugen und heutzutage auf vielen, wenn nicht gar den meisten, e-Commerce-Webseiten zu finden sind. Dabei wird aber lediglich ein kognitiver bias ausgenutzt, der Nutzer im Zweifel dazu veranlasst, Produkte zu kaufen, die sie eigentlich gar nicht brauchen oder wollen. Gut für die unternehmenskritischen Zielmetriken, aber human-centered? Zweifelhaft.

Die bei weitem häufigste Ausprägung von KPI-Centered Design habe ich im obigen Schaubild dargestellt. Sie basiert fast ausschließlich auf A/B-Testing (oder “Experimentation”, wie einige es nennen). Die linke Raute des Prozesses ist stark verkleinert; der “Discovery”-Part ist komplett verschwunden. Gearbeitet wird stattdessen mit Hypothesen, wie ein (digitales) Produkt verändert werden könnte, um eine bestimmte KPI zu beeinflussen. In dieser Phase können Nutzerbedürfnisse durchaus eine Rolle spielen, stehen aber wohl eher selten im Vordergrund, im Gegensatz zu klassischen Metriken wie einer conversion rate, die z. B. die Anzahl der Käufe oder Newsletter-Anmeldungen pro Nutzer beschreiben kann.

Im rechten Teil des Prozesses werden dann verschiedene Variationen basierend auf einer ausgewählten Hypothese gestaltet und schließlich in einem Experiment mit zufälligen (und ahnungslosen) Gruppen von Nutzern gegeneinander ausgespielt. Schneidet eine der Variationen bei der zuvor festgelegten primären Zielmetrik statistisch signifikant besser ab als die Kontrollgruppe, kann implementiert, ansonsten iteriert werden. Komplementär kann noch mit data analytics gearbeitet werden, um ebenfalls ein Auge auf sekundäre Metriken zu haben, die nicht direkt im Experiment gemessen werden.

A/B-Tests haben den großen Vorteil, dass sie schnell und ‒ im Gegensatz zu anderen Methoden der Nutzerforschung ‒ relativ einfach am “lebenden Produkt” durchgeführt werden können. Einer ihrer größten Nachteile besteht darin, dass sie lediglich aufzeigen, wie sich Nutzer verhalten, nicht aber warum genau sie es so tun. Daher kann ein A/B-Test durchaus eine KPI massiv erhöhen, die user experience aber gleichzeitig verschlechtern, ohne, dass man es bemerken würde.

Was kann ein einigermaßen vernünftiger Kompromiss sein?

A/B-Tests haben nun natürlich absolut ihre Daseinsberechtigung und man muss der Realität ins Auge schauen: Es ist praktisch unmöglich, jeden Designprozess exakt entlang des double diamond aufzubauen, insbesondere in der Industrie. Schnelle und unkomplizierte Methoden sind nötig, um kurzfristig Antworten auf dringende Fragen liefern zu können. Dazu müssen selbstverständlich Abkürzungen genommen werden. Und etwas Designprozess ist ja immer noch besser als gar kein Designprozess, nicht wahr‽ Denn man könnte natürlich auch praktizieren, was als “Design by Chance” bezeichnet werden kann. In dieser Ausprägung verschwindet der linke Teil des double diamond vollständig ‒ alle “Discovery”-Entscheidungen basieren ausschließlich auf Bauchgefühl.

Dennoch: Was kann ein einigermaßen vernünftiger Kompromiss sein? Wie kann man sicherstellen, dass man bei aller in der Industrie üblichen KPI- (und insbesondere conversion-)Zentriertheit nicht langsam den Nutzer aus dem Blick verliert und trotzdem immer noch glaubt, man würde Human-Centered Design betreiben?

Um das zu erreichen, passen wir den KPI-Centered-Design-Prozess an zwei Stellen an. Erstens sollten alle Hypothesen, wie ein Produkt verbessert werden könnte, mit harten, nutzerzentrierten Fakten, oder evidence, untermauert werden. Dies verhindert einen allzu starken Fokus auf Ideen, die lediglich auf Bauchgefühl basieren (im schlimmsten Falle auf dem eines HiPPOs). Beispiele für valide evidence können umfassen: Ergebnisse aus bereits abgeschlossenen Nutzerstudien oder Usability-Tests, Nutzerfeedback, Wettbewerbsanalysen, Heatmaps, Analytics-Daten etc. Hypothesen mit entsprechender evidence sollten grundsätzlich höher priorisiert werden als solche ohne. Dies vergrößert die “Define”-Raute wieder ein wenig.

Zweitens erweitern wir den rechten Teil des Prozesses um Usability-Studien und beliebige andere, eher qualitative Nutzerforschungsmethoden. Diese können bereits genutzt werden, um Designs für A/B-Test-Variationen zu validieren bevor sie in die Implementierung gehen, sollten aber spätestens nach einem abgeschlossenen A/B-Test eingesetzt werden, um das “Warum?” aufzudecken, nachdem man das “Wie?” erfahren hat. Diese zusätzliche qualitative Forschung sollte hierbei nicht als Beiwerk betrachtet werden, sondern als gleichberechtigter “Partner” neben dem A/B-Test, der notwendig ist, um ein vollständiges Bild aus KPI- und (so gut es geht) Nutzersicht zu erhalten. Selbstverständlich wird der Aufwand im Vergleich zu reiner “Experimentation” dadurch wieder etwas größer, doch auch hier gibt es effiziente, relativ ressourcenschonende Methoden ‒ wie z. B. think-aloud-Studien mit 5 bis 10 Teilnehmern. Diese können asynchron und vollständig online stattfinden und zumindest sicherstellen, dass keine groben Usability- oder UX-Probleme vorliegen bzw. durch die A/B-Test-Gewinnervariante verursacht werden (vgl. Jakob Nielsen: “Heuristic Evaluation of User Interfaces”). Es muss nicht immer ethnographische Feldforschung sein. Lassen Sie uns diesen angepassten Prozess alles in allem Evidence-Centered Design nennen, aufgrund des größeren Fokus auf nutzerzentrierte Fakten.

Ein anderer Ansatz, sich von KPI-Centered Design aus weiterzuentwickeln, und damit die linke Raute des Designprozesses zu vergrößern, kann ein (zusätzlicher) Fokus auf Produkt-KPIs statt der rein unternehmenszentrierten Klassiker ‒ Anzahl Bestellungen, Warenkorbgröße, Neuregistrierungen etc. ‒ sein. Frameworks, die sich hier anbieten, umfassen z. B. AARRR (aus offensichtlichen Gründen auch die “Pirate Metrics” genannt ) und North Star. Streng genommen ist ein solcher Prozess natürlich noch immer eine Ausprägung von KPI-Centered Design, jedoch mit Zielmetriken, die wesentlich näher am Nutzer sind (und dennoch die Unternehmensbedürfnisse nicht aus den Augen verlieren).

Fazit

Die in diesem Artikel adressierten Ausprägungen bzw. Abstufungen von Design-Prozessen, von Design by Chance bis hin zu echtem Human-Centered Design.

Auch wenn es etwas danach klingen mag, so ist A/B-Testing nicht der Kern des in diesem Artikel beschriebenen Problems. Dieser ist abstrakter und hat eher etwas mit der generellen Denkweise (bzw. dem mindset) und den allgemeinen Prioritäten in einem Unternehmen zu tun. A/B-Testing hat seinen berechtigten Platz im Set von Design- und Forschungsmethoden, taucht im Kontext von rein zielmetrikgetriebenem Design aber so häufig auf, weil die Methode ausschließlich quantitativ und dadurch extrem datengetrieben ist. Dies wird zusätzlich befeuert durch Ansätze wie Lean Startup, die ‒ falsch interpretiert ‒ den Eindruck vermitteln können, A/B-Testing im Gewand von “Experimentation” sei genug, um nutzerzentriert zu sein. Jedoch kann erst eine Kombination von Methoden, die unterschiedliche Fragestellungen beantworten, dazu beitragen, Nutzer wirklich zu verstehen.

Es ist absolut nichts einzuwenden gegen einen starken Fokus auf unternehmenskritische KPIs, schließlich ist business viability neben Nutzerzentrierung (und selbstverständlich technischer Machbarkeit) eine der Säulen guten Designs (vgl. Tim Brown: “Design Thinking”). Mein Wunsch ist lediglich: Wenn man sich dazu entschließt, diesen Ansatz zu verfolgen, dann sollte man ihn auch bitte das nennen, was er ist ‒ nicht nutzerzentriert, sondern KPI-Centered Design.

Acknowledgment

Vielen Dank an Daniel, der beim Korrekturlesen die Idee hatte, “Design by Chance”, AARRR und Northstar mit in den Artikel aufzunehmen.