Jelena Racković · · 4 Min. Lesezeit · Teams & Delivery
Ein UX- und Frontend-Team über viele parallele Projekte führen
Jedes Team, das ich geleitet habe, hat irgendwann denselben Satz gehört: „So war es im Design.“ Er kommt von Frontend- wie Backend-Entwicklern, meist mitten in einem Bug, den niemand eingeplant hat. In dieser Notiz geht es nicht darum, Entwicklern die Schuld zu geben. Es geht um eine Gewohnheit, die es in fast jedem IT-Team gibt, warum sie zählt und warum sie heikler wird, wenn ein Team an vielen Projekten gleichzeitig arbeitet.
„So war es im Design“
Oberflächlich klingt der Satz völlig vernünftig. Das Design zeigte etwas, gebaut wurde genau das, wo ist also das Problem? Das Problem ist, was der Satz stillschweigend annimmt: dass ein Design eine vollständige Spezifikation ist, unterschrieben und versiegelt, und dass alles, was es nicht erwähnt, Sache von jemand anderem ist.
Kein Design deckt alles ab. Leere Zustände, lange Namen, langsame Verbindungen, fehlende Daten, eine zweite Sprache, eine Rolle, an die niemand gedacht hat. Ein Design ist eine Absichtserklärung, und eine Absicht muss interpretiert werden. Wird diese Interpretation durch eine wörtliche Kopie ersetzt, verschwinden die Lücken nicht. Sie erreichen die Nutzer einfach ungeprüft.
Warum ich diese Haltung nicht mag
Ich sehe es vor allem als Frage der Reife, nicht des Könnens. Ein reifer Entwickler liest ein Design so, wie ein guter Lektor ein Manuskript liest: sorgfältig und mit Fragen. Wirkt etwas seltsam, widerspricht einem früheren Screen oder ignoriert einen Fall, den die Daten offensichtlich zulassen, greift er zum Telefon. Der Satz „so war es im Design“ ist das, was übrig bleibt, wenn dieses Gespräch nie stattgefunden hat.
Er teilt außerdem die Verantwortung auf eine Weise, die sich das Produkt nicht leisten kann. Den Nutzer interessiert nicht, aus wessen Schicht der Fehler kam. Er sieht nur, dass er da ist.
Warum am Ende das Design die Schuld trägt
Das hat eine unbequeme Seite, die selten laut ausgesprochen wird. Von Designern wird sehr oft verlangt, zu liefern, bevor sie haben, was sie brauchen. Die Anforderungen kommen spät, die Dokumentation noch später, und die Deadline bewegt sich nicht. Also arbeiten sie aus Instinkt und Erinnerung und füllen die Lücken so vernünftig wie möglich, um den Termin zu halten.
Taucht später ein Fehler auf, führt die Spur zum Design zurück, weil das Design das sichtbarste Artefakt ist. Was die Spur selten zeigt, ist der fehlende Input, der überhaupt erst zum Raten gezwungen hat. Designer lernen, diese Last still zu tragen, und mit der Zeit zermürbt sie sie.
Der Anteil der Organisation
Vieles davon ist gar nicht persönlich. Es ist organisatorisch. Projekte werden schnell durchgedrückt, weil sie geliefert und abgerechnet werden müssen, und dieser Druck ist selbst eine Folge des Umfelds und der Unsicherheit, in der so viele von uns leben und arbeiten. Wenn der Cashflow vom Tempo abhängt, fällt zuerst die Zeit fürs Verstehen weg, und die Gespräche zwischen den Disziplinen sind meist das erste Opfer.
Kein Einzelner kann das ganz beheben. Aber eine Teamleitung kann es benennen und zumindest etwas von dieser Zeit schützen, denn die Kosten des Überspringens kommen immer zurück, mit Zinsen.
Bildung auf beiden Seiten
Ein Teil der Antwort ist Bildung, und sie läuft in beide Richtungen. Entwickler brauchen genug Designkompetenz, um zu erkennen, wann etwas eine Frage verdient, und das Selbstvertrauen, sie zu stellen, statt blind zu bauen. Ein fünfminütiger Anruf bei der Designerin kostet fast immer weniger als ein Tag Nacharbeit. Dasselbe gilt für Backend-Entwickler, deren Datenstrukturen prägen, was eine Oberfläche ehrlich versprechen kann, und die oft als Erste sehen, dass ein Screen um Daten herum gestaltet wurde, die es nicht gibt.
Designer wiederum müssen die Zustände und die Begründung dokumentieren, nicht nur den Happy Path, erklären, warum eine Entscheidung fiel, und erreichbar sein, sobald gebaut wird. Ein Design, das übergeben und dann aus der Ferne verteidigt wird, lädt genau zu der wörtlichen Lesart ein, über die es sich später beschwert.
Über viele parallele Projekte
All das wird schwerer, wenn ein Team an vielen Projekten gleichzeitig arbeitet. Es gibt weniger Gespräche, mehr Annahmen und weniger Erinnerung daran, warum etwas entschieden wurde. Menschen wechseln mehrmals am Tag den Kontext, und der Raum für eine schnelle, informelle Frage schrumpft mit jedem Wechsel.
Was hilft, ist meiner Erfahrung nach recht bescheiden. Designer bleiben während des Bauens erreichbar, nicht nur davor. Jede Übergabe enthält eine kurze Notiz zur Absicht und zu den Fällen, die das Design nicht abdeckt. Frühe Stände werden gemeinsam geprüft, solange Änderungen noch günstig sind. Und eine gemeinsame Komponentenbibliothek gibt beiden Seiten dasselbe Vokabular, sodass eine Frage in einem Satz statt in einem Meeting gestellt werden kann.
Bei nichts davon geht es darum, wer recht hatte. Es geht darum, dass beim nächsten Mal die Frage gestellt wird, bevor der Satz fällt.