Warum Design und Entwicklung bei uns nicht nacheinander laufen

Das klassische Modell ist eine Übergabe: Design entwirft, Entwicklung baut nach. Auf dem Papier eine saubere Arbeitsteilung. In der Praxis kommt die Rechnung später – bei dem Detail, das im Entwurf zwei Minuten gekostet hat und in der Umsetzung zwei Tage. Oder bei dem Zustand, den niemand gezeichnet hat, weil er im Entwurf gar nicht vorkommt: die leere Liste, der Ladevorgang, die abgelaufene Sitzung.

Was ein fertiger Entwurf nicht beantwortet

Ein statischer Screen zeigt einen einzigen Moment: passende Datenmenge, passende Textlängen, alles funktioniert. Die eigentliche Arbeit steckt in den anderen Momenten.

• Was steht da, bevor Daten geladen sind – und wenn keine kommen?
• Wie sieht die Überschrift aus, wenn der echte Produktname doppelt so lang ist wie der Beispieltext?
• Was passiert nach dem Klick, wenn der Server drei Sekunden braucht?
• Und was kostet die Animation, die den Entwurf so gut aussehen lässt?

Diese Fragen tauchen nicht im Design-Review auf, sondern in der Umsetzung – also nach der Abnahme, wenn Umbauen am teuersten ist.

Wie wir stattdessen arbeiten

Wir entwerfen grob und bauen früh. Im Design klären wir Aufbau, Hierarchie und Ablauf; den Rest entscheiden wir im echten Frontend mit echten Daten. Zwei Dinge machen das möglich:

Design-Tokens statt Pixelabgleich. Farben, Typo-Stufen und Abstände sind einmal definiert und in Entwurf und Code dieselben. Es gibt keine Runde „das ist 4px zu viel“, weil niemand freie Werte vergibt – so ist auch unsere eigene Website gebaut.

Der Entwurf wandert früh in den Browser. Statt einen Screen im Designtool fertigzustellen, setzen wir ihn nach wenigen Tagen benutzbar um. Danach klicken alle durch dieselbe Sache, statt über ein Bild zu sprechen.

Was das kostet

Ehrlich gesagt: Es gibt nicht den einen Termin, an dem „das Design fertig“ ist und abgenommen wird. Entscheidungen fallen später und verteilter, und man muss aushalten, dass ein Stand eine Woche lang noch unrund aussieht. Wer ein Abnahmeprotokoll auf Pixelebene braucht, ist mit dem klassischen Modell besser bedient.

Dafür gibt es keine Überraschungen in der Umsetzung – und eine Oberfläche, die auch in den unspektakulären Zuständen funktioniert, nicht nur auf dem Screenshot.