Portfolio-Leitfaden für Design und Entwicklung: Fallstudien, die zur Einstellung führen

Für Designerinnen und Frontend-Entwickler zählt das Portfolio oft mehr als der Lebenslauf. Es ist der Beweis. Ein Lebenslauf behauptet, dass Sie die Arbeit können; ein Portfolio zeigt die Arbeit und, noch wichtiger, wie Sie darüber nachdenken.

Die meisten Portfolios scheitern auf eine von zwei Arten: zu viele mittelmäßige Projekte oder schöne Screenshots ohne Erklärung des Problems, Ihrer Rolle oder des Ergebnisses. Dieser Leitfaden behebt beides.

Die wichtigsten Punkte

Drei bis fünf starke Projekte schlagen ein Dutzend durchschnittliche – Prüfende verbringen insgesamt zwei bis drei Minuten.
Jedes Projekt braucht dasselbe Grundgerüst: Problem, Ihre Rolle, Prozess, Lösung, Wirkung.
Zeigen Sie die unordentliche Mitte – Skizzen, Iterationen, Abwägungen – nicht nur den fertig polierten Endscreen.
Entwickler: Ein Live-Link plus eine saubere README plus lesbarer Code wiegen mehr als eine aufwendige Website.

Auswählen, was hineinkommt

1Listen Sie jedes Projekt auf, das Sie zeigen könnten – Arbeit, Freelance, Nebenprojekte, Studienarbeiten, Hackathons, Open Source.
2Bewerten Sie jedes nach: Relevanz für die gewünschten Stellen, wie viel des Ergebnisses Sie für sich beanspruchen können und ob Sie Ihren konkreten Beitrag erklären können.
3Behalten Sie die besten 3–5. Streichen Sie alles, was Sie stark einschränken müssten oder worüber Sie wegen einer Geheimhaltungsvereinbarung nicht sprechen können.
4Sorgen Sie dafür, dass die Auswahl Bandbreite zeigt – verschiedene Problemarten, nicht fünf Versionen desselben Screens.

Noch keine Berufserfahrung?

Ein selbst gewähltes Projekt, über das Sie ausführlich sprechen können, schlägt ein echtes Projekt, das Sie kaum angefasst haben. Gestalten Sie ein Produkt neu, das Sie nutzen, bauen Sie ein Tool, das Sie gebraucht haben, oder tragen Sie zu einem Open-Source-Repo bei.

Der Aufbau der Fallstudie

Eine Fallstudie ist eine kurze Geschichte mit fester Form. Streben Sie etwas an, das jemand in zwei Minuten überfliegen und in fünf ganz lesen kann.

Fallstudien-Gliederung

1. Überblick (2–3 Sätze)
   Was das Produkt ist, für wen, was das Projekt war.

2. Meine Rolle
   Ihr Titel, das Team, der Zeitraum, wofür Sie verantwortlich waren im Vergleich dazu, wozu Sie beigetragen haben.

3. Das Problem
   Das Nutzer- oder Geschäftsproblem und wie Sie wussten, dass es real war (Daten, Recherche, Beschwerden).

4. Prozess
   Die 3–4 wichtigsten Schritte, die Sie gemacht haben. Zeigen Sie Artefakte: Skizzen, Flows, Prototypen, Experimente, PRs.
   Nehmen Sie mindestens eine Abwägung oder Sackgasse auf und warum Sie die Richtung geändert haben.

5. Die Lösung
   Das Endergebnis, mit Visuals oder einem Live-Link. Kommentieren Sie die Entscheidungen, die zählen.

6. Wirkung
   Zahlen, wenn Sie welche haben (Conversion, Ladezeit, Aufgabenerfolg, Nutzung). Wenn nicht, qualitative Ergebnisse und was Sie als Nächstes messen würden.

7. Was ich gelernt habe
   Ein oder zwei ehrliche Reflexionen.

Statt

„Ich habe den Checkout-Flow neu gestaltet, um die Nutzererfahrung zu verbessern.“ + 4 polierte Screenshots.

Schreiben Sie

„Der Warenkorbabbruch lag mobil bei 68 %. Ich habe 5 Nutzersitzungen durchgeführt, festgestellt, dass das Adressformular der Absprungpunkt war, eine Autovervollständigung mit 2 Feldern gegen das Original mit 9 Feldern getestet und die Gewinner-Variante ausgeliefert. Der Abbruch fiel in 6 Wochen auf 51 %.“ + Vorher/Nachher + die zwei getesteten Prototypen.

Wenn Sie Entwickler sind

Jedes Projekt: ein Live-Demo-Link und ein Repo-Link, beide funktionierend. Eine kaputte Demo ist schlimmer als keine Demo.
Schreiben Sie eine echte README: was es macht, Screenshot oder GIF, Tech-Stack, wie man es lokal ausführt, was Sie als Nächstes tun würden.
Heften Sie Ihre 4–6 besten Repos in Ihrem GitHub-Profil an und fügen Sie eine Profil-README hinzu.
Heben Sie Signale für Code-Qualität hervor: Tests, CI, klare Commits, sinnvolle Struktur. Prüfende öffnen den Code tatsächlich.
Open-Source-Beiträge zählen – verlinken Sie die gemergten PRs und sagen Sie kurz, was jeder bewirkt hat.
Für Backend- oder Datenrollen, wo nichts Visuelles vorhanden ist, ersetzen ein klares Architekturdiagramm und eine schriftliche Erläuterung die Screenshots.

Gliederung einer Projekt-README

# Projektname
Ein Satz dazu, was es macht und für wen.

![demo](demo.gif)

## Warum ich es gebaut habe
2–3 Sätze.

## Stack
Sprachen, Frameworks, nennenswerte Bibliotheken, Hosting.

## Lokal ausführen
Schritte.

## Nennenswerte Entscheidungen
- Entscheidung und der Grund
- Eine Abwägung, die Sie getroffen haben

## Was als Nächstes kommt
Kurze Liste.

Wenn Sie Designer sind

Zeigen Sie Prozess-Artefakte, nicht nur die finalen Comps: Recherche-Notizen, User-Flows, Wireframes, Iterationen.
Nehmen Sie die nicht ausgelieferten Versionen auf und sagen Sie warum – das zeigt Urteilsvermögen.
Halten Sie das visuelle Handwerk auf der Portfolio-Website selbst hoch; sie ist eine Arbeitsprobe, ob Sie es wollen oder nicht.
Verknüpfen Sie jede Entscheidung mit einem Nutzerbedürfnis oder einem Geschäftsziel, nicht mit persönlichem Geschmack.
Für UX-Rollen führen Sie mit dem Denken; für visuelle oder Markenrollen führen Sie mit dem Handwerk – aber beide brauchen beides.

Wo Sie es hosten

Eine persönliche Website auf Ihrer eigenen Domain ist die stärkste Option – volle Kontrolle, wirkt engagiert.
Schnell zu veröffentlichen: eine Vorlage auf einem Website-Baukasten oder eine einfache statische Seite auf GitHub Pages, Vercel oder Netlify.
Designer können mit Behance oder Dribbble für Reichweite ergänzen, aber halten Sie die echten Fallstudien auf Ihrer eigenen Website.
Entwickler: GitHub ist nicht verhandelbar; eine Portfolio-Website ist ein Plus.
Haben Sie immer eine PDF- oder Folienversion von ein oder zwei Fallstudien parat, für den Fall, dass jemand per E-Mail fragt.

Überkonstruieren Sie die Website nicht

Ein Portfolio mit maßgeschneiderten Animationen, das Wochen dauert und immer noch nur ein Projekt enthält, hilft niemandem. Veröffentlichen Sie zuerst eine schlichte, schnelle Website mit drei echten Fallstudien und verbessern Sie sie dann.

Häufige Fehler

Zu viele Projekte, keines ausführlich erklärt.
Screenshots ohne Problembeschreibung, Rolle oder Ergebnis.
Teamergebnisse für sich beanspruchen, ohne zu sagen, was Sie persönlich getan haben.
Keine Kontaktinformationen oder keine offensichtliche Möglichkeit, in Kontakt zu treten.
Passwortgeschützte oder kaputte Links in der Version, die Sie an Recruiter senden.
Das beste Projekt auf Seite drei vergraben.

In die Praxis umsetzen

Erstellen Sie kostenlos einen ATS-tauglichen Lebenslauf – KI-Schreibhilfe, unbegrenzte Downloads, kein Wasserzeichen.

Meinen Lebenslauf starten

Häufig gestellte Fragen

Wie viele Projekte sollte ein Portfolio enthalten?

Drei bis fünf. Prüfende kommen selten über das dritte hinaus. Tiefe bei wenigen schlägt Breite bei vielen.

Darf ich Arbeit unter Geheimhaltungsvereinbarung aufnehmen?

Sprechen Sie zuerst mit Ihrem Arbeitgeber. Oft können Sie Prozess und Ergebnisse auf hoher Ebene zeigen, ohne vertrauliche Details oder nicht veröffentlichte Screens preiszugeben. Im Zweifel beschreiben Sie es in Worten, statt es zu zeigen.

Brauche ich ein Portfolio, wenn ich Backend-Entwickler bin?

Eine Portfolio-Website ist optional, aber ein starkes GitHub-Profil mit angehefteten Repos, guten READMEs und sichtbaren Beiträgen erfüllt denselben Zweck.

Was kommt zuerst, das Portfolio oder der Lebenslauf?

Setzen Sie den Portfolio-Link oben auf Ihren Lebenslauf und auf LinkedIn. Für Design- und Frontend-Rollen können Sie damit rechnen, dass das Portfolio geprüft wird, bevor jemand den Lebenslauf aufmerksam liest.

So bauen Sie ein Portfolio auf (für Designer und Entwickler)