Ganzheitliche fachliche Gestaltung

Dieses Kind braucht einen Namen

Digitale Produkte und Lösungen sind der Weg der Wahl für erfolgreiches Business. Geprägt durch die designfokussierte Welt der Apps und Smartphones erwarten Nutzerinnen und Nutzer heute nicht mehr nur punktuell gute User Interfaces oder User Experience, sie erwarten ganzheitlich gut gestaltete Lösungen.

Produktentwicklung, Technologiepotenziale und Gestaltung müssen dabei zusammengedacht werden. Das stellt Entwicklungsteams vor veränderte Herausforderungen. Einzelne Expertisen, zum Beispiel in UX Design, Produktmanagement und Testen, müssen zusammengebracht werden in interdisziplinären Teams mit der Fähigkeit, Technologiepotenziale zu erkennen und zu nutzen.

Quelle: https://dd-ux.de/

Auf der ersten Digital Design-Konferenz, die die ganzheitliche Gestaltung guter digitaler Produkte zum Thema machte, waren auch wir von BettercallPaul mit einem Vortrag unserer Geschäftsführerin Ute Nause vertreten. Die Kernaspekte wollen wir noch einmal in einem Blog aufarbeiten.

Früher war alles besser (?)

Man könnte wohl Regale einer Bibliothek mit den Grob- und Fachkonzepten unserer Branche füllen. Früher waren das hunderte, wenn nicht gar tausende, Seiten Papier, die geschrieben wurden, bevor ein System in die Entwicklung ging. Zu 100 Prozent durchdacht, jeder Sonderfall spezifiziert, zu detailliert (vor allem in der Ferne) und an dem Tag der Abnahme teilweise schon wieder veraltet.

Wer klug agierte, war allerdings damals schon „iterativ“ unterwegs, um rechtzeitig Learnings einfließen lassen zu können. In jedem Fall war ein Grobkonzept, in dem die Ziele, Rahmenbedingungen und groben Eckpfeiler der Lösung dokumentiert wurden, der Grundstein eines jeden Vorhabens.

Die Organisation war vor grob 20 Jahren auch noch anders geschnitten. Es gab Teilteams für fachliche Komponenten und ein sogenanntes „Chefdesign“ sorgte für Konsistenz und Durchgängigkeit. Teils aufgeteilt in den „fachlichen“ und „technischen“ Part, aber immer besetzt mit einem Menschen, der das zu bauende System „im Kopf hatte“ – jemand, an den man sich wenden konnte, wenn fachliche Fragen auftraten oder technische Hürden zu bewältigen waren.

Heutzutage sind Wörter wie Chefdesign verpönt – weil „zu sehr von oben herab“ und nicht den Gedanken der Agilität verkörpernd. Grobkonzept, Feinkonzept oder Fachkonzept sind auch verboten – Wir schreiben unsere Dokumentation doch innerhalb der User Stories… oder etwa nicht?

Ab damit direkt ins Backlog

Wo früher viel zu fein geplant und zu lange geknetet wurde, ohne „einfach mal zu machen“, wird heute durch (zu?) agile Methoden oft zu schnell geschossen. Von der Planung wandern (vermeintlich gute) Lösungen direkt ins Backlog. Ideen aus Kollaborations-Tools wie miro und aus TEAMS Chats werden sofort in User Stories übersetzt, ohne das „Große Ganze“ zumindest im Groben zu durchdenken.

Das Erste, was oft getan wird, ist, zunächst mal mit einem Team von UX-lern und UI-lern eine coole Oberfläche zu bauen. Man fängt mal mit leichten Business Cases an – Es werden Landing Pages mit hübschen Tortendiagrammen und Grafiken erstellt. Das sieht geil aus. Das Management jubelt. Der Zuschlag wird erteilt. Und dann geht irgendwann alles in die Hose.

Das liegt nicht etwa daran, dass die UI-Spezialisten schlechte Arbeit geleistet haben (Im Gegenteil, denn die haben das Management ja überzeugt), sondern daran, dass keiner das Vorhaben ganzheitlich durchdacht hat.

Oft wurde zu wenig Forschungsarbeit in Bezug auf Daten betrieben – Mit „Lorem Ipsum“ sieht das Tortendiagramm richtig fetzig aus, mit echten Daten funktioniert das auf einmal nicht mehr. Ein Sonderfall sprengt die gesamte Ansicht, weil die Designer in die „Simplicity Trap“ gelaufen sind: es wurde zu sehr vereinfacht und die hochspezialisierten Anwender können ihre Arbeit gar nicht mehr effizient erledigen. Verschiedene Feature Teams laufen einfach mal los und bauen Teile des Anwendungskerns doppelt. Schnittstellen und Stammdaten sind zudem zu langweilig, um sich damit zu beschäftigen, und Stakeholder und Benutzer:innen nerven nur, mit denen will eh keiner reden.

Nachvollziehbarkeit und Doku anhand User Stories? Wie soll das funktionieren, bei einer Experten-Business-Software, die durch mehrere Teilteams parallel entwickelt wird? Ganz zu Beginn mag die Menge an Epics und Stories ja noch überschaubar sein. Aber spätestens ab dem Moment, an dem neue Stories oder Change Requests vorhandene Funktionen verändern, müsste man, um ein vollständiges Bild des Systems aus Stories herauslesen zu können, eine Delta-Analyse machen.

Wer hält alles zusammen?

Wer hält das alles zusammen? Das ist die große Frage.

Der Chefdesigner? Den gibt’s nicht mehr. Die Teamleads oder Projektleiter? Arbeiten die nicht eher auf organisatorischer Ebene? Ach dann der Product Owner? Der ist unser Held, denn der:

entwickelt die Vision und das Produkt-Ziel
nimmt das Team auf strategischer Ebene mit
unterstützt das Team bei der taktischen Umsetzung
gibt dem Team die notwendigen inhaltlichen Informationen
ist verantwortlich für den wirtschaftlichen Erfolg
übernimmt das Planning und Refinement
pflegt das Backlog
beschreibt die Items in Form von User Stories
reviewt die Sprintergebnisse
präsentiert den Fortschritt
übernimmt das Stakeholder-Management

Macht es denn etwas aus, dass…

… der PO seine Aufgabe oft nur in Teilzeit ausführt?
… die Aufgabe auf mehrere Köpfe verteilt ist, die nicht miteinander reden?
… der PO oft keine Entscheidungskompetenz hat oder ein Neuling in der Firma ist?
… der PO am Ende sogar ein extern eingekaufter „Fachfremder“ ist?

JA, das ist fatal. Langwierige Entscheidungen sind die Folge. Endlose Schleifen ohne Ergebnisse. Ständige Rückfragen und Rückdelegationen ins Entwicklungsteam.

Der Scrum Guide 2020 besagt: „Der Product Owner kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der Product Owner ergebnisverantwortlich.“ Machen wir davon Gebrauch!

Digital Design: Wir sind die Brückenbauer

Wenn man will, dann könnte man die Rolle des- oder derjenigen, der/die alles zusammenhält, als Proxy-PO beschreiben: Ein Proxy-Server ist ein Computer, der den Datenverkehr zwischen zwei Geräten, Netzwerken oder Protokollen abfängt und verwaltet. Also eine Art Vermittler.

Eine Analogie, die funktioniert, aber dennoch den wichtigsten Gedanken außer Acht lässt: Eigenmächtige und ganzheitliche Gestaltungskompetenz – eben nicht nur ein Vermittler. Jemand der eine Brücke baut, muss beide Seiten kennen, aber er muss auch in der Lage sein, zu sagen, wie die Brücke aussehen soll. Es bedarf:

Designkompetenz (Konstruktion, Konzeption, Usability, UX, Forscherdrang, …)
Materialkunde (Möglichkeiten und Grenzen, Richtlinien, Form- und Farbgebung, …)
Querschnittskompetenz (Methoden, Vorgehensweisen, das richtige Mindset, …)

Ist diese Person nicht eher ein „Designer“ als ein „Vermittler“? Designer sind kreativ, denken ganzheitlich, können andere Sichtweisen einnehmen und fragen nach dem „Warum“. Und da wir digitale Transformationen begleiten, nennen wir diese Rolle Digital Designer.

Einen Begriff zu haben, hilft auch unseren Kunden, die, je agiler das Umfeld wurde, immer mehr Probleme hatten, das eigene Projekt zu überschauen. Spätestens wenn drei Feature Teams undokumentiert den gleichen falschen Prozess umsetzen, wird immerhin auch jede Menge Geld verbrannt. Es braucht jemanden, der alles zusammenhält. Keinen „so einen wie…“, keinen „16-Ender“ oder „einen von der Sorte…“, sondern einen Digital Designer, der…

… das Ziel, den Scope und den Weg definiert.
… den Elefanten zerlegt.
… einfach mal Bilder malt, sodass jeder im Team kapiert von was geredet wird.
… Strategien erstellt (z.B. für Migration und Einführung).
… die Vision im Auge behält und den Überblick hat.
… der beste Freund des Product Owners ist (und natürlich des ganzen restlichen Teams).

„Jeder hat ein Problem zu lösen. Was schlechtes Design ausmacht, ist der Versuch, Probleme isoliert zu lösen.“

DON NORMAN

Fazit

Das Zauberwort ist „Ganzheitlichkeit„. Wir können kein UI-Design machen, ohne die Fachlichkeit und unsere Datenbasis zu kennen. Genauso wenig können wir UX-Design „später“ machen. Es reicht nicht, in einem Sprint 0 die Planung und ein Konzept zu machen – Jegliches Design im Projekt, sei es GUI, UX, Prozesse, Systemarchitektur oder begleitende Dokumentation, ist eine Daueraufgabe „Hand in Hand“. Wir sind in der Ferne gröber, sind agil, verbessern uns ständig und haben das Ziel gemeinsam vor Augen.

Ein Digital Designer muss dabei nicht alle Gestaltungskompetenzen selbst haben, jedoch sollte er wissen, was eine jede Disziplin ausmacht, um sie zusammenzubringen und das Team und das Projekt ins Ziel zu führen. Er ist ein Generalist mit Spezialisierung.

Über die Autoren

Ute Nause ist Mitgründerin von BettercallPaul und aktuell in der Geschäftsführung München zuständig für Corporate Strategy. Sie ist seit 25 Jahren im IT-Geschäft und dort als Beraterin, insbesondere im Bereich Automotive, tätig. Ihr Herz schlägt für Enterprise Architecture Management (EAM), Prozessgestaltung und Change Management.

Sascha Vöhringer ist ein erfahrener Digital-Designer und Berater bei BettercallPaul in München. Seine Schwerpunkte liegen im Bereich UX und Frontend-Design. Er hat umfassende Erfahrung in allen Projektphasen und schon mehrere Projekte von der Pike auf bis zum Go-Live begleitet.

#DigitalDesign