Warum diese Seite keine Screenshots meiner Designs zeigt

Wer auf dieser Seite nach einer Galerie sucht — bunte Screens, geschwungene Case-Study-Karussells, das übliche “Vorher/Nachher” mit Handy-Mockup und Schlagschatten — wird enttäuscht. Es gibt keine. Nicht, weil mir das Material fehlt. Ich habe fünfzehn Jahre Screens gebaut, bei DefShop, bei Oetker Digital, bei A Eins Digital Innovation. Es gibt genug Material für zehn Dribbble-Profile. Ich zeige es trotzdem nicht. Das ist eine bewusste Entscheidung, keine Notlage — und ich will erklären, warum ich sie für die richtige halte, gerade jetzt, in einer Zeit, in der schöne Screenshots weniger wert sind als je zuvor.

Das Dribbble-Problem: Schönheit ist heute die billigste Währung

Es gab eine Zeit, in der ein poliertes Interface-Mockup tatsächlich etwas über die Fähigkeiten der Person aussagte, die es gebaut hat. Diese Zeit ist vorbei. Jedes Design-Tool mit KI-Funktion kann heute in Sekunden ein makelloses Dashboard-Mockup erzeugen — abgerundete Karten, sanfte Schatten, perfekt austarierte Farbpaletten, ganz ohne dass jemand auch nur eine einzige Interaktionslogik durchdacht hätte. Ein Prompt reicht. Das Ergebnis sieht auf Dribbble hervorragend aus und würde in einem echten Produkt in der ersten Woche an einem Edge Case zerbrechen, den niemand mitgedacht hat, weil es nie gebaut werden musste, sondern nur aussehen musste.

Das ist der Kern meines Problems mit Screenshot-Portfolios: Sie beweisen ästhetisches Urteilsvermögen, aber nichts über Handwerk. Ein einzelnes Bild zeigt einen eingefrorenen Zustand — nie den leeren State, nie den Fehlerfall, nie das Verhalten bei einer Netzwerk-Latenz von zwei Sekunden, nie die Entscheidung, warum ein Dropdown ein Dropdown und kein Radio-Button-Set wurde. Genau die Entscheidungen, die den eigentlichen Wert von Design-Arbeit ausmachen, sind auf einem Screenshot unsichtbar. Was sichtbar bleibt, ist Dekoration. Und Dekoration lässt sich heute in Sekunden generieren, ohne Erfahrung, ohne Verantwortung für das, was danach passiert, wenn echte Nutzer mit echten Daten auf das Interface treffen.

Die NDA-Realität, die kaum jemand ausspricht

Es gibt noch einen zweiten, banaleren Grund, über den in der Design-Szene selten offen geredet wird: Der überwiegende Teil meiner Arbeit gehört mir gar nicht. Bei DefShop habe ich drei komplette Redesigns einer E-Commerce-Plattform verantwortet und die Lead-Gestaltung für zwei native Apps übernommen — das war Auftragsarbeit für ein Unternehmen, dessen Markenrichtlinien und Handelsgeheimnisse nicht auf meiner persönlichen Website landen dürfen. Bei Oetker Digital war ich direkt ins Engineering-Team gestafft, um die Lücke zwischen Design und produktivem Code zu schließen — auch das: interne Produktarbeit, keine frei verwertbaren Assets. Bei A Eins Digital Innovation habe ich Portazon mitgestaltet, die erste deutschsprachige Super-App — ein Produkt mit eigenen Investoren, eigener Roadmap, eigenen Vertraulichkeitsvereinbarungen.

Die ehrliche Konsequenz: Selbst wenn ich wollte, dürfte ich die meisten dieser Screens gar nicht in hoher Auflösung veröffentlichen. Was auf vielen Designer-Portfolios als “Case Study” landet, ist deshalb oft eine sorgfältig entschärfte, mit dem Ex-Arbeitgeber abgestimmte Höflichkeitsversion der eigentlichen Arbeit — Screens ohne echte Nutzerdaten, ohne interne Tools, ohne alles, was tatsächlich zeigen würde, wie eine Entscheidung zustande kam. Diese Bereinigung frisst genau den Teil weg, der eigentlich interessant wäre. Übrig bleibt eine hübsche Hülle, die weder mich schützt noch den Betrachter informiert. Ich habe mich entschieden, dieses Spiel gar nicht erst zu spielen, statt eine gefällige, aber inhaltsleere Version davon zu zeigen.

Selbst bei meiner aktuellen Arbeit als Freelancer für zwei Unternehmen gilt dasselbe Prinzip, nur in kleinerem Rahmen. Ein interaktives Solar-Beratungstool mit Live-Bedarfsermittlung für Sales-Teams oder ein Figma-basiertes Slide-System, das PowerPoint im B2B-Vertrieb ablöst, sind Produkte, die für einen konkreten Geschäftszweck entstehen — nicht für meine Selbstdarstellung. Ich kann öffentlich beschreiben, dass es sie gibt und welches Problem sie lösen, weil das bereits Teil meiner beruflichen Vita ist. Aber die granularen Zugriffsrechte, die internen Vertriebsdaten, die konkrete Bedienoberfläche eines Tools, das gerade produktiv im Einsatz ist — das bleibt zu Recht hinter der Vertraulichkeit des Auftraggebers. Wer ausschließlich mit Screenshots arbeitet, gerät in genau diesem Spannungsfeld ständig in Erklärungsnot: Zeige ich zu viel und riskiere ein Vertrauensproblem mit dem Kunden, oder zeige ich so wenig, dass das Bild wertlos wird? Ein Artikel über die zugrunde liegende Methodik hat dieses Dilemma nicht.

Was ein Screenshot verschweigt, ein Artikel aber zeigen muss

Der eigentliche Unterschied zwischen einem Bild und einem Text ist keine Stilfrage, sondern eine Frage der Beweislast. Ein Screenshot kann nicht lügen, aber er kann auch nicht begründen. Er zeigt ein Ergebnis, ohne den Weg dorthin offenzulegen — und genau der Weg ist das, was ein Junior-Designer von einem erfahrenen unterscheidet. Jeder kann heute (mit oder ohne KI-Unterstützung) ein sauberes Interface zusammenklicken. Was sich nicht kopieren lässt, ist die Fähigkeit, in einem konkreten Meeting zu begründen, warum ein Warenkorb-Icon oben rechts bleiben muss, obwohl die neue Navigation eigentlich links wäre, oder warum ein Onboarding-Flow drei Schritte kürzer werden sollte, obwohl der Product Owner eigentlich einen vierten Schritt für Tracking-Zwecke wollte.

Ein Artikel zwingt mich, diese Begründung tatsächlich auszuformulieren — nicht als Bauchgefühl, sondern als nachvollziehbare Kette von Annahme, Test und Konsequenz. Wenn ich über shadcn/ui schreibe und erkläre, warum Copy-Paste-Distribution eine bewusste Architektur-Entscheidung ist und keine fehlende Paketverwaltung, oder wenn ich darlege, warum “intuitiv” in einem Usability-Review kein Argument, sondern eine unbewiesene Behauptung ist, dann zeige ich etwas, das ein Screenshot strukturell nicht zeigen kann: den Denkprozess selbst, mit allen Abwägungen, Fehlannahmen und Kompromissen, die dazugehören. Das ist unbequemer zu produzieren als ein Mockup — und genau deshalb schwerer zu fälschen.

Ein Bild lässt sich zudem nicht widerlegen, ein Artikel schon. Genau das macht ihn zum härteren Beweis. Wenn ich schreibe, dass ich Figma-Auto-Layout wie CSS Flexbox behandle, oder dass ich Browser-DevTools als festen Bestandteil meines Design-Prozesses nutze, dann ist das eine Behauptung mit Angriffsfläche — jeder, der selbst mit Flexbox oder DevTools arbeitet, kann sofort prüfen, ob das stimmt oder ob ich nur Buzzwords aneinanderreihe. Diese Überprüfbarkeit ist unbequem für mich als Autor, aber sie ist der eigentliche Wert für den Leser. Ein Mockup dagegen kann man nicht widerlegen, weil es keine Behauptung aufstellt — es zeigt einfach nur einen Zustand und überlässt dem Betrachter, sich die Kompetenz dahinter selbst einzubilden.

Warum ich keine neue Dribbble-Bibliothek aufbauen will

Es gibt einen Unterschied zwischen einem Schaufenster und einer Bibliothek, und ich will bewusst Letzteres sein. Ein Schaufenster verkauft: Es zeigt die attraktivsten fünf Prozent einer Arbeit, optimiert für den ersten Eindruck, mit dem Ziel, einen Auftrag oder einen Job auszulösen. Eine Bibliothek gibt: Sie legt offen, wie jemand denkt, mit dem Risiko, dass nicht jeder Gedanke perfekt poliert ist, aber mit dem Vorteil, dass er tatsächlich überprüfbar bleibt. Ich will nicht, dass jemand meine Website verlässt und denkt “schöne Bilder”. Ich will, dass jemand sie verlässt und denkt “so löst diese Person Probleme — und ich verstehe jetzt, wie”.

Das ist auch der Grund, warum diese Seite selbst als Beweisstück funktioniert, ganz ohne eine einzige Design-Galerie. Wie ich in einem früheren Beitrag beschrieben habe, ist die technische Umsetzung dieser Website — Astro für minimales JavaScript, Tailwind v4 mit Design-Tokens direkt im Stylesheet, shadcn/ui als editierbare Komponentenbasis — selbst eine Design-Entscheidung, die sich prüfen lässt. Wer wissen will, ob ich Interfaces bauen kann, muss nicht auf ein Wort vertrauen. Die Seite lädt in Bruchteilen einer Sekunde, respektiert prefers-reduced-motion, nutzt ein durchdachtes Typografiesystem nach der Major-Third-Skala. Das ist überprüfbarer als jedes Mockup, weil es tatsächlich läuft, statt nur auszusehen.

Wissen teilen skaliert anders als Arbeitsproben zeigen

Eine Design-Galerie hat einen strukturellen Deckel: Sie kann nur zeigen, was ich in der Vergangenheit für andere gebaut habe — begrenzt durch NDA, begrenzt durch die Zahl der Projekte, begrenzt durch das, was zufällig fotogen genug war, um es zu präsentieren. Geschriebenes Wissen hat diesen Deckel nicht. Ein Artikel über die Grenzen von Design-Tokens in Tailwind v4 oder über die Governance-Probleme von Copy-Paste-Component-Systemen ist morgen für eine völlig andere Person relevant als heute, unabhängig davon, für welchen Kunden ich gerade arbeite oder ob ich überhaupt gerade in einem Projekt stecke, das man zeigen dürfte.

Das ist auch ökonomisch der klügere Hebel für mich persönlich als Freelancer: Eine Galerie muss ich für jeden neuen Auftrag stillschweigend aktuell halten, mit dem Risiko, dass die aktuellsten und interessantesten Arbeiten gerade die sind, die ich am wenigsten zeigen darf. Wissen dagegen akkumuliert sich. Jeder Artikel bleibt gültig, unabhängig davon, ob der Kunde dahinter öffentlich genannt werden darf. Ich beschreibe die Methode, nicht das Ergebnis für einen bestimmten Auftraggeber — und die Methode ist genau der Teil, der über Projekte hinweg übertragbar ist, während einzelne Bildschirme es nie sind.

Die Kehrseite — wann eine visuelle Galerie trotzdem sinnvoll ist

Ich will nicht behaupten, dass Bild-Portfolios grundsätzlich falsch sind. Für bestimmte Rollen sind sie die richtige Wahl: Ein UI-Designer, der primär für visuelle Konsistenz und Ästhetik eingestellt wird, muss diese Ästhetik zeigen können — da ersetzt kein Text ein Bild, weil die Fähigkeit selbst visuell ist. Auch für sehr frühe Karrierestufen, in denen es noch keine tiefe methodische Erfahrung gibt, über die man schreiben könnte, ist eine Sammlung guter Arbeitsproben oft die ehrlichere Visitenkarte als ein erzwungener Blogbeitrag ohne echten Inhalt dahinter.

Auch für Design-System-Arbeit ist eine Bildergalerie strukturell ungeeignet, und das betrifft einen großen Teil dessen, was ich in den letzten Jahren gemacht habe. Ein Design System lässt sich nicht als einzelnes hübsches Bild zusammenfassen — es ist per Definition kein Zustand, sondern eine Menge von Regeln: wann eine Variante zur eigenen Komponente wird, wie ein Token-Wert sich durch zwanzig Komponenten zieht, wie eine Governance-Struktur verhindert, dass zehn Teams zehn leicht unterschiedliche Buttons bauen. Man könnte einen Screenshot einer Komponentenbibliothek zeigen, aber genau der interessante Teil — warum diese Grenze zwischen System-Komponente und Custom-Komponente genau hier verläuft — bleibt unsichtbar. Das ist einer der Gründe, warum ich Design-System-Themen konsequent als Text behandle: Weil das Medium der eigentlichen Sache angemessener ist als ein Bildausschnitt.

Für meine eigene Position — fünfzehn Jahre Erfahrung an der Schnittstelle von Design und Engineering, mit dem Anspruch, nicht nur schöne, sondern funktionierende und wartbare Systeme zu bauen — ist die Rechnung anders. Die Zielgruppe, die ich erreichen will, sucht keine hübschen Bilder mehr, sie hatte davon in den letzten Jahren mehr als genug und weiß längst, dass ein Mockup nichts über Produktionsreife aussagt. Sie sucht jemanden, der begründen kann, warum eine Entscheidung richtig war, bevor der Code geschrieben wurde, und der diese Begründung auch dann noch verteidigen kann, wenn der erste Einwand kommt.

Es gibt außerdem einen Grund, der mit meinem Werdegang zu tun hat und über reine Marktlogik hinausgeht: Ich habe das Gestalten nicht am Reißbrett gelernt, sondern an Wänden — mit der Sprühdose, unter Zeitdruck, ohne Undo-Taste. Diese Herkunft hat mir früh beigebracht, dass eine Komposition entweder trägt oder nicht, unabhängig davon, wie überzeugend man sie im Nachhinein erklärt. Später kam die Sysadmin-Zeit dazu, in der ein System entweder lief oder nicht, ganz gleich, wie elegant die Doku aussah. Beide Prägungen haben mich skeptisch gemacht gegenüber jeder Form von Beweisführung, die sich nicht überprüfen lässt. Ein Screenshot ist genau das: nicht überprüfbar, nur betrachtbar. Ein Text mit einer nachvollziehbaren Kette von Ursache und Wirkung dagegen schon.

Was das für Auftraggeber und Entscheider bedeutet

Für Product Leadership und alle, die Design-Rollen einstellen oder Budget für Designarbeit freigeben, übersetzt sich das in einen sehr konkreten Vorteil: Ein geschriebener Artikel ist ein günstigerer, ehrlicherer Filter als ein Portfolio-Review. Ein Portfolio-Screening kostet ein Meeting, in dem eine Person ihre eigene Arbeit erklären darf und dabei zwangsläufig die beste Version ihrer Entscheidungen erzählt — Rückfragen sind live schwer zu stellen, unbequeme Kompromisse werden selten erwähnt. Ein Artikel dagegen liegt vollständig offen, jederzeit nachprüfbar, ohne dass ich in Echtzeit eine Geschichte glattziehen kann. Wer vor einer Einstellungsentscheidung oder einer Projektvergabe steht, kann in zehn Minuten Lesezeit prüfen, ob jemand tatsächlich in Trade-offs denkt oder nur in Trends — ein Signal, das ein Case-Study-Deck mit sorgfältig kuratierten Screenshots strukturell nicht liefern kann. Das senkt das Risiko einer Fehlbesetzung spürbar, ohne dass überhaupt ein Kennenlerngespräch nötig war, um die methodische Tiefe einzuschätzen.

Deshalb bleibt diese Seite ohne Galerie. Nicht aus Mangel an Material, sondern aus der Überzeugung, dass die Frage “kann diese Person gut gestalten” heute weniger interessant ist als die Frage “kann diese Person begründen, verteidigen und im Zweifel auch revidieren, was sie gestaltet hat”. Die zweite Frage beantwortet kein Bild. Nur ein Gedanke, ausformuliert bis zum Ende.