040 4840593 0

So können Design und Entwicklung besser miteinander kommunizieren - Teil 1

Meike

6. Juli 2020

Without Development, Design is useless.
Without Design, Development is unusable.
— Yashu Mittal

Design-Mood und Decision Mood – zwei spannende Sichten auf Lösungswege

"Ich verstehe überhaupt nicht, was ich machen soll" – den Satz aus der Zusammenarbeit kennt ihr doch auch, oder? Gerade in einer Workshop-Situation, in der die Zusammensetzung oft rollenspezifisch ist, kann es immer wieder Reibung zwischen Entwicklung und Design geben. Doch woher kommt das? Grundsätzlich sind beide Rollen kreative Domänen. Beide wollen Probleme lösen und innerhalb des Teams auch ziemlich sicher das selbe. Wie kann es also sein, dass es immer wieder zu Konflikten kommt?

Ja, beide Rollen sind kreativ und wollen Probleme lösen. Aber: eben auf unterschiedliche Weise. Um das Verständnis der jeweils anderen Herangehensweise – entweder dem Design Mood oder dem Decision Mood – soll es hier gehen.

Decision- und Design Mood

Wann bin ich im Decision Mood?

Im Decision Mood startet die Problemlösung mit der Annahme, dass alle verfügbaren Lösungsalternativen bereits bekannt sind. Mit Hilfe verschiedener Techniken und Methoden, wie Algorithmen und Heuristiken, wird entschieden, welche der schon vorliegenden Lösungsvarianten die Beste ist. Dies ist eine passive Sicht auf die Lösungsfindung.

Ein Beispiel: Die Auswahl einer passenden Library für die Erweiterung einer App. Üblicherweise werden vorhandene Libraries miteinander verglichen, bis die Entscheidung klar ist: Wir nehmen die Library, die die meisten Anforderungen abdeckt. Das ist in diesem Fall eine effiziente Herangehensweise. Oft gibt es bereits Lösungen, die für den eigenen Anwendungsfall gut genug sind.

Nachteil: Lösungsmöglichkeiten, die noch entstehen können, werden oft nicht mitgedacht.

Wann bin ich im Design Mood?

Demgegenüber steht der Design Mood. Diese Problemlösungsstimmung startet mit der Annahme, dass noch nicht alle Lösungsmöglichkeiten präsent sind. Um die beste Lösung zu finden bedarf es Team-Fähigkeiten, -Zeit und -Ressourcen, um Lösungsvarianten zu erzeugen. Es werden solange Lösungen erzeugt, bis offensichtlich ist, welche Lösungsvariante am besten ist. Das ist also eine aktive Sicht auf die Lösungsfindung, die Techniken zur Entscheidungsfindung überflüssig macht.

Ein Anwendungsbeispiel ist ein Design Studio, in dem von vielen Teammitgliedern verschiedenste Lösungen skizziert werden. Diese werden dann Schritt für Schritt gemeinsam zu einer Lösung verdichtet.

Nachteil hier: Es dauert länger, man kann sich “verzetteln” und man muss manchmal durchs ganze Tal der Unsicherheit schreiten.

Ein 'Vielleicht' lässt sich nicht gut coden!

Im Decision Mood, in dem Softwareentwickelnde oft agieren, müssen Varianten/Sonderfälle reduziert werden, damit man in einer annehmbaren Zeit Anforderungen umsetzen kann. Ein “Vielleicht” lässt sich nicht gut in Code umsetzen ;-). Im Decision Mood agiert man exklusiv, denn man findet die Lösung durch den Ausschluss möglichst vieler Faktoren.
Während man im Design Mood möglichst viele Anwendungsfälle bedenken möchte. Es ist wichtig, das Problem zu hinterfragen und viele Perspektiven einzunehmen, um eine – für alle beteiligten Seiten – optimale Lösung zu finden. Vage Annahmen und offene Fragen sind Teil des Prozesses, da noch nicht alles definiert ist. Im Design Mood agiert man inklusiv, denn das Ziel ist, möglichst viele Faktoren mit einzubeziehen.

Mit Konflikten besser umgehen

Es hilft meiner Meinung nach sehr, sich der eigenen Problemlösungsstimmung bewusst zu machen und den Modus des Gegenüber zu erkennen. So kann man Konfliktpotentiale schnell erkennen und gegebenenfalls vermeiden.

Was wir zur weiteren Unterstützung für Tools und Methoden einsetzen erfahrt im nächsten Blog-Artikel!

Quellen und weiterführende Infos