1. /Services
  2. /Design-driven Development

Design-driven development

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.

Christoph Eichhorn

Kontakt

Der alte Prozess

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.

der neue Prozess

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.

Related Cases