Remote Usability Testing

Compared to traditional in-lab usability testing, remote usability testing is an alternative to get rid of those on-site limitations, such as the lack of representative end-users, the expense of testing, time management problem, and the lack of a proper simulation of the users‘ true environment settings. Remoste usability testing can be usually categorized into synchronous (moderated) and asynchronous (un-moderated) testing.

Synchronous remote usability testing is operated in real time, with the evaluator being spatially detached from the participants. Synchronous testing is also called „live“ or „collaborative“ remote evaluation, is a usability evaluation method that possesses a great deal of similarity to traditional in-lab usability evaluation. This testing enables actual users to take part in the process from their natural environments, using their personal computers to keep the test conditions natural. The benefits of synchronous remote testing are the ability to obtain data from actual users in their normal environment, and reducing inconvenience for participants as there is no need for them to travel to a lab or test centre. Limitations related to the Internet and telecommunications (poor bandwidth/delays) represent some of the disadvantages of this method. Typical synchronous remote usability testing forms may include video call, screen sharing etc.

Asynchronous remote testing is done by detaching the evaluators both temporally and spatially from the participants, it splits the user from the evaluator in terms of location and time. Compared to synchronous testing, asynchronous testing may reach a larger user sample sizes, which would offer a true representation of the users. A more natural test surroundings could offset the testing bias that may occur from a lab, which often leads to participants feeling pressured that can affect the accuracy of usability results. However, this testing is narrow in scope as it doesn’t include observational data and recordings of sudden verbal data. This lack of testing data scope may limit the validity and accuracy of the results, which will lessen the chances of discovering usability problems. Typical asynchronous remote usability testing forms may include Auto-logging, user-reported critical incidents (UCI), unstructured problem reporting, etc.

References:

  1. Alghamdi, AHMED S., et al. „A comparative study of synchronous and asynchronous remote usability testing methods.“ International Review of Basic and Applied Sciences 1.3 (2013): 61-97.
  2. https://www.uxmatters.com/mt/archives/2010/01/unmoderated-remote-usability-testing-good-or-evil.php

Parametrisches Design

Die Grundlage für Parametrisches Design ist die Erzeugung von Geometrien anhand von Anfangsparametern und der Beziehung, die sie zueinander haben.

Um ein spezielles Design zu erzeugen, werden bestimmte Variablen und Algorithmen verwendet. Zwischen diesen unterschiedlichen Parametern können Beziehungen bestehen. Je nach Anfangsparametern kann eine große Bandbreite an Möglichkeiten erforscht werden.

Parametrisches Design ist von grundlegender Bedeutung, für diejenigen, die den Aufwand für die Erstellung und Prüfung von Designvarianten minimieren möchten.

Im Zuge der integrierten Produktentwicklung wurde es notwendig, zu einer umfassenderen Produktrepräsentation im Rechner zu gelangen. Insbesondere bei einem Concurrent-Engineering-Prozess sollten Änderungen schnell und einfach umsetzbar sein. Um diese Forderungen erfüllen und dem Entwerfer ein möglichst intuitiv zu nutzendes Modellierungssystem zur Verfügung stellen zu können, wurden ab Anfang der siebziger Jahre parametrische CAD-Systeme für den Maschinen- und Fahrzeugbau entwickelt. Der Grund dafür ist, dass viele Produkte und Einzelteile in diesen Bereichen Variationen von Grundtypen und -elementen darstellen.

Quelle: http://parametric-van-conversion.de/was-ist-parametrisches-design/ (20.6.2021)

Im Rahmen von Software Engineering werden beim Parametrischen Design den Softwareentwicklern, also Informatiker:innen, Programmier*innen, Designern usw. durch Machine Learning ausgewählte Alternativen vorgeschlagen, aus denen dann gewählt werden kann. Die Datengrundlage für die Auswahl können eben die Definition von Fokusgruppen, Parametern in Personas (das haben wir bisher noch nicht behandelt) sowie quantitative Daten aus Usability Tests sein.

Quelle: LU #9 – Evaluating Techniques II, Folie 11 + Video der VL zu dieser Folie

Fitts‘ Law

Fitts‘ Gesetz ist eine Möglichkeit vorherzusagen wie lange Personen brauchen um etwas zu zeigen. Das Gesetz wurde in vielen verschiedenen Bereichen gezeigt, so gilt es bei Personen unter Drogeneinfluss als auch bei Menschen die mit der Technik nicht vertraut sind.

Fitts Gesetz aus https://de.wikipedia.org/wiki/Fitts%E2%80%99_Gesetz
Fitts Gesetz aus https://de.wikipedia.org/wiki/Fitts%E2%80%99_Gesetz

Dies ist die Originale Schwierigkeitsformel mit D als Abstand zum Ziel und W als Breite. Dies bedeutet in der Anwendung das z.B. oft zusammen benutze Icons nahe aneinander zu positionieren, da damit D und somit auch ID kleiner wird. Die gleiche Idee wird auch verwendet wenn man Menüs am Mauszeiger oder an einem angeklickten Icon öffnet. So kann man in Windows durch diese Methode schnell einen neuen Ordner erschaffen ohne das man lange nach einem sich öffnenden Fenster suchen müsste.

Quellen

(Janis Krzok)

Keystroke Level Model

Beim Keystroke Level Model handelt es sich um ein quantitatives Verfahren aus dem Forschungsbereich des Human Computer Interaction, welches eine Vorhersage darüber treffen soll, wie lange ein erfahrender Benutzer für die fehlerfreie Bearbeitung einer Aufgabe auf einem genannten System braucht.
Um eine Analyse durchzuführen, sollte im besten Fall schon ein High Fidelity Prototype vorhanden sein. Das KLM gehört zu den weitverbreitetsten Techniken und wird oft bei Textverarbeitungsaufgaben verwendet. Für eine Berechnung können verschiedne Operatoren genutzt werden.

K = Ein Tastenanschlag oder Mausklick
P = Mit der Maus auf etwas zeigen
H = Wechsel der Hand zwischen den Eingabegeräten
D = Zeichnen auf einem Bildschirm
M = Mentale Vorbereitungszeit auf eine physische Aktion
R = Antwortzeit vom System

Beispielaufgabe: Ziehen einer Datei in einen Papierkorb

Sources:
Vorlesungsvideo – HCI 09-3 Quantifications
Wikipedia – Keystroke-Level-Model

Nielsens Heuristiken

Von Nielsen et al. wurden 10 Heuristiken für die Bewertung eines User Interfaces zusammengestellt.

  1. Sichtbarkeit des Systemzustands: User Systemzustand jederzeit bewusst machen
  2. Abgleich von System und der realen Welt: Bekannte Objekte nutzen, Metaphern herstellen
  3. User Kontrolle und Freiheit: Notausgang aus unerwünschten Situationen immer ermöglichen
  4. Konsistenz und Standards: Plattformkomform arbeiten, Nutzer soll sich nicht neu orientieren müssen
  5. Fehlerprävention: Fehler durch erneute Abfragen verhindern, „Submit“ oder „Abbruch“ erkennbar
  6. Erkennen statt Erinnern: Aktionen auf Objekten sichtbar machen, dass Nutzer kein Langzeitgedächtnis braucht
  7. Flexibilität und Effizienz: Um erfahrenen Usern eine schnellere Nutzung zu ermöglichen
  8. Ästhetik und Minimalistisches Design: was wird wirklich benötigt, der Rest zerstört Ordnung
  9. Erkennen, Diagnostizieren und Erholen von Fehlern: sollte in menschenfreundlicher Sprache erfolgen
  10. Hilfen und Dokumentationen: schnell auffindbar und gut verständlich

[LU#9, 09-1_HCI_Evaluation_Inspections_and_Quantifications.pdf, Slides: 6-11, 13-15, 17-18]
{Video: 09-1 HCI Evaluation Inspections and Quantifications, Start: 5:28, End: 28:38}

Fitts‘ Law

Die Geschwindigkeit und Genauigkeit von Bewegungen ist von zentraler Bedeutung bei der Gestaltung von interaktiven Systemen.
Insbesondere wie viel Zeit benötigt wird, um von einem Punkt A auf dem Bildschirm zu einem anderen Punkt B zu gelangen und bei Punkt B das entsprechende Ziel zu treffen.
Hierbei ist „distance“ die Entfernung zwischen Punkt A und B und „size“ die Größe des Ziels.
a und b werden empirisch ermittelt.

Quelle: 09-3 HCI Quantifications, https://fu-berlin.eu.vbrickrev.com/#/videos/9a68edc0-eb68-4ca3-985b-d05abdbbb0f1 (Minute: 12:50-14:55), abgerufen 06.07.2021 um 13:00 Uhr oder https://git.imp.fu-berlin.de/hcc/hci1-sose-2020/-/wikis/lecture/09-3_HCI_Quantifications.pdf (Folie 8)

Cognitive Walkthrough

Geht darum herauszufinden was Personen denken, während sie bestimmte Aktivitäten mit dem User-Interface ausführen.
Dabei geht es insbesondere um einen Erstkontakt des Nutzers/der Nutzerin mit dem Interface und somit um die Erlernbarkeit des selbigen.

Was wird für einen Cognitive Walkthrough benötigt?
1. Beschreibung des Interface-Prototyps. Diese muss nicht unbedingt vollständig, aber trotzdem recht ausführlich sein. Somit benötigt der Prototyp auch einen gewissen Reifegrad.
2. Eine repräsentative Aufgabe, die von den Nutzer:innen erfüllt werden soll.
3. Eine vollständige Liste von Aktionen, die durchgeführt werden müssen, um die Aufgabe zu erfüllen.
4. Sich vorher gut überlegen, welche Erfahrungen und Hintergründe die Nutzer:innen haben sollten.

Die Essenz des Walkthroughs ist darauf zu achten, an welcher Stelle die Nutzer:innen vom in 3. idealisierten Pfad abweichen.

Quelle: 09-2 HCI Cognitive Walkthrough, https://fu-berlin.eu.vbrickrev.com/#/videos/19768a87-e963-4acc-afb6-0c3a1d75d36a (Minute 1:40-5:25), abgerufen 06.07.2021 um 13:10 Uhr oder https://git.imp.fu-berlin.de/hcc/hci1-sose-2020/-/wikis/lecture/09-2_HCI_Cognitive_Walkthrough.pdf (Folie 3+4)