Nutzererfordernisse, Anforderungen & User Stories
Nutzerbedürfnisse identifizieren, in strukturierte Anforderungen übersetzen und als User Stories formulieren, die echte Nutzerziele mit UI-Entscheidungen verbinden.
- Den Unterschied zwischen Nutzerwunsch und echtem Nutzerbedürfnis erklären
- Nutzerbedürfnisse in funktionale und nicht-funktionale Anforderungen übersetzen
- User Stories im Standardformat schreiben und bewerten
- Den Weg von einer User Story zu einem konkreten UI-Element nachvollziehen
Kernkonzept
Nutzererfordernisse
Nutzererfordernisse sind das, was Nutzer von einem System tatsächlich brauchen, um ihre realen Ziele zu erreichen. Sie sind nicht dasselbe wie das, was Nutzer fordern.
Nutzer beschreiben Lösungen, keine Bedürfnisse. Die Aufgabe eines UX-Praktikers ist es, hinter der geforderten Funktion das eigentliche Bedürfnis zu finden.
Lösungs-Anfrage
„Ich möchte einen Filter-Button auf diesem Bildschirm."
↳ Beschreibt eine Lösung, nicht ein Bedürfnis. Schränkt Designmöglichkeiten ein.
Nutzerbedürfnis
„Ich muss das richtige Produkt schnell finden, wenn ich schon ungefähr weiß, was ich suche."
↳ Offen für viele Lösungen: Filter, Suche, Shortcuts, Verlauf…
Methode
Anforderungen
Sobald du die Nutzerbedürfnisse verstehst, übersetzt du sie in Anforderungen – spezifische, messbare, testbare Aussagen darüber, was das System tun oder wie es sein muss.
Funktionale Anforderungen
Beschreiben, was das System tut: „Nutzer können Suchergebnisse nach Kategorie, Preisbereich und Bewertung filtern." Direkt testbar: entweder vorhanden oder nicht.
Nicht-funktionale Anforderungen
Beschreiben, wie sich das System verhält: Geschwindigkeit, Zuverlässigkeit, Zugänglichkeit (WCAG AA), Verfügbarkeit. Oft ebenso wichtig, aber häufig vergessen.
Nutzerbedürfnis → Anforderungen (Aufgabenverwaltungs-App)
| Nutzerbedürfnis | Funktionale Anforderung | Nicht-funktionale Anforderung |
|---|---|---|
| "Ich muss die richtige Aufgabe schnell finden, ohne alle zu durchsuchen" | Nutzer können Aufgaben nach Status, Priorität und Fälligkeit filtern | Filterergebnisse erscheinen in unter 200ms |
| "Ich will sicher sein, dass meine Änderungen nicht verloren gehen" | Änderungen werden automatisch gespeichert | Auto-Save erfolgt spätestens 3 Sekunden nach der letzten Eingabe |
| "Ich muss auf einen Blick sehen, was heute erledigt werden muss" | Eine Tagesansicht gruppiert alle fälligen Aufgaben nach Priorität | Die Ansicht lädt vollständig in unter 1 Sekunde |
Format
User Stories
User Stories sind ein Format, um Anforderungen aus der Perspektive des Nutzers auszudrücken. Sie stammen aus der agilen Entwicklung und sind die Standardbrücke zwischen User Research und Entwicklungsarbeit.
Als Erstbesucher…
…möchte ich eine klare Erklärung sehen, was dieser Dienst bietet, damit ich entscheiden kann, ob er für mich relevant ist.
Als wiederkehrender Nutzer…
…möchte ich, dass meine letzte Suche gespeichert wird, damit ich sie nicht jedes Mal erneut eingeben muss.
Als Administrator…
…möchte ich auf einen Blick eine Zusammenfassung der Team-Aktivitäten sehen, damit ich schnell erkennen kann, wer Unterstützung braucht.
Gute User Stories konzentrieren sich auf Ergebnisse, nicht auf Implementierungen. Sie sagen nicht „füge ein Dropdown hinzu" – sie sagen, was der Nutzer tun können muss.
Schritt für Schritt
Von der User Story zum UI-Element
Klicke dich durch die Ableitung – von der User Story zu einem konkreten UI-Baustein:
Von der User Story zum UI-Element
Nutzer beschreiben Lösungen – deine Aufgabe ist es, das echte Bedürfnis dahinter zu finden. Erst das Bedürfnis verstehen, dann die Anforderung formulieren, dann die Story schreiben, dann das UI bauen. In dieser Reihenfolge – nie umgekehrt.