Im März bin ich meinen ersten Halbmarathon gelaufen. Ich hatte einen Trainingsplan, eine Strecke, eine super Laufcommunity und ein Ziel.

Die Gründung eines neuen Studios funktioniert etwas weniger planbar: Es gibt keine Kilometeranzeige, keinen Trainingsplan, und niemand sagt dir, ob du gerade in die richtige Richtung läufst.

Und trotzdem, finde ich, fühlt sich dieser Schritt gerade doch überraschend passend an, denn eigentlich beschäftige ich mich schon seit fast 20 Jahren mit genau einer Frage, auf die sich meine Arbeit herunterbrechen lässt: Wie treffen wir bessere Entscheidungen, bevor wir viel Zeit, Geld und Nerven (und zwar auch die unserer Nutzer*innen)  in die falsche Richtung investieren?

Kurz: Warum bauen wir so häufig Dinge, bevor wir wirklich verstanden haben, was wir bauen sollten?

In fast 20 Jahren Branchenerfahrung habe ich immer wieder erlebt, vor allem am Anfang meines Berufslebens, dass Tech-Produkte und Services an den echten Bedürfnissen der Menschen vorbeigebaut werden. Das hat mich geprägt. Dazu kam ein ziemlich schiefes Verhältnis zwischen Tech und Design: gefühlte Heerscharen von Entwickler*innen, aber im Vergleich dazu eher wenige Menschen, die die menschliche Interaktion strategisch mitdenken. Das Prinzip war fast immer: erst das Tech-Konzept, dann der Code – und ganz am Ende oder parallel das Design.

Unter den vielen Entwickler*innen habe ich mich oft exakt so gefühlt:

POV: Ich frage mich wieso man ein Haus baut, bevor die Statik und die Wege darin geplant sind?

Code first und plötzlich Feldforscherin by accident

Zwei Momente sind bei mir aus dieser Anfangszeit besonders im Gedächtnis hängengeblieben und ich meine, sie haben mein Denken nachhaltig geprägt

Der erste war während der Entwicklung eines neuen digitalen Services. Der Code wurde bereits geschrieben, ich hatte damals noch etwas Frontend-Entwicklung gemacht. Weil das alles sehr mühsam und komplex war, fragte ich vorsichtig, ob wir nicht mal schauen sollten, was die Nutzer*innen eigentlich wollen, bevor wir das alles weiter so mühsam bauen. Die Antwort kam, während der Code weiter getippt wurde: „Machen wir doch schon."

Ich war damals irritiert, und konnte das auch nicht einordnen, was damit gemeint sein soll. Machen wir schon? Wo? Ich traute mich aber nicht, etwas zu sagen – ich war ja „nur" die Designerin, das Ding war: die Technik hatte einfach den Hut auf. Und ich glaube, das war der Moment, in dem mir klar wurde, dass der digitale Designprozess an dieser Stelle “flawed” ist - also etwas grundlegend falsch läuft. Offenbar existierten zwei völlig unterschiedliche Vorstellungen davon, was „machen wir doch schon" eigentlich bedeutet. Die einen meinten damit: bauen, launchen (und eventuell dann lernen) Ich hing gedanklich noch bei der Frage fest, ob wir überhaupt wirklich verstanden hatten, welche Fragen wir hier eigentlich adressieren.

Der zweite Moment war, als wir für ein Meeting in einem großen Industrieunternehmen zu Besuch waren, für das wir eine Enterprise-Software neu entwickelt haben. Ich kam in das Büro dieser Firma und sah bei einigen Mitarbeiter*innen, dass oben am Rand ihrer Monitore eine ganze Reihe Post-its klebten – alle mit demselben Inhalt. Ich fragte, warum die Post-its da klebten, und bekam eine Antwort, die heute fast lächerlich einfach wirkt: Die alte Software, die genutzt wurde (und die wir neu entwickelten), hatte riesige Tabellen. Beim Scrollen verschwanden die Tabellenköpfe. Also hatten sich die Nutzerinnen selbst einen Hack gebaut, damit sie überhaupt noch wussten, welche Spalte was bedeutete. Also, das war keine geplante Feldforschung, das ist einfach so nebenbei passiert.

Das war für uns eine ziemlich wichtige Info, aber sowas hätten wir wahrscheinlich in keinem Interview der Welt erfahren. Solche Dinge erfährt man oft erst, wenn man sieht, wie Menschen tatsächlich arbeiten.

Heutzutage hat sich einiges verbessert, keine Frage. UX und nutzerzentrierte Entwicklung sind mittlerweile Begriffe, die man niemandem mehr lange erklären muss. Das Muster hat sich zwar verfeinert, aber nicht komplett aufgelöst: Noch immer werden Budgets häufig in Umsetzung statt in Erkenntnis investiert, und viele Entscheidungen werden getroffen bevor Nutzer*innen überhaupt in den Prozess kommen.

Die Idee und Gründung von RRRAW ist meine Antwort auf ein Muster, das ich immer wieder erlebt habe: Die entscheidenden Fragen kommen oft erst dann auf den Tisch, wenn die Richtung längst feststeht.

Das Design beginnt vor dem Design

Ich habe  über die Jahre festgestellt, dass das, was mich wirklich interessiert, das ist, was noch vor dem sichtbaren Design passiert: Welche Annahmen haben wir? Was wissen wir wirklich? Welche Fragen werden gar nicht gestellt? Welche Bedürfnisse übersehen wir? Welche Risiken sehen wir noch nicht?

Mein Ansatz  basiert daher auf diesen drei Prinzipien:

1) Prävention statt „Therapie"

Die meisten Probleme, die ich in Projekten gesehen habe, waren erstaunlich selten rein technische Probleme. Meistens waren es Annahmen, die niemand überprüft hatte. Deshalb interessiert mich Prävention mehr als "Therapie". Also lieber früh merken, dass etwas nicht aufgeht, als ein halbes Jahr später hektisch Schadensbegrenzung zu betreiben.

2) Friction ist ein Feature 

Friction, also Reibung, ist meistens negativ konnotiert und gilt als etwas, das wir um Himmels willen vermeiden müssen. Ich meine mit Friction nicht unnötige Komplexität, sondern genau die Art Reibung, die sichtbar macht, wo unsere Annahmen nicht standhalten, Fragen und Bedürfnisse ungeklärt sind oder gar blinde Flecken existieren. Also die "gute", wichtige Friction.

Friction in dem Sinn ist im Entwicklungsprozess nicht unser Feind, sondern unser Freund. Nur wenn wir uns diesen "unbequemen" Dingen stellen, oder eben Antworten bekommen, die nicht ins Bild passen, lernen wir die wichtigsten Dinge.

Friction entsteht, wenn wir unseren Nutzer*innen zuhören, denn dabei bekommen wir auch Antworten, die nicht unseren Wünschen und Annahmen entsprechen. Friction entsteht aber auch, wenn wir im Team die teils unbequemen Fragen stellen oder vor allem auch bereit sind, unsere Annahmen zu hinterfragen. Diese Reibung ist wertvoll, denn sie verhindert nervige, zeitraubende und teure Fehlentscheidungen.

3) Beyond the User

Heutzutage betrifft ein Produkt oder Service selten nur die eine Person, die es nutzt. Klassisches „User Centred Design" greift deshalb oft zu kurz, weil es im Endeffekt nur auf das Individuum – die Nutzerin, den Nutzer – und das Business schaut. Aber die Komplexität unserer Produkte und Services kann soziale, psychologische und ökologische Domino-Effekte in der realen Welt auslösen.

Diese Konsequenzen sollten wir versuchen, frühzeitig zu erkennen. Wer das ignoriert, riskiert Akzeptanz- und Reputationskrisen. Ein Produkt endet nicht zwingend am Interface und ein Service nicht mit der Bewertung - und die Folgen davon sieht man oft erst draußen in der Welt.

Meine Idee hinter RRRAW steht für genau diese Arbeit: fundiertere Entscheidungen treffen, bevor sie teuer werden - zeitlich, monetär, fürs Gemüt und auch für die Gesellschaft. 

Für alles das steht dieses “De-Risking Business by Embracing Friction” auf der Startseite. Und während ich das gerade schreibe, denke ich, eigentlich ist das mehr als ein Claim der ausdrücken soll, welche Haltung und Idee hier dahintersteckt; embracing Friction ist vielleicht doch eher ein "Mindset", wie wir generell an Produkt-und Serviceentwicklung gehen.