Bessere User Experience durch eine Entwicklungsorganisation nach User Journeys

Softwarelösungen, welche umfangreiche Arbeitsprozesse unterstützen sollen, können mitunter sehr komplex werden. Die Komplexität entsteht zum einen durch die fachlichen Anforderungen zum anderen aber auch dadurch, dass Softwarelösungen aus vielen Komponenten bestehen. Damit dabei ein positives Nutzungserlebnis entstehen kann, müssen alle Komponenten, die in einer User Journey vorkommen, sehr gut orchestriert werden und miteinander harmonieren.

Eine User Journey ist für mich die „Reise“, die ein Anwender mit Hilfe der Softwarelösung durchläuft, um seine Arbeitsaufgabe zu erfüllen bzw. sein Ziel zu erreichen. Die User Journey beginnt damit, dass der Anwender sich etwas vornimmt und endet damit, dass dieses Ziel erreicht wurde. Ich differenziere dabei bewusst zwischen User Journey und Customer Journey. Während die User Journey die Anwendersicht auf die Software darstellt, ist die Customer Journey die Sicht des Kunden auf das Unternehmen.

Die besondere Herausforderung liegt dabei nicht nur darin, dass die zahlreichen Komponenten technisch bzw. gestalterisch aufeinander abgestimmt werden müssen. Vielmehr ist es nötig die vielen Menschen, die an den unterschiedlichen Komponenten einer Softwarelösung arbeiten, auf das gemeinsame Ziel einzustimmen. Allen Beteiligten muss klar sein, welches Erlebnis dem Anwender auf seiner Reise geboten werden soll.

In großen Unternehmen ist das mitunter gar nicht so einfach. Unternehmen teilen ihre Organisation meist in kleinere und leichter steuerbare Organisationseinheiten bzw. Teams auf, um der internen Komplexität und der internen Eigendynamik Herr zu werden. Das geht häufig mit einer funktionalen Ausrichtung der Organisation einher – also der Bündelung von Funktionen oder Experten in einzelnen zentralen Teams. Diese Bündelung betrifft aber nicht nur Menschen, sondern auch Softwarekomponenten an denen diese Menschen arbeiten. Softwarekomponenten, die in mehreren Produkten des Unternehmens benötigt werden, werden in zentralen Teams entwickelt und möglichst oft wiederverwendet.

Bei der Entwicklung von großen Softwarelösungen arbeiten heute viele Menschen projektbezogen in unterschiedlichen Teams zusammen. Manchmal verantwortet ein Team (A) die Softwarelösung, die am Ende verkauft werden soll und baut diese auf Basis der Komponenten von anderen Teams (B) bzw. externen Anbietern (C). Manchmal werden die einzelnen Teile einer Softwarelösung über mehrere Teams hinweg entwickelt. Unabhängig davon, ob dabei nach agilen Prinzipien gearbeitet wird oder nicht, haben die Beteiligten in solchen Entwicklungsvorhaben meist mit hohen Abstimmaufwänden, immer wieder auftretenden Wartezeiten, umfangreichen Regelwerken und gegenseitigen Abhängigkeiten zu kämpfen.

Leider spüren die Anwender bei der Verwendung der Software häufig, wie sich ihre User Journey durch die Organisationseinheiten des Unternehmens schlängelt. Immer dann, wenn in der gleichen User Journey zwischen Komponenten gewechselt wird, die von unterschiedlichen Organisationseinheiten entwickelt wurden, werden Brüche mehr oder weniger spürbar. Die Anwender merken die organisatorischen Gegebenheiten beispielsweise an Prozessbrüchen während der Bedienung, an Inkonsistenzen zwischen verschiedenen Komponenten oder an gestalterischen Unterschieden. Das ist oft selbst dann so, wenn die einzelnen Komponenten an sich nach Human-Centered-Design-Prinzipien entwickelt wurden.

Was sich da bemerkbar macht, sind die sich überlappenden Verantwortungsbereiche. Jedes Team strebt danach seine Ziele so gut wie möglich zu erfüllen. Das daraus resultierende Streben nach dem lokalen Optimum, steht einem positiven Nutzungserlebnis in der gesamten User Journey im Weg.

„Organization shapes User Experience“

Abhilfe schafft da ein Perspektivwechsel. Anstatt die User Journey über die Organisation zu verteilen, sollten die User Journeys im Zentrum der Organisation stehen. Crossfunktionale Teams (A) welche je für eine User Journey von Anfang bis Ende verantwortlich sind, werden ein deutlich besseres Nutzungserlebnis erzeugen können, als Teams welche mit einer Mischung aus eigenen und fremden Komponenten arbeiten müssen. Die Teams sind dabei so interdisziplinär aufgestellt, dass sie ohne Abstimmaufwände und teamexterne Unterstützung auskommen.

Um über die verschiedenen User Journeys eine Konsistenz bei wiederkehrenden Use Cases und ein gewissen Grad an Entwicklungseffizienz zu erreichen, kommt man auch in diesem Modell nicht um zentrale Teams herum, die sich um Basiskomponenten oder übergreifende Themenstellungen kümmern. Aber anstatt in einem eigenen zentralen Team vollständige (Basis-)Komponenten für andere Teams zu entwickeln, arbeiten die Teammitglieder der zentralen Komponententeams im Wesentlichen direkt an den User Journeys, in denen ihre Komponente zum Einsatz kommt, mit. Sie sind gleichzeitig Teil der crossfunktionalen Teams, welches die User Journey und Teil der Community bzw. Teams, welches sich um die Basiskomponente kümmert. Dadurch können sie die (Basis-)Komponente deutlich besser auf den Nutzungskontext und die Bedürfnisse der Anwender ausrichten. Echte Grundfunktionalitäten, die in anderen User Journeys wiederverwendet werden sollen, werden in (Basis-)Komponenten ausgelagert, welche im Wesentlichen keine Bedienoberflächen haben (B und C). Diese Komponenten sind dann wie eine Art Grundbaukasten, mit dem eine Software gebaut werden kann. Wichtig ist aber, dass die Integration der Komponenten in die Softwarelösung nicht mehr auf der Ebene der Bedienoberflächen stattfindet. Die Bedienoberfläche wird zwar auf Basis der Grundbaukästen entwickelt, kommt aber immer aus einer Hand – dem Team der User Journey. Über die Lebenszeit der Basiskomponente arbeiten die Mitglieder des Komponententeams in unterschiedlichen User Journey-Teams. Sie werden damit neben anderen Rollen wie UX Designern oder Requirements Engineers zu Multiplikatoren für einen konsistenten Einsatz der Komponenten. 

Durch die Konzentration aller notwendigen Fähigkeiten in einem Team, ist es viel einfacher bei allen Beteiligten für ein gemeinsames und klares Bild von dem angestrebten Nutzungserlebnis zu sorgen. Außerdem werden Wartezeiten und Abstimmaufwände drastisch reduziert und die Entwicklungsgeschwindigkeit spürbar erhöht.

Unternehmen, die sich nach den User Journeys organisieren, die sie ihren Kunden anbieten wollen, sind meiner Meinung nach deutlich besser und effizienter in der Lage positive Nutzungserlebnisse zu bieten.