GLOSSAR ZUM BUCH
Kombination von Workshops
22. Dezember 2017, Toni Steimle

In unserem Buch "Collaborative UX Design" empfehlen wir sieben Workshops. Doch die Anzahl von sieben Workshops wird nicht für jede Projektsituation geeignet sein. So lassen sich viele der Workshops zusammenfassen und als mehrere Tage dauernder grosser Workshop organisieren. Begrenzt wird die mögliche Kombination von Workshops vor allem durch einen Faktor: Tätigkeiten, die nicht in Form von Workshops stattfinden. So lassen sich beispielsweise der Workshop Scoping und der  Workshop Synthese nicht zusammenfassen, da dazwischen Nutzerforschung stattfindet. Zwischen dem Workshop Prototyping und dem Workshop Validierung gibt es ebenfalls Tätigkeiten, welche als Einzeltätigkeiten stattfinden. So wird allenfalls der Prototyp vervollständigt und die Validierung durchgeführt. Im Workshop Validierung werden die Ergebnisse dann gemeinsam ausgewertet.

Abbildung: Workshops und Tätigkeiten, die nicht in Workshops durchgeführt werden.

Somit lassen sich theoretisch die Workshops Synthese, Ideation, Konzept und Prototyping kombinieren. In sogenannten Design Sprints werden alle Workshops in einer Woche zusammengefasst. Dies ist aber für viele Projekte unrealistisch. Erstens ist das Team nicht permanent für das Projekt verfügbar und zweitens kann es Sinn machen, zwischen Workshops einige Zeit verstreichen zu lassen, damit sich die Teammitglieder weitere Gedanken machen können und unabhängig der Workshops auch Gespräche führen können.

Häufige Kombinationen sind:

  • Synthese und Ideation
  • Konzept und Prototyping
  • Ideation und Konzept

Ein möglicher Ablauf von Workshops sieht dann wie folgt aus.

Abbildung: Eine mögliche Kombination von Workshops

In dieser Variante wertet das Team gemeinsam die Ergebnisse der Forschungsaktivitäten aus und generiert für die festgestellten Opportunity Areas Ideen. In einem kombinierten Konzept und Prototyping Workshop werden diese Ideen dann kombiniert und detailliert.

6-3-5

Der Name der Methode 6-3-5 leitet sich aus dem ihr zugrunde liegenden Vorgehen ab. Fünf Teilnehmer entwickeln zunächst jeweils allein drei Lösungsideen zu einem Problem. Sie schreiben die von ihnen gefundenen drei Lösungen als Überschriften von drei Spalten auf ein Blatt, geben das Blatt weiter und führen anschließend die weitergegebenen Lösungsideen der anderen Teilnehmer durch Kommentare fort. Die Blätter werden so lange im Kreis weitergegeben, bis das Blatt mit der eigenen Idee wieder beim ursprünglichen Autor angelangt ist. Bei fünf Teilnehmern resultieren fünf Tabellen mit drei Spalten (die jeweils mit den drei eigenen Ideen der initialen Autoren überschrieben sind) und sechs Zeilen (der eigenen Idee als Überschrift und fünf Kommentaren). Die Methode funktioniert selbstverständlich auch mit weniger oder mehr als fünf Teilnehmern.

A/B-Tests

Mit einem A/B-Test können unterschiedliche Designlösungen im Hinblick auf definierte Metriken direkt miteinander verglichen werden. Nutzer werden alternierend zu den Varianten A und B geleitet, während die Auswirkungen der verschiedenen Varianten gemessen und komparativ gegenübergestellt werden.

Domain Model Map

Eine Domain Model Map beschreibt die zentralen Datenobjekte eines Fachgebietes, deren Zusammenhänge, Attribute und Funktionalitäten.

Forschungsplanungs-Map

Eine Forschungsplanungs-Map beschreibt, mit welchen Forschungsmassnahmen Annahmen untersucht werden können. Als erstes wird die Forschungsfrage hinter der Annahme aufgedeckt. Anschliessend wird definiert, mit welcher Methode die Forschungsfrage beantwortet werden kann - Beispiele wären Interviews, Beobachtungen oder eine Befragung.

How-might-we-Fragen

How-might-we-Fragen beschreiben eine Aufgabenstellung zur Ideenfindung in Form einer Frage: Wie könnten wir ein Problem überwinden? Aus einer Opportunity Area können wir häufig mehrere solcher How-might-we-Fragen ableiten.

Insight Statements

Insight-Statements bauen auf Ergebnissen der Nutzerforschung auf. Sie benennen für die Produktentwicklung wesentliche Erkenntnisse, die für das Team neu sind.

Issue Map

Eine Issue Map unterstützt die Dokumentation von Ergebnissen während Usability-Tests oder Walkthroughs. Issue Maps basieren auf Karten, die festgestellte Beobachtungen kritischen Annahmen bzw. konkreten Screens oder Arbeitsschritten zuordnen.

Journey Map

Eine Journey Map beschreibt den Arbeitsablauf von Nutzern. Sie kann mit Bemerkungen wie Schwächen, Stärken oder anderen Erkenntnissen angereichert werden. Hilfreich können auch Fotos oder Screenshots bei der Annotation der Arbeitsschritte sein.

Metrikenboard

Ein Metrikenboard beschreibt eine Reihe von Metriken rund um die User Experience für bestimmte Personas und Szenarien.

Plädoyer

Vor einer Bewertung der erstellten Beiträge wird bei der Plädoyer-Methode allen Teilnehmern kurz Zeit gegeben, um zusammenfassende Argumente für gezeigte Lösungen vorzubringen. Für ein solches Plädoyer sollte pro Person nicht mehr als eine bis zwei Minuten eingeplant werden. Bei der nachfolgenden Bewertung können die Teilnehmer, wenn sie durch die Argumente anderer überzeugt werden, auch für andere Beiträge stimmen. Häufig werden für die Bewertung Punkte genutzt, deren Vergabe einen Beitrag dann dauerhaft sichtbar auszeichnet.

Szenarien

Szenarien fokussieren auf die Erreichung von Nutzerzielen und betten diese in narrativer Form in einen konkreten, situativen Kontext ein. Von technischen Merkmalen der konkreten Umsetzung abstrahieren Szenarien. Betrachten wir hierzu ein Beispiel:

Es ist Montagabend, 19 Uhr. Patricia war den ganzen Tag bei einem Kunden. Sie reist nun mit dem Zug nach Hause, hierfür wird sie etwa eine Stunde benötigen. Alle Sitzplätze im Zug sind besetzt und Patricia muss stehen. Sie will die Wartezeit nutzen, um ihre heutigen Leistungen zu erfassen: Es gibt zwei Leistungen, die zu erfassen sind. Sie nahm über den ganzen Vormittag hinweg an einem Workshop teil – zusammen mit einer Kollegin. Der Workshop begann um 9 Uhr und endete pünktlich um 12 Uhr. Ihre Anreise zum Workshop betrug 45 Minuten. Am Nachmittag blieb sie vor Ort und dokumentierte die Ergebnisse des Workshops allein.

Opportunity Areas

Opportunity Areas bezeichnen Produktbereiche, die verbessert werden können. Sie stellen Chancen zur Produktoptimierung dar. Opportunity Areas können aus den Erkenntnissen von Nutzerforschungsaktivitäten abgeleitet werden.

Problem Statement

Ein Problemstatement beschreibt die eigentlich zu lösende Fragestellung. Das Problemstatement definiert, welches Problem konkret zu überwinden ist, wer von dem Problem und dessen Lösung betroffen ist und welche Randbedingungen dabei zu berücksichtigen sind.

Priorisierungsmatrix

Eine Priorisierungsmatrix erlaubt die Priorisierung von Features unter gleichzeitiger Berücksichtigung vom Nutzen für die Anwender, Businesszielen und Machbarkeit.

Proto-Persona

Eine Proto-Persona beschreibt einen hypothetischen »archetypischen« Nutzer. Sie steht exemplarisch für einen konkreten Vertreter einer Benutzergruppe mit ähnlichen Anforderungen an 35 Funktionsumfang und Interaktionsdesign eines Produktes. Eigenschaften einer solchen Proto-Persona stellen zunächst Annahmen dar, die im weiteren Projektverlauf validiert werden sollten.

Risiken

Risiken sind mögliche Probleme, deren Eintreffen aus heutiger Sicht nicht sicher ist. Sie verfügen über eine Eintrittswahrscheinlichkeit und eine Auswirkung. Wir unterscheiden zwischen Projekt- und Produktrisiken. Projektrisiken können sich während der Projektlaufzeit auswirken, wohingegen sich Produktrisiken gegebenenfalls erst nach dem Release eines Produktes manifestieren können.

Roadmap

Eine Roadmap beschreibt eine zeitliche Abfolge von aufeinander aufbauenden Releases. Sie kann beispielsweise mit einer in Abschnitte geordnete User Story Map definiert werden.

User Journey

Eine User Journey zeigt die bildhafte Umsetzung eines User Interface vor dem Hintergrund eines gegebenen Szenarios. Die User Journey visualisiert die einzelnen Zustände des User Interface nach Interaktionen von Nutzern im zeitlichen Verlauf der Zielerreichung.

User Story Map

Eine User Story Map ist eine abstrahierte Beschreibung des Arbeitsflusses von Nutzern und unterstützt die schrittweise Ableitung von Funktionen und ihrer Kombinationen, die eine Anwendung Nutzern zur Erreichung ihrer Ziele zu Verfügung stellt.

Validierungsplanung

Eine Validierungsplanung beschreibt, mit welchen Methoden und Prototoypen eine bestimmte Annahme in Bezug auf eine Personas validiert werden kann.

Wireframe

Ein Wireframe zeigt den konzeptionellen Entwurf eines Screens als konkretisierte Layoutdarstellung: Größe, Position und räumliche Bezüge der zentralen Bereiche, Interaktions- und Navigationselemente sind festgelegt. Im Mittelpunkt eines Wireframes steht die Struktur eines Screens, von dessen detaillierter visuell- ästhetischer Ausgestaltung wird abstrahiert. Auch wenn typografische Überlegungen zu- nächst nachgeordnet sind, sollte bei Wireframes kein Blindtext, sondern inhaltlich aussagekräftige Bezeichner verwendet werden, um deren Verständlichkeit evaluieren zu können.