Antwort.

Historisch gesehen beschrieben Analysten Schnittstellen mit Worten oder in Form von Bildschirmmasken in Dokumenten. Dies führte zu Missverständnissen und häufigen Überarbeitungen, da eine Visualisierung der Anforderungen faktisch fehlte. Der moderne Trend besteht in der verpflichtenden Nutzung interaktiver Prototypen (Figma, Axure, Balsamiq), die es Stakeholdern und dem Entwicklungsteam ermöglichen, die "Zukunft" des Produkts zu "sehen".

Problem: Ohne visuelle Prototypen entstehen Missverständnisse selbst in einfachen Szenarien; das Geschäft und das Team können textuelle Beschreibungen unterschiedlich auslegen. Oft tauchen bereits während der Entwicklung Punkte auf, die früher berücksichtigt werden sollten.

Lösung: Aktive Einbindung aller Beteiligten in der Phase der Vereinbarung des Wireframes. Es ist wichtig, Prototypen nicht nur gemäß den Geschäftsprozessen zu erstellen, sondern diese auch mit Erläuterungen zum Verhalten jedes Feldes/Elements zu begleiten, typische/atypische Szenarien (Edge Cases) zu modellieren und Feedback dazu einzuholen, bevor die Aufgabe in die Entwicklung geht.

Schlüsselfunktionen:

Reduzierung der Nacharbeiten durch frühzeitige Validierung von Ideen mit Prototypen
Möglichkeit, Benutzer-Szenarien noch vor dem Codieren manuell zu testen
Einfachere Kommunikation zwischen verschiedenen Rollen durch Visualisierung

Tricksfragen.

Kann man nur mit textuellen Beschreibungen von Bildschirmen auskommen, wenn die Liste der Felder klar ist?

Antwort: Nein. Selbst wenn die Felder bekannt sind, können Struktur, Reihenfolge, Logik der Übergänge, Validierungsregeln und mobile Anpassungen unterschiedlich interpretiert werden. Prototypen helfen, diese Unterschiede vor Beginn der Arbeiten zu identifizieren.

Sind Wireframes eine vollständige Spezifikation für die Entwicklung?

Antwort: Nein, Wireframes sind die visuelle Grundlage. Sie müssen unbedingt mit Verhaltensszenarien, Geschäftsregeln und einer Beschreibung der Ausnahmebehandlungslogik ergänzt werden. Nur die Gesamtheit ergibt die endgültige technische Anforderung.

Wer ist für die Genehmigung der Prototypen verantwortlich: der Analyst oder das Geschäft?

Antwort: Die Verantwortung ist gemeinsam, aber der Analyst initiiert, organisiert die Klärungen und bringt es zu einem Konsens. Das Geschäft bestätigt das Ergebnis.

Typische Fehler und Anti-Patterns

Verwendung von Prototypen als statische Bilder ohne Erläuterungen zu Verhalten und Grenzfällen
Verschiebung der Initiative zwischen Geschäft und Entwicklung ohne Beteiligung des Analysts
Ignorieren mobiler/anpassungsfähiger Fälle

Beispiel aus dem Leben

Negativer Fall: Zu Beginn des Projekts stellte der Kunde eine Beschreibung in Form einer Liste von Feldern zur Verfügung. Bei Tests nach dem Release wurden inkorrekte Fehlerbehandlungsszenarien und nicht offensichtliche Benutzeraktionen entdeckt.

Vorteile:

Schneller Start

Nachteile:

Hohe Anzahl an Rückgaben und Bugs
Unzufriedenheit des Kunden

Positiver Fall: Wir führten eine Reihe von Workshops durch, in denen wir Wireframes für jede Phase entworfen und genehmigt haben. Alle Edge Cases wurden iterativ bis zur Genehmigung bearbeitet.