Wie vor allem drei Projekte dazu führten, dass ich mein Leistungsspektrum reflektiert und neu gedacht habe
2020 und das Jahr der digitalen Nachweise
Eines meiner ersten großen Projekte war die Digitalisierung von Nachweisverfahren für das Bundesinnenministerium. Am Beispiel der Geburtsurkunde.
Ich hab den UX-Research-Fahrplan akribisch eingehalten, da ich als frischer UX Lead auch alles richtig machen wollte. Bürger:innen interviewt, Behörden interviewt, Service Blueprints gebaut. Und irgendwann stand da ein Bild an der Wand, das ziemlich eindeutig war: Der optimale Prozess für Bürger:innen hätte bedeutet, dass sich in den Behörden sehr viel ändern muss. Es gab z.B. (zu dem Zeitpunkt) Gesetze, nach denen Beurkundungen zwingend auf Papier gedruckt werden mussten. Es hätte neue Software gebraucht, neue Abläufe, andere Zuständigkeiten.
Nur: Wir sollten die Nutzerjourney der Bürger:innen optimieren. Diese ganze zweite Ebene (nennen wir sie Behörden-UX) lag außerhalb dessen, was wir bearbeiten durften.Die politischen, rechtlichen und organisatorischen Abstimmungen lagen bei anderen Teilen des Projektteams. Aus meiner UX-Rolle heraus war für mich nicht (jedenfalls nicht immer) transparent, wie unsere Erkenntnisse dort weiterverwendet wurden.
Und das war das erste Mal, dass ich dieses Gefühl hatte: Ich habe hier etwas Wichtiges gefunden, aber ich hatte damals weder die Rolle noch das Mandat, dieser Ebene weiter nachzugehen.
Danach habe ich eine Weiterbildung in Service Design gemacht. Weil ich noch besser verstehen wollte, wie ein gesamter Service im Einklang optimiert werden kann und mit welchen Methoden und Argumenten das möglich wäre.
(Mehr zum Projekt und den Ergebnissen: https://www.malin-rebke.de/arbeit/digitale-nachweise)
Ein paar Jahre später, dieselbe Erfahrung — Ursache gefunden aber kein Handlungsspielraum.
Ein Finanzunternehmen wollte ein neues Produkt bei einer jungen Zielgruppe platzieren. Eine Kampagne für die junge, digital-affine Generation. Wir haben eine quantitative Befragung aufgesetzt und dabei auch abgefragt, wer das Unternehmen überhaupt kennt und mit welchen Werten die Befragten das Unternehmen assoziieren.
Das Ergebnis war klar und eigentlich ein Geschenk: Die Marke war positiv besetzt. Sicher, seriös, vertrauenswürdig. Und: etwas für Ältere.
Damit war die eigentliche Aufgabe eine andere geworden. Bevor man eine Kampagne für eine junge Zielgruppe fährt, braucht es eine Idee davon, wie diese Marke für junge Menschen überhaupt relevant wird. Sonst zahlt man Reichweite für eine Botschaft, die nicht andockt.
Stattdessen wurde die Kampagne gemacht. Im bestehenden Corporate Design. Die Insights zur Markenwahrnehmung blieben liegen.
Was daraus geworden ist, weiß ich bis heute nicht.
Warum Insights liegen bleiben, hat selten mit ihrer Qualität zu tun. Meine Erfahrung ist: Die Antwort liegt selten im Projekt, sondern in der Organisation — in Zuständigkeiten, in gewachsenen Selbstbildern und in der Frage, wer sich mit welchem Teil eines Unternehmens eigentlich identifiziert. Darüber schreibe ich aber ausführlicher in einem eigenen Beitrag.
Und ich muss ehrlich sein: Ich habe diese Aufträge angenommen, wie sie zugeschnitten waren. Ich habe die Insights vorgelegt und mich geärgert, aber ich habe nicht darauf bestanden, die Frage vorher gemeinsam größer zu stellen. Das war nicht meine Rolle, dachte ich. Ich glaube heute, dass genau das die Rolle ist.
Und dann das Projekt, das alles verändert hat
Es ging um Finanzprodukte auf Basis einer Technologie, die bei Kund:innen bis heute kaum bekannt ist. Die regulatorischen Rahmenbedingungen waren offen, die technische Infrastruktur unfertig, der Markt in Deutschland existierte praktisch nicht.
Unser Auftrag: validieren, ob es für diese Art Finanzprodukte eine Nachfrage gibt. Nur… Kund:innen haben keine Nachfrage nach Technologie. Sie haben Nachfrage nach dem, was eine Technologie ermöglicht. Und kaum jemand kannte die Technologie, um die es ging.
Der naheliegende Ausweg wäre gewesen, nicht nach der Technologie zu fragen, sondern nach dem, was Kund:innen von ihr gemerkt hätten: eine geringere Mindestanlagesumme, eine sofortige Abwicklung, niedrigere Kosten. Nur hätte das nichts gebracht.
Denn eine Frage ist erst dann eine Researchfrage, wenn das Ergebnis auch negativ ausfallen kann. „Günstiger, schneller, niedrigschwelliger“ kann kein Nein produzieren. Wer das abfragt, misst Zustimmung, nicht Nachfrage. Und Zustimmung ist keine Information, weil sie vorher schon feststand.
Nachfrage entsteht aus Nutzen minus Preis. Und mit "Preis" meine ich nicht Gebühren, sondern das, was jemand aufgeben muss: Vertrautheit, Absicherung, Verständlichkeit, Beratung, die Gewissheit, wieder rauszukommen. Aussagekräftig ist ausschließlich diese Kostenseite. Der Nutzen ist (in diesem Fall) trivial.
Und genau daran wurde die zweite, interessantere Stelle sichtbar: „Diese Art von Produkt“ war gar kein Produkt. Es war eine Spannbreite.
An einem Ende hätte die Technologie nur die Bauweise verändert — das, was hinter dem Produkt liegt, nicht das, was vorne bei den Kund:innen ankommt. Für Kund:innen hätte sich praktisch nichts geändert, außer, dass es günstiger geworden wäre. Man hätte Bestehendes schlicht ersetzen können. Da gab es keinen Preis, den jemand hätte zahlen müssen und damit auch keine Entscheidung zu beobachten. Wer keinen Unterschied merkt, hat keine Präferenz.
Am anderen Ende standen wirklich neue Anlageformen, die Dinge möglich gemacht hätten, die vorher nicht gingen. Dort wäre die Kostenseite groß gewesen: neues Vertrauen, neue Begriffe, offene Fragen zu Sicherheit und Ausstieg. Dort hätte ein Nein entstehen können. Nur hingen diese Produkte an Infrastruktur und Regulierung, die es noch nicht gab. Und genau dort wäre ein Test heikel geworden — aus einem sehr nachvollziehbaren Grund: Man weckt keine Erwartungen, die man vielleicht nie einlösen kann.
Am Ende blieb die Frage unbeantwortet. Unten war Validierung überflüssig, oben war sie zu früh.
Rückblickend war weder die Research das Problem noch die Vorsicht des Auftraggebers. Das Problem war vor allem das Wort validieren.
Validieren kann man etwas, das existiert. Was hier vorlag, war kein Produkt, das man prüfen konnte, sondern ein Möglichkeitsraum, den man hätte durchdenken müssen. Für diese Aufgabe hatten wir kein Werkzeug im Koffer.
Dabei hätte sich damit auch die Sorge des Auftraggebers erledigt. Ein Szenario verspricht nichts. Man kann mit Kund:innen sehr offen über eine mögliche Zukunft sprechen, ohne ihnen ein Produkt in Aussicht zu stellen — weil beide Seiten wissen, dass über ein Vielleicht geredet wird. Zukunftsmethoden lösen genau das Problem, an dem eine klassische Validierung hier scheitern musste.
Was ich heute stattdessen vorschlagen würde
- Eine Zukunftswerkstatt mit Kund:innen, bei der es nicht darum geht, Präferenzen abzufragen, sondern gemeinsam zu erkunden, wie sie sich ihre Zukunft in diesem Feld überhaupt vorstellen.
- Eine Map der technischen Infrastruktur: Was existiert schon, wo sind die Baustellen, wovon hängt was ab?
- Prototypen, die nicht in der Gegenwart getestet werden, sondern in verschiedenen Szenarien, je nachdem, wie sich Regulierung und Technik entwickeln.
- Eine Einordnung über die Three-Horizons-Methode: Was ist morgen machbar, was übermorgen, was vorerst nicht?
- Und daraus eine Product Roadmap, die mit Unsicherheit rechnet, statt sie wegzudefinieren.
Das Ergebnis wäre nicht „die Nachfrage ist nicht da“ gewesen. Es wäre gewesen: Unter diesen Bedingungen lohnt es sich, unter jenen nicht — und das sind die Signale, auf die wir achten.
Inzwischen gibt es solche Produkte am Markt. Noch nischig, noch nicht besonders innovativ. Ich hätte sie gerne mal mit Kund:innen getestet.
(Mehr Infos zu Service Design im Finanzsektor: https://www.malin-rebke.de/arbeit/finanzsektor)
Was ich daraus mitnehme
Aus den drei Projekten ergab sich ein Muster für mich: Beauftragt wird, was sich benennen lässt. Das eigentliche Problem lag jedes Mal dort, wo es dafür noch keine Sprache gab.
Zweimal war der Auftrag zu eng geschnitten. Beim dritten Mal war er nicht zu eng, sondern falsch benannt: „Validieren" setzt voraus, dass es schon etwas gibt.
Das ist kein Vorwurf an meine Auftraggeber:innen. Wir haben alle so gearbeitet, wie man eben arbeitet. Man beauftragt, was man benennen kann: eine Kampagne, eine Journey, eine Befragung. Und bekommt dann sehr sauber genau das.
Was sich für mich verändert hat: Ich fange nicht mit der Frage an, was gebaut werden soll, sondern mit der Frage, in welcher Welt es funktionieren muss. Design Futuring und Systemic Design geben mir dafür das Werkzeug. Es geht nicht darum, die Zukunft vorherzusagen, es geht darum, mehrere mögliche Zukünfte durchzudenken, die wünschenswerten wie die unbequemen, und daraus abzuleiten, welche Entscheidungen heute in möglichst vielen davon noch tragen.
Und die ehrliche Frage, die ich Teams inzwischen stelle:
Wann habt ihr zuletzt darüber gesprochen, wie die Welt aussieht, in der dieses Produkt in fünf Jahren funktionieren soll?
Die häufigste Antwort ist: noch nie. Nicht weil es niemanden interessiert, sondern weil es kein Format dafür gibt.
Diese Perspektive verändert auch die Formate, an denen ich gerade arbeite. In einem neuen dreitägigen Workshop verbinde ich Research, systemische Analyse und AI-gestütztes Prototyping. Mehr dazu schreibe ich in einem eigenen Beitrag.
Was neu auf der Seite ist
- Design Futuring & Systemic Design — der neue Schwerpunkt
- Service Design — geschärft, mit systemischer Perspektive
- UX Research — bleibt, weil es das Fundament bildet
- Und dieser Blog — um meinen Gedanken und Ideen einen Raum zu geben
Lass uns reden
Wenn du gerade an einem Produkt oder Service arbeitest — neu oder in Überarbeitung — und das Gefühl hast, dass die eigentliche Frage vielleicht größer ist als das, was auf dem Ticket steht: Genau darüber unterhalte ich mich gerne.
Lass uns in einem ersten Gespräch gemeinsam schauen, wo ihr eigentlich hinwollt. Was danach sinnvoll ist — UX Research, Service Design oder Design Futuring —, ergibt sich daraus.
→ Schreib mir kurz, worum es geht
