Aufgabenorientiertes Produkt-UX
Beginnen Sie mit der Situation des Benutzers und dem beabsichtigten Ergebnis. Vorhandene Designsysteme, Forschungsergebnisse und bereitgestellte Entwürfe sind Belege; ersetzen Sie sie nicht durch ein generisches Dashboard. Lesen Sie Muster und Gegenbeispiele für den relevanten Aufgabentyp, nicht jedes Muster.
Vor dem Erstellen eines Bildschirms
Identifizieren Sie für jede primäre Rolle/Aufgabe den Auslöser, bereits bekannte Informationen, zu treffende Entscheidungen, das Abschlussergebnis und den Wiederherstellungspfad. Trennen Sie rollenspezifische Workflows, wenn sich ihre Entscheidungen unterscheiden; teilen Sie Bildschirme, wenn die Aufgabe und der Kontext tatsächlich übereinstimmen.
Erstellen Sie einen kompakten Flow und ein Low-Fidelity-Layout, das proportional zur Änderung ist. Für jeden sichtbaren Bereichszustand:
- Welche Benutzerentscheidung oder -aktion benötigt ihn jetzt?
- Ist er primär, kontextuelles Detail oder in dieser Ansicht unnötig?
- Welche Anforderung, Quelle oder explizite Designentscheidung rechtfertigt ihn?
Verwenden Sie dies, um Informationen auszuwählen, nicht um mehr Produkttext zu generieren. Fügen Sie nicht automatisch Übersichtskarten, Diagramme, Banner, Filter, Navigation, KI-Erklärungen oder „Demnächst“-Panels hinzu. Eine Metrik gehört dorthin, wenn jemand eine relevante Entscheidung damit trifft. Die technische Herkunft kann dorthin gehören, wenn sie zur Beurteilung der Aktualität oder Gültigkeit benötigt wird; Debug-Protokolle und Implementierungsstatus gehören in der Regel zu Entwicklungsaufzeichnungen.
Verringern Sie nicht blind. Behalten Sie Barrierefreiheitshinweise, aussagekräftige Fehler, wesentlichen Kontext, erforderliche Offenlegungen und Entscheidungskonsequenzen bei. Eine primäre Aktion ist ein nützlicher Standard, keine willkürliche Ein-Knopf-Begrenzung. Vermeiden Sie es, wichtige Aktionen hinter generischen Menüs zu verstecken, nur um die Anzahl sichtbarer Steuerelemente zu reduzieren.
Zustand und Interaktion
Modellieren Sie relevante Zustände: initial, laden, leer, fehlgeschlagen, erfolgreich, bearbeiten/ungespeichert, veraltetes Ergebnis und Berechtigungseinschränkungen. Verwenden Sie nur Zustände, die das Produkt benötigt. Stellen Sie sicher, dass ausgewählte Eingaben und angezeigte Ergebnisse auf denselben Kontext verweisen. Bewahren Sie die Arbeit des Benutzers bei behebbaren Fehlern. Wählen Sie explizite Aktionen, wenn stille Änderungen den Benutzer überraschen würden.
Bei der Auswahl einer Bearbeitungsoberfläche oder der Änderung zustandsbehafteter Layouts lesen Sie Interaktionsmusterauswahl. Wählen Sie Inline-Bearbeitung, einen Dialog oder eine dedizierte Seite basierend auf Aufgabenkomplexität, Häufigkeit, Kontextanforderungen und verfügbarem Platz; verwenden Sie kein Modal, nur um einen Layoutfehler zu verbergen. Überprüfen Sie die Position vor/nach, den Scroll und den Fokus bedeutungsvoller Steuerelemente. Absichtliche Offenlegung kann Inhalte verschieben; unbeabsichtigte Sprünge oder verschwindende Ziele müssen korrigiert werden.
Verwenden Sie die Tokens, Komponenten, Sprache und Barrierefreiheitskonventionen des Projekts. Überprüfen Sie eine bereitgestellte Referenz mit einem verfügbaren unterstützten Tool; ein fehlendes Figma MCP ist kein Grund, anzuhalten. Kennzeichnen Sie ein nicht inspiziertes Design niemals als übereinstimmend. Führen Sie keine neue Komponentenbibliothek nur für eine kleine Änderung ein.
Überprüfen Sie zugängliche Namen und Beschreibungen über gültige/fehlerhafte/wiederhergestellte Zustände hinweg, nicht nur die visuelle Sichtbarkeit und den Fokus. Eine versteckte Nachricht kann dennoch verfügbar gemacht werden, wenn sie durch eine zugängliche Beschreibung referenziert wird; verbinden Sie Fehlertext nur, wenn der Fehler zutrifft.
Überprüfung des gerenderten Flows
Verwenden Sie ein verfügbares Browser- oder Anwendungstool, um die Aufgabe von ihrem tatsächlichen Einstiegspunkt aus auszuführen. Überprüfen Sie die Struktur auf Beschriftungen und Steuerelemente sowie die gerenderten Screenshots auf Hierarchie, Beschnitt, Abstände und visuelle Zustände. Automatisierte Barrierefreiheits- oder DOM-Prüfungen allein belegen keine visuelle oder Benutzerfreundlichkeitsqualität.
Für Responsive-Prüfungen bestätigen Sie die tatsächlichen Viewport-Abmessungen des Browsers und überprüfen Sie das endgültig aufgenommene Bild. Das Zuschneiden eines Screenshots, das Ändern der Breite eines Elements oder das alleinige Überprüfen des horizontalen Überlaufs ist kein gleichwertiger Viewport-Test. Wenn das Tool den Viewport nicht setzen oder überprüfen kann, markieren Sie diese Abdeckung als nicht verifiziert. Gleichen Sie den Screenshot mit dem gemeldeten Ergebnis ab: Fehlende Inhalte, unbrauchbarer Umbruch oder unsichtbare Aktionen können nicht als visuell bestanden bezeichnet werden, nur weil eine DOM-Prüfung bestanden wurde.
Für jeden Befund protokollieren: Reproduktion → beobachtetes Verhalten → Auswirkung auf den Benutzer → kleinste sinnvolle Korrektur → erneute Überprüfung. Kennzeichnen Sie Rückschlüsse getrennt von Beobachtungen. Bevorzugen Sie das Entfernen, Verschieben, Konsolidieren oder Verbessern von Standardwerten, bevor Sie Erklärungen hinzufügen. Wiederholen Sie keine bestandene Überprüfung, es sei denn, Änderungen oder verbleibende Bedenken rechtfertigen dies.
Wenn der Browserzugriff nicht verfügbar ist, überprüfen Sie Code-/Layout-Belege und markieren Sie die Laufzeit-UX als nicht verifiziert; setzen Sie die unabhängige Arbeit fort. Erstellen Sie keine gefälschten Screenshots, Klicks oder Benutzervalidierungen. Die Überprüfung durch den Entwickler oder Agenten ist keine Benutzerstudie.