Website-Design-Spezifikation: Oberflächenzustände vor der Entwicklung

Im Entwurf sieht das Anfrageformular fertig aus: Felder, eine Schaltfläche, eine ordentliche Überschrift. Doch während der Entwicklung stellt sich heraus, dass niemand Fehlermeldungen, das Warten auf eine Antwort und das erneute Absenden abgestimmt hat. Eine Website-Design-Spezifikation wird genau für solche Situationen benötigt: Sie erklärt, wie sich die Oberfläche unter verschiedenen Bedingungen verhält, nicht nur, wie sie im Idealfall aussieht.

Vor Beginn der Programmierung sollten Szenarien, Zustände und die Regeln für Zustandswechsel abgestimmt werden. Dann versteht der Geschäftsinhaber den Umfang des Auftrags, der Designer übergibt Entscheidungen ohne versteckte Annahmen, und der Entwickler muss das Verhalten des Produkts nicht allein festlegen. Im Folgenden zeigen wir einen praktischen Weg, dieses Paket ohne unnötige Dokumentation zusammenzustellen.

1. Trennen Sie Designentscheidungen von ansprechenden Ansichten

Die Design-Übergabe an die Entwicklung, auch Handoff genannt, umfasst die abgestimmten Regeln für die Oberfläche zusammen mit den Entwürfen. Eine Ansicht zeigt einen bestimmten Moment. Die Spezifikation ergänzt die Bedingungen: Was löst eine Aktion aus, welche Daten werden benötigt, was sieht die Person während des Wartens, und wie setzt sie ihre Arbeit nach einem Fehlschlag fort? Für das Unternehmen ist wichtig, dass diese Entscheidungen nicht zufällig bei der Umsetzung der Layouts entstehen.

Beginnen Sie mit dem gewünschten Ergebnis des Nutzers: eine Dienstleistung finden, Optionen vergleichen, eine Anfrage absenden. Geben Sie für jeden Nutzerpfad die Ausgangsbedingung, die nächste Aktion und das Merkmal für den Abschluss an.

Dieses Dokument ist keine Anfrage zur Auswahl einer Agentur. Falls Sie noch Anbieter vergleichen, hilft Ihnen ergänzend der Beitrag über RFI, RFP und RFQ zur Auswahl eines Auftragnehmers. Hier geht es um eine andere Entscheidung: Welche Informationen muss das Team genau erhalten, bevor es ein bereits festgelegtes Design umsetzt?

2. Erstellen Sie eine Zustandsmatrix statt einer Sammlung von Kopien

Oberflächenzustände beschreiben die Reaktion einer Komponente auf eine Situation. Bei einem Feld sind das ein leerer Wert, die Eingabe, der Fokus und ein Fehler; bei einer Liste das Laden, ein Ergebnis, keine Ergebnisse und eine Störung. Nicht jeder Bereich braucht alle Varianten. Wählen Sie diejenigen, die im abgestimmten Szenario tatsächlich auftreten können, und erklären Sie, warum die übrigen nicht zutreffen.

Trennen Sie Aussehen und Verhalten

Die Farbe einer Schaltfläche beim Darüberfahren erklärt nicht, ob sie während einer Anfrage angeklickt werden kann. Ebenso legt ein gezeichneter Ladeindikator nicht fest, wann er verschwindet. Halten Sie neben der visuellen Variante drei Dinge fest: das Ereignis, das den Zustand auslöst, die verfügbaren Aktionen und die Bedingung für das Verlassen des Zustands. Hängt die Antwort vom Server ab, markieren Sie diese Abhängigkeit für die Besprechung mit dem Entwickler.

Für wiederkehrende Elemente genügt eine zentrale Quelle der Regeln mit Verweisen aus den Entwürfen. Eine eigene Ansicht ist dort erforderlich, wo sich die Anordnung oder der Nutzerpfad ändert.

Vermischen Sie unterschiedliche Gründe für leere Zustände nicht

„Sie haben noch keine Produkte gespeichert“ und „Für diese Filter wurden keine Ergebnisse gefunden“ erfordern unterschiedliche Aktionen. Im ersten Fall passt ein Wechsel zum Katalog, im zweiten eine Änderung der Suchbedingungen. Nicht verfügbare Daten sollten nicht als null Ergebnisse dargestellt werden: Hier liegen eine andere Ursache, ein anderer Text und möglicherweise eine andere Möglichkeit zur Wiederholung der Anfrage vor.

3. Beschreiben Sie Meldungen, Fokus und die Fortsetzung der Arbeit

Verschieben Sie Fehlertexte nicht ans Projektende. Die Spezifikation braucht die tatsächlichen Formulierungen, den Anzeigeort und den Zeitpunkt des Erscheinens. Bei einem E-Mail-Feld ist „Geben Sie eine Adresse im Format [email protected] ein“ hilfreicher als „Ungültiger Wert“. Das Prüfformat muss dabei den abgestimmten Datenregeln entsprechen und darf nicht auf einer zufälligen Einschränkung des Entwurfs beruhen.

In der Erläuterung zu WCAG-Kriterium 3.3.1 zur Fehlererkennung hält das W3C fest: Ein automatisch erkannter Eingabefehler muss in Textform beschrieben und das betroffene Element identifiziert werden. Ein roter Rahmen kann die Erklärung ergänzen, ersetzt sie aber nicht. Das ist eine konkrete Anforderung an einen Fehler, keine Bestätigung der Barrierefreiheit der gesamten Website.

Legen Sie das Verhalten des Tastaturfokus gesondert fest — also des aktuellen Elements, mit dem eine Person ohne Maus interagiert. Wohin wechselt er nach dem Öffnen eines Dialogs, dem Schließen eines Fensters oder einem fehlgeschlagenen Absendeversuch? Zeigen Sie im Entwurf eine sichtbare Hervorhebung und beschreiben Sie den erwarteten Ablauf in einer Anmerkung. Die endgültige Lösung wird erst in der umgesetzten Oberfläche geprüft.

Eine Meldung wie „Gespeichert“ oder „Keine Ergebnisse gefunden“ kann erscheinen, ohne dass eine andere Seite aufgerufen wird. WCAG 4.1.3 zu Statusmeldungen erläutert, wie solche Änderungen für assistive Technologien programmatisch zugänglich sein müssen, ohne den Fokus zwingend zu verschieben. Verlangen Sie nicht für jede Änderung dieselbe Benachrichtigung: Die Art der Ansage hängt vom Kontext und der Bedeutung des Ereignisses ab.

In der Designphase genügt es festzuhalten, welche Meldung die Person erhalten soll und ob ihre Arbeit unterbrochen werden muss. Der Entwickler legt die technische Umsetzung fest, der Tester prüft das Ergebnis. Einen breiteren Kontext bietet der GL.ua-Beitrag über Design mit Schwerpunkt Barrierefreiheit; eine Zustandsspezifikation deckt nur einen Teil dieser Aufgabe ab.

4. Gehen Sie ein hypothetisches Beispiel für eine Angebotsanfrage durch

Ein hypothetisches Beispiel: Ein Unternehmen nimmt über seine Website Anfragen zur Kalkulation von Möbeln entgegen. Der Besucher wählt die Produktart, hinterlässt Kontaktdaten und ergänzt einen Kommentar. Das Geschäftsziel ist eine Anfrage, die beantwortet werden kann. Dies ist ein Lernszenario, keine Beschreibung eines Kunden oder Ergebnisses von GL.ua.

Vom Klick bis zur Bestätigung

Vor dem Absenden zeigt das Formular Pflichtfelder und Hinweise an. Wenn die Kontaktangabe fehlt, erscheint nach einem Absendeversuch eine konkrete Erklärung neben dem Feld. Der Kommentar bleibt erhalten. Die WAI-Empfehlungen zu Formularbenachrichtigungen stellen Ansätze für eine zusammenfassende Fehlerliste und Erläuterungen neben den Feldern vor. Die Spezifikation legt die für dieses Formular benötigte Kombination fest, statt alle Varianten gleichzeitig zu übernehmen.

Wenn die lokalen Prüfungen erfolgreich sind, wechselt die Schaltfläche in den Zustand „Wird gesendet“. In dieser hypothetischen Lösung ist ein erneuter Klick erst nach Abschluss der aktuellen Anfrage möglich. Gesondert abzustimmen ist, ob Felder während des Wartens geändert werden können und welche eingegebenen Werte nach einem fehlgeschlagenen Versuch erhalten bleiben. Der visuelle Zustand der Schaltfläche allein legt diese Regeln nicht fest.

Bestätigt der Server, dass die Anfrage angelegt wurde, zeigen wir „Anfrage gesendet“ und den abgestimmten nächsten Schritt an. Wird die Verbindung unterbrochen und ist das Ergebnis unbekannt, schreiben wir nicht „Die Anfrage wurde nicht angelegt“: Das weiß die Oberfläche nicht. Es braucht einen eigenen Text zur fehlenden Bestätigung und einen abgestimmten Weg, das Ergebnis zu klären. Den Wiederholungsmechanismus legt das Team zusammen mit der serverseitigen Umsetzung fest, nicht allein im Design.

5. Prüfen Sie Inhalte und Responsivität vor der Layout-Umsetzung

Ein Entwurf mit kurzen Überschriften zeigt nicht, was bei einer langen Dienstleistungsbezeichnung oder einer mehrzeiligen Fehlermeldung passiert. Ergänzen Sie Beispiele mit realistischen Inhaltsstrukturen: einen langen Namen, ein fehlendes Bild, mehrere Meldungen in einem Formular. Stimmen Sie für jeden komplexen Bereich Umbrüche, Kürzungen und eine Möglichkeit ab, verborgene Inhalte vollständig zu lesen.

Beschreiben Sie Responsivität als Regeln für die Neuanordnung, nicht nur als Paar „Computer — Smartphone“. Geben Sie an, welche Elemente ihre Reihenfolge ändern, was sichtbar bleibt und wie sich Tabellen und lange Listen verhalten. Die genauen Breitengrenzen wählt das Team passend zu den Inhalten und Komponenten. Prüfen Sie Zwischengrößen gesondert: Zwei abgestimmte Ansichten beschreiben nicht alle Situationen dazwischen.

Prüfen Sie für eine mehrsprachige Website Texte unterschiedlicher Länge. Halten Sie die Herkunft der Schriften, die verfügbaren Schriftschnitte und die Regeln für Icons fest. Exportierte Materialien müssen den im Entwurf verwendeten entsprechen.

6. Stimmen Sie das Paket ab und gehen Sie die nummerierte Prüfung durch

Kriterien für die Entwicklungsreife des Designs sollten sich daran orientieren, ob das Szenario umgesetzt werden kann, nicht an der Anzahl gezeichneter Seiten. Das Mindestpaket enthält eine Übersicht der Nutzerpfade, eine Bibliothek wiederkehrender Komponenten, eine Zustandsmatrix, Texte, responsive Regeln und eine Liste offener Fragen. Jede Frage braucht eine verantwortliche Person und eine Entscheidung: vor dem Start klären oder ausdrücklich aus dem aktuellen Umfang ausklammern und zurückstellen.

Führen Sie vor Beginn der Entwicklung die folgenden Prototypprüfungen durch. Wiederholen Sie vor dem Start der Website dieselben Szenarien in der Umsetzung: Ein klickbarer Entwurf beweist nicht, dass Meldungen, Übergänge und die Datenverarbeitung korrekt funktionieren.

1. Durchlaufen Sie den Hauptpfad von der Ausgangsbedingung bis zum bestätigten Ergebnis.
2. Prüfen Sie für jede Aktion das Warten, den Erfolg und den Fehlschlag. Finden Sie Zustände ohne Ausweg.
3. Setzen Sie lange und fehlende Werte ein und prüfen Sie mehrere Formularfehler gleichzeitig.
4. Durchlaufen Sie den Pfad auf einem schmalen Bildschirm und bei einer Zwischenbreite. Prüfen Sie auf der fertigen Website zusätzlich die Tastaturbedienung und die Ansage wichtiger Meldungen.
5. Gleichen Sie Entwürfe, Texte und Komponentenbibliothek ab. Beseitigen Sie Widersprüche und legen Sie eine Version für die Umsetzung fest.
6. Notieren Sie ungeklärte Abhängigkeiten und stimmen Sie ab, welche den Start blockieren. Prüfen Sie vor dem öffentlichen Start anhand eines funktionierenden Szenarios, ob sie geklärt sind.

Verwenden Sie für die Abnahme des fertigen Produkts einen gesonderten Plan. Der Beitrag zur Abnahme einer Unternehmenswebsite betrifft die nächste Phase. Die Design-Übergabe definiert das Erwartete, die Abnahme prüft das Tatsächliche; beide Verfahren hängen zusammen, ersetzen einander aber nicht.

7. Bewerten Sie Zeitrahmen, Kosten und das Risiko übermäßiger Detailtiefe

Die Vorbereitungszeit hängt von der Anzahl unterschiedlicher Szenarien, der Verfügbarkeit der Inhalte, der Komplexität der Komponenten und dem Tempo der Abstimmungen ab. Klären Sie zuerst die Geschäftsregeln, arbeiten Sie dann den Hauptpfad und die Ausnahmen aus und stimmen Sie anschließend die Responsivität und das Übergabepaket ab. Parallele Arbeit ist möglich, doch Ergebnismeldungen sollten nicht finalisiert werden, solange das Ergebnis selbst nicht feststeht.

Schlüsseln Sie die Kosten nach Szenarioanalyse, Prototyping, visueller Gestaltung, Komponenten, Zustandstexten, responsiven Varianten und der Prüfung mit dem Entwickler auf. Klären Sie Ausgaben für Schriften, Illustrationen oder Werkzeuge zur Zusammenarbeit gesondert, falls sie benötigt werden. Auch die Pflege der Spezifikation bei Änderungen kostet Zeit. Ohne diese Aufschlüsselung kann eine niedrigere Schätzung lediglich einen geringeren Übergabeumfang bedeuten.

Die größten Risiken sind widersprüchliche Versionen, nicht abgestimmte Serverantworten und Anforderungen, die erst nach dem Start auftauchen. Halten Sie Datum und Version des Pakets fest und beschreiben Sie Änderungen anhand ihrer Auswirkungen auf Szenarien, Entwürfe und Prüfungen.

Es ist nicht nötig, für jede theoretische Kombination eine Ansicht zu zeichnen. Für eine Informationsseite ohne Formulare können kompakte Komponenten- und Responsivitätsregeln ausreichen. Arbeiten Sie die Stellen detailliert aus, an denen eine Person Daten eingibt oder ihren Fortschritt verlieren könnte.

Ein abgestimmtes Designpaket macht Änderungen vor der Programmierung sichtbar. Übermitteln Sie GL.ua (Glyanets) eine Liste der wichtigsten Szenarien und die vorhandenen Entwürfe, um die Website-Entwicklung zu besprechen und den Umfang der Designvorbereitung für die Umsetzung abzustimmen.