Geht man den ersten Schritt allein?

TL;DR: Die erste Lösung braucht Überzeugung. Das bessere Produkt braucht die Fähigkeit, diese Überzeugung wieder loszulassen.

Irgendjemand muss den ersten Schritt machen

Nutzerzentrierte Produktentwicklung klingt in der Theorie angenehm geradlinig: mit Menschen sprechen, ihre Bedürfnisse verstehen, etwas entwickeln, Feedback einholen und die Lösung verbessern.

In der Praxis beginnt ein Produkt trotzdem häufig mit einer Entscheidung, die jemand zunächst allein treffen muss. Noch gibt es keine konkrete Oberfläche, auf die Nutzende reagieren können. Es existieren vielleicht Gespräche, Beobachtungen und erste Annahmen – aber irgendwann muss daraus ein Entwurf werden.

Dieser erste Schritt ist ein Educated Guess. Er beruht auf Erfahrung, Umsicht und dem bisherigen Verständnis des Problems. Und er braucht Überzeugung. Ohne sie bleibt eine Idee abstrakt. Niemand investiert Zeit in einen Entwurf, den er selbst nicht für plausibel hält.

Der erste Entwurf soll zeigen: Ich habe zugehört. Ich habe das Problem verstanden. Ich kann eine mögliche Lösung vorweisen.

Doch genau darin liegt auch eine Gefahr.

Eine vollständige Lösung, die niemand benutzen wollte

Bei einem frühen Produktentwurf brauchte die Anwendung eine größere Menge strukturierter Informationen. Das Datenmodell stand und aus technischer Sicht lag der nächste Schritt nahe: eine Oberfläche, über die sich alle benötigten Daten administrieren ließen.

Ich baute eine vollständige Eingabemöglichkeit. Die Felder waren vorhanden, die Informationen konnten sauber erfasst werden und alles landete dort, wo es im System hingehörte. Das war keine leichtfertige oder offensichtlich schlechte Lösung. Sie war nach bestem Wissen entstanden und erfüllte ihren Zweck.

Bei einem ersten Praxistest fiel die Reaktion darauf eindeutig aus.

Sinngemäß lautete sie: Diese riesige Formularseite fülle ich nicht aus. Warum lässt sich das nicht schlauer lösen?

Für mich waren die vielen Felder zunächst eine notwendige Voraussetzung. Die Anwendung brauchte diese Informationen schließlich, um ihren Nutzen entfalten zu können. Wer diesen Nutzen wollte, musste die Daten eben eingeben. Das erschien mir praktikabel.

Aus Nutzersicht war dieselbe Oberfläche kein notwendiger Schritt, sondern ein Blocker.

Die gleiche Lösung zeigte damit zwei unterschiedliche Seiten: Ich sah ein vollständig abgebildetes Datenmodell. Auf der anderen Seite stand eine große Menge Arbeit, die das Produkt seinen Nutzenden aufbürdete.

Wenn Kritik die eigene Expertise trifft

Meine erste Reaktion war nicht sofortige Dankbarkeit für das wertvolle Nutzerfeedback. Ich wollte meine Entscheidung verteidigen.

Das hatte auch damit zu tun, dass ich sorgfältig gearbeitet hatte. Man baut eine solche Lösung nicht mit dem Vorsatz, etwas Dummes oder Nutzerfeindliches zu entwickeln. Man setzt Erfahrung, Wissen und Zeit ein und gelangt nach bestem Gewissen zu einem Ergebnis.

Wenn ein Nutzer dieses Ergebnis ablehnt, kann sich das deshalb persönlicher anfühlen, als es eigentlich ist. Für einen Moment wird nicht nur die Oberfläche infrage gestellt, sondern scheinbar auch die eigene Erfahrung. Gestalter, Entwickler und Produktmenschen kennen diesen Reflex vermutlich: Wir möchten erklären, warum unsere Entscheidung doch richtig war.

Besonders stark wird dieser Reflex, wenn noch keine bessere Alternative sichtbar ist. Solange ich nur die bestehende Lösung kenne, klingt ihre Ablehnung schnell so, als gäbe es überhaupt keinen gangbaren Weg.

Dass Kritik wehtut, ist dabei nicht das eigentliche Problem. Entscheidend ist, was danach passiert.

Professionelle Distanz heißt nicht Gefühllosigkeit

Nutzerzentrierung bedeutet nicht, dass jede Rückmeldung angenehm ist. Sie bedeutet auch nicht, dass erfahrene Produktmenschen innerlich vollkommen unberührt bleiben.

Professionalität zeigt sich für mich an einer anderen Stelle: Der Nutzer darf ehrlich reagieren, ohne anschließend meine Gefühle auffangen zu müssen. Auch ein schlichtes „Das gefällt mir nicht“ ist zunächst eine valide Reaktion. Es ist noch keine Analyse und erst recht keine fertige Produktentscheidung. Aber es kann einen wichtigen Hinweis enthalten.

In solchen Momenten hilft mir Abstand. Einmal durchatmen, gegebenenfalls eine Nacht darüber schlafen und verhindern, dass aus dem ersten Verteidigungsimpuls eine vorschnelle Antwort wird. Erst mit etwas Distanz kann ich die Kritik wieder von meinem Selbstbild trennen.

Die Lösung wurde kritisiert. Nicht meine Person.

Das klingt einfach. Nach rund zwanzig Jahren mit Feedback weiß ich trotzdem: Es braucht Übung.

Zurück zum Problem

Nachdem der erste Widerstand abgeklungen war, konnte ich die Perspektive wechseln. Ich versuchte nicht länger, die vorhandene Formularlösung angenehmer zu erklären. Stattdessen rückte ein Wunschszenario in den Mittelpunkt.

Die Frage lautete nicht mehr:

Wie bringen wir den Nutzer dazu, all diese Felder auszufüllen?

Sondern:

Wie könnte das Produkt an diese Informationen gelangen, ohne dem Nutzer diese Arbeit aufzubürden?

Von diesem Wunschszenario aus ließ sich wieder technisch denken. Der Einsatz eines Large Language Models bot eine Möglichkeit, einen erheblichen Teil der Arbeit zu übernehmen. Die benötigten Informationen verschwanden nicht. Aber die große Wand aus Textfeldern musste nicht länger der Weg dorthin sein.

Der wichtige Schritt war nicht der Einsatz von AI. Der wichtige Schritt war, die bereits umgesetzte Lösung nicht länger mit dem eigentlichen Problem zu verwechseln.

Feedback ist Rohmaterial, keine Anweisung

Aus dieser Erfahrung folgt für mich nicht, dass jede einzelne Nutzermeinung unmittelbar umgesetzt werden sollte.

Zunächst darf jede Rückmeldung aufgenommen werden. Danach beginnt die Einordnung. Wer gibt das Feedback? Entsteht die Reaktion aus einer persönlichen Vorliebe oder aus einem tatsächlichen Hindernis? Wiederholt sich das Signal bei anderen? Was sagen Menschen im Gespräch, wie verhalten sie sich bei der Nutzung und was zeigen messbare Größen wie Dauer oder Erfolgsquote?

Keine dieser Quellen liefert allein die ganze Wahrheit. Aussagen, beobachtetes Verhalten und Nutzungsdaten sind einzelne Teile eines Puzzles. Über mehrere Kontakte hinweg kann daraus eine Evidenzkette entstehen, die eine Produktentscheidung belastbarer macht.

Nutzende übernehmen damit nicht die Rolle der Produktentwicklung. Sie diktieren nicht die Lösung. Ihre Perspektive kann aber Annahmen widerlegen, die innerhalb des Teams vollkommen plausibel wirkten.

Das macht ihre Perspektive nicht in jeder fachlichen Frage überlegen. Für die tatsächliche Nutzung ist sie jedoch häufig die wichtigere.

Überzeugt beginnen, beweglich bleiben

Ein Produkt kann nicht ohne eigene Ideen entstehen. Jemand muss Beobachtungen interpretieren, Annahmen treffen und einen ersten Entwurf wagen. Erfahrung und Überzeugung sind dafür keine Hindernisse, sondern Voraussetzungen.

Schwierig wird es erst, wenn der erste Entwurf zum Beweis der eigenen Kompetenz werden muss. Dann wird jede Gegenreaktion zu etwas, das abgewehrt werden soll.

Vielleicht liegt ein Teil professioneller Produktarbeit genau in dieser Spannung: eine Idee sorgfältig genug zu entwickeln, um an sie zu glauben – und gleichzeitig genügend Abstand zu bewahren, um sie wieder loslassen zu können.

Die erste Lösung braucht Überzeugung. Das bessere Produkt braucht die Fähigkeit, diese Überzeugung wieder loszulassen.