Den Nutzungskontext als Team bestimmen

Veröffentlichungsdatum: 27 Nov, 2020 |
Veröffentlichungsdatum: 27 Nov, 2020
Tag(s):

Im Designprozess eines interaktiven Produkts trifft ein Produktteam immer wieder Gestaltungsentscheidungen. Das Team bestimmt so, was getan werden muss aber auch was es nicht umsetzen wird. Ein Produktteam muss für informierte Entscheidungen ein gemeinsames Verständnis von vielen Einflussfaktoren entwickeln, damit die Arbeit in eine einheitliche Richtung investiert wird. Um ein gemeinsames Verständnis des Kontexts zu gewährleisten, stehen Instrumente wie Szenarien und Storyboards zur Verfügung. Bevor wir diese aber ausarbeiten können brauchen wir zwangsweise Entscheidungen darüber, welche Nutzungskontexte unser Produkt unterstützen soll.

Der Nutzungskontext

Das Wissen um den Nutzungskontext eines Produkts gehört zu den vier Wissensdomänen der Produktentwicklung. Nach der ISO 9241-210:2010 wird der Nutzungskontext definiert als „Benutzer, Aufgaben, Ausrüstung (Hardware, Software und Materialien) sowie die physischen und sozialen Umgebungen, in denen ein Produkt verwendet wird“ [1]. Er beschreibt also beispielsweise Aspekte wie wann und wo unter welchen Umständen ein Produkt von wem wozu verwendet wird. Allerdings finden sich zu all den einzelnen Fragen, die sich hierbei ergeben viele unterschiedliche Antworten, deren Kombinationen untereinander schnell unübersichtlich werden. Daher brauchen wir eine Methode, um strukturiert vorgehen zu können. Eine gut geeignete Methode zur strukturierten Erfassung und Bestimmung der Merkmale des Nutzungskontextes ist die morphologische Analyse.

Morphologische Analyse

Die morphologische Analyse ist eine Methode, bei der Parameter und Merkmale für eine mögliche Lösung eines Problems gesammelt und strukturiert werden. Der Ansatz wurde Ende der 1940er Jahre von dem Astrophysiker Fritz Zwicky (1898-1974) entwickelt. Er entwickelte die morphologische Analyse, „um die abstrakteren strukturellen Zusammenhänge zwischen Phänomenen, Konzepten und Ideen, unabhängig von ihrem Charakter, zu untersuchen“ [2] und um eine umfangreiche Visualisierung aller möglichen Lösungen  für ein definiertes Problem zu ermöglichen [3]. Die morphologische Analyse wurde also entwickelt, um abstraktere, strukturelle Beziehungen zu untersuchen und ein definiertes Problem durch die Visualisierung aller möglichen Lösungen handhabbarer zu machen. Daher ist sie auch eine häufig verwendete Methode zur Generierung von Ideen und als Kreativitätstechnik sehr beliebt.

Nach Zwicky [2] besteht die morphologische Analyse aus fünf Aktivitäten. Sie beginnt mit der Definition des Problems, der Bestimmung der Merkmale (Parameter) und der Festlegung der möglichen Werte (Ausprägungen) der Merkmale. Die Definition des zu lösenden Problems ist der Ausgangspunkt der morphologischen Analyse, da sie klärt, was das Ergebnis der Analyse beantworten soll. Dann werden die Parameter des zu lösenden Problems bestimmt, welche voneinander unabhängig und für die Fragestellung relevant sein müssen. Danach werden alle möglichen Ausprägungen dieser Parameter gesammelt. Anschließend erfolgt die Konstruktion der morphologischen Matrix unter Verwendung der identifizierten Parameter und ihrer Ausprägungen. Wie in der beispielhaften Darstellung ersichtlich enthält die morphologische Matrix alle möglichen Kombinationen von Ausprägungen der verschiedenen Parameter. Abschließend erfolgt die Auswahl der möglichen Konfigurationen. Bei dieser Aktivität wird für jeden Parameter genau eine Ausprägung aus der Matrix ausgewählt.

Beispiel einer morphologischen Analyse

Beispiel einer morphologischen Analyse für den Fahrkartenkauf

Ablauf der morphologischen Analyse eines Nutzungskontextes

Zum Sammeln der möglichen Parameter beginnt man mit Einzelarbeit. Zunächst sammeln die Teilnehmer in ruhiger Einzelarbeit die Parameter (Tageszeit, Endgerät etc.) , des Nutzungskontextes für ihr Produkt auf einzelnen Blättern Papier. Anschließend bringen sie ihre Ergebnisse in ihrer Gruppe zusammen. Doppelte Parameter werden entfernt und Widersprüche innerhalb der Gruppe aufgelöst. Falls erforderlich, notieren die Teilnehmer mögliche Werte (morgens, mittags etc.) für einen Parameter, sofern dies für das Erreichen eines gemeinsamen Verständnisses dieses Parameters relevant ist.

Auf der Grundlage der Parameterliste definierten die Teilnehmer nun in der Gruppe mögliche Parameterwerte und erstellten dadurch eine morphologische Matrix. Nachdem die Gruppe eine morphologische Matrix erstellt hat, wählen sie bis zu drei realistische und relevante Konfigurationen aus. Um zu überprüfen, ob die Konfiguration realistisch genug ist, stellt ein Teilnehmer diese Konfigurationen der Gruppe in narrativer Form vor und beschreibt, wie ein bestimmter Benutzer das Produkt in dem ausgewählten Kontext verwenden würde. Fühlt sich diese Auswahl an Konfigurationen hilfreich an, ist die morphologische Analyse abgeschlossen.

Ablauf bei größeren Gruppen

Einer der Mehrwerte der morphologischen Analyse ist die Entwicklung eines gemeinsamen Verständnis des Teams. Daher sollte das ganze Produktteam soweit wie möglich daran teilhaben. Meist sind Produktteams aber verhältnismäßig groß und sollten daher bei der Durchführung der morphologischen Analyse in mehrere Gruppen aufgeteilt werden, die in einem Workshop separat arbeiten aber ihre Ergebnisse immer wieder angleichen. Dabei stellen die jeweiligen Gruppen ihre Ergebnisse nach jedem Schritt den Vertretern der anderen Gruppe vor und erhalten dadurch Rückmeldungen, die sie in ihre Ausarbeitung einfließen lassen können. Bevor die Sammlung der Ausprägungen begonnen wird, ist es empfehlenswert, dass die Gruppen ihre Parameterlisten vereinheitlichen und so einen gemeinsamen Ausgangspunkt erzeugen.

Zusammenfassung

Obwohl einige Autoren die morphologische Analyse als erschöpfend bezeichnen [3], lässt sich das kaum beweisen, da es unbekannte Unbekannte geben kann [4]. Der konstruierte Lösungsraum ist immer durch das Wissen der Teilnehmer begrenzt. Da die Teilnehmer auch die Parameter spezifizieren, können sie nur einen begrenzten Teil der Realität und der möglichen Lösungen darstellen. Obwohl erwartet wird, dass die Liste der Anforderungen „alle wesentlichen Anforderungen“ [5] enthält, können entwickelte Konfigurationen „durch ein Modellierungswerkzeug, das Techniken wie die Strukturanalyse verwendet, auf Vollständigkeit überprüft werden“ [6]. Die morphologische Analyse ist eine strukturierte Modellierungsmethodik, die einen Ansatz für den Nutzungskontext bietet.

Insgesamt lässt sich feststellen, dass die morphologische Analyse des Nutzungskontextes ein Team zusammenbringen kann. Die gemeinsame Diskussion und die strukturierte Vorbereitung des Nutzungskontextes geben einen Anstoß für die weitere Produktentwicklung. Die erstellte morphologische Matrix kann zur Auswahl der Ausprägungen der Parameter verwendet werden, die dann bei der Konstruktion von Szenarien und Storyboards verwendet werden können.

Weitere Ausführungen zur Methode, sowie Good Practices und zu vermeidende Stolpersteine finden sich in unserer Veröffentlichung:

Winter, Dominique; Hausmann, Carolin; Schön, Eva-Maria; Thomaschewski, Jörg (2020): Morphological analysis of the ‘context of use’ Application of morphological analysis to the collaborative understanding of the context of use, 2020 15th Iberian Conference on Information Systems and Technologies (CISTI), Sevilla, Spain, 2020, pp. 1-6, doi: 10.23919/CISTI49556.2020.9141034

Literatur

[1] ISO 9241-210:2010, Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems, Geneva, Switzerland: International Organization for Standardization, 2010.

[2] F. Zwicky, Discovery, Invention, Research – Through the Morphological Approach. New York, NY: Macmillan, 1969.

[3] C.R. O’Neal, “New approaches to technological forecasting—Morphological analysis : An integrative approach.” In: Business Horizons, Elsevier, vol. 13(6), pp. 47-58, December 1970.

[4] A. Sutcliffe and P. Sawyer, “Requirements elicitation: Towards the unknown unknowns.” In: 21st IEEE Internetional Requirements Engineering Conference. Rio de Janeriro, Brasil, 2013.

[5] IEEE 830-1998, IEEE Recommended Practice for Software Requirements Specifications, New York, NY: The Institute of Electrical and Electronics Engineers, 1998.

[6] P. Bourque and R.E. Fairley, Guide to the Software Engineering Body of Knowledge (SWEBOK®): Version 3.0. Los Alamitos, CA: IEEE Computer Society, 2014.

0 Kommentare

Einen Kommentar abschicken

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Weitere Blogbeiträge