Über diese Website
Warum aus einem klassischen Lebenslauf ein persönlicher digitaler Raum wurde – und wie ein alter Entwurf mit einem neuen Web-Stack endlich zum Leben erwachte.
Lange Zeit lebte meine berufliche Geschichte in einem sorgfältig gepflegten DIN-A4-Dokument voller Stationen, Zeiträume und Qualifikationen. Es erfüllte seinen Zweck, fühlte sich aber nie wirklich nach mir an.
Ein Lebenslauf erklärt, was jemand gemacht hat. Er zeigt deutlich schlechter, wie diese Person denkt und wie unterschiedliche Erfahrungen zusammenhängen. Meine Arbeit verbindet agile Delivery, Produktdenken, UX, Frontend-Entwicklung und IT-Betrieb. Ich wollte einen Ort, der diese Verbindung und den Menschen dahinter sichtbar macht.
Ein Portfolio für einen Agile Coach?
Persönliche Websites von Scrum Mastern und Agile Coaches folgen häufig einem sicheren Muster: Frameworks erklären, Zertifikate auflisten, Kontaktformular ergänzen. Die Arbeit lässt sich schwerer visualisieren als Design oder Entwicklung. Workshop-Boards und Velocity-Charts zeigen Aktivität, aber selten Urteilsvermögen.
Designerinnen und Designer können ein Interface zeigen, Entwicklerinnen und Entwickler auf funktionierenden Code verweisen. Vertrauen, klarere Entscheidungen oder ein Team, das seine Probleme selbst lösen lernt, lassen sich nicht als Screenshot festhalten. Deshalb wurde die Umsetzung des Portfolios selbst zum Teil der Geschichte.
Meine Antwort war: Die Website selbst muss das Beispiel sein. Struktur, Sprache und Interaktionen sollen zeigen, wie ich Menschen, Produkt und Technologie verbinde und einer abstrakten Profession eine klarere Stimme geben.
Ein Portfolio sollte nicht beschreiben, wie ich denke. Es sollte es mit jeder Entscheidung beweisen.
Der Entwurf war längst da
Ich begann ohne fertige Botschaft. Dann fand ich einen alten Adobe-XD-Entwurf wieder, den ich Jahre zuvor gestaltet, aber nie umgesetzt hatte.
Die geöffnete Navigation aus dem früheren Portfolio-Konzept. Ihr Raster, ihre Größe und die dunkle visuelle Sprache wurden zur Grundlage dieser Website.
Der Entwurf stammte aus einer Phase, in der UX und Entwicklung meine Geschichte bestimmten. Die dunkle Fläche, das strenge Raster, die große Typografie und das Handzeichen fühlten sich trotzdem richtig an. Ich bewahrte diesen Charakter und entwickelte die Botschaft in Richtung agile Delivery, Teamentwicklung und Ownership weiter. Die Identität musste nicht neu erfunden werden. Sie musste zu dem Menschen aufschließen, der ich inzwischen geworden war.
Ich baute den alten Entwurf nicht Pixel für Pixel nach. Ich behandelte ihn wie ein Produkt mit einem wertvollen Kern: Bewahren, was noch funktioniert, entfernen, was nicht mehr passt, und jede neue Entscheidung am heutigen Zweck ausrichten.
Zurück zum JAMstack
Das Projekt brachte mich mit einer neuen Generation von Werkzeugen zurück zum JAMstack. Ich habe mit leistungsfähigen Content-Management-Systemen gearbeitet und weiß, warum Organisationen sie brauchen. Ich kenne aber auch ihren Apparat aus Datenbanken, serverseitigem Rendering, Plugins, Updates und Konfiguration. Eine persönliche Website braucht den größten Teil davon nicht.
Im JAMstack liegen Inhalte und Komponenten im Repository, Seiten werden vorab erzeugt und überwiegend als statische Dateien ausgeliefert. JavaScript und externe Dienste kommen gezielt hinzu. Das reduziert betriebliche Komplexität, verbessert das Caching und verkleinert die Angriffsfläche.
Früher habe ich Gatsby und Bootstrap genutzt. Diesmal wollte ich diese Standards hinterfragen und sehen, wie sehr sich der Workflow weiterentwickelt hat.
Warum Astro?
Astro passt, weil diese Website vor allem aus Inhalten besteht. Es liefert für die meisten Seiten statisches HTML und behandelt JavaScript als bewusste Ergänzung. Navigation, Übergänge und der interaktive agile Kreislauf brauchen Verhalten. Artikel, berufliche Stationen und Leistungen brauchen keine clientseitige Anwendung.
Astro-Komponenten halten das System modular. Der Islands-Ansatz begrenzt clientseitigen Code auf die Stellen, an denen Interaktion ihren Preis rechtfertigt. Die Seite bleibt nützlich, bevor eine Animation oder ein Skript startet.
Der Blog nutzt Markdown in einer Astro Content Collection. Eine Quelle speist Artikelseiten, Kategorien, Schlagwörter, RSS-Feed und Startseite. Ein Schema prüft die Metadaten, während Text und Layout getrennt bleiben. Datenbank und Administrationsoberfläche sind nicht nötig.
Tailwind für das System, GSAP für die besonderen Momente
Tailwind CSS passte zu einem visuellen System aus wiederkehrenden Abständen, Linien, Typografie, Rasterproportionen und einer kleinen Farbpalette. Gemeinsame CSS-Tokens halten diese Entscheidungen konsistent, Utility-Klassen beschleunigen die responsive Iteration.
Das alte Adobe-XD-Raster ließ sich in responsive Regeln übersetzen, auf verschiedenen Breiten testen und verfeinern, ohne eine Sammlung einmaliger Komponentenstile aufzubauen.
GSAP bringt Bewegung dorthin, wo sie die Persönlichkeit der Website unterstützt: Hero, Logo, Timeline und Übergänge. Das Ziel ist Rhythmus und Überraschung, ohne Reibung zwischen Menschen und Inhalt zu erzeugen.
Von VS Code bis in die Produktion
Der Quellcode liegt auf GitHub. IONOS Deploy Now macht aus jedem Produktions-Push einen reproduzierbaren Build und ein automatisiertes Deployment. Der Ablauf ist einfach: ändern, prüfen, committen und die Pipeline veröffentlichen lassen.
Ich entwickelte die Website in VS Code mit Codex an meiner Seite. Es beschleunigte Komponenten, Styling und Fehlersuche. Sein Wert lag nicht darin, Entscheidungen zu ersetzen. Es verkürzte den Weg zwischen einer Idee und einem Ergebnis im Browser. Das fühlte sich nach guter Produktarbeit an: Richtung und Grenzen setzen, schnell Feedback erhalten, Ergebnis verbessern.
Ein erstes Release, keine endgültige Antwort
Inhaltsplan und Markenbotschaft entstanden während der Arbeit. Ich schrieb einen Abschnitt, sah ihn im Zusammenhang, bemerkte, was falsch klang, und versuchte es erneut. Das Ergebnis ist mehr als ein digitaler Lebenslauf, bleibt aber ein erstes Release.
Eine Idee wird am schnellsten klar, wenn sie konkret genug ist, um ihr widersprechen zu können.
Die Website kann nun, was ein Dokument nicht konnte: eine abstrakte Profession greifbar machen, meine agile Arbeit mit meinem technischen Hintergrund verbinden und sich durch echtes Feedback weiterentwickeln.