UX-Research und Prototyping: Wie gute Benutzeroberflächen entstehen

Das Anfrageformular auf Ihrer Website funktioniert, Anfragen kommen herein. Trotzdem ruft der Vertrieb fast jeden Interessenten zurück und stellt dieselben Fragen: welcher Volumenstrom, welche Förderhöhe, welches Medium, wie viele Stück? Manche Besucher brechen mittendrin ab und greifen zum Telefon, wer abends kommt, meldet sich gar nicht mehr. Die Versuchung ist groß, das Formular einfach „schöner machen“ zu lassen. Mit Schönheit hat das Problem aber nichts zu tun.

Dieser Beitrag zeigt an einem durchgehenden Beispiel, wie eine gute Oberfläche entsteht: dem Anfrageformular eines mittelständischen Pumpenherstellers aus dem Sauerland, der über den Fachhandel und direkt an Anlagenbauer verkauft. Sie sehen, was in jedem Schritt passiert, von der Recherche über Prototyp und Nutzertest bis zur Übergabe an die Entwicklung und zur Messung nach dem Launch, und welche Schritte Sie nicht weglassen sollten. Dieselbe Methode funktioniert auch für einen Checkout oder eine Terminbuchung.

Recherche: Wem hören Sie zu, bevor Sie gestalten?

Recherche beginnt mit einer schlichten Frage: Was wissen wir nicht? Beim Pumpenhersteller war das klar. Welche Angaben haben Kunden bei einer Anfrage zur Hand, welche nicht? Und was braucht der Vertrieb tatsächlich, um ein Angebot zu kalkulieren? Die Antworten kamen aus vier Quellen.

Stakeholder-Interviews

Einzelgespräche von höchstens einer Stunde mit je einer Person aus Vertrieb, technischem Support und Fertigungsplanung. Die Frage ist einfach: Was passiert, wenn eine Anfrage eingeht, und wo hakt es? Zwei Dinge kamen heraus. Mehrere Formularfelder schaute sich niemand an. Und die Angaben, die der Vertrieb am dringendsten brauchte, nämlich Temperatur des Mediums und Feststoffanteil, wurden gar nicht abgefragt.

Am meisten brachten diese Fragen:

• Welche Angaben sind zwingend nötig, damit aus einer Anfrage ein Angebot werden kann?
• Was fragen Sie beim Rückruf am häufigsten nach?
• Welche Anfragen nehmen Sie nicht ernst, und warum?
• Was würde sich an Ihrem Arbeitsalltag ändern, wenn das Formular anders wäre?

Nutzerinterviews

Danach haben wir mit echten Kunden gesprochen: Einkäufern im Fachhandel und Ingenieuren bei Anlagenbauern. Schon fünf oder sechs Gespräche zeigen viel. Stellen Sie Fragen, die nicht lenken: „Erzählen Sie mal, wie Ihre letzte Anfrage abgelaufen ist“ funktioniert, „War unser Formular einfach?“ nicht. Menschen beschreiben recht ehrlich, was sie getan haben, aber kaum zuverlässig, was sie künftig wollen.

Wenn Sie Gespräche aufzeichnen, informieren Sie die Teilnehmenden vorher und holen Sie ihre Einwilligung ein. Auch Research-Aufnahmen sind personenbezogene Daten im Sinne der DSGVO, inklusive Informationspflichten und Löschfristen.

Webanalyse

Ist in Google Analytics 4 die automatische Messung von Formularinteraktionen aktiv (ein Teil der erweiterten Messung), zeigen die Ereignisse form_start und form_submit, wie viele Personen das Formular beginnen und wie viele es absenden. Das automatische Ereignis ist nicht bei jedem Formularaufbau zuverlässig; sicherer ist ein eigenes Ereignis auf der Bestätigungsseite. Mit einer Trichteranalyse in den explorativen Auswertungen sehen Sie, woher Besucher kommen und wo sie aussteigen. Sitzungsaufzeichnungen und Heatmaps (etwa Hotjar oder Microsoft Clarity) zeigen, wo gezögert wird; einsetzen dürfen Sie sie nur mit Einwilligung über das Cookie-Banner.

Wettbewerb und Vorbilder

Schauen Sie sich die Anfrageformulare des Wettbewerbs und gute Beispiele aus anderen Branchen an, am besten, indem Sie sie selbst ausfüllen. Es geht nicht ums Kopieren, sondern darum, was Kunden anderswo gewohnt sind. Ein Raster wie die zehn Usability-Heuristiken der Nielsen Norman Group hält die Analyse fern von „Gefällt mir irgendwie“.

Jede Methode beantwortet eine andere Frage, und keine reicht allein:

Persona oder Jobs to be Done?

Viele Projekte beenden die Recherche mit einem Persona-Poster: „Einkaufsleiter Thomas, 42, zwei Kinder, trinkt seinen Kaffee schwarz.“ Solche demografischen Details helfen selten bei einer Gestaltungsentscheidung. Aus Thomas' Alter folgt nicht, welches Feld ein Pflichtfeld sein sollte.

Die Alternative ist der Jobs-to-be-Done-Ansatz, der mit Clayton Christensen verbunden wird. Die Frage lautet: In welcher Situation und für welches Ergebnis „engagiert“ der Kunde dieses Produkt oder dieses Formular? Beim Pumpenhersteller zeigten sich zwei getrennte Jobs:

• Der Fachhändler: „Mein Kunde wartet. Ich habe eine Typennummer und will schnell Preis und Lieferzeit, um mich zurückzumelden.“
• Der Ingenieur beim Anlagenbauer: „Ich brauche die passende Pumpe für eine neue Anlage. Ich gebe den Betriebspunkt vor und will das richtige Modell samt Datenblatt.“

Ein Formular erledigte beide Jobs schlecht. Der Händler wollte keine vierzehn Felder ausfüllen, der Ingenieur fand keinen Platz für seine technischen Werte. Der Kern der Lösung war eine einzige Frage am Anfang: „Haben Sie eine Typennummer?“

Personas gehören deshalb nicht in den Papierkorb. Auch die Nielsen Norman Group sieht beide Werkzeuge als Ergänzung; auf Recherche gestützte, verhaltensbezogene Personas helfen einem Team, sich in Nutzer hineinzuversetzen. Unsere Empfehlung: Bei B2B-Formularen, Checkouts und werkzeugartigen Oberflächen zuerst die Jobs aufschreiben und Personas bei Bedarf ergänzen.

Informationsarchitektur und Card Sorting

Informationsarchitektur beschreibt, wie Inhalte gruppiert und benannt werden: was im Menü steht, welche Seite unter welcher liegt, wonach Kategorien gebildet werden. Auf der Website des Pumpenherstellers waren die Produkte nach interner Logik sortiert, also nach Baureihen. Kunden suchten dagegen nach Anwendung: Abwasser, Brandschutz, Gebäudetechnik, Lebensmittel.

Das lösen Sie nicht per Bauchgefühl, sondern mit Card Sorting. Beim offenen Card Sorting bekommen Teilnehmende Inhaltskarten und bilden und benennen eigene Gruppen. Beim geschlossenen Card Sorting stehen die Gruppen fest, die Karten werden zugeordnet. Die Nielsen Norman Group empfiehlt für offenes Card Sorting in den meisten Projekten rund 15 Teilnehmende; mit Werkzeugen wie Optimal Workshop lässt sich das online durchführen.

Verwenden Sie in den Bezeichnungen die Wörter Ihrer Kunden. Wenn Ingenieure im Interview von „Förderhöhe“ sprechen und auf der Website ein anderer Fachbegriff steht, meinen beide dasselbe, aber niemand findet es. Sammelbegriffe wie „Lösungen“ oder „Leistungen“ verraten Besuchern ohnehin nicht, was dahinter steckt.

Um eine neue Struktur zu prüfen, eignet sich ein Tree Test besser. Teilnehmende sehen nur die Menühierarchie als Text und lösen Aufgaben wie „Wo finden Sie das Datenblatt einer Abwasserpumpe?“ Weil das visuelle Design außen vor bleibt, misst das Ergebnis die Struktur selbst.

User Flows und Wireframes

Ein User Flow zeigt die Schritte, die jemand bis zum Ziel geht. Für das Anfrageformular haben wir je einen Flow pro Job gezeichnet: Händler mit Typennummer und Ingenieur mit technischen Werten. Zeichnen Sie nicht nur den Idealweg, sondern auch die Ausnahmen. Was, wenn jemand die Einheit nicht kennt, der Datei-Upload scheitert oder die Anfrage um Mitternacht kommt?

Ein Wireframe ist dieser Ablauf in grauen Kästen. Farben, Fotos und Schriften bleiben bewusst draußen, damit die Diskussion bei „Gehört dieses Feld hierher?“ bleibt und nicht bei „Soll das blau sein?“ landet. Verwenden Sie im Wireframe echte Texte. Ein Feld mit der Beschriftung „Lorem ipsum“ heißt, dass auch Hilfetext und Fehlermeldung noch niemand durchdacht hat.

Der Flow endet nicht mit dem Absenden. Was steht auf der Bestätigungsseite, enthält die Bestätigungsmail eine Zusammenfassung, erfährt der Kunde, wann sich der Vertrieb meldet? „Wir melden uns am Montagvormittag“ ist besser als Funkstille.

Diese Entscheidungen fielen beim Pumpenhersteller in der Wireframe-Phase:

• Zwei Wege gleich am Anfang: „Ich habe eine Typennummer“ und „Helfen Sie mir bei der Auswahl“.
• Vier Felder auf dem Händlerweg: Typ, Stückzahl, gewünschter Liefertermin, Kontaktdaten.
• Auf dem Ingenieursweg ein Formular in Schritten mit je einem Thema: Anwendung, Medium, Volumenstrom und Förderhöhe, weitere Angaben, Kontakt.
• Die Einheit (m³/h oder Liter pro Sekunde) wird direkt im Feld gewählt; niemand muss umrechnen.
• Bei jedem technischen Feld die Option „Weiß ich nicht“. Unbekannte Werte dürfen leer bleiben, und der Vertrieb sieht das in der Anfrage.

Klickbarer Prototyp und Tests mit wenigen Personen

Sind die Wireframes abgestimmt, entsteht in Figma ein klickbarer Prototyp: keine programmierte Website, aber nah genug an der Realität, dass Buttons funktionieren, Schritte weiterschalten und Fehlermeldungen erscheinen. Testen Sie die mobile Version unbedingt auf einem echten Smartphone; die Figma-App öffnet Prototypen direkt auf dem Gerät. Denken Sie daran, dass ein Ingenieur die Anfrage vielleicht auf der Baustelle stellt, mit einer Hand und im Regen.

Sie müssen nicht jeden Screen prototypisch umsetzen, nur die, durch die Ihre Testaufgaben führen. Ein grauer Low-Fidelity-Prototyp testet Ablauf und Struktur; Texte, visuelle Hierarchie und kleine Interaktionen brauchen einen High-Fidelity-Prototyp. Wer beides gleichzeitig testet, bekommt Kommentare zu Farben und keine Antworten zum Ablauf.

Wie viele Testpersonen reichen?

Jakob Nielsens Empfehlung aus dem Jahr 2000, gestützt auf ein Modell, das er 1993 mit Thomas Landauer entwickelt hat, ist bis heute der praktischste Ausgangspunkt: Testen Sie mit fünf Personen, um Usability-Probleme zu finden, beheben Sie sie und testen Sie erneut. Seine Begründung: Jede weitere Person wiederholt überwiegend Probleme, die schon aufgefallen sind. Mehrere kleine Runden bringen deshalb mehr als eine große Studie.

Die Regel hat Grenzen. Gibt es sehr unterschiedliche Nutzergruppen, bei uns Händler und Ingenieure, brauchen Sie Teilnehmende aus jeder Gruppe. Wollen Sie Quoten messen, etwa wie viele Personen das Formular fehlerfrei abschließen, brauchen Sie eine quantitative Studie mit deutlich mehr Teilnehmenden. Ein Test mit fünf Personen findet Probleme; er beweist nicht, wie häufig sie auftreten.

So laufen die Sitzungen ab

• Geben Sie eine echte Aufgabe: „Fordern Sie mit diesen technischen Werten ein Angebot an.“ „Schauen Sie sich das Formular mal an“ ist keine Aufgabe.
• Bitten Sie die Person, laut zu denken, und schweigen Sie dann. Helfen, Tipps geben oder „Sie könnten da klicken“ sagen, verfälscht den Test.
• Notieren Sie, wo sie hängen bleibt, welche Wörter sie benutzt und was sie erwartet hat. Die Frage, was ihr gefallen hat, bringt am wenigsten.
• Nehmen Sie zu jeder Sitzung eine beobachtende Person mit, idealerweise aus dem Vertrieb. Wer selbst sieht, wie jemand am eigenen Formular scheitert, ist schneller überzeugt als nach jedem Bericht.
• Bei Aufzeichnungen gilt: vorher informieren, Einwilligung einholen, Speicherdauer festlegen.

Moderierte Tests, vor Ort oder per Videocall, erlauben die Frage „Was haben Sie gerade erwartet?“. Unmoderierte Remote-Tests mit Werkzeugen wie Maze erreichen schneller mehr Menschen, aber diese Frage entfällt. Für die ersten Runden empfehlen wir moderierte Tests. Rekrutieren Sie aus Kunden und Händlern; Kolleginnen und Kollegen sind die schlechtesten Testpersonen, weil sie Produkt und Fachjargon so gut kennen wie Sie.

Beim Pumpenhersteller stolperten die Ingenieure in der ersten Runde über die Einheitenauswahl, und die Händler wussten nicht, wo die Typennummer auf dem Typenschild steht. In Runde zwei kam ein kleines Bild des Typenschilds neben das Feld, und das Problem tauchte nicht mehr auf.

Barrierefreiheit beginnt im Design

Barrierefreiheit erst am Ende der Entwicklung zu prüfen, ist der teuerste Weg. Die meisten Entscheidungen fallen im Design, und dort ist eine Korrektur eine Sache von Minuten. Die WCAG 2.2, im Oktober 2023 als W3C-Empfehlung veröffentlicht, haben Kriterien ergänzt, die Formulare direkt betreffen:

• Zielgröße, Minimum (2.5.8, AA): Klickziele sollten mindestens 24 mal 24 CSS-Pixel groß sein oder genug Abstand haben. Winzige Checkboxen und eng gesetzte Links sind die typischen Verstöße.
• Fokus nicht verdeckt, Minimum (2.4.11, AA): Ein per Tastatur fokussiertes Feld darf nicht vollständig hinter einer fixierten Kopfzeile oder dem Cookie-Banner verschwinden.
• Redundante Eingaben (3.3.7, A): Was im selben Vorgang schon eingegeben wurde, darf nicht erneut verlangt werden; es wird automatisch übernommen oder steht zur Auswahl. Rechnungs- und Lieferadresse doppelt tippen zu lassen, verstößt genau dagegen.
• Barrierefreie Authentifizierung, Minimum (3.3.8, AA): Die Anmeldung darf keinen kognitiven Test wie das Merken eines Passworts verlangen, sofern es keine Alternative oder Hilfe gibt. Einfügen im Passwortfeld oder Passwortmanager zu blockieren, ist deshalb eine schlechte Idee.
• Ziehbewegungen (2.5.7, AA): Alles, was per Ziehen funktioniert, braucht eine Alternative mit einfachem Klick oder Tippen.

Dazu kommen ältere Regeln, die trotzdem ständig gebrochen werden: mindestens 4,5:1 Kontrast für normalen Text, eine sichtbare Beschriftung für jedes Feld (Platzhaltertext ist keine Beschriftung) und Fehlermeldungen, die nicht nur über Farbe funktionieren und sagen, wie sich der Fehler beheben lässt. Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz; für viele Online-Shops und digitale Dienstleistungen für Verbraucher sind diese Punkte damit Pflicht statt Kür.

Designsystem und Übergabe an die Entwicklung

Ein Designsystem ist die Bibliothek der wiederverwendbaren Bausteine einer Oberfläche (Buttons, Formularfelder, Hinweisboxen, Schrittanzeigen) samt ihren Regeln. In Figma besteht es aus Komponenten und Varianten, im Code werden dieselben Komponenten häufig in einem Werkzeug wie Storybook dokumentiert. Ein Anfrageformular wirkt wie eine Seite, steckt aber voller Zustände.

Gestalten Sie jeden Zustand jeder Komponente: Standard, Hover, Fokus, deaktiviert, Fehler, Laden, Erfolg. Bekommt die Entwicklung nur den Idealzustand, rät sie den Rest, und jeder rät anders.

Auch Text ist eine Komponente. Wenn das Designsystem festhält, wie Fehlermeldungen aufgebaut sind (was ist passiert, wie behebe ich es), dass Buttons sagen, was sie tun, und wie Pflichtfelder markiert werden, muss beim nächsten Formular niemand die Diskussion neu führen.

Zur Übergabe gehört mehr als ein Dateilink. Ein gutes Übergabepaket enthält:

• Maße, Farb- und Schrift-Tokens und exportierbare Assets, etwa im Dev Mode von Figma.
• Interaktionshinweise: Wann wird ein Feld geprüft, wann erscheint die Fehlermeldung, was passiert nach dem Absenden?
• Sämtliche Texte: Beschriftungen, Hilfetexte, Fehlermeldungen, Bestätigungsseite und Bestätigungsmail.
• Hinweise zur Barrierefreiheit: Fokusreihenfolge, Feldbeschreibungen für Screenreader, wie Fehler angesagt werden.
• Einen Messplan: Welches Analyseereignis wird bei welchem Schritt ausgelöst?

Mit der Übergabe ist die Arbeit im Design nicht beendet. Kurze Prüfungen während der Umsetzung und ein Durchgang durch alle Zustände auf echten Geräten vor dem Launch fangen Abweichungen ab, solange sie klein sind.

Nach dem Launch: messen, lernen, wiederholen

Richtig gelernt wird, sobald das neue Formular live ist. Legen Sie vor dem Launch schriftlich fest, was als Erfolg gilt; hinterher lassen sich Zahlen viel zu leicht schönlesen. Beim Pumpenhersteller waren es drei Kennzahlen: der Anteil derer, die das begonnene Formular absenden, die Zahl der Anfragen, die trotzdem einen Rückruf brauchen, und die Zeit von der Anfrage bis zum Angebot.

Zwei dieser drei Werte stehen nicht in der Webanalyse, sondern im CRM des Vertriebs. Gute UX-Messung verfolgt die Arbeit selbst, nicht nur Klicks.

Zahlen zeigen, wo ein Problem liegt, selten warum. Eine einzige Frage auf der Bestätigungsseite („Konnten Sie alle nötigen Angaben machen?“) oder ein kurzer Anruf bei jemandem, der abgebrochen und dann angerufen hat, erklärt manchmal in einem Satz, was keine Statistik zeigt.

Bei wenig Traffic sollten Sie von A/B-Tests keine Wunder erwarten. Ein belastbares Ergebnis braucht genug Besucher, und auf einer kleinen B2B-Website kann das sehr lange dauern. Kleine Usability-Tests alle paar Monate, regelmäßiges Feedback aus dem Vertrieb und ein Blick auf deutliche Veränderungen in der Analyse sind realistischer.

Wo anfangen?

1. Wählen Sie einen Ablauf: das Formular, den Checkout-Schritt oder den Antragsprozess, der den meisten Umsatz bringt oder die meisten Beschwerden auslöst.
2. Sprechen Sie je eine Stunde mit Vertrieb und Support und lassen Sie sich zeigen, wo es hakt.
3. Holen Sie Start- und Abschlusszahlen dieses Ablaufs aus der Webanalyse. Gibt es keine Messung, richten Sie zuerst sie ein.
4. Sprechen Sie mit fünf oder sechs echten Kunden über ihre letzte Erfahrung und schreiben Sie in einem Satz auf, welchen Job sie erledigen wollten.
5. Zeichnen Sie Wireframes mit echten Texten und bauen Sie daraus einen klickbaren Prototyp.
6. Testen Sie mit fünf Personen, beheben Sie die Probleme, testen Sie erneut.
7. Nehmen Sie Barrierefreiheitskriterien und alle Komponentenzustände in das Übergabepaket auf.
8. Halten Sie die Erfolgskennzahlen vor dem Launch fest und schauen Sie danach wieder darauf.

Bei AYTE Digital beginnen wir Gestaltungsprojekte in genau dieser Reihenfolge, mit Recherche und Prototyp. Wenn ein Formular oder Ablauf bei Ihnen Probleme macht, sehen wir ihn uns gern gemeinsam an und klären, welche Schritte er wirklich braucht und welche Sie sich sparen können.