Website-Briefing: So wird Ihr Projekt kalkulierbar

Beginnen Sie mit der Entscheidung Ihrer Kunden

Ein brauchbares Website-Briefing lässt sich auch ohne die Besprechungen verstehen, aus denen es entstanden ist. Ein Entwickler sollte daraus erkennen, wer die Website benutzt, welches Problem diese Person lösen möchte und wann die erste Version ihren Zweck erfüllt. „Modern und hochwertig“ beschreibt einen Eindruck. Für eine belastbare Kalkulation fehlen damit noch die entscheidenden Angaben.

Beginnen Sie mit einer konkreten Situation: Ein Interessent muss prüfen, ob Sie seine Anlage betreuen können, und die nötigen Informationen für eine erste Einschätzung übermitteln. Welche Angaben braucht er dafür? Welche Informationen muss Ihr Team anschließend erhalten? Eine versendete Nachricht und eine fachlich brauchbare Anfrage sind unterschiedliche Ergebnisse.

Die folgende Struktur ist unsere redaktionelle Arbeitshilfe. Sie ist kein verbindliches Branchenformular. Die verlinkten Quellen stützen einzelne Methoden, nicht einen bestimmten Projektpreis oder eine zugesicherte Entwicklungsdauer.

Beschreiben Sie eine Aufgabe statt einer Klickfolge

Formulieren Sie das gewünschte Ergebnis aus Kundensicht. „Eine Wartungsanfrage für einen bestimmten Gebäudetyp stellen“ lässt sich später überprüfen. „Den blauen Button oben rechts anklicken“ verrät dagegen bereits den Lösungsweg und zeigt kaum, ob jemand die Bedienung selbst versteht.

Nielsen Norman Group empfiehlt realistische Nutzungsszenarien, die eine Handlung auslösen, ohne den Bedienweg vorzugeben. Für Ihr Briefing bedeutet das: Beschreiben Sie Anlass, verfügbare Informationen und Ziel. Die Oberfläche darf im Prototyp noch verbessert werden.

Prüfen Sie zusätzliche Funktionen an dieser Aufgabe. Welches Hindernis beseitigt ein Rechner, ein Chat oder ein Kundenkonto? Ist der Nutzen noch unklar, halten Sie die Idee als mögliche Erweiterung fest. So bleibt die erste Version vollständig nutzbar, ohne jede denkbare Funktion sofort zu finanzieren.

Machen Sie den Umfang in einer Tabelle sichtbar

Zählen Sie Seitentypen und Inhalte getrennt. Zehn Seiten auf einer gemeinsamen Vorlage können weniger Entwicklungsaufwand verursachen als ein einzelner komplexer Konfigurator. Umgekehrt müssen auch Texte für einfache Vorlagen geschrieben, geprüft und eingepflegt werden. Diese Arbeit verschwindet nicht durch ein vorhandenes CMS.

Geben Sie Schnittstellen eine eigene Beschreibung

„CRM anbinden“ reicht für ein festes Angebot selten aus. Benennen Sie das Zielsystem, den anzulegenden Datensatz, die zu übertragenden Felder und den zuständigen Ansprechpartner. Beschreiben Sie außerdem, was bei einer wiederholten Übertragung oder einer neuen Anfrage eines bestehenden Kontakts passieren soll.

Verwenden Sie anonymisierte Beispieldaten. Eine Musteranfrage mit dem erwarteten Ergebnis im Zielsystem macht offene Regeln oft schneller sichtbar als eine Sammlung von Einstellungsansichten. Zugangsdaten gehören in eine gesondert vereinbarte sichere Übergabe, nicht in ein frei versendetes Briefing.

Sie müssen die technische Lösung nicht selbst entwerfen. Entscheidend sind die fachlichen Regeln. Fehlen Dokumentation oder Klarheit über das Zielsystem, sollte eine Untersuchung ein eigenes Ergebnis liefern: etwa eine Feldzuordnung und einen geprüften Beispielvorgang. Erst danach lässt sich der verbleibende Umfang verlässlich einordnen.

Planen Sie Inhalte und Barrierefreiheit vor der Freigabe

Legen Sie fest, wer Aussagen, Bilder und Übersetzungen freigibt. Bei mehreren Sprachversionen brauchen auch Fehlermeldungen, Bestätigungen und Formulare eine zuständige Person. Ein übersetztes Menü allein macht noch keinen vollständigen Ablauf in einer anderen Sprache.

Die Planungshilfe der W3C WAI behandelt Ziele, Verantwortlichkeiten, Ressourcen und messbare Prüfkriterien für Barrierefreiheit. Übertragen Sie diese Grundidee in Ihren Umfang: Welche Abläufe werden geprüft, nach welchem vereinbarten Ziel und durch wen?

Benennen Sie beispielsweise Tastaturbedienung, verständliche Formularfehler und fachlich notwendige manuelle Prüfungen. Ein automatischer Scan kann Hinweise liefern; die vereinbarte Bewertung muss trotzdem klar beschrieben sein. Das Briefing sollte keine pauschale Zusicherung enthalten, die später niemand konkret abnehmen kann.

Beispiel: Eine Anfrage mit brauchbarem Kontext

Das folgende Beispiel ist erfunden und kein Kundenprojekt. Ein Dienstleister erhält Nachrichten mit Telefonnummern, erfährt aber häufig nicht, welche Leistung benötigt wird. Die erste Version enthält deshalb drei Leistungsseiten und ein Formular, das die gewählte Leistung mit der Nachricht übermittelt.

Der Abnahmetest beginnt auf einem Smartphone: Leistung auswählen, gültige Kontaktdaten eintragen, einmal absenden und die eingegangene Nachricht prüfen. Sie muss die gewählte Leistung und die Eingaben enthalten. Bei einem fehlenden Pflichtfeld muss klar sein, was zu korrigieren ist. Scheitert die Übermittlung, darf keine erfolgreiche Zustellung behauptet werden.

Im Prototyp prüfen Sie Orientierung und Verständlichkeit. In der fertigen Anwendung prüfen Sie die echte Übertragung. Diese Nachweise beantworten verschiedene Fragen. Eine schöne Bestätigungsansicht allein belegt nicht, dass Ihr Team die Anfrage tatsächlich erhält.

Vereinbaren Sie Entscheidungen und Übergabe

• Bestimmen Sie eine Person, die widersprüchliche Rückmeldungen auflöst und Freigaben erteilt.
• Ordnen Sie jedem benötigten Inhalt einen Verantwortlichen und einen Liefertermin zu.
• Beschreiben Sie Korrekturrunden und die Behandlung zusätzlicher Anforderungen.
• Verbinden Sie jeden Meilenstein mit einem vorzeigbaren Ergebnis und klaren Abnahmekriterien.
• Nehmen Sie Zugänge, Sicherungen, Veröffentlichung und alltägliche Änderungen in die Übergabe auf.

Lassen Sie eine unbeteiligte Kollegin oder einen Kollegen das Briefing lesen. Kann diese Person die erste Version und deren Abnahme nicht erklären, fehlen noch Entscheidungen. Mehr Seiten helfen dann weniger als eine präzise Antwort auf die offene Frage. Halten Sie Annahmen ausdrücklich als Annahmen fest, damit aus einer vorläufigen Idee keine unbemerkte Lieferpflicht wird.

Vom Briefing zum vergleichbaren Angebot

Nutzen Sie das Website-Briefing für den ersten vollständigen Kundenablauf. Liegen bereits Angebote vor, hilft der Leitfaden zum Angebotsvergleich. Bei einer bestehenden Website ergänzen Sie wichtige Adressen und verwenden das Relaunch-Briefing.

Bei WebSoftLeader besprechen wir den Umfang anhand eines Prototyps oder Plans vor der ersten Zahlung. Danach folgen die vereinbarten Zahlungen von 30%, 30% und 40% zu den festgelegten Ergebnissen. Welche Arbeit jeweils abgeschlossen sein muss, gehört in das konkrete Angebot. Die Zusammenarbeit erfolgt remote; Zuständigkeiten und Freigaben bleiben dabei nachvollziehbar dokumentiert.

Quellen und Einordnung

Quellen geprüft am 15. Oktober 2026. Tabelle, Beispiel und Übergabecheckliste sind redaktionelle Arbeitshilfen von WebSoftLeader. Das Beispiel enthält keine gemessenen Kundenergebnisse.

• Nielsen Norman Group: Aufgaben für Nutzungstests. Grundlage für ergebnisorientierte Testszenarien.
• W3C WAI: Barrierefreiheit planen. Grundlage für frühzeitige Planung und Zuständigkeiten.