UX Designer by Default

Abstract. Die Business Analyse (BA) bzw. das Requirements Engineering (RE) und die User Experience (UX) haben eine engere Beziehung als man zu-nächst annehmen würde. Insbesondere wenn kein dediziertes UX Personal verfügbar ist, kann dies schnell zu suboptimalen Projektergebnissen führen, da es keine Option ist, keine UX zu erzeugen. Dieser Beitrag erläutert kurz und knapp die Zusammenhänge und die Rolle des BA/RE als Teil davon. Darüber hinaus werden Vorschläge gemacht, wie durch ein leicht angepasstes Vorgehen in der Anforderungsanalyse Verbesserungen der UX er-reicht werden können.

(Vortrag beim Diskussionsaustausch „Menschenzentriertes RE“ der Fachgruppe Requirements Engineering 2022)

Einführung

Paul Watzlawick, ein bekannter Psychotherapeut und Kommunikationswissenschaftler, ist insbesondere für das folgende Zitat bekannt: „Man kann nicht nicht kommunizieren“ [1]. Die Interaktion insbesondere mit technischen Systemen ist so ge-sehen ebenfalls eine Form der Kommunikation zwischen Menschen und Maschinen. Aus dieser Interaktion heraus entsteht bei den Nutzern eine so-genannte Nutzungserfahrung, die im Englischen auch als User Experience (UX) bezeichnet wird. Diese wird in der ISO Norm 9241-210 definiert als „a person’s perceptions and responses that result from the use or anticipated use of a product, system or service” [2].

Führt man nun diese beiden Aspekte zusammen, gelangt man relativ schnell zu der Einsicht, dass es eigentlich nicht die Möglichkeit gibt, eine User Experience nicht zu erzeugen. Dadurch, dass ein System auch nicht nicht kommunizieren kann, entsteht so oder so ein entsprechendes Nutzungserlebnis. Dies reduziert die Optionen für die Gestaltung einer User Experience auf genau zwei: 1. Man gestaltet die User Experience gezielt mit entsprechendem Mitteleinsatz oder 2. man tut dies nicht und erhält irgendein zufälliges Resultat. Insbesondere bei letzterem Ansatz findet die User Experience eine Ausprägung von drei möglichen in Mertons Framework zu den sogenannten Unintended Consequences [3]: Unverhofft positiv, negativ oder gar das Gegenteil von dem, was vielleicht doch so halbwegs beabsichtigt war.

Problem

Für die absichtliche Gestaltung der UX existiert im Normalfall entsprechendes Fachpersonal. Aber auch die Frage, wer mitunter für die unbeabsichtigte User Experience verantwortlich ist – insbesondere, wenn keine dedizierten UX Professionals verfügbar sind – ist relativ einfach zu beantworten. Requirement Engineers und Business Analysten erheben und dokumentieren Nutzeranforderungen und führen diese einer nachfolgenden Implementierung zu. Auf diese Weise wird die Berufsgruppe der Anforderungsexperten zum UX Designer by Default, also demjenigen, dem die Aufgabe zufällt, wenn keine UX Professionals verfügbar sind. Problematisch ist dies insbesondere, weil es den wenigsten bewusst ist und es auch in der Ausbildung kaum oder gar nicht thematisiert wird. Des-wegen ist ihr Vorgehen häufig nicht gerade dafür ausgerichtet, eine optimale User Experience zu schaffen – mit entsprechenden Resultaten.

Idee & Ansatz

Aber bekanntermaßen ist das Bewusstsein über einen Sachverhalt der erste Schritt zur Veränderung bzw. Verbesserung. Denn eine verstärkte Achtsamkeit den Nutzern gegenüber ist relativ leicht zur er-reichen, da sich die Methodiken und Vorgehens-weisen im Requirements Engineering/der Business Analyse und dem User Experience Design ohnehin schon recht ähneln. Die Idee ist also, in den Fundus der Praktiken zu schauen, um dort die vorhandenen Methoden und Techniken deutlich mehr in Richtung eines menschenzentrierten Ansatzes zu entwickeln, damit sich im Folgenden eine gewisse User Experience einstellen kann. Dies hat nicht nur den Vorteil, dass die Nutzer weniger Fehler begehen oder eine implementierte Lösung nicht mehr nur schlichtweg ablehnen: Eine gute User Experience hat sogar eine unmittelbare Auswirkung auf den Return-on-Invest (ROI) [4] und somit auch einen positiven Effekt auf den dazugehörigen Business Case.

Nachdem die Idee klar ist, stellt sich die Frage nach der Form der Umsetzung. Um die Anpassung von Methoden besser zu demonstrieren, wurde der Ansatz gewählt, dies exemplarisch für jedes Wissensgebiet (engl. knowledge area) im Business Analysis Body of Knowledge (BABOK) [5] – einem internationalen Standard für die Business Analyse des International Institute of Business Analysis (IIBA) – durchzuführen. Die dortigen Wissensgebiete fassen zusammengehörige oder ähnliche Tätigkeiten unter einer gemeinsamen Überschrift zusammen. Insgesamt gibt es 6 Gebiete. Diese sind in der Tabelle 1 kurz dargestellt.

Name Kurzbeschreibung
Business Analysis Planning and Monitoring (BAPM) Beschreibt die Aufgaben zur Organisation und Koordination der Business Analyse und Stakeholder.
Elicitation and Collaboration (EC) Beschreibt die Aufgaben zur Vorbereitung, Erhebung, Bestätigung, Dokumentation und Kommunikation von Informationen.
Requirements Life Cycle Management (RLCM) Beschreibt die Aufgaben zum Management und der Pflege von Anforderungen von der ersten Erhebung bis zu ihrer Ausmusterung.
Strategy Analysis (SA) Beschreibt die Aktivitäten zur Bedarfsermittlung und zur Findung von ersten Lösungsansätzen, diese zu erfüllen.
Requirements Analysis and Design Definition (RADD) Beschreibt die Aufgaben zum Spezifizieren und Modellierung von Anforderung, sowie ihrer Verifizierung und Validierung und der Entwicklung von Lösungsalternativen als Antwort auf den Bedarf.
Solution Evaluation (SE) Beschreibt die Aufgaben zur Bewertung der Performanz einer Lösung, um Ansätze für deren Verbesserung zu finden.

Im Gebiet BAPM wird beispielsweise das allgemeine Vorgehen festgelegt. Zum einen bietet es sich hier an, einen partizipativen Ansatz zu wählen, der die Nutzer mit einbezieht. Zum anderen wird in diesem Bereich auch die Stakeholder Analyse durchgeführt. Da ein Großteil von fehlgeschlagenen Projekten an der Nutzerakzeptanz scheitern, empfiehlt es sich, gleich hier die Nutzer passend einzuordnen und entsprechend zu berücksichtigen.

Im Gebiet EC, also insbesondere bei der Erhebung von Anforderungen, ist auf einen geeigneten Methodenmix zu achten, der alle Faktoren des Kanomodells [6] abdeckt, um eine entsprechende Nutzerzufriedenheit zu erreichen. Insbesondere Basisfaktoren sorgen für hohe Unzufriedenheit bei Nichterfüllung. Bei Performanzfaktoren steigt bzw. fällt die Zufriedenheit linear mit dem Grad der Umsetzung und Begeisterungsfaktoren machen ihrem Namen alle Ehre, kommen aber nur meist im kleinen Umfang vor.

Das gleiche Modell bietet sich an, um im Gebiet RLCM die Priorisierung von Anforderungen vorzunehmen um einen gewissen Featuremix für einen Release zu ermitteln, der auf eine hohe Nutzerzufriedenheit ausgelegt ist. In Form einer Pyramide bauen auf dem breiten Fundament von Basisfaktoren die Performanzfaktoren auf. Die Spitze der Pyramide bilden die Begeisterungsfaktoren.

Business Cases im Rahmen der Strategy Analysis profitieren davon, wenn man den ROI einer guten User Experience berücksichtigt. Als Einflussfaktoren wären hier zu nennen: weniger Fehler, geringere Supportkosten, geringere Trainingskosten, weniger Fehlentwicklungen, eine gesteigerte Produktivität sowie mehr Umsatz durch das daraus resultierende Image.

Im Bereich der Solution Evaluation kann die Nutzerperspektive besser unterstützt werden, wenn entsprechend nutzerrelevante Aspekte wie Durchführungszeiten, Fehlerraten, das allgemeine Nutzerverhalten sowie gängige Heuristiken und Gestaltungsgrundsätze gemessen und kontrolliert werden.

Fazit

Keine User Experience zu erzeugen ist keine Option. Durch geschickte Eingriffe in die RE/BA Methoden und Vorgehensweisen lassen sich Benutzerbedürfnisse relativ leicht besser integrieren. Dies erlaubt einem UX Designer by Default, positive Ergebnisse bei der User Experience zu erzielen.

Referenzen

  1. Watzlawik, P., Beavin, J.H., Jackson, D.D. (1969). Menschliche Kommunikation. Formen. Störungen, Paradoxien. Bern. Hans Huber Verlag. ( Affiliate Link)
  2. International Organization for Standardization (2019). ISO 9241-210:2019. Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems.
  3. Merton, R.K. (1936). The Unanticipated Con-sequences of Purposive Social Action. American Sociological Review, 1(6), 894-904
  4. Moran, K. (2020). Calculating ROI for DesignProjects in 4 Steps. https://www.nngroup.com/articles/calculating-roi-design-projects/ (Abruf: 12.02.2023)
  5. International Institute of Business Analysis (2015). Business Analysis Body of Knowledge (BABOK) – Version 3 ( Affiliate Link)
  6. Kano, N., Seraku, N., Takahashi, F., Tsuji, S. (1984). Journal of The Japanese Society for Quality Control, 14(2), 147-156
Christoph Oemig

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert