Wir arbeiten als Interface-Designer vor allem in größeren Projekten oft mit externen Programmierern zusammen. Man könnte sagen, jemand anders übernimmt die Umsetzung für uns.
Das Schöne an dieser Art zu arbeiten, ist dass wir uns voll und ganz auf unsere Spezialität konzentrieren können, das Design einfacher und nützlicher Software. Wir müssen uns aber noch um etwas anderes kümmern, nämlich die Umsetzung.
Das klingt jetzt falsch, schließlich gibt es ja genau dafür die externen Programmierer. Tatsache ist jedoch, dass Designer auch während der Umsetzung eine große Verantwortung tragen. Eine Verantwortung, die wir nicht einfach mit der Übergabe eines Style-Guides abgeben können.
Auch der beste Style-Guide ersetzt kein persönliches Gespräch
Die Programmierer stehen vor einer schwierigen Aufgabe. Um das zu begreifen, muss ich selbst keiner sein. Während wir Designer „nur“ unser Design kommunizieren müssen, sprich den Entwicklern zeigen, wie die Software funktionieren soll, sind sie dafür zuständig, dass die Software wirklich funktioniert. Und das ist ein gewaltiger Unterschied.
Oft glauben wir (Designer), es wäre genug dem Programmierer ein paar Screenshots, Flow-Diagramme und Skizzen des User Interfaces in einer Art Style-Guide zu beschreiben und zu schicken. In Wahrheit wissen wir aber, dass kein Dokument der Welt, die echte Kommunikation zwischen Designer und Programmierer ersetzen kann.
Und genau das meine ich, wenn ich sage, dass wir miteinander arbeiten müssen. Wir müssen miteinander reden, uns austauschen, versuchen, die eigenen Ideen klarzumachen, Feedback annehmen, selbst Feedback geben. Es ist ein dauerndes Hin und Her. Alles ist in Bewegung, nicht wie auf einem Blatt Papier, auf dem alles stillsteht.
Miteinander reden, nicht aneinander vorbei arbeiten
Deshalb mein Vorschlag: Anstatt 20, 40 oder mehr Stunden zu investieren, um unsere Arbeit in einem Dokument zu präsentieren, nehmen wir uns zwei Stunden, um unsere Arbeit direkt mit den Programmierern zu besprechen. Die neugewonnen 18 bzw. 38 Stunden investieren wir in Kommunikation.
Das heißt, anstatt unsere Zeit mit Style-Guides zu verschwenden, verwenden wir sie, um nützliche E-Mails zu schreiben, Probleme am Telefon zu besprechen und um uns gelgentlich im Team zusammenzusetzen und den Projekt-Fortschritt zu diskutieren. Das kostet uns keinen Cent bzw. keine Minute mehr und bietet trotzdem einen unbezahlbaren Vorteil:
Alle Beteiligten sind an Board – und das ständig. Es kann nicht sein, dass ein Designer während der Entwicklung nicht mehr zur Verfügung steht, weil er schon das nächste Projekt bearbeitet. Der Designer muss von Anfang an damit rechnen, dass seine Kompetenz während der gesamten Entwicklung gebraucht wird und nicht auf eine sogenannte Design-Phase beschränkt werden kann.
Unser neues Buch: Wir erklären dir in klarer und verständlicher Weise, wie User Testing in der Praxis wirklich funktioniert » Zum Buch
Auf diese Weise lässt sich die strenge Trennung zwischen Design und Programmierung etwas lockern. Natürlich finden große Teile von Design und Programmierung immer noch nacheinander statt, wir stehen jedoch alle regelmässig in Kontakt und treffen gemeinsame Entscheidungen.
Als Designer ist das eine riesige Erleichterung. Nicht nur, weil man keine sinnlosen Style-Guides mehr schreiben muss, sondern weil man Design-Entscheidungen dann treffen kann, wenn sie wirklich auftreten und nicht bereits Wochen oder Monate im Vorfeld auf hellseherische Weise voraussagen muss.
Aus Faulheit eine Tugend machen
Ein aktuelles Beispiel: Wir arbeiten gerade gemeinsam mit externen Programmierern, einem Grafik-Designer und einer Historikerin zusammen, um gemeinsam eine Spiele-App zu entwickeln. Als unsere Mockups fertig waren, wollte ich erst einen Style-Guide schreiben, den ich dann bequem per Mail an alle Beteiligten schicke, um unsere Design-Phase offiziell abzuschließen.
Nun, ich habe es nicht gemacht. Es schien mir zu aufwendig und ich dachte mir, es wäre einfacher, wenn ich meine Mockups ausdrucke und direkt mit den Programmierern bespreche. Außerdem habe ich zu verstehen gegeben, dass ich für Rückfragen jederzeit bereitstehe. Es hat sich gezeigt, dass unsere gemeinsame Arbeit enorm von dieser ursprünglichen Faulheit profitieren konnte.
Anstatt zu hoffen, dass ich mit einem Dokument alle möglichen Fragen bereits beantworten konnte und mich zu ärgern, wenn doch jemand nachfragt, weil etwas nicht verständlich beschrieben war, warte ich jetzt geradezu darauf. Ich warte, bis Fragen auftauchen und versuche dann diese Fragen so gut es geht zu beantworten. Das ist mein Job als Designer.
Designer sind Projekt-Manager
Als Interface-Desiger, UX-Designer oder wie auch immer man unsere Tätigkeit nennen möchte, haben wir einen unglaublich tiefen Einblick in die Projekte, an denen wir aktiv mitarbeiten. Es wäre schade, diesen Einblick für uns selbst zu behalten und nicht auch mit anderen zu teilen.
Als Designer sollten wir uns auch um Projekt-Management kümmern. Das heißt, wir müssen E-Mails schreiben, Telefonate führen, Workshops moderieren und Präsentationen halten. Nur auf diese Weise können wir uns voll einbringen. Nur auf diese Weise leisten wir gute und nützliche Arbeit.
Designer und Programmierer brauchen eine neue Art miteinander zu arbeiten. Produktentwicklung ist kein Staffellauf, in dem Designer die ersten 100 Meter rennen und schließlich an die Programmierer übergeben, die den Weg ins Ziel alleine bewältigen müssen. Produktentwicklung ist ein Mannschaftssport.
Es geht um Verantwortungsbewusstsein und um Vertrauen. Nicht nur darum, seine Arbeit möglichst gut zu präsentieren, sondern vor allem darum, seine Arbeit möglichst gut zu machen. Und das am besten miteinander und nicht einer nach dem anderen.
