Alle Case Studies

deutschland-forstet-auf.de — Relaunch der Plattform

Screenshot der Plattform deutschland-forstet-auf.de mit einer bewaldeten Landschaft und einem Aufruf, Bäume zu pflanzen.
Kunde
Deutschland Forstet Auf (gemeinnützig)
Rolle
Frontend- und Backend-Entwicklung; UX-Korrekturen während der Umsetzung
Zeitraum
6 Wochen (2025)
Umfang
Relaunch inkl. Eventverwaltung und E-Mail-Automatisierung
Stack
Astro · React · Storyblok · Supabase · NestJS · Express · Storybook · Netlify

Kontext

Die Plattform bringt Freiwillige mit Aufforstungsaktionen in ganz Deutschland zusammen, betrieben von einem kleinen, überwiegend ehrenamtlichen Team. Die alte Seite war technisch veraltet, und die Organisation wollte mehr: ein neues Design, um mehr Menschen zu erreichen, dazu Funktionen, die es vorher nicht gab, darunter Organisation von Aktionen, Eventverwaltung und E-Mail-Automatisierung. Das Design kam von einer Designerin, das Backend von einem Fullstack-Developer, ich habe hauptsächlich das Frontend umgesetzt.

Entscheidungen

Decision 1

Designs zu Ende denken, bevor man sie baut

Die gelieferten Designs zeigten den Idealfall: einen Viewport, mit kurzen Inhalten und ohne Ausnahmen. Responsives Verhalten, Randfälle und Umsetzungsaufwand waren nicht Teil davon. Das ist normal, und es ist genau der Punkt, an dem ich nicht einfach „umsetze". Ich habe jedes Layout gegen drei Fragen geprüft: Was passiert bei unterschiedlichen Inhaltslängen? Was passiert bei anderen Viewports? Was kostet das in Umsetzung und Performance? Wo die Antwort fehlte, habe ich sie definiert und dabei die gestalterische Absicht erhalten, statt sie wegzuvereinfachen.

Trade-off: Die Machbarkeitsprüfung kostet Zeit vor dem ersten Commit. Dafür spart sie das Dreifache an einem Layout, das auf dem Telefon auseinanderfällt.

Decision 2

Das Karten-Raster: ein konkretes Beispiel

Das Design sah ein 4×2-Raster aus Karten vor, bewusst unruhig: Karten abwechselnd nach links und rechts gekippt, die zweite Reihe gespiegelt, jede zweite Spalte auf der Y-Achse versetzt. Auf dem Desktop-Mockup funktionierte das gut. Alles Weitere war offen: Wie verhält sich die Neigung bei langen Titeln? Wann bricht das Raster auf 2×4, wann auf eine Spalte? Überlebt der Versatz auf dem Telefon, und wenn ja, welcher? Ich habe die Logik dahinter formuliert: Regeln für Neigung, Versatz und Breakpoints, die auf jedem Gerät und mit jedem Inhalt funktionieren, ohne das Dynamische des Entwurfs zu verlieren.

Trade-off: Regeln machen das Layout weniger frei als das Mockup. Dafür verhält es sich vorhersagbar, statt bei jedem neuen Inhalt neu verhandelt zu werden.

Decision 3

Redaktion und Code strikt getrennt

Alles Redaktionelle, also Aktionen, Texte, Bilder, liegt in Storyblok, nicht im Code. Die Seitenstruktur liegt im Code, nicht im CMS. Das Team kann keine neuen Seitentypen erfinden, ohne zu fragen. Dafür kann es alles andere allein erledigen, ohne die Seite durch Inhaltspflege versehentlich zu zerlegen.

Trade-off: Weniger Flexibilität für das Team, keine Entwicklerabhängigkeit im Tagesbetrieb. Für eine ehrenamtlich betriebene Plattform der richtige Schnitt.

Einblicke

Folgt in Kürze

Das gekippte Karten-Raster im laufenden Betrieb.

Folgt in Kürze

Dasselbe Raster, aufgelöst nach den Regeln, die das Mockup offengelassen hat.

Ergebnis

Die Seite ist live und trägt den Tagesbetrieb der Organisation, von der Ankündigung der Pflanztage über die Eventverwaltung bis zur automatisierten E-Mail-Kommunikation. Das Team pflegt die Inhalte seit der Übergabe selbst.

Kontakt aufnehmen

Ähnliches Projekt? Am schnellsten klärt eine kurze Nachricht, ob es passt.

Nachricht schreiben