1. /Inside
  2. /Design-driven­ development

Wir nehmen es vorweg: Es gibt ihn nicht, den idealen Prozess. Die Anwendung eines spezifischen Vorgehensmodells garantiert nicht automatisch die beste Produktlösung. Ausschlaggebend für den Projekterfolg und die Time-to-Market ist vielmehr die Kombination aus dem richtigen Framework, dem richtigen Tooling und den richtigen Personen.

Als Entwicklungspartner und Dienstleister in unterschiedlichen Branchen und Projekten haben wir in den letzten drei Dekaden viele Erfahrungswerte sammeln können. Agil zu werden war ein Prozess. Es zu bleiben bedeutet für uns, permanent zu überprüfen, ob das jeweilige Vorgehensmodell zum Produkt passt. Neben den veränderbaren Variablen gibt es aber auch Konstanten im Projektalltag, auf die man vertrauen kann – und sollte.
 

Das alte Bild vom Prozess

In vielen Projekten lässt sich oftmals noch ein klassisches Bild erkennen: Der Kunde (oft vertreten durch seine Stakeholder aus dem mittleren Management) hat eine Anforderungsliste, die er an das Design übergibt. Hier werden nach der Analysephase Konzepte entwickelt und gemeinsam mit dem Kunden bewertet, bevor diese dann ausgestaltet werden. Anschließend wird das fertige Design an die Entwicklung übergeben, welche dann damit beschäftigt ist, nach bestem Wissen und Gewissen umzusetzen, was vorgegeben wurde. Abschließend wird – egal ob final oder sprintweise – das Resultat an den Stakeholder übergeben.

DDD_1

Sowohl der Design- als auch der Entwicklungsprozess haben sich in den letzten Jahren gewandelt. Das Design hat einen ganzheitlicheren Blick auf die Dinge bekommen und User Experience und Usability sind zu einem etablierten „Must“ geworden – ganz zu schweigen vom Thema „Marke“ im Produkt. Auch neue Tools machen die Designentwicklung schneller und damit effizienter.

Zeitgleich ist gerade in der Softwareentwicklung einiges in Sachen Agilität passiert. Wer heute ohne agiles Mindset und ohne Scrum oder Kanban entwickelt und gerade in großen Softwareprojekten nicht in kleinen Inkrementen, sauberen Komponenten, skalierbaren Architekturen und im Sinne einer ständigen Veränderung denkt, wird es schwer haben, mit den Wettbewerbern Schritt zu halten.

In der getrennten Abfolge von Anforderung, Design und Development lässt sich aber auch so etwas wie ein Wasserfall-Modell erkennen – ein Risiko für den Projekterfolg, vor allem, wenn es im Prinzip nur um das Fertigstellen des Liefergegenstandes geht.
 

Getrieben sein, das Richtige zu tun

Wie es das Wort „Driven“ ausdrückt, geht es ein Stück weit auch um die innere Haltung: getrieben und motiviert zu sein, das Richtige zu tun. Im Design-driven development ist es das primäre Ziel, aus den Anforderungen schneller zu lernen und diese sauber zu definieren – nicht losgelöst voneinander, sondern als Produktteam. Dabei sollte der Diskurs im Vordergrund stehen. Das Design kann dabei helfen, diesen Diskurs und die weitergehende Entwicklung durch Visuelles zu unterstützen und schneller zu Erkenntnissen zu gelangen. Getreu dem Motto: „Learn fast“. Hier steckt das eigentliche Potenzial: Die besten Produkte sind das Ergebnis einer kontinuierlichen Vereinfachung und Ausdetaillierung sowie eines individuellen Weges.

DDD_2

Unnötige Iterationen können wegfallen, wenn das Entwicklungsziel von allen Projektbeteiligten frühzeitig verstanden wird und die gemeinsam erarbeitete Spezifikation vorhanden ist. Die enge und interdisziplinäre Zusammenarbeit von Designer*innen und Entwickler*innen in einem Produktteam ist dann erfolgreich, wenn Scrum und Kanban neu ausgelegt werden. Schnelles Testen und die Beantwortung der Produktanforderungen durch das gesamte Team ermöglichen Lösungen, die auf einem validen Fundament stehen, weniger Fragen in der Entwicklung aufwerfen und vor allem schneller als in einem zwei- oder dreiwöchigem Rhythmus sichtbar sind.

Vorteile durch Design-driven development:

  • Schnellere Spezifikation und Visualisierung der Anforderungen
  • Gemeinsames Produktverständnis
  • Frühes Ausräumen von Missverständnissen
  • Schnellerer Erkenntnisgewinn durch frühes Testen und gemeinsames Bewerten
  • Geringeres Risiko durch Auflösen der unabhängigen Phasen (Requirements & Design & Development)
  • Geringere Entwicklungsaufwände/weniger Iterationen

Wenn alle Expertisen mitwirken und am Erfolg des Produktes teilhaben, fördert dies nicht nur den Teamspirit, sondern bringt möglicherweise auch etwas „Start-up“-Kultur in das Projekt. Dies passt nicht nur zu uns, sondern ist unser UXMA-Leistungsversprechen als Entwicklungspartner: Ganzheitliche Produktentwicklung mit individuellen Produktteams.

Christoph Eichhorn
In der Rolle als Prokurist und Head of User Experience & Digital Design treibt Christoph Eichhon die Themenbereiche Human Centered Design und Design Driven Development mit großem Engagement und tiefgehender Expertise voran.
Eckhard Anders
Geschäftsführer Eckhard Anders prägt seit bereits seit 2008 den Bereich der Software-Entwicklung bei UXMA maßgeblich und hat den Weg für agile Projektarbeit und die digitale Transformation bereitet. Wie kein Zweiter steht der studierte Informatiker für eine vernetzte Zukunft.
props.nextPost.title

Das BSH Roxxter Projekt: Eine interdisziplinäre­ Meisterleistung­