Vorlage für Design-Case-Studies: So schreibst du Case Studies, die wirklich Aufträge gewinnen

Jeder Hiring Manager hat gerade einen Stapel Design-Portfolios in Browser-Tabs offen. Auf jedes verwenden sie dreißig Sekunden. Vielleicht sechzig, wenn das Hero-Element seinen Job macht. Die Case Study, die gewinnt, beantwortet in diesem Fenster die echte Frage des Managers, nicht die mit den hübschesten Mockups.

Das ist die praxistaugliche Vorlage. Acht Abschnitte in fester Reihenfolge, die Zahlen, die zählen, und die Prozessbilder, die wirklich Gewicht haben. Wenn dein aktuelles Portfolio wie ein Schulprojekt klingt, ist das hier das Muster für den Rewrite.

Was Hiring Manager wirklich lesen

Der Hiring Manager sucht nach dem Beleg, dass du etwas ausgeliefert hast, das eine Zahl bewegt hat. Alles andere ist Kontext. Prozessdiagramme, Moodboards und Absätze über „meine Reise“ kommen an zweiter Stelle, nicht an erster. Die Case Study, die scheitert, beginnt mit der Reise. Die Case Study, die gewinnt, beginnt mit dem Ergebnis.

Die Designer, die das intuitiv verstehen, liefern Portfolios, die überzeugen. Die Designer, die es nicht tun, liefern Portfolios, die „gutes Feedback bekommen“ und keine Interviews. Der Unterschied ist strukturell, nicht künstlerisch.

Die Vorlage mit acht Abschnitten

Diese acht Abschnitte in dieser Reihenfolge decken jede Case Study ab, die ein Designer schreiben muss. Leuchtturmprojekte bekommen die volle Behandlung. Kleinere Projekte bekommen eine komprimierte Version. Die Abschnitte bleiben dieselben.

Abschnitt 1: Das Ergebnis in einem Satz

Beginne mit dem Resultat, nicht mit dem Setup. Ein Satz. Was das Design ausgeliefert hat und was sich verändert hat.

„Checkout für ein B2B-SaaS neu gestaltet, Conversion im ersten Quartal um 32 % gesteigert.“ Das ist ein Case-Study-Einstieg. „Ich habe mich gefreut, dieses Projekt für ein Stealth-Mode-Startup im Fintech-Bereich zu übernehmen“ ist eine Case Study, die nach fünf Sekunden geschlossen wird.

Hiring Manager gleichen diesen Einstieg mit dem Rest der Seite ab. Wenn der Rest ihn stützt, lesen sie weiter. Ist der Einstieg vage (Erlebnis transformiert, Journey neu gedacht, eine neue Denkweise geschaffen), nehmen sie an, dass die Zahlen fehlen, weil sie schlecht sind. Schreib das Ergebnis so schlicht wie eine Schlagzeile in einer Wirtschaftszeitung.

Abschnitt 2: Das Problem in einem Absatz

Im Problemabschnitt verlieren die meisten Portfolios ihre Leser. Er liest sich wie ein Literaturüberblick über das Unternehmen. Hiring Manager brauchen keine Firmengeschichte, sie brauchen die Einschränkung, die die Designaufgabe erzeugt hat.

Zwei bis vier Sätze, maximal. Was war kaputt. Wen hat es getroffen. Warum blieb es kaputt. Das ist das Problem.

Ein guter Problemabsatz:

Der Checkout hatte in der Enterprise-Stufe eine Abbruchrate von 63 %, weil Einkaufsteams ein Angebot nur mit Screenshots an die Finanzabteilung weitergeben konnten. Der bestehende Ablauf ging von einem einzelnen Käufer mit Kreditkarte aus. Die Lösung bedeutete, für einen Gremienkauf auf Rechnung mit 60 Tagen Zahlungsziel neu zu gestalten.

Keine Vorgeschichte. Kein „der Kunde kam auf uns zu“. Direkt zur Einschränkung. Der Beitrag zu den Prinzipien für Landingpage-Design behandelt dieselbe Disziplin für Marketingtexte. Gleiche Regel für Case Studies.

Abschnitt 3: Die Rahmenbedingungen

Case Studies ohne Rahmenbedingungen lesen sich wie Fiktion. Jedes echte Projekt hat welche (Zeitplan, Team, Plattform, Compliance, Budget, bestehendes System). Sie aufzulisten schafft Vertrauen, weil sie beweisen, dass der Designer in der echten Welt gearbeitet hat und nicht an einem privaten Rebrand einer Fortune-500-Marke.

Fünf bis sieben Stichpunkte. Halte sie konkret.

• Team aus zwei Designern, einem Engineer, einem PM
• Sechs Wochen von Kickoff bis Release
• Bestehendes Designsystem gesperrt, nur Ergänzungen, keine Überschreibungen
• Nur Enterprise-Stufe, Consumer-Checkout bleibt unberührt
• Muss in den bestehenden SAP-Beschaffungsablauf integriert werden
• Barrierefreiheitsziel WCAG AA ab Tag eins
• Keine neue Backend-Arbeit, nur Frontend und Integration

Rahmenbedingungen sind keine Beschwerden. Sie sind der Beweis, dass der Designer die Box verstanden hat, bevor er in ihr gezeichnet hat.

Abschnitt 4: Der Prozess, komprimiert

Die meisten Portfolio-Case-Studies investieren zu viel in den Prozess. Sie enthalten jede divergente Skizze, jedes Workshop-Artefakt, jedes Moodboard. Hiring Manager lesen das nicht. Sie suchen drei Dinge: Hat der Designer das Problem gerahmt, hat er die Lösung validiert, hat er ausgeliefert, was er entworfen hat.

Zeige für jedes einen Beleg, einmal.

Beleg für die Rahmung: ein Diagramm, Flow oder eine Entscheidungsmatrix, die zeigt, wie der Scope definiert wurde. Eine Journey Map, ein Service Blueprint, eine Zusammenfassung einer Wettbewerbsanalyse, ein Screenshot eines Decision Logs. Ein Artefakt, beschriftet mit dem, was es beantwortet hat.

Beleg für die Validierung: ein Research- oder Testartefakt. Zusammenfassung eines Usability-Tests mit zwei Zitaten, A/B-Testergebnis, Analytics-Screenshot mit dem Ausgangszustand, eine Prototyp-Iteration mit annotierten Änderungen. Ein Artefakt, beschriftet mit dem, was es verändert hat.

Beleg für die Auslieferung: das tatsächlich live gegangene Design. Nicht das finale Figma-Comp. Die Live-URL, der App-Store-Screenshot, der aufgezeichnete Flow. Case Studies, die Figma-Comps zeigen und nie das ausgelieferte Produkt, wirken wie Papierdesigns.

Abschnitt 5: Das Decision Log

Das ist der Abschnitt, den die meisten Designer überspringen. Es ist der Abschnitt, den Hiring Manager zweimal lesen.

Ein Decision Log ist eine kurze Liste nicht offensichtlicher Entscheidungen während des Projekts, mit Abwägung und Ergebnis. Es beweist, dass der Designer Meinungen hatte, die an der Realität getestet wurden, und das ist das einzige und stärkste Einstellungssignal, das ein Portfolio senden kann.

Drei bis fünf Einträge. Vorlage für jeden:

• Entscheidung: was gewählt wurde
• Alternative: was verworfen wurde
• Grund: die Einschränkung oder Erkenntnis, die die Entscheidung getrieben hat
• Ergebnis: was nach dem Release passiert ist

Beispiel:

• Entscheidung: Das Teilen von Angeboten wurde als schreibgeschützter öffentlicher Link neu gebaut statt als nativer CC-an-Finanzabteilung-Ablauf.
• Alternative: CC an die Finanzabteilung im Produkt, mit Pflicht zur Kontoerstellung.
• Grund: Einkauf und Finanzen gehören oft zu verschiedenen Systemen, und der Einkauf hätte nicht auf einen Kontoerstellungsprozess gewartet.
• Ergebnis: 71 % der Enterprise-Angebote wurden innerhalb von 24 Stunden nach Erstellung geteilt, vorher waren es 12 %.

Decision Logs sind das Nächste, was ein Portfolio einem echten Arbeitsinterview kommt. Schreib sie zuerst, dann schreib den Rest der Case Study darum herum.

Abschnitt 6: Das Ergebnis, mit Zahlen

Der Ergebnisabschnitt ist der Gehaltsscheck der Case Study. Alles davor war das Setup. Die Zahlen hier müssen echt, konkret und zuordenbar sein.

Drei Arten von Zahlen funktionieren.

Business-Zahlen. Umsatz, Conversion, Retention, Aktivierung, Time-to-Value, CAC, LTV. Das sind die Zahlen, die Hiring Manager zuerst wollen, weil sie direkt auf den Grund verweisen, warum es das Designteam gibt.

Produktzahlen. Task Completion, Fehlerrate, Anzahl der Support-Tickets, Zeit pro Aufgabe, Feature-Adoption. Sie beweisen, dass das Design das Nutzerverhalten verändert hat, und das beweist, dass das Design gut war.

Qualitätszahlen. Score im Accessibility-Audit, Verbesserung der Core Web Vitals, Adoption des Designsystems, eingesparte Übergabezeit. Das sind die Zahlen der zweiten Reihe, nützlich, wenn Business- und Produktzahlen nicht verfügbar sind (unter NDA, zu früh zum Messen).

Eine aus jeder Kategorie reicht völlig. Drei Zahlen pro Case Study schlagen zehn, weil drei konkrete Zahlen ehrlich wirken und zehn nach Füllmaterial.

Wenn das Projekt unter NDA steht, sag das klar. Ersetze exakte Zahlen durch überprüfbare Spannen („ein Conversion-Plus im niedrigen zweistelligen Bereich“, „Aktivierung verdoppelt“). Erfinde nichts. Hiring Manager haben Freunde in jeder Firma, und sie fragen nach.

Abschnitt 7: Deine Rolle, ohne Schnörkel

Jede Case Study braucht eine klare Antwort auf die Frage, die der Hiring Manager tatsächlich im Kopf hat: Was hat dieser Designer persönlich gemacht.

Zwei bis drei Sätze. Schreibe „ich“, wenn die Arbeit solo war, „unser Vierer-Team“, wenn nicht, und nenne in beiden Fällen den konkreten Beitrag.

Gut:

Ich habe das Interaction Design geleitet und das Decision Log verantwortet. Ich habe beim Checkout-Flow mit einem Engineer und beim Scoping mit einem PM zusammengearbeitet. Eine andere Designerin im Team hat das visuelle System verantwortet, das ich angewendet, aber nicht entworfen habe.

Vage:

Ich habe den gesamten Designprozess end-to-end geleitet und eng mit funktionsübergreifenden Partnern zusammengearbeitet, um eine begeisternde User Experience zu liefern.

Die vage Version wirkt wie eine Nebelwand. Sie löst immer mehr Interviewfragen aus, nicht weniger. Schreib die schlichte Version und spar dir das Interview für das Gespräch, das du wirklich führen willst.

Abschnitt 8: Die Reflexion

Ein kurzer Absatz. Was du anders machen würdest, wenn du das Projekt noch einmal durchführen würdest.

Das ist das Erkennungszeichen für Seniorität. Junior-Designer reflektieren in Allgemeinplätzen („Ich würde früher mehr mit Nutzern iterieren“). Senior-Designer reflektieren mit Konkretem („Ich habe den Zeitplan der Beschaffungsintegration um vier Wochen unterschätzt und hätte ihn an Tag eins als eigenen Workstream geplant, statt ihn ins Checkout-Projekt zu falten“).

Zu positive Reflexion („alles lief großartig“) wirkt wie ein Glaubwürdigkeitsproblem. Zu negative Reflexion („ich bin gescheitert“) wirkt unprofessionell. Spezifische, taktische Reflexion wirkt wie jemand, der aus dem Projekt gelernt hat und aus dem nächsten wieder lernen wird.

---

Was du aus den meisten Case Studies streichen solltest

Die meisten Portfolio-Case-Studies sind länger als nötig, weshalb Hiring Manager sie überfliegen. Streiche Folgendes:

Den Absatz „Über den Kunden“. Ist der Kunde bekannt, weiß der Hiring Manager es schon. Wenn nicht, gehört der Kontext in die Problemdarstellung, nicht in einen eigenen Block.

Das Moodboard. Fast nie relevant für eine Einstellungsentscheidung. Heb Moodboards für interne Arbeitsdateien und Kundenpräsentationen auf, wo sie ihren Platz verdienen.

Das Raster mit divergenter Ideenfindung. Neun Konzepte auf einer Seite, von denen acht verworfen wurden, sind ein Workshop-Artefakt, kein Portfolio-Artefakt. Zeige die finale Richtung und die eine Alternative, die ein echter Kandidat war.

Die Rolle nie ausgelieferter Comps. Schöne Comps von Dingen, die nie live gingen, sagen dem Hiring Manager, dass der Designer vielleicht nicht liefert. Das ist das falsche Signal. Beginne immer mit ausgelieferter Arbeit.

Den Essay über den persönlichen Stil. Abschnitte zur „Designphilosophie“ werden übersprungen. Wenn die Philosophie echt ist, zeigen die Case Studies sie, ohne sie anzukündigen.

---

Länge der Case Study nach Seniorität

Die Länge einer Case Study ändert sich mit der Seniorität, die Struktur nicht. Die acht Abschnitte bleiben. Die Tiefe innerhalb der Abschnitte verschiebt sich.

Alles über 2500 Wörter ist eine Case Study, die niemand zu Ende liest. Die Regel für Senior- und Staff-Rollen heißt Dichte, nicht Länge. Mehr Urteilskraft pro Absatz, nicht mehr Absätze.

So schreibst du den ersten Entwurf

Der schnellste Weg zu einer veröffentlichungsreifen Case Study ist, in dieser Reihenfolge zu schreiben, die nicht die Reihenfolge ist, die der Leser sieht.

1. Schreibe zuerst das Decision Log. Drei bis fünf Einträge. Das ist der schwierigste Teil und der Teil, um den sich alles andere dreht.
2. Schreibe als Zweites den Ergebnisabschnitt. Hol dir die Zahlen, bevor du um sie herum schreibst.
3. Schreibe als Drittes Problem und Rahmenbedingungen. Jetzt weißt du, welche Rahmenbedingungen zählten, weil du weißt, welche Entscheidungen sie getrieben haben.
4. Schreibe als Viertes den Prozessabschnitt. Wähle die drei Artefakte, die ihren Platz verdienen.
5. Schreibe Rolle und Reflexion zuletzt. Kurz, ehrlich, fertig.
6. Schreibe den Ein-Satz-Einstieg ganz oben zuletzt neu, nachdem alles andere geschrieben ist. Er ist der zuletzt entworfene Satz und der zuerst gelesene.

Diese Reihenfolge erzwingt das harte Denken am Anfang. Designer, die in Lesereihenfolge schreiben, landen meist bei hübscher Prosa und fehlender Substanz.

So präsentierst du Prozess, ohne den Leser zu langweilen

In Prozessabschnitten werden die meisten Portfolios zu Tode überflogen. Die Lösung ist Dichte, nicht Löschen.

Ein annotierter Screenshot pro Artefakt. Keine Galerie der gesamten Arbeitsdatei. Ein einzelner Screenshot mit drei Callouts, die erklären, was das Artefakt beantwortet hat.

Ein einziges Prototyp-Video, nicht länger als 30 Sekunden. Verzichte auf die ungeschnittene Bildschirmaufnahme. Schneide das Prototyp-Video zu einer knappen Schleife, die die zentrale Interaktion zeigt, beschriftet.

Vorher und nachher, jedes Mal. Jeder Vergleich mit einem „Vorher“ ist stärker als einer ohne. Selbst eine Bleistiftskizze neben dem ausgelieferten Produkt wirkt wie Fortschritt. Das Wireframe-Glossar erklärt, welche frühen Artefakte Gewicht haben.

Ein Voxel, eine Skizze oder ein Low-Fi-Frame statt noch eines polierten Comps. Der Kontrast zwischen Low-Fidelity-Denken und High-Fidelity-Auslieferung beweist, dass der Designer ein Problem durchgearbeitet hat, statt sich in eine Lösung hineinzustylen.

Wenn du ein Team willst, das Portfolios prüft und Case Studies mit Hiring Managern im Loop neu schreibt, engagiere Brainy. Portfolio-Reviews gehören zu unseren am schnellsten gebuchten Angeboten für Senior- und Staff-Designer auf Jobsuche.

Der Bestanden/Durchgefallen-Test für Case Studies

Lass jede Case Study durch fünf Prüfungen laufen, bevor sie in deinem Portfolio live geht.

Scan-Test. Kann ein Leser Problem, Ansatz und Ergebnis allein aus den Überschriften und den ersten Sätzen entnehmen. Wenn nicht, ist die Scanbarkeit kaputt. Der Beitrag zu visueller Hierarchie im Design behandelt die strukturelle Lösung.

Zahlen-Test. Stehen mindestens zwei echte Zahlen auf der Seite. Wenn nicht, ist die Case Study eine Geschichte ohne Pointe.

Rollen-Test. Kann ein Leser „Was hat dieser Designer persönlich gemacht“ in unter 10 Sekunden Lesezeit beantworten. Wenn nicht, ist der Rollenabschnitt zu vage.

Entscheidungs-Test. Zeigt die Case Study mindestens drei nicht offensichtliche Entscheidungen mit benannten Trade-offs. Wenn nicht, wirkt der Designer wie ein Ausführer, nicht wie ein Denker.

Auslieferungs-Test. Gibt es einen Beleg, dass die Arbeit tatsächlich live ging. Eine URL, ein Screenshot auf einem echten Gerät, ein App-Store-Link, ein Screenshot von Produktionscode. Wenn nicht, ist die Case Study ein spekulatives Stück, kein professionelles.

Fünf Prüfungen. Fünf Minuten. Jede Case Study, jedes Mal.

---

FAQ

Wie lang sollte eine Design-Case-Study sein?

Zwischen 800 und 2500 Wörtern, je nach Seniorität. Junior-Case-Studies umfassen 800 bis 1200, Mid-Level 1200 bis 1800.

Senior 1500 bis 2200. Staff- und Principal-Case-Studies dürfen bis 2500 reichen, wenn Entscheidungen und Zahlen es rechtfertigen. Alles Längere verliert den Leser.

Was sollte jede Design-Case-Study enthalten?

Acht Abschnitte in dieser Reihenfolge: ein Ein-Satz-Ergebnis, einen Problemabsatz, Rahmenbedingungen, einen komprimierten Prozessabschnitt, ein Decision Log, messbare Ergebnisse, eine klare Aussage zu deiner persönlichen Rolle und eine kurze Reflexion. Jede Case Study braucht alle acht, auch wenn manche nur zwei Sätze lang sind.

Wie schreibt man eine Case Study, ohne ein NDA zu brechen?

Ersetze konkrete Zahlen durch überprüfbare Spannen („ein Conversion-Plus im niedrigen zweistelligen Bereich“) und benannte Marken durch die Branche („ein Fintech mit über 100 Enterprise-Kunden“). Nenne das NDA gleich zu Beginn der Case Study deutlich. Erfinde keine Zahlen oder Marken. Hiring Manager prüfen nach, und erfundene Case Studies beenden Karrieren.

Wie zeigt man Prozess, ohne den Leser einzuschläfern?

Beschränke dich auf drei Artefakte (eines für die Rahmung, eines für die Validierung, eines für die Auslieferung). Annotiere jedes Artefakt mit dem, was es beantwortet hat. Ersetze lange Prototyp-Videos durch 30-Sekunden-Schnitte der zentralen Interaktion. Nimm immer einen Vorher-Nachher-Vergleich auf. Dichte schlägt Menge in jedem Portfolio-Review.

Was ist der größte Fehler, den Designer in Case Studies machen?

Mit dem Setup statt mit dem Ergebnis zu beginnen. Die erste Zeile einer Case Study sollte das Resultat des Projekts sein, nicht die Begeisterung beim Start. Hiring Manager scannen von oben nach unten. Ist das Ergebnis auf Seite zwei vergraben, ist die Case Study schon verloren.

Wie schreibe ich eine Case Study, wenn ich das Projekt noch nicht ausgeliefert habe?

Liefere zuerst etwas aus. Nicht ausgelieferte Case Studies wirken spekulativ, und Hiring Manager werten sie ab. Wenn das Projekt vor dem Release auftauchen muss, kennzeichne es klar als „in Entwicklung“ und konzentriere dich auf Decision Log und Research-Abschnitte. Zeige nie nicht ausgelieferte Comps, als wären sie echt.

Das Portfolio ist eine Verkaufsseite

Jede Case Study ist eine Verkaufsseite für den Designer, der sie geschrieben hat. Das Produkt ist der Designer. Der Käufer ist der Hiring Manager. Der Preis ist ein vierzigminütiges Interview.

Verkaufsseiten, die gewinnen, sind direkt, konkret und ehrlich. Sie beginnen mit dem Ergebnis, belegen es mit Rahmenbedingungen und Entscheidungen, stützen es mit Zahlen und enden mit einer klaren Aussage, wer der Verkäufer ist. Verkaufsseiten, die verlieren, verstecken das Ergebnis hinter Prozess, polstern die Geschichte mit Kontext und lassen den Leser rätseln, was er eigentlich gekauft hat.

Schreib die acht Abschnitte. Streich den Ballast. Liefere die Case Study aus. Dann mach es für das nächste Projekt noch einmal, und für das danach, bis das Portfolio wie eine Reihe ausgelieferter Wetten wirkt, die sich ausgezahlt haben, und nicht wie eine Reihe von Reisen, die dir Spaß gemacht haben.

Wenn du ein Team willst, das Portfolios prüft, neu schreibt und so ausliefert, dass sie in Interviews münden, engagiere Brainy. Wir haben diese Vorlage über Produkt-, Brand- und UX-Portfolios hinweg eingesetzt, und die Struktur trägt jedes Mal.

Weiterlesen

• Prinzipien für Landingpage-Design
• Visuelle Hierarchie im Design
• Brand Identity vor Kunden präsentieren
• Preise für Brand-Identity-Design