deutschland-forstet-auf.de — Relaunch der Plattform
- Kunde
- Deutschland Forstet Auf (gemeinnützig)
- Rolle
- Frontend- und Backend-Entwicklung; UX-Korrekturen während der Umsetzung
- Zeitraum
- 6 Wochen (2025), Umfragemodul als Folgeauftrag (2026)
- Umfang
- Relaunch inkl. Eventverwaltung und E-Mail-Automatisierung, später ein Umfragemodul
- Stack
- Astro · React · MUI · Storyblok · Supabase · NestJS · Express · Brevo · 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-Entwickler. Ich habe hauptsächlich das Frontend umgesetzt. Mit einem Folgeauftrag kam die Organisation für das Umfragemodul zurück, das ich vom E-Mail-Versand bis zur Auswertung in Storyblok gebaut habe. Die Seite ist live und trägt den Tagesbetrieb der Organisation. Nach einem Aktionstag bekommen Teilnehmende einen Fragebogen per E-Mail, und das Team wertet die Antworten in Storyblok aus.
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 muss später kein Layout nachgebaut werden, 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
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. Nach einem Aktionstag bekommen Teilnehmende einen Fragebogen per E-Mail, und das Team wertet die Antworten direkt in Storyblok aus.
Anmo art/cha
Nächste Case StudyKontakt aufnehmen
Ähnliches Projekt? Am schnellsten klärt eine kurze Nachricht, ob es passt.
Mail-Programm öffnet sich nicht? Kopier die Vorlage und schick sie an hello@dadario.studio.