Interview: Was ein gutes Briefing ausmacht. Über Projekte, KI und echtes Vertrauen

Gibt es Briefings, bei denen ihr schon nach wenigen Minuten wisst, ob aus dem Projekt etwas wird?

Sergei: Manche Briefings gehen einfach nicht in die Tiefe. Da werden nur die Hard Facts abgeklappert. Und man hat das Gefühl, dass sich die Kunden nur noch ein separates Vergleichsangebot holen. 

Paul: Genau. Entweder sind es generische Hard Facts – oder das Briefing ist mittlerweile einfach KI-generiert. Die Leute verstehen dann selbst nur zur Hälfte, was in ihrem eigenen Briefing überhaupt drinsteht.

Ihr sprecht KI direkt an. Woran merkt ihr, dass ein Briefing aus einem Sprachmodell stammt?

Sergei: Wir hatten schon Briefings mit super spezifischen technischen Anforderungen, die eigentlich überhaupt keinen Sinn ergaben. Die kamen ganz klar von einer KI als Antwort auf die Frage: Wie setzen wir das und das am besten um? Alles sehr technische Sachen. Und dann lernst du die Leute im Call kennen und merkst, dass deutlich weniger technisches Verständnis dahintersteckt.

Also lieber die KI mal außen vor lassen und selbst nachdenken?

Paul: Ja. Viel sinnvoller ist es, in die Tiefe zu gehen und kontextuelle Dinge mitzugeben. Also zu sagen: Das wollen wir mit unserer Website erreichen. Das sind unsere Nutzer. Das sind unsere aktuellen Schwachstellen. So etwas hilft wirklich weiter.

Der Punkt ist klar: KI kann viele Aufgaben beschleunigen. Bei einem Briefing ersetzt sie aber nicht das eigene Verständnis für das Geschäft. Es hilft wenig, wenn niemand im Unternehmen die dahinterliegende Logik nachvollziehen kann.

Kommen Kunden oft mit einer festen Vorstellung, wissen aber nicht genau, warum sie das wollen?

Paul: Genau das ist der Punkt. In größeren Projekten gehen wir deshalb gerne gemeinsam mit dem Kunden in einen Problem- und Lösungsraum. Das ist relativ klassisch aus dem Design Thinking abgeleitet.

Der Unterschied ist entscheidend. Ein Kunde, der mit einer fertigen technischen Lösung ankommt, überspringt die wichtigste Frage: Welches Problem soll überhaupt gelöst werden? Genau diese Lücke füllt eine gute Agentur – vorausgesetzt, sie bekommt den nötigen Kontext.

Ihr habt Design Thinking und Research erwähnt. Was passiert in dieser Phase konkret?

Paul: Desk Research heißt bei uns: Wir schauen uns die Zahlen an, wir werten die Analytics aus, wir sprechen mit den Stakeholdern. Wir schauen, welche Marketingmaßnahmen bereits laufen und wie die Website in diesen Flow eingebunden wird. Dann skizzieren wir eine Lösung – und zwar deutlich bevor wir überhaupt in den Design- und Entwicklungsprozess gehen.

Sergei: Nur wollen viele Kunden für diese Phase ungern Geld ausgeben. Sie sehen die Notwendigkeit nicht und denken: Ich kenne doch unsere Zahlen, ich kenne unsere Kunden, ich weiß, worum es ihnen geht.

Viele Kunden glauben inzwischen ja auch, sie könnten ihre Designs selbst bauen. Wie seht ihr das?

Paul: Viele Kunden denken heute, sie könnten Design selbst machen, weil es fast nichts mehr kostet. Die harten Skills, die früher nötig waren, um ein spezifisches Design zu erstellen, rücken in den Hintergrund – man denkt scheinbar, man braucht sie nicht mehr. Aber viele unterschätzen, dass der eigentliche Mehrwert ganz woanders liegt. Es geht darum, den richtigen Kontext zu schaffen, das Produkt zu explorieren und eine Systematik aufzubauen, um es am Ende optimal auszurollen.

Sollte ein Kunde im Briefing schon ein Budget nennen?

Sergei: Viele haben Angst, sich festzulegen. Deshalb gibt es bei den meisten gar keine Budgetangabe – sie erwarten einfach ein Angebot mit Preis. Wenn doch jemand eine Summe nennt, ist das ein gutes Zeichen. Das haben wir aber eher bei Kunden, mit denen wir schon zusammengearbeitet haben.

Das heißt, sie vertrauen eurer Einschätzung?

Sergei: Ja, bei langjährigen Geschäftspartnern ist das so. Und bei öffentlichen Ausschreibungen ist das Budget oft so niedrig, dass sie es von vornherein nennen müssen. Dann ist die Frage eher: Was bekommen wir für das Geld?

Den Research-Bereich kann man unglaublich groß aufblähen. Aber irgendwann nimmt der Grenznutzen ab. Viele wissen bei einer Anfrage selbst noch nicht, ob sie es „quick and dirty" wollen oder von Grund auf neu und sauber konzipiert.

Paul: Auch für uns gibt es viele Variablen. Wir können eine einfache Website bauen. Oder eine mit 20 visuellen Modulen, viel Varianz und einem richtig guten Design. Oder wir bilden die gleichen Inhalte in zehn Modulen ab. Es kommt darauf an, welche Erwartungshaltung der Kunde hat.

Sobald die Arbeit losgeht, wird Feedback oft zur großen Geschichte. Was ratet ihr Kunden?

Paul: Idealerweise gibt es eine Person, die zu einem festen Zeitpunkt gesammeltes Feedback gibt. Projekte laufen dann am besten, wenn wir mit einem dedizierten Projektmanager auf Kundenseite ein Weekly haben und der Zeitstrahl klar ist. Wir setzen im Verlauf feste auch gerne Feedback-Zeitpunkte: Design fertig, Design-Feedback, Content eingepflegt, Projekt fertig, abschließendes Feedback. Und am liebsten würde ich zum Schluss immer gemeinsam ein Bier trinken gehen.

Wie geht es weiter, wenn das Projekt live ist?

Sergei: Die meisten Projekte gehen bei uns in eine langfristige Betreuung über. Es gibt eine Art dauerhafte Revision, in der wir die Seite oder das Produkt kontinuierlich optimieren. Wir bauen laufend weitere Features ein, denn ein Launch ist selten der finale Stand. Wenn der Zeitdruck nachlässt, arbeiten wir unseren Backlog ab – da steht alles drin, was geplant war und was als Idee von uns oder vom Kunden kam.

Was wäre euer größter Wunsch mit Blick auf Briefings?

Paul: Dass Kunden uns noch stärker als Experten vertrauen. Es wäre viel wichtiger, aus dem Briefing zu erfahren, was der Kunde eigentlich erreichen möchte und wo seine aktuellen Probleme liegen. Über mögliche Lösungsansätze muss er sich vorher gar keine Gedanken machen – und sich auch nicht per KI aufschlauen. Denn maßgeschneiderte Lösungen sind unser Job und unsere Expertise.