Digitale Gestaltung

Menschzentriertes Interaktionsdesign hat, wie bereits erwähnt, viele verschiedene Strömungen und zugrunde liegende Philosophien. Oberflächlich betrachtet wirken sie aufgrund der gleichen Zielsetzung und ähnlicher Vorgehensweisen sowie der Verwendung gleicher Methoden auch wenig differenziert: Da Designprojekte häufig komplex und gerade am Anfang schwer zu durchdringen sind und das zu lösende Problem nicht immer klar ist, liegt allen menschzentrierten Gestaltungsansätzen eine iterative Vorgehensweise zugrunde. Diese Vorgehensweise strebt an, ein Problem in kleine Teilprobleme herunterzubrechen, weiter zu definieren und zu verstehen und möglichst strukturiert und zielgerichtet im Einklang mit technischen Limitationen und Potenzialen, Nutzungsanforderungen und kontextuellen Gegebenheiten zu lösen.

Wie bereits angedeutet, werden Designansätze und deren Philosophien in Prozessmodellen festgehalten, die bei der entsprechenden Strukturierung und Dokumentation von Vorgehensweisen, Arbeitspakten und Projektabschnitten helfen sollen. Hierbei geht es letztlich nicht um eine strikte Einhaltung von vorab definierten hierarchischen Strukturen. Stattdessen zielt diese Formalisierung darauf ab, ein bestimmtes Problem zu umreißen und zu erfassen, gegebenenfalls neu zu definieren und vor allem funktionierende und angemessene Lösungen zu finden (Lawson 2006; Rosson und Carroll 2002; Shneiderman et al. 2016; Cooper et al. 2014). Ein gewisses Maß an Standards und Normierungen hilft jedoch, sich für eine grundsätzliche Gestaltungsrichtung zu entscheiden und sich im Team bzw. mit den betroffenen Stakeholdern abzustimmen sowie anfallende Aktivitäten zielgerichtet zu koordinieren. Die Flexibilität erlaubt einen kreativen und sinngerichteten Umgang mit aufkommenden und unerwarteten Herausforderungen oder sich als falsch herausstellenden Annahmen. Anstatt Arbeiten nach Vorschrift erlaubt es diese semistrukturierte Vorgehensweise, passgenaue Lösungen zu entwickeln, und lässt Raum für Innovationen und einen flexiblen Umgang mit unerwarteten Ereignissen.

Trotz dieser grundlegenden Gemeinsamkeiten unterscheiden sich die verschiedenen menschzentrierten Gestaltungsansätze im Detail, zum Beispiel darin, wie eng Nutzer:innen in den Gestaltungsprozess eingebunden werden, ob Abläufe und Designphasen normiert sind, wie viele dieser Designphasen es im dokumentierten Designprozess gibt oder auch für wen eine Technologie gestaltet werden soll. Prinzipiell muss man auch davon ausgehen, dass Designprojekte aufgrund einzubindender Nutzer:innen- und Stakeholdergruppen, Anwendungsgebiete, Arbeitsabläufe und entsprechender bestehender Strukturen und Prozesse individuell sind. Das bedeutet, dass es nicht die perfekte Vorgehensweise geben kann, sondern Designprozesse, Methoden und Werkzeuge projektabhängig ausgewählt werden sollten. In der Regel werden Designprozesse aber durch eine bestehende Unternehmenskultur und Struktur schon vorgegeben, da sie sich zum Beispiel einfacher mit bestehenden Softwareentwicklungsprozessen vereinbaren lassen, sie weniger zeitlichen und monetären Aufwand bedeuten oder einfach das Entwickler- und Designteam sehr erfahren mit einem bestimmten Ansatz ist. Dennoch sind all diese Ansätze valide und ihre Auswahl und Passfähigkeit auf Designprojekte kontextabhängig.

6.2.1 Interaction Design

Im Fokus des Interaktionsdesigns steht die Gestaltung digitaler Produkte und Services. Im Vergleich zu traditionellen Designdisziplinen interessiert sich diese Gestaltungsdisziplin insbesondere für das Verstehen und Gestalten von menschlichem und technischem Verhalten (Cooper et al. 2014). Diese Erkenntnisse fließen in den Gestaltungsraum für interaktive digitale Produkte, Umgebungen, Systeme und Dienstleistungen ein und stellen den Menschen in den Mittelpunkt der Gestaltungsentscheidungen (Auernhammer et al. 2022). Die im nächsten Abschnitt genannten Modelle unterstützen einen strukturierten Entscheidungsprozess, der nach Lawson (Lawson 2006) einer dreidimensionalen Darstellung von Design ähnelt: „eine Verhandlung zwischen Problem und Lösung durch die drei Aktivitäten der Analyse, Synthese und Bewertung“ (Lawson 2006). Entsprechend wird beim Interaktionsdesign deutlich, dass eine Linearität beim Abgleichen und Gestalten zwischen Problem- und Lösungsraum nicht vorausgesetzt werden kann. Im Gegenteil: Diese drei Aktivitäten sind miteinander verwoben und nicht in ihrer Abfolge hierarchisch geordnet. Entsprechend können Designprozesse und -aktivitäten in der Praxis sehr individuelle Ausprägungen aufweisen.

6.2.2 Design Thinking, Double Diamond und ISO 9241-210

Strukturierte Ausprägungen des Ansatzes des Interaktionsdesigns sind unter anderem Design Thinking (IDEO U 2023), Double Diamond (Cat Drew) oder das nutzer:innenzentrierte Designprozessmodell (ISO/TC 159/SC 4/WG 6 Human-centred design processes for interactive systems 2020) der ISO-Norm 9241:210.

Design Thinking in seiner heutigen Form geht auf eine Strömung der Designforschung in akademischen Kreisen zurück, die sich mit der Denk- und Handlungsweise von Designer:innen auseinandersetzt. Eine zugrunde liegende Annahme dieser Strömung ist, dass Designprobleme nicht deterministisch, sondern wicked, also komplex, von vielen nur teilweise bekannten Faktoren abhängig und nur schwer zu durchdringen sind (Rittel und Webber 1973; Buchanan 1992; Kimbell 2011). Lösungsversuche erfordern eine entsprechende Einbindung aller relevanten Stakeholder in den Designprozess und ein iteratives Vorgehen, um bestehende Probleme und deren Zusammenhänge möglichst gut zu verstehen und zufriedenstellende, innovative Lösungen zu finden. Buchanan argumentiert in seiner Arbeit, dass die generalisierte Form dieser designerischen Denkweise (designerly thinking) entsprechend nicht nur auf begreifbare Objekte, sondern auf jedwede Form von mehr oder weniger komplexen Problemen angewendet werden kann (Buchanan 1992). Entsprechend wird Design Thinking heute häufig im Kontext von Organisations- und Business-Transformationen und -Innovationen verwendet und erlangte durch die flexible, kreative Denkweise und dafür passgenaue und leicht durchzuführende Methoden Popularität (Kimbell 2011). Es gibt jedoch kein einheitliches Design-Thinking-Prozessmodell, sondern viele ähnliche, die sich durch die Anzahl der zu durchlaufenden Schritte unterscheiden. Ein häufig verwendetes ist das Design-Thinking-Modell nach IDEO (IDEO U 2023). Dieses sieht sechs aufeinanderfolgende Phasen vor, wobei jederzeit iterative Schleifen und Sprünge zwischen den Phasen möglich sind (siehe Abb. 6.1):

1. 1.

   Frame a Question: Die Phase Fragestellung sieht das Identifizieren und Formulieren einer Forschungsfrage vor, die im Laufe des Designprozesses beantwortet werden und kreative Lösungsansätze ermöglichen soll.

2. 2.

   Gather Inspiration: In der Phase Inspiration rücken die tatsächlichen Bedürfnisse von Nutzer:innen und Kund:innen in den Vordergrund. Diese sollen das Designteam zu kreativen Ideen inspirieren.

3. 3.

   Generate Ideas: Die Phase Ideenfindung hat zum Ziel, neue Lösungen zu identifizieren. Getreu dem Motto „Kill your darlings“ gilt es hierbei, bahnbrechende Ideen zu entwickeln und die offensichtlichen hinten anzustellen.

4. 4.

   Make Ideas Tangible: Die Phase Prototypischer Entwurf wird häufig auch Prototyping genannt. Ideen werden externalisiert und durch das Entwickeln anschaulicher Artefakte begreifbar, erklärbar und testbar gemacht.

5. 5.

   Test to Learn: Nun gilt es, in der Phase Evaluation die Prototypen zu testen und anhand der Ergebnisse und des Nutzer:innen-Feedbacks zu lernen. Das Gelernte soll dann in weiteren Iterationen im Design berücksichtigt werden, um das Produkt zu verbessern.

6. 6.

   Share the Story: Sobald man die richtige Lösung gefunden hat, muss diese zusammen mit ihrer Entstehungsgeschichte an Kolleg:innen, Kund:innen und Nutzer:innen weitergegeben werden. Hierzu dient die letzte Phase Kommunikation.

Der Design-Thinking-Prozess basiert häufig auf sechs Phasen. Zwischen allen Phasen kann bei Bedarf gesprungen werden. Lizensiert als CC BY-SA 4.0, Valerie Schandl für WMDE (https://commons.wikimedia.org/wiki/File:Design_Thinking_Workshop_WMDE.png)

Full size image

Es gibt allerdings auch viele andere Prozessmodelle, nach denen Designaktivitäten in einem Projekt von der Designherausforderung bis zum Designergebnis gestaltet und strukturiert werden können. Der Double-Diamond-Prozess (Cat Crew) – angelehnt an die zweifache „Diamanten“-ähnliche Struktur im Ablauf – wird zum Beispiel in abwechselnd divergierende und konvergierende Phasen unterteilt, die den Übergang von der Designherausforderung zu einem Ergebnis beinhalten (siehe Abb. 6.2). Dies bedeutet, dass zuerst breitaufgestellte Aktivitäten in der Nutzer:innenforschung anstehen (entdecken/discover), gefolgt von der Definition potenzieller Lösungsansätze (definieren/define), die im nächsten Schritt entwickelt (entwickeln/develop) und evaluiert bzw. vorgestellt werden (liefern/deliver).

Der Double Diamond Design Process nach Design Council (Cat Drew 2019). Der Prozess wird sehr häufig im Design Thinking verwendet und stellt die Notwendigkeit der Ideenerweiterung und Reduktion durch Priorisierung in den Vordergrund. Lizensiert als CC-BY 4.0 Design Council (https://www.designcouncil.org.uk/our-resources/framework-for-innovation/)

Full size image

Einer der bekanntesten Prozesse ist der normierte nutzer:innenzentrierte Designprozess nach der ISO-Norm 9241:210. Dieser besteht aus den fünf Aktivitäten 1) Planung des nutzer:innenzentrierten Prozesses, 2) Verstehen und Spezifizieren des Nutzungskontextes 3) Dokumentieren der Nutzungsanforderungen, 4) Erstellen entsprechender Designlösungen und 5) deren Evaluierung auf der Grundlage der Nutzungsanforderungen. Nach diesem Prozessmodell können Designer:innen die Aktivitäten 2 bis 5 nach Bedarf iterieren und müssen dieses Modell nicht in einer strikten Reihenfolge durchlaufen (ISO/TC 159/SC 4/WG 6 Human-centred design processes for interactive systems 2020).

Alle diese Gestaltungsansätze eignen sich zur Entwicklung neuer und innovativer Ideen, werden jedoch in der Praxis ebenso gerne verwendet, um bestehende digitale Prozesse, Produkte oder Dienstleistungen zu evaluieren und zu optimieren. Gelegentlich werden nicht alle Phasen durchlaufen, sondern nur einzelne Aktivitäten innerhalb der einzelnen Phasen durchgeführt. Die Designer:innen verantworten häufig die Aktivitäten innerhalb der Phasen, jedoch kann es je nach Projektumfang oder Unternehmen zu Überscheidungen in Rolle und Funktion mit anderen Teammitgliedern kommen. Häufig entfällt zum Beispiel die Nutzer:innenanalyse (= User Research), die sehr zentral für ein gutes Design ist, auf andere Rollen im Projektteam. Diese werden dann nicht oder nicht nur von den eigentlichen Produktdesigner:innen durchgeführt, sondern je nach Projektmanagementmethode oder Projektteamzusammenstellung unter den Teammitgliedern aufgeteilt oder sogar ausgelagert. Ein anschauliches Beispiel hierfür ist die Rolle des Product Owner im Scrum-Prozess, der nicht notwendigerweise an der Umsetzung der Nutzungsanforderungen selbst beteiligt ist, diese aber verwaltet, pflegt, in Abstimmung mit dem Kunden priorisiert und bei Bedarf erweitert.

Wie Nutzungsanforderungen durch methodisches Vorgehen und die Verwendung von Werkzeugen umgesetzt werden, besprechen wir in den nächsten Abschnitten. Unter anderem wird dabei auf die Charakteristiken etablierter Interaktionskonzepte im 2D-Bereich eingegangen.

Iterative/inkrementelle und sequenzielle/lineare Prozessmodelle in der Produktentwicklung

Wie vorhergehend beschrieben, basieren gerade moderne Designprozessmodelle, aber auch viele agile Softwareentwicklungsmethoden auf einer iterativen Vorgehensweise. Iterativ in diesem Sinne bedeutet nichts anderes, als Tätigkeiten oder Phasen in einem Prozess (mehrfach) zu wiederholen und dadurch die Qualität des zu schaffenden Objekts oder Produkts zu erforschen, zu verstehen und kontinuierlich zu verbessern (Cockburn 2008). Alistair Cockburn bezeichnet Iterationen auch als „re-do“. Eine iterative Vorgehensweise dient unter anderem dazu, aus Fehlern oder auch Erfolgen zu lernen und entsprechende Konsequenzen durch erneutes Durchlaufen von Prozessphasen in einen neuen Entwurf einfließen zu lassen. Bei den vorher beschriebenen Prozessmodellen bedeutet dies nicht, dass man immer alle Schritte innerhalb einer Iteration durchlaufen muss. So können Phasen übersprungen oder mehrfach durchlaufen werden, um Prozesse abzukürzen und Innovationen so zu beschleunigen.

Mit iterativen Vorgehensweisen lassen sich sehr gut inkrementelle Ansätze kombinieren. Ein weitverbreitetes Modell, das Iteration und Inkrementierung vorschreibt, ist zum Beispiel Scrum. Während sich Iterationen auch auf einzelne Eigenschaften eines Objekts anwenden lassen, werden Inkrementierungen besonders im Gesamtkontext eines Projekts oder Designproblems sichtbar: Im Sinne der Softwareentwicklung bezeichnet ein Inkrement oftmals eine für sich alleinstehende funktionsfähige Komponente eines komplexeren Systems oder ein Teilprodukt, das nach Fertigstellung in das Gesamtsystem integriert wird. Cockburn bezeichnet eine inkrementelle Vorgehensweise auch als „add onto“ (Cockburn 2008) und stellt deren Eignung für die Verbesserung von Entwicklungsprozessen oder zur Anforderungsanpassung heraus. Auf den Designprozess angewandt bedeutet ein Inkrement also, dass ein komplexeres Designproblem in kleinere Teilprobleme heruntergebrochen wird. Diese Teilprobleme werden dann durch eine iterative Vorgehensweise unter Anwendung eines Prozessmodells gelöst und als einzelne Inkremente zu einer Gesamtlösung zusammengesetzt.

Dem stehen sequenzielle und lineare Prozessmodelle gegenüber, wie zum Beispiel das Wasserfallmodell (Benington 1983), eines der bekanntesten und ältesten Vorgehensmodelle der Softwareentwicklung. Ähnlich wie iterative Prozessmodelle besteht auch das Wasserfallmodell aus unterschiedlichen Phasen, die über die Dauer eines Projekts durchlaufen werden. Beim Wasserfallmodell sind das je nach Ausprägung die Phasen Anforderungserhebung, Entwurf, Implementierung, Überprüfung und Wartung. Anders als bei iterativen Modellen wie zum Beispiel dem Double-Diamond-Prozess werden diese Phasen aber nur genau einmal und in der vorgeschriebenen Reihenfolge (Sequenz) durchlaufen. Hierbei wird eine nachfolgende Phase erst begonnen, wenn die vorhergehende restlos abgeschlossen ist.

Selbstreflexion:

Führen Sie sich die iterativen Prozessmodelle der ISO 9241:210 und das klassische Wasserfallmodell vor Augen. Wann eignet sich eine iterative und inkrementelle Vorgehensweise besonders gut für Designprobleme? Wann sind sequenzielle Prozessmodelle wie das Wasserfallmodell vielleicht besser geeignet? Kann man das Wasserfallmodell auch iterativ und inkrementell einsetzen?

Als Disziplin der Informatik befasst sich die Verbraucherinformatik hauptsächlich, aber nicht ausschließlich mit der Gestaltung digitaler Artefakte und Services im interdisziplinären Kontext (siehe Kap. 2). Entsprechend müssen Designprozesse häufig in Softwareentwicklungsprozesse integriert werden. Dies kann jedoch eine Herausforderung darstellen, da Softwareentwicklung und Design nicht immer nach den gleichen Ansätzen vorgehen: Software ohne eine klare Vorstellung der Nutzenden und deren Anforderungen zu entwickeln, kann teuer sein. Deshalb stellen nutzer:innenzentrierte Designmodelle gerade zu Anfang des Projekts, wenn Anforderungen noch unsicher sind, möglichst günstige Designentwürfe (Prototypen) her. Diese sind zum Beispiel auf Papierbasis oder beschränken sich auf Skizzen – funktionsfähige Software wird erst recht spät im Prozess produziert (Ferreira et al. 2011). Im Gegensatz dazu forcieren agile Softwareentwicklungsmethoden wie Scrum von Anfang an das frühe Fertigstellen funktionsfähiger Software. Dieser scheinbare Widerspruch erfordert ein hohes Maß an Koordination zwischen Design- und Softwareentwicklungspraktiken, die häufig auf Teamebene individuell gelöst werden müssen.

Im Kontext der Softwareartefaktgestaltung sind heute immer noch Designansätze und Paradigmen relevant, die auf die Gestaltung von zweidimensionalen Anwendungen abzielen und damit einhergehend auf bewährte Interaktionskonzepte aus dem Bereich der Desktopanwendung zurückgreifen. Zu den wichtigsten Konzepten und Begrifflichkeiten zählen folgende:

• GUI – Graphical User Interface (Die Verwendung von grafischen Repräsentanten hat sich für eine nutzer:innenzentrierte Interaktion durchgesetzt. Grafische Darstellungen ermöglichen eine schnelle Wiedererkennbarkeit und das schnelle Auffinden von Funktionen.)

• WIMP – Windows, Icons, Menus, Pointing Devices (Die seit Jahrzehnten etablierten Anwendungen basieren auf grafischen Nutzerschnittstellen, welche die hier genannte Strukturierung der Bildschirmanzeige, Steuerung und Funktionseingabe ermöglichen und sicherstellen.)

• Direct Manipulation and Feedback (steht für eine direkte Beeinflussung der grafisch verfügbaren Komponenten und Elemente, die über ihre Veränderung und/oder Ergebnis der Manipulation an die Nutzer:innen eine sofortige Rückmeldung geben.)

• Desktop/folder/file (beschreiben die für die Nutzer:innen zugängliche und meist sichtbare Informationsarchitektur, die Informationen so strukturiert, dass sie schnell auffindbar und schnell abzulegen sind.)

• WYSIWYG – What you see is what you get (häufiger Begriff, der im Gegensatz zur text-basierten Interaktion über die Kommandozeile die unmittelbare visuelle Veränderung von Informationen durch Interaktion mit grafischen Elementen beschreibt. WYSIWYG wird häufig in Form von softwarebasierten und interaktiven Editoren als Gestaltungswerkzeug zur App- und Webentwicklung eingesetzt.)

Durch den technologischen Fortschritt und die Verbreitung und Adaptation neuer Hardware hat sich der Fokus auf vornehmlich visuell geprägte und zweidimensionale Anwendungen mittlerweile erweitert. Sprachassistenten, virtuelle Umgebungen, KI-basierte Applikationen und die Allgegenwärtigkeit und Interoperabilität unterschiedlicher Geräte und Systeme erfordern ganzheitlichere Designansätze, die auch jenseits von Bildschirmen und Touchscreens erfolgreich angewendet werden können. Diese Herausforderungen werden im Abschn. 6.6 näher behandelt.

Zunächst widmen wir uns Designmethoden, Werkzeugen, Guidelines und Prototyping als fundamentalen Bestandteilen der Artefaktgestaltung.

6.3.1 Designmethoden

Designmethoden sind dazu gedacht, Designaktivitäten anzuleiten, zu dokumentieren und zu beschreiben (Bodker 2021). Sie basieren meistens auf dem Wissen und der Erfahrung, die Designer:innen sich über eine lange Zeit angeeignet und angewandt haben. Häufig geht es um eine Abschätzung, welches Ergebnis erwartet werden kann und welche an den Kontext angepassten und geeigneten Methoden ausgewählt werden können. Das Ziel der Methoden besteht darin, Designaktivitäten zielgerichtet und zweckdienlich einzusetzen, um das Gesamtvorgehen zu organisieren und zu strukturieren. Zusätzlich ermöglicht der Einsatz von Methoden eine gewisse Wiederholbarkeit der Aktivitäten sowie die Sichtbarmachung der Verbindung zwischen Vorgehen und Ergebnis für andere. Neben ihrer Funktion als Strukturierungshilfe beschreiben diese auch die Anwendung von Designwerkzeugen (Bodker 2021; Ehn 1988; Mathiassen 1984). Deshalb werden Methoden häufig als präskriptive Blaupausen verstanden, die einen hierarchischen Prozess (siehe Abschn. 6.2) vorgeben und keine Abweichungen vorsehen (Gray 2016). Jedoch fußt diese Annahme darauf, dass implizites und non-verbales Wissen schwierig festzuschreiben und zu überliefern ist – dadurch kann in Methoden nur das greifbare und formalisierte Wissen externalisiert werden (Gray 2016; Bodker 2021; Stolterman et al. 2009). Damit Designmethoden tatsächlich zu den gewünschten Ergebnissen führen, brauchen Designer:innen den entsprechenden Grad an Fähigkeiten, Erfahrung und Aneignung (Gray 2016). Folglich können Methoden als Ausführung von und Werkzeuge der Designpraktiken betrachtet werden.

6.3.2 Werkzeuge (Tools)

Wie bereits erläutert, folgt Gestaltung keinem linearen Entscheidungsprozess, weshalb auch kein kausaler Zusammenhang zwischen Designaktivitäten, -nutzen und -zwecken sowie entsprechend relevanten Designwerkzeugen beschrieben werden kann (Stolterman et al. 2009). Stolterman et al. haben sich vor diesem Hintergrund mit der Designer:innen-Werkzeug-Beziehung beschäftigt und Kriterien identifiziert, nach denen Designer:innen ihre Werkzeuge auswählen. Das daraus resultierende Tool-in-Use-Modell beschreibt, dass die drei Faktoren Zweck, Aktivität und Werkzeug sehr eng, aber nicht hierarchisch miteinander verbunden sind und sich gegenseitig beeinflussen. Zudem unterscheiden Stolterman et al. zwei Gruppen von (digitalen) Designwerkzeugen im Hinblick auf ihre Verwendung: Die erste Gruppe an Tools dient Designer:innen zur Einordnung und Reflexion eigener Ideen, Handlungen und Herausforderungen (tools for thinking). Im Gegensatz dazu bilden Designwerkzeuge zur Erstellung von Ergebnissen und greifbaren Artefakten die zweite Gruppe (tools for production) (Stolterman et al. 2009). Allerdings ist auch diese Unterscheidung nicht eindeutig, da Designwerkzeuge je nach Designziel und Kontext unterschiedlich eingesetzt und somit auch beiden Gruppen zugeordnet werden können. Bildbearbeitungssoftware wie Adobe Photoshop ist zum Beispiel ein solches Werkzeug – Designer:innen können darin schnell ihre Ideen skizzieren, aber auch visuell ansprechende und weit entwickelte Designs erstellen, die dann exakt so im finalen Produkt eingebunden werden.

6.3.3 Design Guidelines

Im Gegensatz zu Methoden werden Design Guidelines tatsächlich als „präskriptives Gestaltungswissen“ (Sein et al. 2011) gehandelt, das aus der Entwicklung und Evaluation von IT-Artefakten entstanden ist (Purao et al. 2020; Gabbard und Swan 2008). Design Guidelines werden formuliert, zusammengetragen und getestet, um vor allem „gutes Design voranzutreiben“ (Johnson 2014). Sie basieren üblicherweise auf empirischer Evidenz und/oder Erfahrung (Johnson 2014), unterstützen die Formulierung von Designstandards (Cheriton 1976) und verringern den Aufwand sowohl für Entwickler:innen (Norman 1983) als auch Nutzer:innen (Cheriton 1976). Im besten Falle sollen Design Guidelines und Designprinzipien technologische Trends überdauern (Nielsen 1993) und deshalb in der menschlichen Psychologie und Wahrnehmung begründet sein (Johnson 2014). Design Guidelines hängen deshalb maßgeblich mit der intuitiven Bedienbarkeit von Softwareartefakten zusammen: Diese ergibt sich aus dem, was Nutzer:innen in ihrer Vergangenheit über die Interaktion mit Systemen gelernt haben und entsprechend von ihrer Interaktion mit einer Benutzerschnittstelle erwarten. Das Betätigen eines Buttons mit der Aufschrift „Abbrechen“ wird so im Regelfall mit der Unterbrechung des aktuellen Vorgangs und der Rückkehr zum vorherigen Systemzustand gleichgesetzt – unabhängig davon, ob ein solcher Button im Kontext eines Kaufprozesses an einem Parkscheinautomaten oder der Routenberechnung im Navigationssystem eines Fahrzeugs betätigt wird. Dies kann natürlich nur der Fall sein, wenn das entsprechende Verhalten über eine möglichst große Anzahl von Systemen gleich implementiert und dadurch auch erwartbar wird. Solches Designwissen wird dann häufig als Design Guideline festgeschrieben.

Korrekt angewendet erfüllen Design Guidelines also das, was Nutzer:innen unabhängig von der verwendeten Hardware von einer (digitalen) Benutzerschnittstelle erwarten. Design Guidelines können zum Beispiel Platzierungen bestimmter Designelemente festschreiben und die Ausgestaltung von interaktiven Dialogen im Fall eines Systemfehlers regulieren.

6.3.4 Prototyping und Prototypen

Prototyping ist, wie auch die Anforderungserhebung und die Evaluation, eine der fundamentalen Aktivitäten im Designprozess, sei es nun im Industriedesign, Produktdesign oder Softwaredesign. Im Kontext des Interaktionsdesigns wird als Prototyping im Regelfall die Aktivität der Prototypenerstellung bezeichnet (Floyd 1984). Das daraus entstehende spezifische Objekt oder Artefakt wird als Prototyp bezeichnet (Lim und Stolterman 2008) und stellt im Regelfall eine frühe Produktversion oder bestimmte Teile davon dar.

Prototypenentwicklung kann entweder allein oder kollaborativ durchgeführt werden. Kollaborative Ansätze stützen sich häufig auch auf Interdisziplinarität, Stakeholder- und Endnutzer:inneneinbindung, um die Ungleichverteilung von Wissen abzumildern. Das ist wichtig, da Nutzer:innen den Anwendungskontext und darin auftretende Herausforderungen wesentlich besser einschätzen können als Designer:innen oder Softwareentwickler:innen – allerdings fehlt ihnen häufig das technische Wissen, das zur idealen Lösungserstellung benötigt wird. Diese Ungleichverteilung von Wissen wird auch als Asymmetry of Knowledge (Rittel 1984) bezeichnet und stellt bis heute eine große Herausforderung in der System- und Produktentwicklung dar. Entsprechende kollaborative Designansätze sind zum Beispiel partizipatives Design (auch Participatory Design) oder Co-Design.

Prototyping an sich kann auch als eigenständiger Designprozess gesehen werden. In diesem Fall kann man im Regelfall die folgenden vier Schritte beobachten (Floyd 1984):

• Auswahl der Funktionen, um festzustellen, welche (potenziellen) Eigenschaften des finalen Produkts im Prototyp dargestellt werden sollen.

• Erstellung des Prototyps mit möglichst geringem Ressourcenverbrauch (z. B. Zeit, Personal) – ein Prototyp sollte in diesem Sinne nie teurer sein als das fertige Produkt.

• Evaluierung des Prototyps mit dem Ziel, nächste Schritte für den übergreifenden Designprozess zu identifizieren und ggf. Design- und Entwicklungsfragen zu beantworten.

• Weiterverwendung oder Integration des Prototyps in das finale Produkt oder Entsorgung/Ersetzung, nachdem dieser seine Bestimmung erfüllt hat.

Eine besondere Prototypingstrategie stammt aus der Lean-Startup-Bewegung (Edison et al. 2015) und vertritt die Ansicht, dass jeder entstehende Prototyp bereits ein funktionales Artefakt sein soll, das sich mit einer Grundproblematik von Kund:innen oder Nutzer:innen auseinandersetzt, einen entsprechenden Mehrwert bietet und ein schnelles Abgreifen von entsprechendem Feedback ermöglicht. Ziel einer jeden Prototypingaktivität ist es folglich, ein Minimum Viable Product (MVP) zu schaffen, das eine möglichst günstige, aber funktionale Lösung für ein vorher identifiziertes Problem oder eine Idee bietet (siehe Abb. 6.3). Die entsprechende Produktidee kann so sehr schnell und kostengünstig analysiert, iteriert, verfeinert oder verworfen werden.

Ein gängiges Beispiel für die Entwicklung eines MVP zeigt die schrittweise Produktentwicklung für das Kund:innenbedürfnis „Fortbewegung“, in diesem Beispiel für „Fortbewegung auf dem Wasser“. Beide gezeigte Entwicklungsprozesse brechen das große Designproblem in kleinere Teilbereiche herunter. Der obere Entwicklungsprozess braucht jedoch sehr lange, bevor das Grundbedürfnis der Nutzer:innen erfüllt werden und entsprechendes Feedback eingeholt werden kann, da die entwickelten Teilfragmente für sich alleinstehend nicht nutzbar sind. Anders mit dem unteren Prozess: Bereits der erste Prototyp – das Floß – erfüllt das Bedürfnis, trockenen Fußes von A nach B zu gelangen. Im weiteren Verlauf des Prozesses wird das Produkt entsprechend weiterentwickelt und auf Basis von Nutzer:innenfeedback verfeinert

Full size image

Erstellung eines MVP – Fallbeispiel Dropbox

Ein oft vorgestelltes Beispiel für eine MVP-basierte Produktentwicklung aus der Praxis ist die Erfolgsgeschichte von Dropbox (Slocum 2010). Das 2007 von Drew Houston und Arash Ferdowsi als Startup gegründete Unternehmen bietet mittlerweile neben Speicherplatz in der Cloud für Privatpersonen und Unternehmen auch Dateisynchronisierung, Produktivitätstools und entsprechende Endnutzersoftware an. Da Dropbox in seiner Funktionsweise eine komplexe und fehlerfrei funktionierende Infrastruktur erfordert, war es für Drew schwierig, einen kostengünstigen Prototyp zu entwickeln. Entsprechend schwierig gestaltete sich die Suche nach Investor:innen und Betanutzer:innen: Das Alleinstellungsmerkmal der Produktidee – eine nahtlose Integration von Dateisynchronisierung, Versionierung, Up- und Download – zu erklären, ohne einen funktionierenden Prototyp vorweisen zu können, stellte sich als wenig überzeugend heraus. Deshalb erstellte Houston ein kostengünstiges vierminütiges Werbevideo in Form einer Produktdemonstration, das anschaulich die Vorzüge des Clouddienstes darstellte.

Das Video, das noch immer über die Plattform YouTube auffindbar ist, zeigt einen kurzen Installations- und Setupprozess und die Registrierung eines neuen Endgeräts. Zusätzlich erklärt Houston die Kernfunktionen von Dropbox: die nahtlose Synchronisierung von Dateien und deren Änderung auf mehreren Endgeräten, Versionierung, Filesharing, das Zusammenspiel der Webplattform mit der Desktopanwendung sowie die Effizienz des Synchronisierungsalgorithmus.

Als das Video erschien, existierte noch nichts außer der Produktidee. Dennoch trugen sich quasi über Nacht mehrere zehntausend Interessierte auf der über die im Video beworbene Website getdropbox.com verfügbaren Warteliste für das Betaprogramm des Clouddienstes ein (Slocum 2010).

Selbstreflexion:

Nehmen Sie die Smartphone-App, das Computer- oder Konsolenspiel oder den digitalen Service, die Sie zuletzt verwendet haben, als Beispiel. Welche Grundproblematik oder Grundfunktionalität erfüllt das Produkt? Wie könnte das MVP dazu aussehen?

In diesem Teil sollen zentrale Begriffe eingeführt werden, um Gestaltung aus Nutzer:innensicht gehaltvoll bewerten und diskutieren zu können. Zusätzlich helfen diese Begriffe, perspektivisch Gestaltungsziele zu definieren und Verbesserungen bzw. Veränderungen nachvollziehbar zu machen.

6.4.1 Usability und (digitale) Ergonomie

„Ergon“ (griech.) bedeutet Arbeit, Werk und „nomos“ Gesetz, Regel, was zusammengesetzt die Wissenschaft der Gesetzmäßigkeit menschlicher Arbeit beschreibt. Im Sinne der Mensch-Maschine-Interaktion zielt die Ergonomie auf eine Verbesserung der Schnittstellen zwischen Mensch und Maschine ab, sei es im Sinne der Optimierung der Verwendung digitaler Werkzeuge oder der Zusammenarbeit zwischen Mensch und (intelligenten) Maschinen. In jedem Fall handelt es sich hierbei um die Analyse und Anpassung von Prozessen und Werkzeugen an den Menschen, damit eine langfristige, gesundheitsunbedenkliche und produktive Verwendung bzw. Zusammenarbeit gewährleistet ist (Grudin 2017).

Softwareergonomie oder auch Usability bezieht sich spezifisch auf die Erforschung der Gebrauchstauglichkeit und Benutzbarkeit von Softwaresystemen, traditionell vornehmlich im Arbeitskontext. Durch das Ausweiten des ursprünglich auf den Arbeitskontext beschränkten Einsatzes digitaler Systeme auf unseren privaten Alltag beschreibt Usability mittlerweile aber die allumfassende Gebrauchstauglichkeit von Software aus der Nutzer:innenperspektive.

Im Sinne der ISO 9241-11 ist ein Werkzeug in dem Ausmaß gebrauchstauglich, in dem es durch bestimmte Nutzer:innen in einem bestimmten Kontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.

• Effektivität – Können die Nutzenden ihre Ziele erreichen?

• Effizienz – Ist das Ziel mit möglichst geringem Aufwand zu erreichen?

• Zufriedenheit – Ist die Nutzung des Systems oder Produkts für die Nutzenden zufriedenstellend?

Bewertung der Gebrauchstauglichkeit von Werkzeugen

Usability lässt sich grundsätzlich nur vor dem Hintergrund eines bestimmten Anwendungskontextes beurteilen. Das lässt sich gut am Beispiel eines Feuerzeugs zeigen.

Ohne Kenntnis über die Aufgabe ist es nicht möglich, eine Aussage über die Usability des Werkzeugs zu treffen. Effektivität, Effizienz und Zufriedenstellung können immer nur vor dem Hintergrund einer bestimmten Aufgabe gemessen werden. Denn ob man damit einen Grill anzünden oder eine Bierflasche öffnen will, führt zu völlig unterschiedlichen Bewertungen.

Zudem muss immer auch der Kontext der Aufgabe, z. B. die Eigenschaften der Nutzer:innen des Werkzeugs, betrachtet werden.

Falls die Nutzer:innen geübt im Öffnen von Bierflaschen mit Feuerzeugen sind, werden wir feststellen, dass sie die Bierflasche mit hoher Sicherheit vollständig und genau mit dem Feuerzeug öffnen werden. Die Effektivität des Feuerzeugs als Werkzeug für das Öffnen von Bierflaschen wäre damit belegt.

Die Effizienz unseres Feuerzeugs könnte allerdings infrage gestellt werden, wenn sehr viele Bierflaschen mit dem Feuerzeug geöffnet werden müssen. Ein Kneipenwirt würde ein solches Werkzeug daher möglicherweise anders bewerten als jemand, der nur ein Bier auf seinem Balkon trinken möchte.

Die Zufriedenheit würde man in beiden Fällen dadurch erheben können, dass man fragt, ob die Nutzer:in das entsprechende Werkzeug anderen Nutzer:innen weiterempfehlen oder doch zur Anschaffung eines Flaschenöffners raten würde.

Selbstreflexion:

Wie würden Sie andere „Werkzeuge“ für die Aufgabe „Bierflasche öffnen“ aus einer Usability-Sicht bewerten, wie z. B. eine Küchenschere, ein Schweizer Taschenmesser oder einen Korkenzieher? Gehen Sie dabei jeweils auf die verschiedenen Ebenen Effektivität, Effizienz und Zufriedenstellung ein.

Allerdings ist es wichtig zu wissen, dass sich die Effizienz der Interaktion mit einem digitalen Werkzeug nicht ausschließlich über maximal geringen Aufwand im Sinne von Dialogschritten und Zeit definieren lässt.

Viel wichtiger ist die Gestaltung einer Interaktion im Sinne der sogenannten Interaktionsprinzipien der ISO 9241-110, die hier kurz genannt werden. Demnach ist eine Interaktion effizient im Sinne der Usability, wenn sie folgenden Prinzipien entspricht:

1. 1.

   Aufgabenangemessenheit

2. 2.

   Selbstbeschreibungsfähigkeit

3. 3.

   Erwartungskonformität

4. 4.

   Fehlertoleranz

5. 5.

   Steuerbarkeit

6. 6.

   Lernförderlichkeit

7. 7.

   Nutzerbindung

Das letzte Prinzip, die Nutzerbindung, nimmt hierbei eine Sonderstellung ein. Die anderen sechs Prinzipen beziehen sich in erster Linie auf die Aufgabengestaltung an sich, während das User Engagement mehr den subjektiven und emotionalen Aspekt der Nutzung adressiert und somit auch einen wichtigen Beitrag zur Zufriedenstellung des Nutzers liefert.

Beginnen wir mit einem vereinfachten Bild menschzentrierter Gestaltungsaktivitäten, angelehnt an die ISO 9241-210 (siehe Abb. 6.4).

Menschzentrierte Gestaltungsaktivitäten im Prozess

Full size image

Bei der Entwicklung von etwas Neuem sieht der Prozess vor, dass man in der oberen linken Ecke mit der Analyse des Nutzungskontextes beginnt. Hier geht es, auch im Sinne der Verbraucherpraxeologie, darum zu verstehen, welche Aufgaben bzw. Abläufe durch das Werkzeug genau unterstützt werden sollen, welche Eigenschaften, Fähigkeiten, Routinen und Wissen die Nutzenden aufweisen und welche Bedeutungen oder auch Motivationen dahinterstehen. Aber auch Eigenschaften des Kontextes, wie das soziale und physikalische Umfeld, gilt es bei der Analyse mit zu berücksichtigen. Ist die Analyse des Kontextes in einem ersten Schritt nach bestem Wissen und Gewissen geschehen, werden Anforderungen an die Nutzung des Systems formuliert, denen eine Prototypengestalt gegeben werden muss. Dies ist von immenser Wichtigkeit, denn eine Liste von Anforderungen kann nicht valide durch die Nutzenden geprüft werden. Das Ergebnis der Prüfung bzw. Evaluation kann im besten Fall sein, dass man das Artefakt, den Prototypen, leicht verbessern muss, beispielsweise dadurch, dass man ein Bedienelement, das die Nutzenden im Test nicht gut als solches erkannt haben, stärker hervorhebt. Etwas aufwendiger wird es, wenn man lernt, dass man Anforderungen nicht verstanden oder nicht umgesetzt hat. Dies erfordert ggf. die Gestaltung neuer Features, die das bisherige Gesamtdesign vielleicht in stärkerem Maße beeinflussen. Am meisten Arbeit bedeutet es, wenn man ggf. ganze Aufgabenstränge oder Nutzer:innengruppen bei der Analyse übersehen hat. Wichtig ist bei dem oben beschriebenen Prozess, dass er iterativ ausgelegt ist, sodass man vom Groben bis ins Feine Schritt für Schritt vorgehen kann. Auch sind diese menschzentrierten Aktivitäten nicht als eigener Prozess zu verstehen, sondern können leicht in jeden iterativen und agilen Softwareentwicklungsprozess eingeflochten werden.

Vom Kontextszenario zur Nutzungsanforderung

Beim Usability Engineering nach ISO 9024:210 wird zunächst anhand von Interviews der Ablauf von Aufgaben untersucht, die durch das Werkzeug genau unterstützt werden sollen. Im Fall der Entwicklung einer Einkaufs-App würde man z. B. typische Nutzer:innen fragen, wie ein Wocheneinkauf normalerweise abläuft. Dabei könnten dann Kontextszenarien wie das folgende Fragment herauskommen:

(…) So kauft Frau Muster z. B. Dosenmilch an dem Tag im Vorrat ein, an dem das Angebot besteht. Dazu schaut sie sich die Papierprospekte schon eine Woche vorher an, um den Einkauf von Vorratsprodukten mit ihrer Tochter entsprechend durchführen zu können. (…)

Welche Erfordernisse würden sich daraus nun ableiten lassen? Wichtig ist hierbei, von der bestehenden Lösung „Papierprospekt“ zu abstrahieren und stattdessen die Gründe für dessen Nutzung zu fokussieren. Das heißt, wir fragen uns hier nach den Zuständen, in denen sich der:die Nutzer:in befinden muss, um ein bestimmtes Ziel zu erreichen.

Erfordernis: Der:Die Einkaufende muss wissen, wann Dosenmilch im Angebot ist, um an diesem Tag einen Vorratseinkauf tätigen zu können.

In Falle des eben genannten Erfordernisses könnten beispielhaft zwei Nutzungsanforderungen für ein entsprechendes System benannt werden:

Nutzungsanforderungen:

• Der:Die Nutzende muss am System erkennen können, wann Dosenmilch im Angebot ist.

• Der:Die Nutzende muss am System einen Vorratseinkauf auswählen können.

Diese Nutzungsanforderungen sind bewusst technikunabhängig formuliert und lassen durch die Verwendung basaler Handlungsbegriffe (z. B. auswählen) (Meixner und Görlich 2009) maximalen Raum für Gestaltungen. Dementsprechend kann eine Liste von Nutzungsanforderungen später als Checkliste für das (prototypische) Design dienen (vgl. Abschn. 6.3.4).

Selbstreflexion:

Überlegen Sie, welche Erfordernisse und Nutzungsanforderungen sich aus dem folgenden Beispiel ableiten ließen.

Herr Muster fährt regelmäßig mit der Straßenbahn zur Arbeit. Obwohl er die benötigte Zeit von seiner Wohnungstür bis zur Haltestelle exakt kennt, verpasst er aufgrund von Unregelmäßigkeiten im Fahrplan häufig seine gewählte Verbindung. Über Verspätungen und Zugausfälle wird er im Regelfall erst direkt an der Haltestelle informiert Das führt dazu, dass Herr Muster häufig mehrere Minuten an der Haltestelle warten muss und deshalb regelmäßig mit 30 Min. Puffer aus dem Haus geht, um nicht zu spät zur Arbeit zu kommen. (…)

6.4.2 User Experience

User Experience (Design) wird häufig im Zusammenhang mit „Usability“ und „User Interface Design“ genannt und fälschlicherweise teils auch synonym verwendet. Jedoch handelt es sich hierbei um Teilbereiche, die zu einer (positiven) User Experience beitragen und den Interaktionsraum definieren. Rogers, Sharp & Preece (Rogers et al. 2002) definieren UX wie folgt: “User experience goals differ from the more objective usability goals in that they are concerned with how users experience an interactive product from their perspective rather than assessing how useful or productive a system is from its own perspective”. Diese Definition steht im Einklang mit Donald Norman (Norman et al. 1995), der die Gestaltungsansätze und Nutzer:innenforschung rund um diesen Begriff über die Jahrzehnte stark geprägt hat.

„User Experience“, im Deutschen auch Nutzer:innenerlebnis genannt, beschreibt im Regelfall den Ansatz, bei der Gestaltung von Services und Produkten neben der pragmatischen auch die hedonischen Qualitäten mit einzubeziehen und das Produkt als Konstrukt aus Artefakt und Nutzungserlebnis zu betrachten (Hassenzahl et al. 2003, 2010). Die pragmatischen Qualitäten lassen sich in Nützlichkeit und Gebrauchstauglichkeit sowie intuitive Handhabung zusammenfassen. Im Gegensatz dazu schaffen hedonische Qualitäten die Voraussetzungen für eine emotionale Bindung und Begeisterung der Kund:innen und Nutzenden, die im Einklang mit der Marke des Herstellers steht. Donald Norman als einer der Begründer des User-Experience-Designs beschreibt das Ziel folgendermaßen: „Kein Produkt ist eine Insel. Ein Produkt ist mehr als nur ein Produkt. Es ist ein zusammenhängendes, integriertes Paket von Erfahrungen. Denken Sie alle Phasen eines Produkts oder einer Dienstleistung durch – von den ersten Absichten bis zur abschließenden Reflexion, von der ersten Nutzung bis zu Hilfe, Service und Wartung. Sorgen Sie dafür, dass sie alle nahtlos zusammenarbeiten. Das ist Systemdenken“ (Norman 2009). Der Konsum digitaler Produkte und Services ruft bei jeder Nutzung ein Erlebnis hervor, das durch die Umgebung und alle Beteiligten kontextualisiert wird. Dadurch wird bestimmt, wie häufig und mit welcher Akzeptanz dieses Produkt in Zukunft genutzt wird und ob es ein beständiger Begleiter des Alltags wird. Bei negativer Erfahrung kann es zu einer Nicht-Nutzung und Ablehnung des Produkts kommen (Walsh et al. 2014). Subjektive Erfahrungen spielen eine tragende Rolle bei der Beurteilung des Produkts. Sie können meist auf unterschiedliche Bedürfnisse, Fähigkeiten und Kompetenzen in Verbindung mit dem Produkt zurückgeführt werden (Schrepp et al. 2014).

Obwohl Designer:innen das Erlebnis mit dem Produkt nicht kontrollieren können, können sie über die Ausgestaltung der Produktmerkmale wie Inhalt, Präsentationsstil, Funktionalität und Interaktionsstil eine Nutzungserfahrung gestalten und somit letztlich Einfluss auf das zukünftige Produkterlebnis nehmen (Hassenzahl 2018). Zum Beispiel zeigt eine Studie die Auswirkungen von Tönen und Musik auf das Nutzungserlebnis mit einem Sprachassistenten (Esau-Held et al. 2023).

In Bezug auf Verbraucher:innen betrachten wir häufig die Nutzung eines Services oder Produkts im Kontext der Customer Journey oder Consumption Journey. Dies bedeutet, dass das Produkt nicht nur ein einziges Erlebnis umfasst, wie zum Beispiel nur den Kauf über eine Website, sondern in eine ganze Reihe von miteinander verbundenen Berührungspunkten mit einem Unternehmen oder Produkt und damit verknüpften Erlebnissen und Tätigkeiten eingebettet ist. Dementsprechend ist die UX ein Teil einer ganzen Customer Experience (CX) (Gilmore et al. 2002). Jedes Mal, wenn Verbraucher:innen mit einer Marke oder einem Unternehmen interagieren, ist daran eine Erwartungshaltung und somit ein Erlebnis geknüpft, die bzw. das konsistent und zufriedenstellend sein sollte. Beispielsweise sollten beliebte Funktionen auf der Webseite eines Supermarkts genauso in der Smartphone-App verfügbar sein und die Interaktionsmechanismen auf denselben Prinzipien beruhen. Zusätzlich sollte sich der Markenauftritt auch im Prospekt widerspiegeln. In Unternehmen werden zur Beurteilung bereits unterschiedliche Messungen herangezogen, wie beispielsweise die Abfrage, ob der:die Kund:in als Ausdruck seiner:ihrer (Un-)Zufriedenheit das Produkt weiterempfehlen würde. Wichtig ist hierbei zu unterscheiden, dass – obwohl die Webseite eine großartige UX bieten und die Conversion Rate hoch sein mag – gleichzeitig die CX innerhalb des ganzen Unternehmens, also eine pünktliche Lieferung, einfaches Retourenmanagement etc. fehlschlagen kann. Deshalb sollte die UX stets im großen Kontext einer umfassenden Journey betrachtet werden und nicht als Einzelerlebnis.

Neben subjektiven Produkt- und Dienstleistungserlebnissen spielen soziale Bedeutungssysteme für die Gestaltung von Technologien und ihren Schnittstellen eine ebenso große Rolle. In Kap. 2 wurde der Zusammenhang zwischen sozialer Praxis und Konsum erläutert, um ein umfassendes Verständnis für die Motivation und Nutzung von digitalen Produkten zu schaffen und deren wechselseitigen Einfluss auf unser Verhalten darzulegen. In diesem Kapitel wiederholen wir einige der Kernpunkte der Praxeologie und betrachten diese unter dem Aspekt der Gestaltung und der Rolle der Designer:innen.

6.5.1 Soziale Praktiken und Interaktion als Designmaterial

Wie in Abschn. 6.3.2 beschrieben, ist Design Thinking (Kimbell 2011) ein verbreiteter Gestaltungsansatz, um digitale Lösungen in Produkt- oder Serviceform zu entwickeln. Allerdings wird in der Designforschung auf die erheblichen Schwachpunkte eines solchen Vorgehens aufmerksam gemacht: Kimbell kritisiert zum Beispiel, dass das Verständnis von Design Thinking in Bezug auf das, was Designer:innen denken und tun, eine mehrdeutige, übergeneralisierte, kontextlose und teilweise widersprüchliche Perspektive ist (Kimbell und Street 2009; Kimbell 2011). Insbesondere wird die individuelle Leistung der Designer:innen überbetont. Das alleinige Zuschreiben der Designleistung an Designer:innen entspricht aber laut Kimbell nicht der Realität, da auch Gestaltung eine soziale Praxis ist, in der Kontext, Artefakte und verteilte Anstrengungen von Designer:innen und den Stakeholder:innen ihrer Produkte involviert sind (z. B. (Schön 1988; Bucciarelli und Bucciarelli 1994)). Aus Sicht von Kimbell endet Design folglich nicht mit der Schaffung eines Produkts, sondern umfasst auch dessen Aneignung und Verwendung durch Nutzer:innen in Alltagssituationen (Kimbell und Street 2009; Kimbell 2011).

Entsprechend kann die Theorie der sozialen Praxis als Linse zur Einordnung und Beschreibung von Gestaltungsaktivitäten und Ergebnissen genutzt werden, um ein allumfassenderes Verständnis von Herausforderungen, Kontext und daraus abgeleiteten notwendigen Designaktivitäten zu erlangen. Unter der Linse der sozialen Praktik (oder Praxeologie) sind Praktiken „die alltäglichen Aktivitäten, die den größten Teil dessen ausmachen, was die Menschen in ihrem täglichen Leben tun“ (Kuijer et al. 2013). Shove et al. legen ein Rahmenwerk vor, das auf den drei Elementen Materialien, Kompetenzen und Bedeutungen basiert (Shove et al. 2012):

• Materialien beschreiben alle Artefakte, die zur Durchführung einer Praktik benötigt werden. Diese Definition schließt auch Infrastrukturen (z. B. Stromnetzwerk, Straßen), Objekte, Werkzeuge, Hardware und den eigenen menschlichen Körper mit ein.

• Kompetenzen beschreiben die unterschiedlichen Aspekte praktischen Wissens und damit einhergehendes Verständnis. Neben explizitem Wissen, das sehr einfach verschriftlicht und weitergegeben werden kann, umfassen Kompetenzen auch implizites Wissen – also solches, das z. B. durch Erfahrung und Intuition entsteht.

• Bedeutungen beschreiben geistige Aktivitäten, Emotionen und Motivationen, die mit einem in einer Praktik enthaltenen Material oder der Praktik selbst verknüpft sind.

Basierend auf diesem Rahmenwerk kann auch die Einbettung eines Produkts oder Services in einer sozialen Praxis aufgezeigt werden, die über die eigentliche Nutzung hinausgeht. Dadurch wird ersichtlich, welche weiteren Nutzer:innen, Praktiken, Materialien, Bedeutungen und Kompetenzen mit der Ausgangspraktik verknüpft sind. HCI-Studien verwenden Praxeologie häufig als Linse zur Analyse von Praktiken und zur Gestaltung von praktikunterstützenden oder -verändernden Benutzerschnittstellen und Produkten, wie z. B. im Kontext von Nachhaltigkeit und Konsum (Lawo 2023; Shove 2003; Kuijer et al. 2013; Spurling et al. 2013). Die Gestaltung der Technologien hängt entsprechend maßgeblich von der Ausgangspraktik und dem Veränderungswunsch der betroffenen Stakeholder ab.

6.5.2 Participatory Design – soziale Partizipation als Designer:in

Participatory Design oder partizipatives Design (PD) fußt auf der aktiven und gleichberechtigten Beteiligung der betroffenen Menschen oder Nutzer:innengruppe an der Gestaltung der (Arbeits-)Praktik. Damit wird ein starker demokratischer Prozess verbunden, der die Einbindung der späteren Anwender:innen und Betroffenen schon früh in die soziale und technologische Ausgestaltung von Systemen und deren Interaktionsdesign vorsieht (Muller 1991). Die Idee, Nutzer:innen überhaupt einzubinden, steht stark im Zusammenhang mit der Entwicklung der „Work Activity Theory“ (Bodker 2021; Ehn 1988). Diese hat ihre Ursprünge in Russland und Deutschland und ist eng mit der Strömung des demokratischen Prozesses in Skandinavien 1970 verwandt. In den frühen 1990er-Jahren wurden diese Ansätze adaptiert und in der HCI etabliert. Zu einem der bekanntesten PD-Ansätze zählt Mullers Arbeit (Muller 1991). Eine weitere Strömung, die diesen Designansatz geprägt hat, kam aus den USA, wo die pragmatische und ökonomische Perspektive verfolgt wurde, dass PD nicht nur zu einem besseren Produkt führen, sondern auch die Arbeitsprozesse innerhalb von Unternehmen dauerhaft verbessern können sollte.

In Kombination mit unterschiedlichen Kreativitätstechniken stellt PD die Ideen der Nutzer:innen in den Mittelpunkt für Innovation, woraus sich die „User-driven Innovation“ über die Zeit herausgebildet hat. Die Hinzunahme von Methoden und Strukturierung des Vorgehens richtet sich nach dem spezifischen Projekt.

Das Besondere an diesem Ansatz ist die unmittelbare Nähe zu sozialen Praktiken und die bewusste Vermischung der Rollen von Nutzer:innen und Designer:innen. Dabei gibt es unterschiedliche Grade und Regeln bei der Einbindung dieser beiden Gruppen. Beispielsweise bezeichnete Mumford (Mumford 1981) den Ansatz, die Ideen, Anmerkungen und Inhalte von Nutzer:innen nur in Betracht zu ziehen, sie aber nicht als elementaren Bestandteil einer Lösung zu verwenden, als „Consultative Design“. Im Gegensatz dazu sieht Mumford das „Consensus Design“, das Nutzer:innen die volle Bestimmungsgewalt zuschreibt, bei dem jedoch auch die Verantwortung für das finale Ergebnis geteilt wird. Diese Kategorisierung ist mit wesentlichen Fragen verbunden, nämlich:

1. 1.

   Wer bekommt die Entscheidungskompetenz: Designer:innen oder Nutzer:innen?

2. 2.

   An welcher Stelle ist Raum für Spontaneität, Iteration und Nutzer:innenbeteiligung?

3. 3.

   Wie bereitwillig und intensiv möchten sich Nutzer:innen am Gestaltungsprozess beteiligen?

In der Umsetzung von PD können diese Fragen projektspezifisch beantwortet und als Prozessbestandteile integriert werden, in denen Überlegungen zu Arbeitsteilung, Gruppengrößen und zeitlicher Einbindung vorangestellt werden. Weitere Kritik an diesem Ansatz behandelt die Frage, wie viel Wissen benötigt wird, um qualifiziert und effektiv an so einem Prozess teilnehmen zu können. Weiterhin werden diese Perspektiven in Unternehmen häufig durch Schnittstellenpersonen ersetzt, die den Nutzer:innen möglichst nahestehen, jedoch ihre eigene Ansicht mitbringen, was nicht mit echter diverser Nutzer:innenbeteiligung gleichgesetzt werden sollte. Dies ist dem häufigen Produktionsdruck und den knappen Budgets im operativen Geschäft geschuldet. Abgesehen davon stellt sich die Frage, welche Rolle und welchen Raum zudem die Entwickler:innenperspektive einnimmt, die zusätzliche Anforderungen und Grenzen mit sich bringt. Abschließend sollte ebenfalls in Betracht gezogen werden, ob das vorliegende Problem überhaupt einer technologischen Lösung bedarf, und ob die Ursache eventuell gar nicht durch digitale Systeme behoben werden kann. PD zielt jedoch meistens auf eine technologiezentrierte Lösung und Gestaltung.

Die Demokratisierung von Innovation

Die Ursprünge von Participatory Design wurden in den 1970er-Jahren durch Skandinavien stark vorangetrieben und sind mit einem gewerkschaftlichen Hintergrund verknüpft, der die Demokratisierung des Arbeitsplatzes durch aktive Einbindung der Arbeiterklasse in die Gestaltung von Technologie im Arbeitskontext eingefordert hat (Clement und Van den Besselaar 1993; Bannon et al. 2018): Existierende Arbeiterunionen hatten nur wenig Erfahrung mit Informationstechnologie und Automatisierung und wurden förmlich dazu gezwungen, IT-Systeme zu akzeptieren, die durch Manager entwickelt und eingeführt wurden (Spinuzzi 2005). Das führte zum einen zu einem starken Einschnitt in bestehende Arbeitsprozesse und Gewohnheiten, zum anderen aber auch zu Kontroll- und Autonomieverlust der Arbeitenden, Kündigungen und Arbeitslosigkeit durch fortschreitende Automatisierung (Spinuzzi 2005). Um dies zu verhindern und Softwareentwickler:innen und Arbeiter:innen die gemeinsame Entwicklung von IT-Systemen zu ermöglichen, entwickelten skandinavische Forscher:innen basierend auf der Work Activity Theory (Bodker 2021; Ehn 1988) und Action Research den PD-Ansatz (Spinuzzi 2005). Dieser erlaubte den Arbeitenden als Designer:innen aktiv am Gestaltungsprozess teilzunehmen und das Endprodukt so zu formen, dass nicht nur ihre Fähigkeiten Wertschätzung erhielten, sondern auch die Vorteile von Automatisierung und IT im Arbeitsalltag ausgenutzt werden konnten (Von Hippel 2005).

Im Lauf der Zeit gewannen IT-Systeme jedoch auch außerhalb des Arbeitskontextes immer mehr an Bedeutung und sind heute aus unserer Gesellschaft kaum mehr wegzudenken. Mit der fortschreitenden Digitalisierung unseres Alltags nimmt auch nutzergetriebene Innovation zu (Von Hippel 2005). Von Hippel führt dies auf zwei grundlegende Entwicklungen zurück: Zum einen erhöht die stetige Verbesserung von Computer-Hard- und Software und ihre einfacher werdende Handhabung das Innovationspotenzial für Nutzer:innen. Zum anderen erleichtert das Internet als wichtiger Kommunikationskanal den Austausch und die Kombination eigener Produktideen oder Personalisierungen existierender Produkte mit denen anderer (Von Hippel 2005). Die für Innovation benötigten Mittel werden also für Nutzende zugänglicher – allerdings, so Bjorgvinsson et al., nur für „eine kleine Elite von Lead-Usern oder Domänenexperten, die vom verbesserten Zugang zu Informationen und Produktionsmöglichkeiten profitieren“ (Björgvinsson et al. 2010).

Die Rolle des Designers kann also – je nach Kontext – einen Wandel erfahren. Während in industriegetriebenen Innovations- und Entwicklungsprozessen trotz nutzerzentrierter Gestaltungsansätze häufig Designexpert:innen Entscheidungsträger und so für die Ausgestaltung und Entwicklung von Produkten verantwortlich sind, übernehmen in nutzergetriebenen Innovationsprozessen Endanwender:innen selbst diese Rolle.

Selbstreflexion:

Warum kann die Rolle des:der Designer:in gravierende Auswirkungen auf die Produktqualität aus Nutzer:innensicht haben? Welche speziellen Herausforderungen versucht Participatory Design in diesem Kontext zu lösen?

Mittlerweile ist Usability Engineering als Gestaltungsansatz in Unternehmen stark verbreitet. Der Schwerpunkt liegt auf der Design-Synthese durch Integration von bereits bekannten und bewährten Lösungen. Im Gegensatz dazu existieren aber auch explorative Designansätze. Diese dienen zum Beispiel zur:

• Identifizierung und Erfüllung von bisher unbekannten oder ungelösten Kund:innen- und Nutzer:innenbedarfen

• Ergründung technologischer Grenzen

• Identifizierung neuer Einsatzmöglichkeiten von (nicht etablierter) Technologie in (nicht etablierten) Anwendungskontexten:

  • bekannte Technologie in einem neuen Anwendungskontext

  • neu entstehende Technologie in einem bekannten Anwendungskontext

  • neu entstehende Technologie in einem neuen Anwendungskontext

Explorative Designansätze befassen sich also großteilig mit dem Unbekannten. Häufig wenden sie sich deshalb auch von etablierten Interaktions- und Darstellungsmodalitäten ab, weshalb die aus dem WIMP-Kontext bekannten Designansätze und -werkzeuge oft nicht gut oder ausreichend gut funktionieren. So folgt die Gestaltung eines Skills für einen Sprachassistenten zum Beispiel anderen Regeln als die Gestaltung einer Smartphone-App – allein durch die Abwesenheit visueller Darstellungen. Solche Technologien werden häufig auch als Post-WIMP bezeichnet, also Benutzerschnittstellen, die nicht mehr oder nicht ausschließlich auf den Modalitäten für Windows, Icons, Menus, und Pointern aufbauen, die wir von der Interaktion mit Computern und Smartphones kennen. Diese Art von Systemen können auch gänzlich unsichtbar sein, wie zum Beispiel ein vollautomatisiertes und sensorisch gesteuertes Smart Home, das nur über Beleuchtung und Raumtemperatur mit dem:der Nutzer:in interagiert. In diesem Zusammenhang werden auch häufig Augmented-Reality- (AR-) und Virtual-Reality- (VR-) Anwendungen genannt, da diese zumindest theoretisch nahtlos in den uns umgebenden (physischen) dreidimensionalen Raum integriert und zum Beispiel durch Gesten, Näherung und Sprache gesteuert werden – oder aber auch durch geschickte Platzierung von Inhalten oder anderen Aktionen den:die Nutzer:in selbst steuern können.

Da explorative Designansätze oft (aber nicht ausschließlich) technologiegetrieben sind, besteht die Gefahr, dass Nutzer:innen und deren Bedürfnisse durch die Begeisterung für die Technologie an sich selbiger untergeordnet werden. Das kann im Falle einer Technikdemonstration sogar notwendig sein, widerspricht aber den Grundsätzen des nutzer:innenzentrierten Designs und ist daher für eine tatsächliche Produktentwicklung oft nicht erstrebenswert.

Aufgrund der vielen Unbekannten in explorativen Designansätzen und der schwer abschätzbaren Folgen von nicht-etablierter Technologie ist es wichtig, auch die Auswirkung eines Designs jenseits der tatsächlichen Interaktion und der Interagierenden zu betrachten (Krauß et al. 2023). Gerade die letzten Jahrzehnte haben gezeigt, dass der Einsatz von Technologie schnell ungewollte und unvorhersehbare Folgen herbeiführen kann und immer häufiger auch mehr oder weniger unbeteiligte Dritte (Bystanders) oder gar die Gesellschaft an sich in Systemdesign mit einbezogen werden müssen.

Jedoch sind diese Designansätze nicht auf die Exploration von Problemen beschränkt, sondern dienen auch der tatsächlichen Umsetzung von real erhältlichen Produkten. Man muss sich also auch die Frage stellen, ab wann sich ein Designartefakt durch die Adaptation und Integration durch Nutzer:innen in ihren Alltag der Kontrolle des Designers entzieht (Kimbell und Street 2009; Kimbell 2011) – und wer im Falle eines unvorhergesehenen negativen Ereignisses die Verantwortung trägt (siehe Kap. 5).

Im Folgenden gehen wir näher auf die Umsetzung explorativer Designansätze ein, um die Inhalte dieses Kapitels nochmals aus praktischer Sicht aufzuarbeiten und darzustellen. Die gewählten Design Case Studies im nächsten Abschnitt behandeln die Gestaltung einer Mixed-Reality-Anwendung und eines Sprachassistenzsystems als Technologien, die in den letzten Jahren stark in den Fokus von Unternehmen und Wissenschaft gerückt sind.

6.6.1 Design Case Study I – Technologiegetriebene Entwicklung einer Trainingssoftware im medizinischen Umfeld

Die Fallstudie SmartZSVA (Krauß et al. 2019; Krauß und Uzun 2020) zeigt ein Beispiel für einen technologiegetriebenen Designansatz, der sich bestmöglich an der nutzer:innenzentrierten Anwendungsgestaltung orientiert. Das dreijährige Projekt umfasste neben der Entwicklung von Einsatzmöglichkeiten von Smartglasses und Mixed-Reality-(MR-)Brillen im Kontext der zentralen Sterilgutversorgungsabteilung ZSVA (jetzt Aufbereitungseinheit für Medizinprodukte – AEMP) in Krankenhäusern auch die prototypische Entwicklung einer MR-Applikation zur Unterstützung unerfahrener Mitarbeiter:innen. Dabei wurden zahlreiche Methoden verwendet, zum Beispiel teilnehmende Beobachtungsstudien, semistrukturierte Interviews, Fokusgruppen, Storyboarding, Paper Prototyping, Wizard-of-Oz, Expertenevaluation, die Think-Aloud-Methode und genormte Usability- und UX-Fragebögen.

6.6.1.1 Vorgehensweise mit dem Gestaltungsziel abstimmen

Realweltliche Problemstellung: Die AEMP ist durch ihre zentrale und wichtige Rolle in der Gesundheitsversorgung sowie deren Berührungspunkte mit potenziell infektiösen und scharfen/spitzen Geräten eine Abteilung, die durch Arbeits- und Infektionsschutz stark reguliert ist. Durch Ermangelung digitalisierter und integrierter Prozesse in der AEMP und fehlenden Schnittstellen mit anderen organisatorischen Einheiten in Krankenhäusern (zum Beispiel der Lagerhaltung medizinischer Produkte und der OP-Planungsprozesse) stehen Mitarbeitende häufig vor organisatorischen und exekutiven Herausforderungen in ihrer täglichen Arbeit. Außerdem erfordert die Vielzahl an Aufgaben und Objekten, die Mitarbeitende zerlegen, reinigen, zusammensetzen, verpacken und sterilisieren müssen, ein hohes Maß an Konzentration: Viele Geräte, zum Beispiel Klemmen und Scheren, unterscheiden sich optisch kaum, verfügen aber über einen anderen Einsatzbereich. Ein Vertauschen dieser Werkzeuge könnte fatale Auswirkungen im Operationssaal haben, weshalb viele Arbeitsprozesse penible Dokumentationsarbeit und das strenge Einhalten von Vorschriften und Arbeitsabläufen verlangen. Andere, vergleichbare Einsatzszenarien (z. B. Logistik) haben gezeigt, dass Technologie wie MR und Smartglasses in solchen Kontexten gewinnbringend für die Unterstützung der Mitarbeitenden eingesetzt werden können.

Gestaltungsziel: Mit der fortschreitenden technologischen Entwicklung sogenannter Mixed-Reality-Headsets wird auch deren industrieller Einsatz interessanter. Diese Technologie bietet gerade im Vergleich zu herkömmlichen Desktopanwendungen viele Vorteile – zum Beispiel die In-situ-Anzeige von Informationen als digitale Überlagerung der physischen Umgebung im dreidimensionalen Raum sowie die Möglichkeit der Freihandinteraktion und -steuerung von Anwendungen durch Näherung, Spracheingabe und Eyetracking. Die AEMP stellt jedoch durch die hohe Wärme, Feuchtigkeit und Lärmbelastung sowie die generelle Sensitivität dieser Abteilung durch die Handhabung von (potenziell) infektiösen, spitzen und scharfen Werkzeugen sowie der nur langsam fortschreitenden Digitalisierung von Arbeitsprozessen eine besondere Herausforderung dar. Im Rahmen des Projekts sollen daher nicht nur lohnende Einsatzszenarien und dafür notwendige technische Schnittstellen erarbeitet, sondern der Mehrwert von MR in selbigen auch durch eine Beispielanwendung demonstriert werden.

Designansatz: Das Projekt stand vor zwei großen Herausforderungen: Erstens waren zu Beginn des Projekts dem Designteam sowohl die Arbeitsabläufe als auch die Rollen, Verantwortlichkeiten und deren Herausforderungen in der AEMP nicht ausreichend bekannt. Zudem ist die AEMP eine äußerst wichtige und sensible Einrichtung in Krankenhäusern oder bei externen Dienstleistern und verlangt dementsprechend ( z. B. hohe Hygienestandards, unbequeme, laute, feuchte und warme Arbeitsumgebung) sehr robuste Hard- und Software. Zusätzlich bestand der Anspruch für die Mitarbeitenden und Stakeholder, ein Produkt bzw. einen Demonstrator mit einem tatsächlichen Mehrwert zu entwickeln, der über eine rein technische Demonstration hinausging.

Zweitens war die einzusetzende Post-WIMP-Technologie – MR-Headsets – gerade erst am Anfang ihrer Massentauglichkeit. Entsprechend gab es nur wenige Anhaltspunkte, Designwerkzeuge und Guidelines, die bei der Gestaltung und Umsetzung einer MR-Anwendung hätten unterstützen können. Zu diesem Zeitpunkt wies die Hardware noch viele ergonomische Schwachpunkte auf und war sehr anfällig für Störungen durch äußere Einflüsse. Daher war es sehr schwer, negative Einflüsse der Hardware auf die Erfahrung unserer Nutzenden mit der prototypischen Softwareanwendung herauszufiltern und entsprechend zu bewerten. Zudem folgten die grafischen Darstellungsmöglichkeiten und Elemente der verwendeten Hololens1 noch stark dem WIMP-Paradigma. So wurden zum Beispiel die Funktionalität einer Maus („point and click“) auf die Blickrichtung und eine bestätigende Fingergeste abgebildet.

Folglich haben wir uns für einen nutzer:innenzentrierten Gestaltungsprozess nach der ISO Norm 9241:210 entschieden. Zum einen räumt dieser Gestaltungsansatz ausreichend Raum für die Kontextanalyse ein und ermöglicht durch schnelles und iteratives Prototyping die kostengünstige Entwicklung, Erprobung, und Weiterentwicklung von Designideen. Zum anderen eignet sich der Designprozess durch seine Normung sehr gut in sensiblen und industriellen Anwendungsfeldern.

6.6.1.2 Designprozess spezifizieren und Methoden anwenden

Zur Erhebung relevanter Anwendungsfelder wurden fünf unterschiedliche AEMP in deutschen Krankenhäusern und von Dienstleistern in das Gesamtprojekt eingebunden. Da das genaue Einsatzszenario für die Demoanwendung nicht klar war, begannen wir mit einer eingehenden Kontextanalyse in Form von teilnehmenden Beobachtungsstudien in allen Einrichtungen, verbunden mit Interviews unterschiedlicher Stakeholder, von den Angestellten bis hin zum:zur Abteilungsleiter:in der AEMP oder dem:der Geschäftsführer:in des externen Dienstleisters sowie dem Softwarezulieferer der eingesetzten AEMP-Software. Zusätzlich führten wir mit Führungskräften einen Brillen-Experience-Workshop durch, um die Technologie anhand von vorläufig identifizierten Einsatzszenarien und unterschiedlicher Hardware vorzustellen, die selbige zu evaluieren sowie Schwächen, Stärken und Herausforderungen zu erarbeiten.

Aus diesen Bemühungen ergaben sich acht Anwendungsfälle: 1) Lagerhaltung, 2) Schulung sowie dafür benötigte Inhalte und Abläufe, 3) das Packen von medizinischen Werkzeugen und Sets, 4) Fernunterstützung, 5) Nachverfolgung und ortsungebundene Anzeige von Informationen von Sets und medizinischen Werkzeugen, 6) Dokumentation von Routinekontrollen von Geräten und Prozessen, 7) das Zerlegen, das Aufstecken (auf die Reinigungsvorrichtungen) und das Wiederzusammensetzen medizinischer Werkzeuge nach der Reinigung sowie 8) die Anzeige von durch Geräte oder Priorisierung hervorgerufenen Warnungen und Statusbenachrichtigungen.

Diese Anwendungsfälle wurden dann in Gesprächen mit Führungskräften und Domänenexpert:innen anhand von deren Mehrwert und potenzieller positiver Auswirkung auf den Arbeitsalltag in der AEMP bewertet und priorisiert. Die resultierenden drei Anwendungsfälle mit dem höchsten zu erwartenden Mehrwert, nämlich Lagerhaltung, Schulung und dafür benötigte Inhalte und Abläufe, sowie das Packen von medizinischen Werkzeugen und Sets, wurden dann prototypisch in der Demonstratoranwendung umgesetzt. Hierfür wurden neben Prozessdarstellungen in Form von Ablaufdiagrammen auch Storyboards (siehe Abb. 6.5) eingesetzt, die bereits eine mögliche Implementierung gezeigt haben.

Beispiel für ein Storyboard für den Prozessschritt des Packens von medizinischen Werkzeugen in ein Trägersieb. (Quelle: Fraunhofer FIT; all rights reserved)

Full size image

Als Vorbereitung auf die schrittweise Implementierung der Beispielanwendung nach der agilen Scrum-Methode wurden beobachtete Prozessabläufe und entsprechende Herausforderungen in Nutzer:innenanforderungen übersetzt und in Form von User Stories festgehalten. Diese User Stories wurden dann erneut nach den Prinzipien eines MVP priorisiert und implementiert. Auch erste notwendige Interaktionsmodalitäten konnten wir so erarbeiten, wie zum Beispiel, die Anwendung ohne den Einsatz der Hände bedienen zu können. Stattdessen wurden eine näherungsbasierte Interaktion und Steuerung über einen Fußschalter in Betracht gezogen. Andere Interaktionen folgten stark dem WIMP-Paradigma, besonders grafische Elemente, die in Fenstern dargestellt wurden und in Form von Buttons und Icons auf mögliche Interaktionen hinwiesen.

Aufgrund der schweren Erreichbarkeit der tatsächlichen Anwender:innen stützten wir unser iteratives Vorgehen hauptsächlich auf das Feedback von Domänenexpert:innen und AEMP-Führungskräften mit Personalverantwortung. Erst im letzten Schritt der Prototypvertestung wurde unser Prototyp in zwei unterschiedlichen AEMPs mit insgesamt 12 Mitarbeitenden getestet und bewertet.

Während die generelle technische Demonstration sehr gut funktionierte und auch die ausgewählten Anwendungsfälle durch die Mitarbeitenden positiv bewertet wurden, deckten diese auch einige Schwachstellen auf. Zum Beispiel äußerten unsere Studienteilnehmer:innen Bedenken in Bezug auf Autonomieverlust und damit einhergehenden Verlust von Anerkennung im sozialen Gefüge der medizinischen Einrichtung. Zudem wurde auch die Befürchtung geäußert, dass Vorgesetzte durch diese Technologie und die Art der Anwendung eine größere Kontrolle über Mitarbeitende erlangen und diese gegebenenfalls sozial isoliert werden könnten.

Dieses Feedback war wertvoll, um sich mit der negativen, unvorhergesehenen Auswirkung neuer Technologien im sozialen Umfeld zu befassen und deren Einsatz kritisch zu reflektieren.

6.6.2 Design Case Study II – Practice-based Prototyping für Sprachassistenzsysteme

Anhand dieser Fallstudie (Esau et al. 2022b) möchten wir praxisbasiertes Design näher erläutern und aufzeigen, wie dieses zu einer nutzer:innenzentrierten Gestaltung eines interaktiven Sprachassistenten beigetragen hat. Hierfür werden die verwendeten Methoden wie Contextual Inquiry, Experteninterviews, Rollenspiele, Wizard-of-Oz und Videoprototyping vorgestellt und im Kontext der Gestaltung für Sprachinteraktion beschrieben.

6.6.2.1 Vorgehensweise mit dem Gestaltungsziel abstimmen

Realweltliche Problemstellung: Viele unterschiedliche Versuche, Lebensmittelverschwendung zu vermeiden und einen bewussten Umgang mit Lebensmitteln zu fördern, scheitern. Trotz Aufklärungskampagnen oder Nudging fällt es Haushalten und deren Mitgliedern schwer, die Genießbarkeit von Lebensmitteln richtig einzuschätzen. Aus der Forschung wissen wir, dass Informationen allein nicht ausreichen, um eine dauerhafte Verhaltensänderung hervorzurufen. Ein großer Unsicherheitsfaktor bei Lebensmittelverschwendung ist die eigene Fähigkeit, Lebensmittel richtig einzuschätzen und im Entscheidungsmoment das Wissen parat zu haben.

Gestaltungsziel: In den letzten Jahren konnten wir eine zunehmende Nutzung von Sprachassistenten wie zum Beispiel Amazons Alexa beobachten (Porcheron et al. 2017a; Graesser et al. 2017; Provoost et al. 2017; Vtyurina und Fourney 2018; Murad und Munteanu 2019). Diese werden besonders häufig in der Küche aufgestellt und verwendet. Ihre Fähigkeit, überall aus dem Raum ansprechbar zu sein, Wissen schnell und gezielt abzurufen und mittels Sprachausgabe verfügbar zu machen, macht diese Technologie zu einem potenziellen Teil der Lösung (Vtyurina und Fourney 2018). Sie bieten nämlich die Möglichkeit, die „Kompetenz zum Handeln“ (Gherardi 2008) der Menschen zu verbessern und so einen bewussten Umgang mit Lebensmittelressourcen zu fördern. Zusammengefasst soll ein interaktiver und sprachbasierter Guide entwickelt werden, der in Kollaboration mit dem Menschen durch Wissen und Anweisungen zu einer eigenen Erkenntnis und Entscheidung führt.

Designansatz: Aus diesen Überlegungen heraus haben wir uns am Prozess des Design Thinking orientiert und verfolgen einen Ansatz, der die sozialen (Lebensmittel-)Praktiken der Menschen in den Mittelpunkt stellt. Dies ermöglicht ein genaues Verständnis der Herausforderungen und aktuellen Lösungsansätze der Menschen, um ihnen zielgerichtet zu helfen, und gemäß ihren Ressourcen und Limitationen zu gestalten. Anstatt die Technologie in den Mittelpunkt zu stellen und diese eventuell mit weiteren Sensoren auszustatten, soll der Mensch auch in Zukunft unabhängig von der Technologie Entscheidungen treffen können.

Im Gegensatz zu WIMP-Anwendungen gibt es für die Gestaltung von Sprachassistenten nur wenige Guidelines, die zudem noch nicht durch jahrzehntelange Gestaltung von unterschiedlichen Personen, Firmen und Kulturkreisen validiert worden sind (Clark et al. 2019; Porcheron et al. 2017a; Murad und Munteanu 2019; Simpson 2020). Zusätzlich zeigen Forschungsarbeiten aus den letzten Jahren, dass sehr häufig eine Nicht-Nutzung dieser Technologie eintritt bzw. die Interaktion mit Sprachassistenten auf sehr wenige, limitierte Anwendungsszenarien beschränkt ist. Zum einen lässt sich diese Folge auf die hohen Erwartungen an die Sprache als natürliche Interaktionsmodalität zurückführen (Cho et al. 2019; Porcheron et al. 2017a; Sciuto et al. 2018). Zum anderen bringen gesprochene Sprache als Interaktion und die dazugehörigen Plattformen und Ökosysteme sowohl konzeptionelle als auch technische Herausforderungen mit sich (Esau et al. 2022a). Frühere Forschungen zu Intelligent Personal Assistants (IPAs) und Conversational User Interfaces (CUI) (Porcheron et al. 2017a; Munteanu und Penn 2018; Murad und Munteanu 2019; Sciuto et al. 2018) haben mehrere Probleme aufgedeckt, die eine schnelle Akzeptanz behindern (Cho et al. 2019; Porcheron et al. 2017a; Sciuto et al. 2018), wie z. B. mangelnde Verarbeitung natürlicher Sprache (Grudin und Jacques 2019; Luger und Sellen 2016; Myers et al. 2018) und ein schwerwiegender Mangel an Benutzerfreundlichkeit, z. B. Kontrollverlust, fehlendes Feedback, begrenzte Auffindbarkeit u. a. (Burmester et al. 2019; Murad und Munteanu 2019; Myers et al. 2018; Porcheron et al. 2017b). Sprachbasierte User Interfaces bringen gegenüber visuell-zentrierten WIMP-Anwendungen gewisse Limitationen mit sich, die sich durch die aktuelle Umsetzung der Technologie nicht ausgleichen lassen. Zum Beispiel passen aktuelle mentale Modelle der Nutzenden, die sie aufgrund ihrer Erlebnisse in der Interaktion mit Webseiten oder Apps gesammelt haben, nicht zur Umsetzung von sprachbasierten Anwendungen und erfordern bei der Gestaltung einen Voice-first-Ansatz (Esau et al. 2022a). Daher müssen wir diese Erkenntnisse in unseren Designprozess einfließen lassen und entsprechend die Methodik auswählen. Beim Auftreten von Problemen während des spezifischen Designverlaufs sollte mit diesen offen umgegangen und entsprechend vom Plan abgewichen werden, indem Anpassungen iterativ und situationsbedingt vorgenommen werden.

6.6.2.2 Designprozess spezifizieren und Methoden anwenden

Anhand der Problemstellung und Gestaltungsidee haben wir uns für eine Vorgehensweise (siehe Abb. 6.6) entschieden, die sich zunächst intensiv mit den Bedürfnissen und aktuellen Praktiken der Nutzer:innen auseinandersetzt (1). Im nächsten Schritt fließen die erhobenen Daten in ein konzeptionelles Modell, das die Blaupause für das anstehende Prototyping (3) bereitstellt. Im Detail besteht die Prototypingphase aus vier Schritten (3a–d), unter Anwendung der in der Grafik genannten Methoden. Nach der Umsetzung wurde zudem ein Videoprototyp (4) erstellt, der innerhalb einer Interviewreihe (5) evaluiert wurde. Im Folgenden werden die Methoden und Ergebnisse der einzelnen Phasen erläutert.

Iteratives Vorgehen im Gestaltungsprozess des Sprachassistenten nach Ablauf einer Design Case Study (Esau et al. 2023); all rights reserved

Full size image

1. (1)

   Verstehen der Nutzer:innen und Praktiken

   • Umfeld/Zielgruppe private Verbraucher:innen beschreiben

   • dahingehend die Anforderungserhebung aus Nutzersicht

   Dazu haben wir in 15 Haushalten kontextbezogene Untersuchungen durchgeführt und sechs Expert:innen zu ihrer Vorgehensweise bei der Bewertung der Lebensmittelqualität befragt. Wir haben Fisch als Beispiel gewählt, da es sich hierbei um ein besonders sensibles Lebensmittel handelt und für Verbraucher:innen mit den meisten Unsicherheiten verbunden ist. Darüber hinaus haben wir sechs Fischexpert:innen interviewt, um herauszufinden, wie man Verbraucher:innen anleitet und Lebensmittelkompetenz vermitteln kann. Diese Erkenntnisse haben wir in unser Design einfließen lassen. Zur Datenanalyse haben wir unter anderem die drei Elemente der Praktiken (Materialien, Kompetenzen, Bedeutungen) verwendet und das Vorgehen der Expert:innen beobachtet und notiert.

   • Kompetenz: Lebensmittel bewerten und Zustand, Haltbarkeit sowie Risiko des Verzehrs beurteilen zu können, genereller Umgang mit Lebensmitteln entlang des Consumption Lifecycle (Einkaufen, Zubereiten, Lagern, Entsorgen, Planung)

   • Material: Lebensmittel, Küche, Mindesthaltbarkeitsdatum, Küchenwerkzeuge, Nutzung von Medien und Technologien

   • Bedeutung: Genuss, Energie, Gesundheit, Teilhabe

2. (2)

   Konzeptionierung

   • Strukturierung und Einordnung der Ergebnisse anhand der Relevanz für die Gestaltung

   • Entwurf eines ersten Dialogverlaufs mit den wichtigsten Entscheidungspunkten

   • Erste Überlegungen zu Rolle und Verhalten des Assistenten

   An dieser Stelle haben wir Nutzer:innen so weit eingebunden, dass sie maßgeblich an der Ideenentwicklung beteiligt waren. Jedoch hatten wir im Verlauf des Gestaltungsprozesses als Forscher:innen und Designer:innen entschieden, wie die folgenden Ergebnisse interpretiert werden sollen und in das Design des Sprachassistenten einfließen. Dies bedeutet auch, dass wir mit den Risiken verantwortungsvoll umgehen müssen, die aus dem Einsatz eines solchen Systems hervorgehen könnten, wie z. B. eine falsche Entscheidung hinsichtlich der Lebensmittelfrische. Unsere Ergebnisse zeigen, dass Verbraucher:innen motiviert und gewillt sind, ihre Sinne zu nutzen. Allerdings vermissen sie häufig eine entsprechende Anleitung und Unterstützung bei der Interpretation. Daher sollten wir Ratschläge geben, die über die offensichtlichen visuellen Anzeichen von Verderb hinausgehen, und klare, schnell umsetzbare Anweisungen vermitteln, die das Lernen durch Erfahrung und die Zusammenarbeit mit dem Sprachassistenten fördern. Wir müssen die Vorschriften zur Lebensmittelsicherheit im Kontext erklären und Beschreibungen verwenden, welche die graduellen Unterschiede in der Lebensmittelqualität veranschaulichen, wie z. B. „Seetang ähnlich“. Außerdem zeigen unsere Ergebnisse, dass Frische oft negativ beschrieben wird, als eine Abweichung von den Erwartungen, wie etwas aussehen, schmecken und sich anfühlen muss. Der Prototyp sollte jedoch davon absehen, den Verbraucher:innen die Schuld zu geben, wenn sie entgegen der Empfehlung gehandelt haben. Stattdessen müssen wir die Anweisungen und Bewertungskategorien sorgfältig und geduldig so transparent und nachvollziehbar wie möglich erklären:

   • Bestimmung des Dialogverlaufs anhand von im Lebensmittelstandard festgeschriebenen Qualitätsmerkmalen und Vorgehen der Expert:innen

   • Verwendung nutzer:innengerechter Ansprache und Erklärungen

   • Formalisierung und Externalisierung von Wissen durch sensorische Beschreibungen und Kriterien

   • Überlassen der finalen Entscheidung beim Menschen

3. (3)

   Prototyping

   • Anreichern des Dialogverlaufs durch Beispiele mittels Rollenspielen

   • Verfeinern des Dialogs unter Anwendung der Wizard-of-Oz-Methodik

   • Implementierung des Dialogs in Google DialogFlow

   Basierend auf den vorläufigen Ergebnissen unserer Nutzer:innenstudien haben wir einen Sprachassistenten mit dem Namen „Fischer Fritz“ entwickelt und implementiert. Dafür haben wir die möglichen Pfade und Ergebnisse in einem Entscheidungsbaum visualisiert und die Reihenfolge der Abfrage der wichtigsten Merkmale festgelegt. Ziel war es, so viele Fragen wie nötig und so wenige wie möglich zu implementieren. Nutzer:innen sollten effizient zu einer Entscheidung gelangen können und dabei Vertrauen in den Assistenten und ihre eigene Überprüfung der Lebensmittelfrische aufbauen. Hierfür eignen sich Rollenspiele besonders gut. Eine Person übernimmt die Rolle des:der Expert:in und die andere Person die des:der Nutzer:in. Dieses Gespräch wird im besten Falle aufgezeichnet und transkribiert, um gleichzeitig Dialogbeispiele zu sammeln, die als abwechslungsreiche Bausteine im späteren Produkt verwendet werden können. Zudem bietet es sich hier stark an, mit tatsächlichen potenziellen Nutzer:innen zusammenzuarbeiten, um die Validität und Qualität der Empfehlungen und Interaktionsabläufe mit dem Sprachassistenten zu erhöhen. Eine einfache Umsetzung könnte beispielsweise sein, mit den genannten Personen zu telefonieren und Szenen nachzustellen.

   Wizard-of-Oz ist eine Methode, die es bereits seit den 1970er-Jahren gibt, um die Intelligenz von Maschinen zu simulieren, ohne diese vorher entwickeln und implementieren zu müssen. Das bedeutet, dass die Person, welche die Rolle des Assistenten spielt, im Gegensatz zum Rollenspiel nur noch vorgeschriebene Sätze und Dialogbestandteile verwendet. Je nach Reifegrad des Dialogs kann der gespielte Assistent Abweichungen in den Antworten zulassen, damit das Ziel des Dialogs erreicht werden kann. Hiermit bietet die Methode genug Flexibilität, um dem Erkenntnisgewinn für das Verbesserungspotenzial nicht im Wege zu stehen. Der Handlungsspielraum beschränkt sich auf eine Regelsammlung ähnlich zur Programmierung und kann entsprechend den Regeln des Frameworks implementiert werden. Im Allgemeinen spricht man bei Sprachassistenzsystemen von Utterances, Intents und Entities, die durch die vorangegangenen Methoden generiert werden sollten. Hier jeweils ein Beispiel zur Erläuterung:

   • Utterance (Äußerung Sprachassistent): „Kannst du beschreiben, ob das Fischfleisch hell und eher weißlich, blass oder rosafarben oder eher bräunlich, gelblich oder grünlich ist?“.

   • Intent (Absicht der Nutzer:in): BeschreibungFischfleischFrisch

   • Entity (Informationsgruppe): hell, weißlich blass

4. (4)

   Videoprototyp

   • Videoprototyp vermittelt das Verständnis für den Einsatz einer Technologie und die Relevanz für den menschlichen Alltag

   • Ziel der Evaluation war eine konzeptionelle Bewertung

   Schließlich erstellten wir einen szenariobasierten Video-Prototyp, um die Erfahrung und den Ansatz über die Benutzerfreundlichkeit und die detaillierten Funktionen hinaus zu evaluieren. Wir haben Video-Prototyping als gängige Methode in der HCI verwendet, um uns auf die konzeptionelle Bewertung neuartiger Artefakte zu konzentrieren. So wurde es von Diefenbach und Hassenzahl (Diefenbach und Hassenzahl 2017)Provide link vorgeschlagen, um mehrere Erfahrungsebenen wie Interaktion, Funktionalitäten und Emotionen gleichzeitig zu beobachten. Im Gegensatz zu einem Usability Test standen für uns bei dieser Evaluation nicht die unmittelbare Nutzer:innenerfahrung und Interaktionsschwierigkeiten im Vordergrund, sondern die konzeptionelle Frage, ob eine solche Anwendung und Technologie für die Verbraucher:innen relevant sein könnte. Die Aufmerksamkeit wird vielmehr auf die eingebetteten Alltagserfahrungen gelenkt, ohne die Nutzer:innen mit Usability-Problemen oder unausgereiften technischen Aspekten abzulenken (Diefenbach und Hassenzahl 2017; Sproll et al. 2010). Diese Methode ist auch für die Mensch-Agent-Interaktion geeignet (Syrdal et al. 2008; Honig und Oron-Gilad 2020).

5. (5)

   Evaluation

   • Reflexion und Einordung der Ergebnisse

   • Basis für die nächsten Schritte in Gestaltung und Entwicklung

   Während der Evaluation zeigten wir das Video und diskutierten anschließend mit 15 Verbraucher:innen über die Wirkung und Fähigkeiten des Sprachassistenten, der das Wissen und die Anweisungen vermitteln sollte, zudem über die Rolle des Menschen, der in dieser Situation als Sensor fungiert und welche Bedeutung das für die Gestaltung zukünftiger Technologien hat. Der nächste Schritt müsste nicht zwangsweise die Weiterentwicklung der Sprachinteraktion sein, sondern eventuell doch die Hinzunahme weiterer Technologien, wie beispielsweise die Objekterkennung als Möglichkeit, die Frische zu überprüfen. Zusätzlich konnten wir in diesem Teil der Studie das Potenzial der Anwendung, Körperwissen zu lehren und eine kollaborative Entscheidungsfindung zur Verringerung der Lebensmittelverschwendung bereitzustellen, diskutieren. Dies führte zu weiteren Erkenntnissen, wie wir unser Design für die Implementierung im Alltag der Haushalte verbessern können.

Die Gestaltung digitaler Produkte und Services stellt innerhalb der Verbraucherinformatik den Menschen und seine sozialen (Konsum-)Praktiken in den Mittelpunkt. Besonders wichtig ist es, den Menschen als Verbraucher:in und Nutzer:in frühzeitig in den Entwicklungsprozess einzubinden, um sicherzustellen, dass das System den situierten Bedürfnissen und Gewohnheiten entspricht. Daher sollten auch technologiegetriebene Ansätze mit menschzentrierten Ansätzen kombiniert werden, um eine erfolgreiche Integration in den Alltag zu ermöglichen. Zur Vorgehensweise können lineare, inkrementelle oder iterative Gestaltungsansätze herangezogen werden, die alle gleichermaßen valide sind. Zusätzlich tragen Normungsansätze, Werkzeuge und Prototypen zur Gestaltung nutzer:innenzentrierter Systeme bei. Hier dienen Usability und User Experience als entscheidende Kriterien zur Bewertung einer solchen Gestaltung. Insgesamt unterstützten und demokratisieren soziale Praktiken und Participatory Design diesen Prozess, indem Nutzer:innen teilweise die Rolle der Designer:innen ausfüllen. Mit dem hier beschriebenen Vorgehen is es möglich, auch zukünftige und noch nicht erprobte Technologien für den Alltag der Verbraucher:innen zu explorieren und bedeutungsvoll zu gestalten.

1. 1.

   Was sind soziale Praktiken, und welche Rolle spielen sie im Design?

2. 2.

   Was ist der Unterschied zwischen Design Thinking und einem Prozessmodell? Welche Phasen gibt es?

3. 3.

   Erläutern Sie die ISO Norm 9241:210. Beschreiben Sie auch die Ziele und Schritte dieses Prozesses.

4. 4.

   Was sind die 4 Phasen des Double Diamond?

5. 5.

   Was ist Usability? Nennen Sie die Kriterien nach der ISO 9241:210.

6. 6.

   Wie unterscheidet sich User Experience (UX) von der Customer Experience (CX)?

7. 7.

   Erläutern Sie die Unterschiede zwischen technologiezentriertem und nutzer:innenzentriertem Design.

8. 8.

   Was sind Tools (Werkzeuge), und wie werden diese im Design eingesetzt?

9. 9.

   Was ist ein Prototyp? Was ist Prototyping?

10. 10.

    Erläutern Sie GUI, WIMP und WYSIWYG. Was bedeuten die Abkürzungen?

11. 11.

    Was sind Post-WIMP-Interfaces? Erläutern Sie zwei Beispiele.

12. 12.

    Welche Elemente der Design Case Study I machen das vorgestellte System zu einem Post-WIMP-System? Welche sind eher einem WIMP-System zuzuordnen?

13. 13.

    Wäre die Design Case Study II in Abschn. 6.6.2 auch als WIMP-System in deren Kontext nutzbar? Was könnten mögliche Nachteile sein?