Von User Experience Design, Agilität und Personas

Im Rahmen des World Usability Days und der vom Beratungsunternehmen USECON organisierten Konferenz „Return on Experience“ durfte ich einen Vortrag über den Zusammenhang zwischen User Experience Design und agilem Arbeiten halten. Zu allererst: Was ist User Experience eigentlich genau? So wie viele andere Begrifflichkeiten wird auch “User Experience” oft ungenau verwendet. Im Wesentlichen bezeichnet es die Gesamtheit der Erfahrungen, die ein Anwender mit einem Produkt oder einer Dienstleistung macht. Ziel des User Experience Design ist es, ein Produkt oder eine Dienstleistung so zu gestalten, dass die positive Erfahrung maximiert wird und negative Aspekte wie Frustration etc. vermieden werden. Somit spannt sich User Experience Design von der Gestaltung von Bildschirmmasken bis hin zum zielgerichteten Auslösen von Emotionen während der Produktnutzung.
Doch was hat das Ganze jetzt mit agilem Arbeiten zu tun?
Wenn wir uns die Ideen rund um Scrum 3.0 näher ansehen, erkennen wir, dass der User heute noch viel stärker in den Mittelpunkt rückt. Innovationsmethoden wie Design Thinking gehen ebenfalls diesen Weg und orientieren ihre gesamte Prozessmethodik ausschließlich am Endanwender. Die logische Konsequenz: Kompetenzen wie User Experience Design werden zu einer zentralen Fähigkeit von Scrum-Teams. Sie benötigen daher nicht nur einen User Experience Designer im Team, sondern müssen diese Kompetenz breiter integrieren – User Experience muss jeden im Team etwas angehen!
Die Grenzen zwischen Agilität und User Experience Design verschmelzen besonders stark bei der ganzheitlichen Integration von Personas in den Entwicklungsprozess. Personas sind fiktive Endanwender. Sie werden im Rahmen der Entwicklung modelliert, um sich besser in die Lebenswelt der künftigen User einfühlen zu können. Personas werden meist mit einem kleinen Lebenslauf versehen, um sie so real wie möglich zu gestalten. Sinn und Zweck ist es, jede User Story mit einer Persona als Rolle zu versehen. Welche Funktionalität braucht diese Persona genau? Und wie muss diese Funktionalität nutzbar sein, um die Persona zu begeistern?

Ein Beispiel aus dem Online Banking:
Ein Digital Native (20 Jahre, Student) stellt ganz andere Ansprüche an eine Überweisung als ein typischer Filialkunde (65 Jahre, Rentner). Ein „Heavy Trader“ hat an das Wertpapier-Depot völlig andere Anforderungen als der Durchschnittsbürger, der mit Wertpapieren für eine Zusatzrente spart.
So schaffen Personas die Brücke zwischen User Experience Design und User Storys. Mit Hilfe der Persona an jeder User Story kann sich das Team in die potentiellen Anwender hineinversetzen und so die optimale Lösung/Experience für jeden Anwender-Typ designen. Für Product Owner bieten Personas zudem die Möglichkeit, eine zusätzliche Achse der Priorisierung einzubeziehen. Funktionen, die hochprofitable Kunden (wie z.B. Heavy-Trader) überdurchschnittlich nutzen würden, wären eventuell priorisierter zu betrachten als andere.
Doch Personas können noch weit holistischer als in User Storys verwendet werden. Auf einem höheren Level können sie auch in Customer Journeys verwendet werden. In Customer Journeys wird analysiert, wie bestimmte Personas mit dem Unternehmen in Berührung kommen, um dessen Produkte zu kaufen oder Dienstleistungen in Anspruch zu nehmen. Hier können wertvolle Inputs für das Design der User Experience und in weiterer Folge für die Entwicklung generiert werden. Wie sieht ihre Customer Journey aus? Ist es ein Erlebnis aus einem Guss oder eine beschwerliche Reise mit vielen Hindernissen?

Um den Kreis der Personas nach User Storys und Customer Journeys zu schließen, sollten in weiterer Folge die tatsächlichen Anwender, die die Produkte oder Dienstleistungen verproben, anhand dieser Personas ausgewählt werden. So können die verschiedenen Hypothesen, die auf Basis der Personas erstellt wurden, an realen Beispielen verifiziert werden. Dieser gesamtintegrative Ansatz stellt sicher, dass die Entwicklung zentral am User und dessen Vertreter in Form der Personas ausrichtet ist.
In Zeiten der Digitalisierung wird User Experience zunehmend an Stellenwert gewinnen – gerade in agilen Teams, die an den Innovationen von morgen arbeiten. Bereiten wir dieser Entwicklung den Boden und forcieren wir ein breites User Experience Wissen in unseren Teams, um diesen neuen Anforderungen zu begegnen.

Agile methods in safety-critical projects

Before I joined borisgloger consulting, I worked for a software vendor that delivers solutions for safety-critical environments. While we initially tried to manage the development with traditional project management methods, we switched to more agile methods over time. During this time I also was constantly in contact with the Vienna Institute of Systems and Safety Engineering, in particular with Hans Tschürtz. Together we developed a procedure model that allows the usage of agile methods while ensuring compliance to safety standards.
Agile in safety-critical projects has become a more important topic today than five years ago, when we started developing our ideas. Agile is everywhere, especially in the automotive industry. Customers and users value innovative solutions while taking safety for granted. They even punish companies if there are only minor indications that safety is not assured – refer for example to the discussion about the driving assistance system of Tesla. Thus we need a development approach, that allows being innovative and flexible while ensuring upmost safety for potential users. In the following paragraphs I will discuss the key success factors of such an approach.

The Team

Cross-functional teams are most important in agile development. We need to have all the skills that are necessary for developing the product represented in the team. In safety-critical projects this requirement calls for the integration of a safety engineer in the development team. Further we should treat safety like quality – a value everyone in the team has to care about.

The Start

When starting a safety-critical project, we recommend an initial workshop phase, in which the whole development team plus experts analyzes the requirements, elaborates a first rough technical concept and performs a first safety analysis. Depending on the context and size of the project, this workshop may last from 2 to 10 days. We don’t believe that it is necessary to do months of analyzing and designing. To keep the workshop attendees focused we recommend to carry out the following workshop off-site.
The workshop itself is split in four parts:

After elaborating those parts, the results lay the foundation for the development project, that can now start with its iterations.

Impact Assessment

During the iterations, every new user story has to be assessed if the new functionality has an impact on the current safety concept. Are the new hazards introduced? Do we need new safety measures? A first analysis can be already done during the backlog refinement meeting. The more cross-functional a team is, the easier the identification should be. If the user story has an impact, the team knows that at least some parts of the safety concept have to be updated in the iteration.

Definition of Done

To maintain an overview of what is necessary if the user story has an impact, you can make use of your Definition of Done. Just add all required tasks, for example an update of the Functional Failure Analysis or an update of the safety case. Of course, this checklist can be quite long for safety-critical projects, but that’s the constraint that such projects have to face.
I hope you got a little insight in how safety-critical projects can be tackled with agile methods. If you have any further questions, don’t hesitate to contact me.