InSitu Tasks

IDEE UND ZIEL

Um herauszufinden, wie Nutzer Anwendungen oder Dienstleistungen nutzen (z.B. wie viel Energie bei der Zubereitung einer Mahlzeit verbraucht wird), werden alle Beteiligten gebeten eine spezifische Aufgabe z.B. „Essen zubereiten“ durchzuführen, um anschließend das Verhalten und die Energieverbräuche vergleichen zu können.

Umgebung Technischer Aufwand Zeitlicher Aufwand Benötigtes Know-How Nutzer-/ Stakeholder-integration

Reale Umgebung der Nutzer,

LL-Infrastruktur

Aktive Integration, informierend

KONZEPT UND VORAUSSETZUNGEN

Der InSitu Task ist eine analytische Methode, bei der sich ein oder mehrere Usability-Experten in die Rolle eines Benutzers versetzen, um anhand eines Prototyps einen typischen Handlungsablauf durchzuspielen. Dabei achten Sie darauf, ob die Interaktion verständlich und klar ist und sich das Produkt wie erwartet verhält. Der Forscher identifiziert unpassende Bedienelemente, schlechte Bezeichnungen, ungenügendes Feedback oder unnötige Schritte der Interaktion.

 

Verortung im Living Lab: Die Methode der InSitu Tasks wird erst nach der Prototypenentwicklung relevant, da nur lauffähige Prototypen sinnvoll getestet werden können.

Forschungsumgebung: Für die methodische Umsetzung ist keine besondere Umgebung erforderlich. Die zentrale Voraussetzung ist die Nutzbarkeit des entwickelten Prototyps.

Nutzer-/Stakeholderintegration: Eine Integration von weiteren Stakeholdern ist nicht zwingend erforderlich, da die Experten, Forscher oder Designer das Produkt als eine erste Instanz testen können. Erst, wenn nach dem Experten Walkthough keine Fehler mehr identifiziert werden können, sollte der Produkttest mit Nutzern durchgeführt werden.

Aufwand: Der Aufwand ist als vergleichsweise niedrig zu bewerten, da keine besonderen Anforderungen an die Forschungsumgebung oder zur Nutzerintegration notwendig sind. Auch die Umsetzung bedarf nur einer geringen Vorbereitung. Es genügen 2-4 Gutachter, möglichst zukünftige Anwender des Systems und 1 Entwickler als Moderator.

UMSETZUNG IN DER PRAXIS

Definition des Inputs: Als Vorbereitung muss der Input für den Walkthrough definiert werden. Dazu gehören folgende Schritte:

  • Festlegen, welcher Teil der Anwendung oder der Dienstleistung getestet werden soll
  • Verstehen der Arbeitsabläufe
  • Formulieren von praxisnahen Aufgaben
  • Wahl einer geeigneten Benutzerrolle
  • Vorbereiten des Prototyps

Von der Benutzerschnittstelle sollten vor allem die Teile getestet werden, die besonders oft verwendet werden oder besonders kritisch oder komplex in ihrer Anwendung sind. Das Verständnis über die Arbeitsabläufe sollte bereits durch die Nutzerforschung vorhanden sein, ansonsten macht es Sinn einen Fachexperten hinzuziehen, der über die Arbeitsabläufe informiert ist. Für die Benutzerrollen und die Beispielaufgaben können Personas und Szenarien herangezogen werden.

Durchführen des Walkthroughs: Wenn die Vorbereitungen abgeschlossen sind, beginnt der eigentliche Walkthrough. Dabei versuchen die Experten sich in die gewählte Benutzerrolle hineinzuversetzen und die Aufgaben anhand des Prototypens Schritt für Schritt durchzuspielen. Dabei wird angenommen, dass ein Benutzer immer den kognitiv einfachsten Weg wählt. Für jeden Schritt sollen dabei folgende Fragen beantwortet werden:

  • Wird der Benutzer versuchen, den richtigen Effekt zu erzielen?
  • Wird der Benutzer erkennen, dass die korrekte Aktion zur Verfügung steht?
  • Wird der Benutzer eine Verbindung herstellen zwischen der korrekten Aktion und dem gewünschten Effekt?
  • Wenn die korrekte Aktion ausgeführt worden ist: Wird der Benutzer den Fortschritt erkennen?

 

Protokollieren von kritischen Informationen: Während des Walkthroughs wird jeder Schritt protokolliert, bei dem eine der obigen Fragen mit nein beantwortet wurde. Dazu werden folgende Angaben festgehalten:

  • die Frage, welche mit „nein“ beantwortet wurde,
  • den Grund, wieso sie mit „nein“ beantwortet wurde,
  • mögliche Verbesserungsvorschläge.

Überarbeiten der Benutzerschnittstelle: Nach dem Walkthrough soll versucht werden für die identifizierten Schwachstellen Verbesserungen auszuarbeiten. Dabei können folgende Tipps helfen:

  • Wenn der Benutzer nicht versucht, den richtigen Effekt zu erzielen, ist dies häufig ein Hinweis darauf, dass der Arbeitsablauf falsch abgebildet wurde und der Benutzer nach einer anderen Aktion sucht.
  • Wenn der Benutzer nicht erkennt, dass die richtige Aktion zur Verfügung steht, ist eventuell die Platzierung, die Beschriftung oder die Wahl des Interaktionselements ungeeignet.
  • Wenn der Benutzer keine Verbindung zwischen der Aktion und dem gewünschten Effekt herstellen kann, so liegt dies in der Regel an einer unpassenden Bezeichnung der Aktion. Er führt unbewusst eine andere Aktion als beabsichtigt aus.
  • Wenn der Benutzer den Fortschritt nicht erkennt, liegt dies in der Regel an einer fehlenden und zu wenig offensichtlichen Rückmeldung.

GRENZEN UND HERAUSFORDERUNGEN

Die Methode ist sehr schnell und einfach umsetzbar und kann bereits mit frühen Prototypen durchgeführt werden. Nachteilig ist jedoch, dass der Experte die Arbeitsabläufe und Informationsbedürfnisse der Nutzer sehr gut kennen muss.

 

Ansonsten kann es vorkommen, dass der Experte vermeintliche Probleme identifiziert, die in der Praxis so nicht vorkommen.

VORTEILE DER NUTZUNG IM LIVING LAB

Im Living Lab bietet der Einsatz der Methode, gerade aufgrund der schnellen Umsetzbarkeit und des geringen Vorbereitungsaufwands, die Möglichkeit, mit wenig Mitteln gute Erfolge zu erzielen. Daher wird die Methode insbesondere für KMU als relevant eingeschätzt.

 

Vor allem im Living Lab Prozess ist es von Vorteil, wenn der Experte im direkten Kontakt mit der Nutzergruppe steht, um für diese stellvertretend Probleme, Fehler, oder Herausforderungen in der Produktnutzung zu identifizieren.

ANWENDUNGSBEISPIEL

Ein Anwendungsbeispiel ist die Aufgabe, Anrufe innerhalb eines Telefon-Systems weiterzuleiten. Das Telefon ist ein Standardmodell und folgende Anleitung liegt dem Telefon bei:

   FWD *2

   CNCL #2

   SEND ALL *3

   CNCL #2

Die Erfahrung zeigt, dass zumindest einige Benutzer in der Lage sind, das System ohne Training zu nutzen, da sie unerwartet der Anforderung ein Telefonat weiterzuleiten ausgesetzt sind. Dieses Problem kann mittels einer der zwei folgenden Optionen gelöst werden:

  • Die unerwartete Anforderung eliminieren
  • Eine Aufforderung integrieren, wodurch die Anforderung nicht mehr unerwartet ist

 

Die erste Lösung ist offensichtlich die bessere, da sie eine Vielzahl sekundärer Probleme beseitigt. Allerding ist diese Lösung aufgrund technischer Umsetzungsmöglichkeiten nicht durchführbar. Die zweite Lösung bringt wiederum selbst Schwierigkeiten mit sich. Die Integration einer akustischen Anordnung ist ebenfalls technisch nicht umsetzbar. Daher ist eine Ergänzung zur Anleitung zu machen, beispielsweise: „Um Anrufe weiterzuleiten drücken Sie #2 und legen auf, dann drücken Sie *2 und wählen die gewünschte Nummer“.

WEITERFÜHRENDE LITERATUR

  • Moser, C. (2012): User Experience Design. Mit erlebniszentrierter Softwareentwicklung zu Produkten, die begeistern. Springer, Berlin.
  • Wharton, C.; Rieman, J.; Lewis, C.; Polson, P. (1994): The cognitive walkthrough method: a practitioner's guide. University of Colorado, Colorado. Online verfügbar unter http://www.colorado.edu/ics/sites/default/files/attached-files/93-07.pdf (Zugriff am: 06.07.2016).
  • Nielsen, J.; Mack, R. (1994): Usability Inspection Methods. John Wiley & Sons, New York.
Um unsere Webseite für Sie fortlaufend verbessern zu können, verwenden wir Cookies. Hier erfahren Sie mehr zum Einsatz von Cookies.
Informationen zum Datenschutz Details anzeigen Erforderliche Cookies und Dienste erlauben Alle Cookies und Dienste erlauben

Privatsphäre Einstellungen

Einige Funktionen dieser Website benötigen Ihre Zustimmung.

  • Cookies und Dienste die für die Funktionalität der Website erforderlich sind. Diese können nicht wieder deaktiviert werden!
  • erforderlich für Living Labs Landkarte

Details anzeigen

Auswahl erlauben

Alle Cookies und Dienste erlauben

Informationen zum Datenschutz

Impressum

X