Retrieval describes the process of remembering information from the long-term memory. There are three ways to retrieve information: recall, recognition and relearning.

Recall describes the access of information without cues. In other words: Not by sensory input but by brain activity. Thus to recall information correctly, coordination and time is needed.

Example: A journalist writes a column about a specific topic that they have a lot of knowledge about.

Recognition describes the identification of already learned information by sensory input. This means that the information is retrieved when encountering it again.

Example: A person sees their favorite food from childhood and immediately remembers how they ate it as a child.

Relearning describes learning of information that one already has learned in the past.

Example: A person picks up a language again that they have learned in school and is able to learn it again quite quickly.

Sources:

Müller-Birn, C., Lecture „05-2 HCI Human Memory“

Introduction to Psychology: Module 7: Memory: Retrieval, https://courses.lumenlearning.com/wmopen-psychology/chapter/reading-retrieval/, visited 21.05.21

Interaktionstypen bieten eine Möglichkeit den Designraum, der uns zur Verfügung steht, zu Konzeptionalisieren. Im Wesentlichen geht es dabei darum, sich Gedanken zu machen, wie Personen mit einem Software System interagieren können. Es werden zwischen den folgenden vier Haupttypen unterschieden.

1. Instructing: Hier können können Nutzer:innen Befehle erteilen und Optionen auswählen. Eignet sich sehr gut für Aktivitäten, die sich wiederholen.
2. Conversing: Ermöglicht die Interaktion mit dem Softwaresystem als würde man ein Gespräch führen
3. Manipulating: Hier ist man in der Lage mit Objekten in der gewohnten Weise zu interagieren und sie zu verändern.
4. Exploring: Ermöglicht es sich durch einen virtuellen oder physischen Raum zu bewegen.

Source:
Müller-Birn, C., Lecture 04-01 | From Requirements to Conceptual Design

Interface Metaphern ermöglichen dem Nutzer unbekannte Funktionen besser zu verstehen, indem sie mit bekannten Objekten (meistens aus der realen Welt) verknüpft werden. Diese haben dann meistens die gleiche oder eine sehr ähnliche Funktionalität. Durch diese gemeinsame Domain kann der Nutzer sich dann die Funktion der Komponente herleiten. Beispiele sind eine Speicherdiskette zum Speichern oder eine Schere zum Ausschneiden von Inhalten.

Vorteile:

• einfacheres Erlernen neuer Funktionen
• Mentales Modell wird klar
• Chance innovative Ideen klar darzustellen

Nachteile:

• Konflikte zu Design Prinzipien und kulturellen Regeln
• Beschränkung der Funktion auf die Metapher
• Limitiert Designer bei Kreativität und neuen Ansätzen

Quellen:

Human-Computer Interaction, Jenny Preece, 1994, Chapter 7 (http://www.perflensburg.se/Privatsida/cp-web/cajpmeta.htm)

Guss S. (2003) Interface Metaphors and Web-Based Learning. In: Zhou W., Nicholson P., Corbitt B., Fong J. (eds) Advances in Web-Based Learning – ICWL 2003. ICWL 2003. Lecture Notes in Computer Science, vol 2783. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-45200-3_17

Müller-Birn, C., Lecture 04-01 | From Requirements to Conceptual Design

„Design rationales provide information that explains why a conceptional design/prototype/final product is designed how it is being designed.“ [1]

By using them, we easily make a decision together by having sufficient background knowledge, while at the same time ensuring high quality driven by the needs of customer groups.

The benefits of Design Rationales, according to LU#4 slides, could be listed as:
» organize a potentially large design space
» present arguments for design trade-offs
» enforce design discipline
» support communication throughout development life cycle [1]

Source: [1] LU#04, 04-3_HCI_Defining_Design_Rationales.pdf, Slide 2] visited 01.07.2021

The ‚Wizard of Oz‘ Prototype describes a prototype where a user tests only a simulation of planned functions. It enables to test functions of a product that has not yet been implemented and is used in agile software development.

To simulate unimplemented functions, a simple prototype, an user that interacts with the prototype and a human who performs the tasks given by the user are needed. Role playing is then used to test how the end user interacts with the product. The goal is to save time and money while finding out if a feature is useful and needed.

Advantages

• Covers the complete functionality
• Is fully interactive
• Cheap method to test functionality

Disadvantages

Interaction with the prototype is perhaps not technically realizable in the final product itself.

---

Sources

Wizard of Oz prototype, https://www.designthinking-methods.com/en/5Testen/wizardofOzTE.html, retrieved on 04. Mai 2021, 13:00
Definition Wizard of Oz prototype, https://searchcio.techtarget.com/definition/Wizard-of-Oz-prototyping, retrieved on 04. Mai 2021, 13:00
Müller-Birn, C., Lecture 04-02 | Iterative Design and Prototyping | Slide 16

…  is used to build a hierarchy of sub-tasks from a task. It was originally used in manufacturing industry to create good training steps. CS-students might think of the result of HTA as a tree, where the nodes are sub-tasks which consist of input conditions (necessary to activate node) and actions, which both together achieve the goal, leading to a feedback.

You might use four heuristic questions to fine-grain sub-tasks:

• paired actions: Are there additional actions which complete one action?
• restructure: Can I merge two similar sub-tasks?
• Balance: Are all sub-tasks similarly abstract?
• Generalize: Can sub-task be rephrased to its repeatable?

Sources

[1]  Annett, J. (2003). Hierarchical task analysis. In E. Hollnagel (Ed.), Handbook of Cognitive Task Design. (pp. 17-35). Erlbaum Mahwah, NJ. https://mycourses.aalto.fi/pluginfile.php/614499/mod_resource/content/1/Annett_2003.pdf

[2] Müller-Birn, C., Vorlesung „Human-Computer Interaction I“, Foliensatz „Conceptual Models: Task Focus“

(von Daniel Stachnik)

Die thematische Analyse ist eine iterative Methode, die zum Identifizieren und Analysieren von Mustern in Daten zum Einsatz kommt. Die Besonderheit besteht darin, dass Codes zugewiesen werden anhand des Inhalts, sollte später ein weiterer Code(=Inhalt) auftauchen werden vorangegangene Daten noch einmal auf diese überprüft. Diese Codes erlauben dann das Erkennen von Mustern. Der Prozess beinhaltet:

1. Familisierung mit den Daten
2. Code Zuweisung anhand der Daten
3. Suche nach Mustern in Codes
4. Überprüfen der Muster
5. Definition und Bennenung der Muster
6. Report

Vorteil: Große und nicht klare Datenmengen können flexibel interpretiert und eingeordnet werden.

Nachteil: Es können Nuancen in denDatenverloren gehen, außerdem ist eine solche Vorgehensweise meist subjektiv und vom Forscher abhängig.

Quellen:

How to do thematic analysis, https://www.scribbr.com/methodology/thematic-analysis/, abgerufen 02.05.2021 um 16 Uhr

HCI-03-01 HCI Elicitating Requirements, https://blogs.fu-berlin.de/hci1-sose2021/lu01-defining-requirements-and-design-rationales/

Thematic analysis | a reflexive approach, https://www.psych.auckland.ac.nz/en/about/thematic-analysis.html, abgerufen 02.05.2021 um 16 Uhr

Eine Persona ist eine fiktive/hypothetische Person mit individuellen Eigenschaften die stellvertretend für die Mitglieder einer von ihnen identifizierten Nutzer:innengruppe steht. Sie stellen dadurch einen Prototyp für eine Gruppe von Nutzer:innen dar. Personas werden aus vorhandenen Daten abgeleitet und um persönliche Eigenschaften wie Name, Aussehen, Beruf und Bildung angereichert. Die abstrakte Masse der späteren Nutzer:innen wird durch diese prototypische fiktive Persönlichkeit ersetzt. Personas stellen dabei nicht durchschnittliche Nutzer:innen dar, sondern spezifische Personen, die Muster im Nutzungsverhalten verdeutlichen.

Vorteile bei der Verwendung von Personas im Designprozess sind zum einen, dass implizite Anforderungen identifiziert werden können. Zum anderen helfen psychologische Aspekte Designentscheidungen auf Nutzer:innen auszurichten.

Quelle: HCI-03-02 Conceptual Models: User Focus, https://blogs.fu-berlin.de/hci1-sose2021/lu01-defining-requirements-and-design-rationales/, abgerufen 02.05.2021 um 13:25 Uhr