Design Sprints für Websites: Wie man in 5 Tagen Ergebnisse erzielt

Sechs Monate für ein Website-Redesign. Drei davon allein für die Abstimmung. Wer das kennt, weiß: Das Problem liegt selten an der Umsetzung. Es liegt an der Entscheidungsfindung. An endlosen Feedbackschleifen, an zu vielen Meinungen ohne klare Richtung, an der Angst, sich festzulegen. Was wäre, wenn man die wichtigsten Entscheidungen für eine neue Website in fünf Tagen treffen könnte?

Genau das verspricht ein Design Sprint. Die Methode stammt von Jake Knapp, entwickelt bei Google Ventures, und wurde ursprünglich für Produktentwicklung konzipiert. Aber sie funktioniert auch für Websites. Nicht eins zu eins. Aber mit den richtigen Anpassungen erstaunlich gut.

Ich habe in den letzten Jahren mehrere Design Sprints für Website-Projekte durchgeführt. Für mittelständische B2B-Unternehmen, für SaaS-Startups, für Unternehmen mit komplexen Produktportfolios. Was ich dabei gelernt habe: Die Methode ist kein Allheilmittel. Aber sie löst ein ganz konkretes Problem, das fast jedes Unternehmen hat — die Unfähigkeit, schnell zu belastbaren Entscheidungen zu kommen.

Bevor wir über die Lösung reden, müssen wir das Problem verstehen. Und das Problem ist nicht technischer Natur. Die meisten Website-Projekte scheitern nicht an der Programmierung. Sie scheitern an der Phase davor.

Typischer Ablauf: Ein Kick-off-Workshop, dann ein Briefing, dann ein Konzept, dann Feedback zum Konzept, dann ein überarbeitetes Konzept, dann nochmal Feedback, dann ein Design, dann Feedback zum Design, dann ein überarbeitetes Design. Irgendwann sind drei Monate vergangen und man hat noch keine einzige Zeile Code geschrieben. Nicht weil die Beteiligten inkompetent wären. Sondern weil der Prozess darauf ausgelegt ist, Konflikte zu vermeiden statt sie zu lösen.

In einem mittelständischen B2B-Unternehmen sitzen am Tisch: Marketing, Vertrieb, Geschäftsführung, vielleicht noch die IT-Abteilung. Jeder hat andere Prioritäten. Marketing will eine schöne Marke. Vertrieb will Leads. Die Geschäftsführung will, dass es nicht zu viel kostet. IT will, dass es wartbar bleibt. Alle haben recht. Aber niemand trifft eine Entscheidung, die einen der anderen verärgern könnte.

Genau hier setzt der Design Sprint an. Er schafft einen strukturierten Rahmen, in dem Entscheidungen nicht aufgeschoben, sondern erzwungen werden. Nicht durch Druck, sondern durch das Format selbst.

Ein Design Sprint ist kein Brainstorming-Workshop. Er ist kein Creative Offsite, bei dem man mit Post-its um sich wirft und am Ende ein gutes Gefühl hat, aber keine konkreten Ergebnisse. Ein Design Sprint ist ein strukturierter Fünf-Tage-Prozess mit einem klaren Ziel: Am Ende der Woche hat man einen getesteten Prototyp und echtes Nutzerfeedback.

Jake Knapp hat das Format bei Google Ventures entwickelt und in seinem Buch "Sprint" beschrieben. Die Grundidee: Statt monatelang zu planen, konzentriert man sich eine Woche lang intensiv auf ein Problem, entwickelt einen Lösungsansatz, baut einen Prototyp und testet ihn mit echten Nutzern. Fünf Tage. Montag bis Freitag. Keine Verlängerung.

Das unterscheidet den Design Sprint fundamental von dem, was viele Agenturen als "Workshop-Woche" verkaufen. In einer Workshop-Woche sammelt man Ideen, diskutiert Möglichkeiten und erstellt vielleicht ein Moodboard. Am Ende hat man einen Stapel Dokumente und das vage Gefühl, Fortschritt gemacht zu haben. In einem Design Sprint hat man am Freitag einen klickbaren Prototyp, den fünf echte Nutzer getestet haben. Man hat Daten. Man hat Fakten. Man kann Entscheidungen treffen.

Das originale Sprint-Format wurde für Produktentwicklung konzipiert. Eine App, ein Feature, ein Service. Eine Website ist etwas anderes. Sie hat mehr Stakeholder, mehr Seiten, mehr Touchpoints. Man kann nicht die komplette Website in einem Sprint abhandeln. Aber man kann — und sollte — die wichtigsten strategischen Fragen klären und die kritischsten Seiten prototypen.

Für Website-Sprints empfehle ich, den Fokus auf maximal drei zentrale User Journeys zu legen. Bei einem B2B-Unternehmen könnte das sein: die Startseite als Einstieg, eine Produktseite als Vertiefung und der Kontaktprozess als Conversion. Diese drei Journeys decken den Kern der Website ab. Alles andere lässt sich davon ableiten.

Noch eine Anpassung: Im Original-Sprint wird am Mittwoch entschieden und am Donnerstag prototypisiert. Für eine Website braucht man etwas mehr Prototyping-Zeit, weil die visuelle Komplexität höher ist als bei einer einzelnen App-Funktion. Ich verschiebe deshalb die Entscheidungsphase auf Dienstagnachmittag und gebe dem Prototyping den gesamten Mittwoch und Donnerstag. Das ist eine Abweichung vom Lehrbuch, aber sie funktioniert.

Der Montag ist der wichtigste Tag. Nicht weil hier die meiste Kreativarbeit passiert, sondern weil hier die Grundlage für alles Weitere gelegt wird. Am Montag geht es darum, ein gemeinsames Verständnis des Problems zu schaffen. Klingt trivial. Ist es nicht.

Ich starte den Tag mit Experteninterviews. Nicht mit externen Beratern, sondern mit den Leuten im Unternehmen, die am nächsten am Kunden sind. Der Vertriebsleiter, der weiß, welche Fragen Interessenten immer wieder stellen. Der Support-Mitarbeiter, der weiß, wo Kunden auf der aktuellen Website nicht weiterkommen. Der Produktmanager, der weiß, welche Features den Unterschied zum Wettbewerb machen.

Diese Interviews dauern jeweils 15 bis 20 Minuten. Während die Experten sprechen, macht das Sprint-Team Notizen. Jeder für sich, auf eigene Notizzettel. Keine Diskussion, kein Kommentieren. Nur zuhören und notieren.

Danach erstellt das Team gemeinsam eine Map: eine vereinfachte Darstellung der Customer Journey auf der Website. Links steht der Nutzer, rechts das Ziel (Kontaktanfrage, Demo-Buchung, Download), und dazwischen die Schritte, die er gehen muss. Diese Map ist bewusst simpel. Sie soll kein vollständiges Sitemap-Dokument sein, sondern den Fokus auf die kritischen Pfade lenken.

Am Ende des Montags steht die Sprint-Frage: Welche Annahme wollen wir diese Woche überprüfen? Für eine B2B-Website könnte das sein: "Verstehen Besucher innerhalb von zehn Sekunden, was unser Unternehmen macht und für wen?" Oder: "Finden potenzielle Kunden den Weg von der Produktseite zur Kontaktanfrage?" Diese Frage gibt dem Rest der Woche eine klare Richtung.

Am Dienstagmorgen geht es um Inspiration und Ideenfindung. Aber nicht in der Art, wie man es von Brainstormings kennt. Keine laute Gruppe, die Ideen an ein Whiteboard ruft. Stattdessen: stille, individuelle Arbeit.

Zuerst schaut sich das Team Referenzen an. Nicht nur Wettbewerber, sondern auch Websites aus völlig anderen Branchen, die ähnliche Probleme gelöst haben. Wie erklärt ein komplexes SaaS-Produkt seinen Wert auf der Startseite? Wie führt ein Maschinenbau-Unternehmen durch ein Produktportfolio mit 500 Varianten? Wie macht ein Beratungsunternehmen den Schritt von "Interesse" zu "Kontaktaufnahme" so einfach wie möglich?

Jeder im Team zeichnet dann seine Lösung. Nicht als Wireframe, nicht als perfektes Design. Als Sketch. Drei Panels auf einem Blatt Papier, die den kritischen Flow zeigen. Diese Sketches werden anonym an die Wand gehängt. Das Team betrachtet sie schweigend, klebt Punkte auf die Elemente, die überzeugend sind — ohne zu wissen, von wem welcher Entwurf stammt. Das eliminiert Hierarchie-Effekte. Die Idee des Geschäftsführers bekommt nicht automatisch mehr Punkte als die des Junior-Marketers.

Am Dienstagnachmittag fällt die Entscheidung. Und hier wird es spannend. Im Design Sprint hat der sogenannte Decider das letzte Wort. Das ist in der Regel die Person mit der höchsten Entscheidungsautorität im Raum — meistens die Geschäftsführung oder der Marketingleiter. Der Decider wählt den Entwurf oder die Kombination von Elementen, die prototypisiert werden. Das ist keine demokratische Abstimmung. Es ist eine informierte Entscheidung einer Person, die die Verantwortung trägt.

Das klingt autoritär. Ist es auch. Aber genau das macht den Sprint so effektiv. In normalen Projekten werden Entscheidungen so lange verwässert, bis alle irgendwie zufrieden sind — was bedeutet, dass niemand wirklich zufrieden ist. Im Sprint trifft eine Person eine klare Entscheidung. Diese Entscheidung wird dann am Freitag mit echten Nutzern getestet. Wenn sie falsch war, weiß man es in drei Tagen statt in drei Monaten.

Mittwoch und Donnerstag gehören dem Prototyp. Und hier trennt sich für Website-Projekte die Spreu vom Weizen. Ein guter Website-Prototyp muss sich echt anfühlen. Nutzer müssen vergessen, dass sie einen Prototyp testen. Wenn die Startseite wie ein Wireframe aussieht, bekommt man kein brauchbares Feedback zur Verständlichkeit der Botschaft.

Figma ist dafür das Werkzeug der Wahl. Nicht weil es das einzig mögliche Tool ist, sondern weil es die perfekte Balance zwischen Detailgrad und Geschwindigkeit bietet. In zwei Tagen lässt sich in Figma ein Prototyp bauen, der wie eine echte Website aussieht und sich auch so anfühlt. Mit echten Texten, nicht mit Lorem Ipsum. Mit echten Bildern, nicht mit grauen Platzhaltern. Mit funktionierenden Links zwischen den Seiten.

Hier kommt ein Detail, das den Unterschied macht: Die Texte müssen echt sein. Nicht perfekt, nicht final, aber echt. Wenn auf der Startseite steht "Headline goes here", testet man nichts. Wenn dort steht "Industrielle Messtechnik für Fertigungsunternehmen — präzise, schnell, zuverlässig", testet man, ob diese Positionierung verstanden wird. Der Prototyp muss die Story erzählen, nicht nur das Layout zeigen.

An diesen beiden Tagen arbeiten typischerweise zwei bis drei Leute am Prototyp: ein Designer, ein UX-Spezialist und jemand, der die Texte schreibt. Der Rest des Sprint-Teams kann in dieser Phase andere Aufgaben übernehmen. Aber der Decider sollte regelmäßig vorbeischauen und sicherstellen, dass der Prototyp der Entscheidung vom Vortag entspricht.

Ein Aspekt, der oft übersehen wird: Die Architektur-Entscheidung für die Website beeinflusst, wie gut der Sprint funktioniert. Wenn man mit einem Headless CMS wie Sanity arbeitet und das Frontend mit Next.js baut, hat der Prototyp eine direkte Verbindung zur späteren Umsetzung. Die Komponenten, die man in Figma prototypisiert, lassen sich eins zu eins in React-Komponenten übersetzen. Die Content-Struktur, die man im Sprint definiert, kann direkt als Schema im CMS angelegt werden.

Das ist kein theoretischer Vorteil. In der Praxis bedeutet es, dass man nach dem Sprint nicht bei null anfängt. Der Prototyp ist nicht ein hübsches Bild, das ein Entwickler dann "irgendwie" umsetzen muss. Er ist eine Blaupause, die sich systematisch in Code und Content-Struktur übersetzen lässt. Bei monolithischen Systemen wie WordPress mit Page Buildern oder TYPO3 funktioniert das nicht. Dort ist der Prototyp bestenfalls eine Inspiration, schlimmstenfalls eine Illusion.

Der Freitag ist der Tag, an dem man ehrliches Feedback bekommt. Nicht von Kollegen, nicht vom Vorstand, nicht von der Agentur. Von echten Menschen, die zur Zielgruppe gehören.

Fünf Testpersonen, jeweils 30 bis 45 Minuten. Das klingt wenig, aber die Forschung von Jakob Nielsen zeigt seit Jahrzehnten: Mit fünf Nutzern findet man rund 85 Prozent der Usability-Probleme. Und im Sprint geht es nicht um statistische Signifikanz. Es geht um Muster. Wenn drei von fünf Testern nicht verstehen, was das Unternehmen macht, hat man ein Problem. Wenn vier von fünf den Kontaktbutton nicht finden, hat man ein Problem. Diese Muster sind nach fünf Tests glasklar.

Die Tests laufen so ab: Ein Moderator sitzt mit dem Tester zusammen und gibt ihm Aufgaben. "Stell dir vor, du suchst eine Lösung für industrielle Messtechnik. Du landest auf dieser Website. Was würdest du tun?" Der Tester navigiert durch den Prototyp, denkt laut und der Moderator beobachtet. Das restliche Sprint-Team schaut per Videostream zu und macht Notizen.

Was dabei herauskommt, ist oft unbequem. Man stellt fest, dass die Botschaft, an der man monatelang gefeilt hat, niemand versteht. Dass die Navigation, die intern logisch erschien, für Außenstehende verwirrend ist. Dass das Feature, auf das der Vertrieb besonders stolz ist, für Erstbesucher irrelevant ist. Das tut weh. Aber es ist besser, das nach fünf Tagen herauszufinden als nach fünf Monaten Entwicklungszeit.

Die Zusammensetzung des Sprint-Teams ist entscheidend. Zu viele Leute und der Sprint wird zum Workshop. Zu wenige und es fehlen wichtige Perspektiven. Die ideale Größe liegt bei fünf bis sieben Personen.

Auf Unternehmensseite braucht man: den Decider (jemand, der verbindliche Entscheidungen treffen kann und darf), jemanden aus dem Marketing (der die Markenperspektive einbringt), jemanden aus dem Vertrieb (der die Kundenperspektive kennt) und wenn möglich jemanden aus der Produktentwicklung oder IT (der die technische Machbarkeit einschätzen kann).

Auf Agenturseite braucht man: einen Facilitator (der den Sprint moderiert und den Prozess steuert), einen Designer (der am Mittwoch und Donnerstag den Prototyp baut) und idealerweise einen Strategen oder UX-Researcher (der die Tests am Freitag durchführt). Der Facilitator ist die wichtigste Rolle. Er muss den Prozess kennen, die Gruppe führen können und — das ist der schwierigste Teil — Diskussionen abbrechen können, wenn sie nicht zielführend sind.

Ein häufiger Fehler: Das Unternehmen schickt Leute, die "mal reinschnuppern" wollen, aber keine Entscheidungskompetenz haben. Das macht den Sprint wertlos. Wenn am Dienstagnachmittag eine Entscheidung fällt und am Mittwoch jemand aus der Geschäftsführung sagt "Das habe ich so nie freigegeben", kann man die Woche in die Tonne treten. Der Decider muss die ganze Woche anwesend sein. Keine Ausnahme.

Ehrlichkeit ist hier wichtig. Ein Design Sprint ersetzt kein vollständiges Website-Projekt. Nach fünf Tagen hat man keine fertige Website. Man hat auch kein fertiges Design. Was man hat, ist wertvoller: Klarheit.

Man weiß, welche Positionierung funktioniert und welche nicht. Man weiß, wie die Startseite strukturiert sein muss, damit Besucher verstehen, was das Unternehmen macht. Man weiß, welche Informationen auf einer Produktseite stehen müssen und in welcher Reihenfolge. Man weiß, ob der geplante Conversion-Pfad funktioniert. Man hat diese Antworten nicht aus dem Bauch heraus, sondern auf Basis von echtem Nutzerfeedback.

Was man nicht hat: ein responsives Design für alle Breakpoints, ein vollständiges Designsystem mit allen Komponenten, eine durchgestylte Unterseite für jede Rubrik, ein technisches Konzept für die Implementierung. Das alles folgt nach dem Sprint. Aber es folgt schneller und mit weniger Reibung, weil die strategischen Fragen bereits beantwortet sind.

In meiner Erfahrung spart ein gut durchgeführter Design Sprint etwa vier bis sechs Wochen im Gesamtprojekt. Nicht weil die eigentliche Arbeit weniger wird, sondern weil die Abstimmungsschleifen dramatisch kürzer werden. Wenn man bereits einen getesteten Prototyp hat, diskutiert man nicht mehr über Grundsatzfragen. Man verfeinert.

Große Konzerne haben eigene UX-Abteilungen, eigene Research-Teams und Budgets für monatelange Discovery-Phasen. Startups sind klein genug, um Entscheidungen am Whiteboard zu treffen. Der Mittelstand steckt dazwischen. Zu groß für informelle Entscheidungen, zu klein für aufwendige Research-Prozesse.

Genau das macht den Design Sprint für mittelständische B2B-Unternehmen so wertvoll. Er komprimiert einen Research- und Strategieprozess, der sonst Wochen dauern und fünfstellige Summen kosten würde, auf fünf Tage. Die Geschäftsführung ist involviert, trifft Entscheidungen und sieht am Freitag die Ergebnisse. Kein monatelanges Warten auf eine Präsentation. Kein Gefühl, die Kontrolle abgegeben zu haben.

Dazu kommt ein politischer Aspekt, den niemand offen ausspricht, der aber real ist: In mittelständischen Unternehmen gibt es oft unausgesprochene Konflikte zwischen Abteilungen. Marketing und Vertrieb haben unterschiedliche Vorstellungen von der Website. Die IT-Abteilung wird selten einbezogen und fühlt sich übergangen. Der Design Sprint zwingt alle an einen Tisch. Nicht für ein vages Strategiegespräch, sondern für konkrete Arbeit mit konkretem Ergebnis. Das schafft Alignment auf eine Art, die kein Strategiepapier leisten kann.

Nicht jedes Website-Projekt braucht einen Design Sprint. Wenn das Unternehmen genau weiß, was es will — zum Beispiel ein Redesign im bestehenden Rahmen, bei dem nur das visuelle Erscheinungsbild modernisiert wird — ist ein Sprint überdimensioniert. Dann reicht ein gutes Briefing und ein erfahrener Designer.

Auch bei sehr kleinen Websites — eine Landingpage, ein One-Pager — ist der Aufwand nicht gerechtfertigt. Fünf Tage mit sieben Leuten für eine einzelne Seite? Das steht in keinem Verhältnis. Hier reicht ein halbtägiger Workshop mit anschließendem Prototyping.

Und wenn das Unternehmen nicht bereit ist, den Decider für die gesamte Woche freizustellen, sollte man den Sprint gar nicht erst anfangen. Ein Sprint ohne Entscheidungskompetenz im Raum ist Zeitverschwendung für alle Beteiligten.

Es gibt Situationen, in denen ein Design Sprint nicht nur hilfreich, sondern notwendig ist. Erstens: Wenn das Unternehmen eine grundlegende Neupositionierung vornimmt. Neues Geschäftsfeld, neues Produkt, Zusammenschluss zweier Unternehmen — in diesen Fällen ist unklar, wie sich das Unternehmen digital darstellen soll. Ein Sprint hilft, diese Fragen zu klären, bevor man Monate in die falsche Richtung arbeitet.

Zweitens: Wenn es intern massive Uneinigkeit über die Ausrichtung der Website gibt. Wenn Marketing etwas anderes will als die Geschäftsführung und niemand bereit ist, nachzugeben. Der Sprint schafft einen Rahmen, in dem diese Konflikte produktiv gelöst werden, statt monatelang weiterzuschwelen.

Drittens: Wenn das Unternehmen eine komplexe Zielgruppe hat und sich nicht sicher ist, welche Informationen und welche Struktur die Website braucht. Ein B2B-Unternehmen mit drei verschiedenen Buyer Personas und einem erklärungsbedürftigen Produkt profitiert enorm davon, die Website-Struktur in einem Sprint zu validieren, statt auf Annahmen zu bauen.

Der häufigste Fehler nach einem Design Sprint: Man lässt drei Wochen vergehen, bevor die eigentliche Umsetzung beginnt. In diesen drei Wochen verpufft das Momentum. Die Ergebnisse werden in Frage gestellt. Neue Stakeholder melden sich zu Wort, die beim Sprint nicht dabei waren. Und plötzlich ist man wieder in der alten Abstimmungsspirale.

Mein Rat: Innerhalb von zwei Wochen nach dem Sprint sollte die Design-Phase starten. Der Prototyp wird zum Ausgangspunkt für das eigentliche Design. Die Content-Struktur wird direkt ins CMS übertragen. Die technische Architektur wird festgelegt. Wenn man mit einem modernen Stack arbeitet — Next.js, ein Headless CMS wie Sanity, Tailwind für das Styling — kann man die Sprint-Ergebnisse direkt in den Entwicklungsprozess überführen, ohne dass Information verloren geht.

Idealerweise hat man schon vor dem Sprint die technische Grundlage geschaffen: ein Projekt-Setup mit Next.js und Sanity, eine CI/CD-Pipeline mit Coolify auf Hetzner, die Basis-Konfiguration des CMS. Dann kann man nach dem Sprint direkt mit der Umsetzung der ersten Komponenten beginnen. Das ist der Vorteil eines modernen, komponentenbasierten Ansatzes gegenüber den monolithischen Systemen vergangener Tage.

Ein Design Sprint ist anstrengend. Fünf Tage intensive Zusammenarbeit, harte Entscheidungen, das unangenehme Feedback am Freitag. Es ist kein Feel-Good-Workshop, nach dem alle begeistert sind. Es ist ein Arbeitsinstrument, das Ergebnisse liefert.

In meiner Erfahrung reagieren die meisten Teams nach dem Sprint mit einer Mischung aus Erschöpfung und Erleichterung. Erschöpfung, weil die Woche intensiv war. Erleichterung, weil endlich Klarheit herrscht. Man weiß, wohin die Reise geht. Man hat die Richtung nicht in einem PowerPoint-Dokument festgehalten, sondern in einem getesteten Prototyp. Das ist ein Unterschied, der sich durch das gesamte weitere Projekt zieht.

Für mittelständische B2B-Unternehmen, die vor einem Website-Relaunch stehen und das Gefühl haben, in einer strategischen Sackgasse zu stecken, ist ein Design Sprint oft der effektivste Weg heraus. Nicht weil die Methode magisch ist. Sondern weil sie etwas erzwingt, was die meisten Organisationen von alleine nicht schaffen: Entscheidungen treffen, bevor alle Informationen vorliegen. Und dann überprüfen, ob diese Entscheidungen richtig waren.

Denn das ist die eigentliche Erkenntnis hinter dem Design Sprint: Perfekte Informationen gibt es nicht. Wer darauf wartet, wartet ewig. Besser ist es, eine fundierte Hypothese aufzustellen, sie schnell zu testen und dann auf Basis realer Daten weiterzuarbeiten. Fünf Tage statt fünf Monate. Das ist kein Versprechen einer Agentur. Das ist eine Methode, die funktioniert — wenn man sie ernst nimmt.