"Mach einfach was Schönes." Wer auch immer diesen Satz erfunden hat, hat unzählige Webprojekte in den Sand gesetzt. Denn bevor auch nur eine Zeile Code existiert, entscheidet das Briefing darüber, ob ein Projekt in drei Wochen live geht – oder ob man sich in sechs Monaten noch über Buttonfarben streitet.
Das eigentliche Problem: "Schön" ist keine Anforderung
Stell dir vor, du gehst zum Schreiner und sagst: "Bau mir einfach was Schönes." Was passiert? Er fragt dich Löcher in den Bauch. Welches Holz? Welche Maße? Schrank, Tisch, Hochbett?
Bei Webseiten passiert das komischerweise seltener – und genau da liegt das Problem. Kunden werfen das Wort "schön" in den Raum und hoffen, dass der Entwickler Gedanken liest. Schön für die 17-jährige Tochter mit TikTok-Ästhetik? Oder für den 65-jährigen Stammkunden, der einfach nur eine gut sichtbare Telefonnummer will? Zwei völlig verschiedene Webseiten.
Ein Briefing ist kein bürokratischer Overhead. Es ist der Bauplan, ohne den kein vernünftiger Handwerker anfängt zu mauern.
Was wirklich ins Briefing gehört
Ivo von blackforest-webcraft.de hat das in einem lesenswerten Artikel sehr konkret aufgeschlüsselt – und die Punkte lassen sich direkt auf jedes Webprojekt übertragen, egal ob Freelancer-Auftrag oder internes Projekt.
Zielgruppe und Ziel – nicht überspringen
Wer kommt auf die Webseite, und was soll er dort tun? Das klingt trivial, ist es aber nicht. Eine Webseite ohne definiertes Ziel ist Deko. Hübsch vielleicht, aber nutzlos. Anfragen generieren, Termine buchen, Vertrauen aufbauen – das sind konkrete Ziele. "Präsenz zeigen" ist keines.
Inhalte klären, bevor das Design startet
Wer liefert die Texte? Bis wann? Wer macht die Fotos? Diese Fragen klingen nach Projektmanagement-Kleinkram, sind aber der häufigste Grund, warum Projekte in Woche sechs plötzlich stehen. Der Entwickler wartet auf Produkttexte, die der Kunde seit Wochen vor sich herschiebt.
Scope Creep aktiv verhindern
"Können wir nicht auch noch schnell...?" – dieser Satz hat schon mehr Projekte torpediert als schlechter Code. Jedes "schnell noch" kostet Zeit, verzögert den Launch und bläht das Budget auf. Was im Projekt drin ist und was nicht, gehört schriftlich festgehalten. Vorher, nicht nachher.
Der Feedback-Prozess als unterschätztes Risiko
Ein Entwurf geht raus, der Kunde zeigt ihn seiner Frau, die Frau zeigt ihn der Schwester, und plötzlich kommen 15 widersprüchliche Anmerkungen zurück. Klassiker. Lösung: Vorher klären, wer entscheidet, wie viele Revisionsrunden es gibt und in welchem Zeitrahmen Feedback kommt.
Na ja, klingt offensichtlich – aber wie oft wird genau das nicht besprochen?
Was KI-Briefing-Tools können und was nicht
Immer mehr Anbieter setzen auf KI-gestützte Tools, die durch Briefing-Fragen führen. Als Startpunkt durchaus brauchbar. Aber ein Tool fragt nach Daten. Ein guter Entwickler oder Designer fragt, warum du etwas machst. Das ist ein fundamentaler Unterschied – und der lässt sich nicht automatisieren.
Die Mini-Checkliste für dein nächstes Projekt
Bevor das nächste Webprojekt startet, lohnen sich 30 Minuten mit diesen Fragen:
- Wer ist die Zielgruppe, konkret (Alter, Beruf, Problem)?
- Was soll passieren, wenn jemand auf der Webseite landet?
- Welche Funktionen sind Must-have, welche Nice-to-have?
- Wer liefert Texte und Bilder – und bis wann?
- Drei Webseiten, die gefallen, drei die nicht gefallen – jeweils mit Begründung
- Wer hat das letzte Wort bei Freigaben?
Wer diese Punkte klar hat, spart sich und allen Beteiligten etliche Stunden Nacharbeit.
Wie läuft das Briefing bei euch ab – habt ihr feste Templates, oder improvisiert ihr euch von Projekt zu Projekt durch?
Top comments (0)