Schlagwort-Archiv: Designorganisation

Software und Usability Engineering und User Experience in kleinen und mittleren Unternehmen #muc17

In der Session „Software und Usability Engineering und User Experience in kleinen und mittleren Unternehmen“ wurden Schlaglichter auf einzelne Probleme geworfen, die kleine und mittlere Unternehmen bei der methodischen Umsetzung von Usability Engineering und UX haben. Die Impulse stammen aus den Förderinitiativen des BMWi im Umfeld von „Mittelstand Digital“.

Ich habe aus der Session im Wesentlichen ein paar Gedankenanstöße mitgenommen. Los ging es mit der These, dass klassische Methoden des Usability Engineerings in erster Linie für mittlere bis große Unternehmen und Wissenschaft anwendbar sind. Kleine Unternehmen taten sich nach der Erfahrung der Initiative bisher schwer klassische und eher schwergewichtige Methoden des Usability Engineering zu adaptieren. Daher geht die Initiative der Frage nach, welche der Methoden des Usability Engineerings für kleine Unternehmen wie adaptiert werden können.

Wenn ich so in die großen Unternehmen um mich herum hineinschaue, dann beobachte ich aktuell eher die gegenteilige Bewegungsrichtung. Im Rahmen der Digitalisierung hat die Geschwindigkeit, in der neue Produkte und Services entwickelt werden müssen, einen deutlich höheren Stellenwert eingenommen. Viele der großen Unternehmen, versuchen von kleinen und vor allem jungen Unternehmen zu lernen schnell zu sein. Dabei ist die Frage der aktuellen Zeit, wie sowohl sichergestellt werden kann, dass mit einem Produkt/Service das richtige Problem auf die richtige Art und Weise gelöst wird, als auch diese so entwickelten innovative Ideen in einer hohen Geschwindigkeit zur Marktreife zu bringen.

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.

chi2016: Design Leadership for Business Innovation

Janaki Kumar (SAP), Irene Au (Khosla Ventures), Margaret Stewart (Facebook), Todd Lefelt (Huge) und Katie Dill (airbnb) diskutierten wie sich das Führen von Designteams in den letzten Jahren verändert hat und vor welche Herausforderungen Designer und Design Leader heute gestellt werden.

Designteams können heute nicht mehr aus reinen Spezialisten bestehen. Heute sind eher Designer gefragt, die sowohl ihr Handwerk beherrschen, als auch über grundlegende Kenntnisse und eine Verständnis zu angrenzenden Disziplinen verfügen, beispielsweise über Technologien oder Business-Strategien. (T-shaped skills) Designer von heute sind der Erfahrung der Referenten nach mutiger und fragen häufiger nach dem Warum von Entscheidungen, Zuständen und Prozessen. Das ist für die Qualität der Arbeitsergebnisse sehr gut. Gleichzeitig ist es aber auch für klassische Organisationen mit hierarchischen Organisationsstrukturen eine Herausforderung.

Im Gegensatz zu den Zeiten, als Designer in der Produktentwicklung noch als Exoten galten, gibt es heute bekannte Karrierepfade für Designer und zahlreiche leuchtende Beispiele für erfolgreiche Designkarrieren in Unternehmen. Designer von heute kennen diese und wollen diese auch nutzen.

Design needs to know business. Designers have to have empathy for business.

Früher war die Tätigkeit von Designern auf das visuelle Design fokussiert. Heute sind sie Partner bzw. Teammitglieder die Hand in Hand mit anderen Disziplinen an der Erarbeitung von Problemlösungen und Strategien arbeiten. Da dies in der Ausbildung von Designern aktuell häufig zu kurz kommt, ist es die Aufgabe von Design Leadern für die entsprechende Ausbildung zu sorgen. Dabei sollte insbesondere auf die Fähigkeiten zur Entwicklung von Strategien Wert gelegt werden. Designer von heute müssen sich viel mehr um geschäftliche Ziele kümmern und dafür Sorge tragen, dass zu deren Erreichung die Anwendersicht nicht zu kurz kommt. Damit das gelingen kann, müssen sie auch in der fachlichen Domäne ausgebildet werden. Allerdings gilt es dabei einen Kompromiss einzugehen, denn je tiefer das fachliche Verständnis und die Kenntnisse in der Fachdomäne sind, um so schwerer fällt es eine frische unvoreingenommene Sichtweise ins Entwicklungsteam zu bringen. Daher sollte bei der Teamaufstellung darauf geachtet werden, dass neben Domänenexperten auch Domänennovizen zum Team gehören.

Everyone today is working more like a startup.

Eine wesentliche Aufgabe von Design Leadern besteht aktuell darin die Zusammenarbeit zwischen den unterschiedlichen Disziplinen zu fördern. Die Disziplin Design muss nach Ansicht der Referenten integraler und integrierender Bestandteil der Produktentwicklung sein. Es bedarf eines gegenseitigen Verständnis und Empathie zwischen Entwicklern und Designern.

Share with people the value of research.

Designer sollten sich neben ihrer kreativen Arbeit um die Kommunikation von Anwenderwissen und die Schaffung von Empathie für Anwender kümmern. Dazu sollten sie auch die Ergebnisse ihrer Arbeit zielgruppenorientierter gestalten. An die Stelle von Berichten und Präsentationen sollten kreative Formate treten, welche Diskussion und Austausch fördern.

Designmethoden und Designprozesse sollten daher auch eher als Vorschlag denn als Dogma gesehen werden. Es gibt nicht den einen richtigen Prozess oder die eine richtige Methode. Methoden und Prozess müssen zum Team passen und auch deren Bedürfnisse adressieren. Ein dogmatisches Festhalten an einem starren Prozess ist nicht erfolgsversprechend … auch dann nicht, wenn es sich um sogenannte Industriestandards handelt.

Bei der Rekrutierung von Designern empfiehlt die Runde neben Designfähigkeiten auch auf eine anwenderorientiere Denkweise zu achten. Letzteres wird als eine wesentliche Eigenschaft für Designer gesehen, da sie über die Gestaltung von Bildschrimen hinaus denken und das gesamte Erlebnis der Anwender im Blick haben sollten.

Zum Abschluß noch eine kleine Erkenntnisse am Rande: Das Designteam von Airbnb hat aktuell 60 Mitarbeiter.