Ich habe kürzlich diesen sehr guten Artikel gelesen über den nicht enden wollenden Disput zwischen Software-Designern und -Entwicklern und wer letztlich für die User-Experience verantwortlich zeichnet.

Ich war zuerst verführt, den Artikel hier einfach zu verlinken und dann ins Bett zu gehen, aber als ich gesehen habe, dass der Artikel von 2010 ist, habe ich spontan beschlossen, dass es an der Zeit ist, das Thema nochmal vom heutigen Standpunkt zu betrachten. Schließlich hat sich doch so viel verändert... oder nicht?Anstatt nun aber einfach nur meine Meinung niederzuschreiben, fand ich es viel interessanter und informativer, mir ein paar Experten zur Hilfe zu holen und da es schon spät war, hab ich einfach zwei imaginäre Freunde von mir interviewt. Wie es der Zufall will, heißen beide "Pat".

Was mein imaginärer Freund Pat, der Designer, zum Thema User-Experience zu sagen hat:

Ein einfacher Vergleich mit dem Bau eines Hauses veranschaulicht die Situation  perfekt. Im Zusammenhang mit Häusern sind die Architekten das Pendant der Designer und die Ingenieure sind das Gegenstück zu den Entwicklern. Viele Ingenieure haben wenig Wertschätzung übrig für die Arbeit der Architekten und sehen sie stattdessen als Kontrahenten, die Ihnen das Leben schwer machen. Wir Designer erfahren oft dasselbe Level an Geringschätzung von Software-Entwicklern, in deren Augen wir den ganzen Tag damit verbringen in einem Zeichenprogramm hübsche Buttons zu malen und dann ein bischen mit den Farben herumspielen.

Ein guter Architekt denkt zuerst aber vor allem an die Bedürfnisse seiner Kunden und das unter Berücksichtigung von Zeit und Budget. Er denkt an die Landschaft, das Klima der Region und die Gemeinde in der das Haus entstehen wird. Natürlich brauchen wir Designer es eine Portion Talent und guten Geschmack, aber genauso wie die Architekten müssen wir unser Ego aus der Gleichung nehmen und in den Mittelpunkt stellen, was der Nutzer möchte. Ein Programmierer kann durchaus einen für sein Empfinden hübschen bunten Button erschaffen. Aber um zu verstehen, was der Nutzer möchte, sind wissenschaftliche Methoden und das Testen von Initialen Designs und Prototypen genauso notwendig wie jahrelange Erfahrung.

Darüberhinaus verstehen wir, dass User-Experience nicht bei der Anwendung, die wir entwerfen, endet. Die ist nur eine von vielen Kanälen, die unseren Kunden mit dessen Kunden verbindet. Jede Anwendung muss organisch in eine Gesamt-Thematik passen und sich in anderen Bestandteilen wie Produktdesign, der Unternehmens-Website, Werbung, etc. widerspiegeln.

Die Kohärenz ist wichtig, damit der User versteht, dass all diese Kanäle ein großes Ganzes bilden und vom selben "Sender" ausgehen.

Man kann einen Entwickler eine Software programmieren lassen, die er selbst gut findet. Man kann ihn durchaus auch dazu bringen eine Software zu programmieren die einem selbst gefällt. Aber das Ziel ist es, eine Software zu entwicklen, die von ihren Nutzern als besonders wahrgenommen wird und in der sie sich wohl fühlen.

Es ist einfach besser, dem Designer die Verantwortung zu übertragen...

Und jetzt kommt mein imaginärer Freund Pat, der Software-Entwickler, mit seiner Meinung in der Angelegenheit:

Um den Vergleich vom Hausbau mit Architekten und Ingenieuren aufzugreifen:

Architekten verbringen Jahre damit alle möglichen Details zu Baukonstruktion und Bauausführung zu lernen, da hat der Bauherr oft gar keine Vorstellung von. Sie lernen wie das Fließverhalten des Wassers innerhalb der Rohrsysteme von Länge, Durchmesser, Anzahl der Abzweigungen und dem Material der Rohre abhängt. Sie lernen Gewichte, Kosten und Haltbarkeit der verschiedensten Materialien die beim Bau verwendet werden. Wenn Sie dann einen Plan zeichnen, haben sie im Hinterkopf schon die elektrische Verkabelung, Wasserrohre, Abflüsse, Fundamente, Sonneneinstrahlung, Statik, Straßenlärm, ... die Liste ist lang.

Was wir in der Software-Welt brauchen sind Anwendungs-Architekten, keine Designer. Das müssen keine Programmier-Experten sein, aber sie sollten ein fundiertes Wissen von Betriebssystemen und Plattformen haben und die Möglichkeiten und Grenzen verschiedener Programmiersprachen kennen.

UI-Designs berücksichtigen selten fundamentale Dinge wie Bildschirm-Übergänge, Animationen, Fehlermeldungen oder meist auch schon nur wie ein bestimmter Button aussehen soll wenn er gerade "gedrückt" wird.

Wenn wir Glück haben, wird uns noch ein Navigations-Flow geliefert, der aber selten beinhaltet was passieren soll, wenn etwas schief geht - sagen wir, ein Netzwerkzugriff fehlschlägt. Für gewöhnlich werden Ressourcen die geladen oder erzeugt werden müssen (ein Profilbild bspw.) behandelt, als ob sie auf magische Weise zum richtigen Zeitpunkt einfach da wären und das Design sagt nichts weiter dazu, was in der Zeit passieren soll, während man die Ressourcen lädt oder bereitstellt, ganz zu schweigen, was der Nutzer sehen soll, wenn die Ressource garnicht zur Verfügung steht.

Last, not least: Im täglichen Projektgeschäft ist die Zeit, die wir zum Programmieren einer Software haben, im Regelfall streng vorgegeben und das Design darf daher nicht einfach nur berücksichtigen, was theoretisch alles möglich wäre sondern vor allem, was der Entwickler in dieser festgelegten Zeit überhaupt schaffen kann und das hängt ab von der Plattform, Art und Anzahl der Ziel Geräte und anderer Faktoren.

Es ist wirklich das beste, sich zuerst an den Entwickler zu wenden!

Also, was machen wir jetzt daraus?

Es ist mir klar, dass keiner der Beiden in der Lage ist, eine gute Software ganz alleine herzustellen. Entwickler denken, dass sie zumindest einen Vorteil haben, weil Sie immerhin irgendwie eine Software erstellen können und die Designer ja nur einen Haufen von schönen Bildern und Zeichnungen. In Wirklichkeit zählt das aber nichts, weil man mit einer "funktionierenden" App, die aber total am Nutzer vorbeigeht, kein Geld verdienen kann.

Also, wer rettet die Situation? Wer ist das fantastische Wesen, dass die Fähigkeiten von Designer und Entwickler in einer Person vereint? Die Antwort wird Sie aus den Socken hauen (*trommelwirbel*): Es sind.... die beiden zusammen.

Ja, diese Antwort war sehr naheliegend. Das Entscheidende ist jedoch, dass dieses Gespann nur funktioniert, wenn es auch als echtes Team arbeitet. In direkter und konstanter Kommunikation. Das geht aber nur, wenn der Entwickler dem Designer vertraut, dass der wiederum sich für sein Layout nicht durch das Werfen einer Münze entschieden hat, sondern basierend auf Recherche, Best-Practices, Standards und Erfahrung. Es läuft aber auch umgekehrt nur, wenn der Designer dem Entwickler glaubt, dass dieser besagtes Layout nicht kritisiert weil er zu faul ist es zu programmieren, sondern weil der grundlegende Aufbau der App mit diesem Layout zu nicht sofort offensichtlichen Problemen führen könnte.

Um eine solche Kooperation zu erlernen, muß jeder von beiden aus seiner Komfortzone herauskommen und bereit sein, zumindest ein grundlegendes Verständnis von der Arbeit des Anderen zu erwerben. Bei ImagineOn haben wir die Weichen in diese Richtung schon gestellt, lange bevor ich zum Team hinzugekommen bin, und unsere Entwickler werden ermutigt, sich ein ganzheitliches Verständnis vom Prozess der Produktion einer Software anzueignen. Von Usability-Methoden und Normen, UX best practices, Gemeinsamkeiten und Herausforderungen jedes Betriebssystems und mehrerer Programmiersprachen, Backend-Systeme und mehr, als wichtige Ergänzung zum tiefergehenden Verständnis des eigenen Fachgebiets. In anderen Worten: Ihr seid dran, Designer!

Aber es gibt auch noch eine andere Seite der Medaille. Ja, ich schreibe zum Teil auch, um ein wenig Frust abzubauen und die Diskussion erneut zu befeuern aber auf jeden Fall in der Hoffnung, dass die Botschaft auch eine dritte Partei erreicht: die Kunden. Ein Teil der Verantwortung für den Status Quo entfällt nämlich dorthin. Solange so vorgegangen wird, dass Kunden zuerst das Design abnehmen wollen, bevor dieses dann einem Entwickler zur Umsetzung gegeben wird, können wir die Gesamtsituation nicht wirklich verbessern - Stichwort: Budget-Denken vs Agile Projekte 

Der Kunde ist also gefordert, sich zumindest ein oberflächliches Verständnis davon anzueignen, wie eine Software entsteht oder sich hier von den Fachleuten beraten zu lassen (ich kann eine Firma empfehlen...) damit die Designer und Entwickler wirklich gemeinsam und als Team an die Arbeit gehen können.

Entwickler sollten immer schon während der Konzept- und Designphase ins Boot geholt werden, genauso wie die Designer im gesamten Verlauf der Herstellung dabei bleiben sollten, beide Parteien dabei als Team in enger Abstimmung und ohne für jede Änderung und Abstimmung immer den Umweg über den Kunden als Mittelsmann nehmen zu müssen.

Nur so können wir uns nämlich produktiv streiten anstatt uns heimlich übereinander zu ärgern.