Wenn ein Entwickler glaubt, der Designer zu sein, und wie man es gemeinsam löst

Zwei Menschen, zwei Probleme

Wenn ich diese Situationen genau betrachte, ist der Entwickler selten nachlässig oder arrogant. Er löst ein anderes Problem als die Designerin. Sie dachte an den Weg des Nutzers durch die Aufgabe; er dachte an Performance, Daten, die spät ankommen, oder eine Komponente, die so gezeichnet eine Woche Bauzeit bräuchte. Beides sind berechtigte Anliegen. Das Problem ist, dass niemand sie gemeinsam auf den Tisch gelegt hat.

Erst über das Problem einig werden

Deshalb geht es im ersten Gespräch nie darum, wer recht hatte. Es geht darum, was der Screen erreichen muss und welche Bedingungen er respektieren muss, von beiden Seiten. Sobald das aufgeschrieben ist, löst sich der Designstreit meist von selbst. Manchmal war die Änderung des Entwicklers besser, und wir behalten sie. Manchmal erfüllt eine kleine Anpassung sowohl das Nutzerbedürfnis als auch die technische Grenze. Gelegentlich bleibt das ursprüngliche Design, und jetzt verstehen alle, warum.

Entwickler früher einbinden

Die dauerhafte Lösung ist, sich nicht erst am Ende zu treffen. In meinem Team sehen Entwickler Entwürfe, solange sie noch roh sind, und Designer hören von technischen Grenzen, bevor sie etwas polieren. Ein kurzes Gespräch in dieser Phase spart später Tage an Nacharbeit und nimmt das Gefühl, Design werde von oben übergeben statt gemeinsam gebaut.

Respekt in beide Richtungen

Entwickler, denen die Oberfläche wichtig ist, sind ein Gewinn, keine Bedrohung. Ihre Instinkte sind oft gut, und ihr Wissen darüber, wie sich Dinge tatsächlich verhalten, macht das Design besser. Was sie brauchen, ist ein klarer Weg, Ideen einzubringen, und eine klare Verantwortung für die endgültige Entscheidung. Was Designer brauchen, ist die Demut zuzuhören. Ist beides da, stellt sich die Frage, wer die Designerin ist, einfach nicht mehr.