Einführung in die Mikrointeraktionen

  1. Microinteraction (Def.) = ein einzelner Produktmoment, der sich mit einem einzigen Use Case beschäftigt

  2. Einsatzmöglichkeiten von Microinteractions:

  3. Vier Teile von MI [Microinteraction Model]

    1. Trigger:
      • user-initiated: Bedürfnisse der User müssen verstanden werden (was will der User machen, wann und wie oft?, wichtigster Teil von user-initiated triggers: Steuerungsmechanismen/Eingabegeräte
      • system-initiated: Anwendungen erkennen selbst Veränderungen/Gegebenheit im System und lösen MI aus
    2. Rules: jede MI folgt mindestens einer vom Designer definierten Regel, Regel -> was passiert wenn die MI getriggert wird?
    3. Feedback: Feedback muss immer zur Microinteraction passen, kann verschiedene Formen annehmen
      • visuell, auditiv, haptisch (z.B. Vibration)
      • herausstechend/ eindeutig (z.B. Licht geht an wenn der Schalter umgelegt wird)
      • subtil/ umgebend (z.B. kleine "unread" Felder wenn man eine neue eMail bekommen und noch nicht gelesen hat)
      • beschreibend (z.B. Navistimme die auf Abbiegen reagiert)
      • mehrdeutig (z.B. blinkende LED mit bestimmtem Muster)
      • unterbrechend (z.B. Klingelton)
    4. Loops and Modes: : "Meta-Regeln" - was passiert mit der MI im Laufe der Zeit? Wird sie irgendwann abgeschaltet?

Trigger: Auslöser

  1. Definition Trigger: “Trigger sind physische oder digitale Elemente oder Konditionen, die eine Mikrointeraktion starten.” --> sie initiieren die Mikrointeraktion

  2. Arten von Trigger:

    • Manuelle Trigger:
      • vom Nutzer ausgelöst
      • Einfache Bedienelemente wie Buttons, Icons, On/Off-Schalter
      • Was und wann und in welchem Kontext möchte der Nutzer etwas tun?
      • Verfügbarkeit sollt beachtet werden --> immer oder kontextabhängig?
      • Ziel: die Position des Triggers mit dem Nutzerbedürfnis abzustimmen
    • Unsichtbare Trigger:
      • Keine Hinweise auf Interaktionsmöglichkeit
      • Durch Versuch und Irrtum erkennbar
      • Sensor-basiert --> Gestik oder Sprache
      • Vereinfachen den Screen - Aufbau
      • Darf keine wichtige Funktion sein
      • Muss erlernbar sein
    • System Trigger:
      • Vom System initiiert
      • Erscheinen wenn eine bestimmte Kondition oder ein bestimmter Zustand erreicht ist

      • Können ausgelöst werden durch: Fehler, Position, eingehende Informationen, Betriebsinterne Information, andere Mikrointeraktionen, andere Nutzer

  3. Aufbau von Trigger:

    1. Bedienelement:
      • einseitig: Button, einfache Geste
      • zweiseitig: Schalter
      • mehrseitig: Ziffernblatt
      • kontinuierlich: Slider
      • mehrere Elemente bspw. im Formular
    2. Zustand:
      • default: Ausgangszustand
      • rollover: Cursorposition
      • hover: Tooltips
      • active: Hintergrundaktivitäten anzeigen
      • On click/tap/press: in Aktion
      • toogle/setting: Zustandsbeschreibung
    3. Label:
      • Mikrointeraktion oder Zustand bezeichnen
      • sollen zur Eindeutigkeit beitragen
      • kurz und aussagekräftig
      • Konsistenz einhalten

  4. Gestaltung von Triggern:

    1. Den Trigger als Trigger erkenntlich gestalten:
      • Ähnlich zu einem physischen Bedienelement (Schalter) gestalten
      • Es soll eine Möglichkeit zur Interaktion erwecken
    2. Der Trigger soll immer die gleiche Aktion hervorrufen:
      • Nutzer kann ein korrektes mentales Modell aufbauen
      • Die Arbeitsweise des Triggers darf sich nicht verändern
    3. Der Trigger soll Informationen weitertragen:
      • Informationen innerhalb der Mikrointeraktion
      • Prozessschritt des Produkts
      • nur die Schlüsselinformation
    4. Nicht dem visuellen Angebotscharakter widersprechen:
      • Aussehen wie ein Button → Verhalten wie ein Button
    5. Je häufiger die Benutzung, desto sichtbarer:
      • von Mehrheit der Benutzer → sehr gut sichtbar
      • Von einigen Benutzer verwendet → gut sichtbar
      • Von wenigen Benutzer verwendet → versteckt
      • Gut erkennbare Trigger --> Bewegen sich, pulsierend oder mit einem Label (bspw. Button)
    6. Nur ein Label mit neuen Informationen:
      • wenn der Trigger diese Informationen nicht transportien
      • ein fehlendes Label führt zur Unkenntlichkeit der Button-Funktion
      • Sollen klar und verständlich sein
      • Sollen anzeigen, was passieren wird
    7. Gestaltung von System Triggern:
      • Häufigkeit beachten
      • Vorhandene Information nutzen
      • Zustand des Triggers genau kennen
      • Verhalten bei Systemfehlern festhalten

  5. Zusammenfassung Trigger

    • Trigger sind Initiierung von Mikrointeraktion
    • Arten von Triggern --> Manuell - vom Nutzer initiiert / Systemisch - vom System initiiert
    • Buttons, Icons, Bewegung/Gestik, Spracheingabe, Tippen
    • Wiedererkennungswert und Konsistenz
    • Labels sollen zur Eindeutigkeit beitragen
    • Trigger benötigen Regeln

Rules: Regeln

  1. Regeln

    = Def.: einfaches, nicht-techniches Modell, wie die Mikrointeraktion funktioniert. Was kann getan werden und was nicht und in welcher Reihenfolge?

    • wichtigster Teil einer Regel: das Ziel
      • leicht verständlich (ich weiß warum ich das tue)
      • leicht erreichbar (ich weiß dass ich das tun kann)
      • kein Zwischenschritt im Prozess, sondern Endstadium!
    • Regeln bestimmen:
      • Wie reagiert die MI auf den Trigger?
      • Welche Kontrolle hat der User, vor allem während die MI läuft?
      • In welcher Reihenfolge laufen welche Schritte ab?
      • Welche Daten genutzt werden und wo sie her kommen?
      • Die Einstellungen und Eigenschaften von Algorithmen/Technischen Abläufen
      • Welches Feedback gegeben wird und wann (mehr dazu siehe Feedback)
      • In welchem Modus ist die MI?
      • Wiederholt sich die MI und wenn ja, wie oft und mit welcher Frequenz?
      • Was passiert wenn die MI vorbei ist

  2. Wichtige Punkte für das Erstellen von Regeln:

    • Mentale Modelle des Nutzers müssen mit einbezogen werden
    • gut: wenn es nicht möglich ist, eine Regel ein einem einfachen Satz oder einem Diagramm zu erklären, gib dem Nutzer Feedback was gerade passiert
    • besser: nutze Regeln, die so auf die mentalen Modelle des Nutzers abgestimmt sind, dass sie keine Erklärung brauchen
    • Nutzer werden Erwartungen an die Mikrointeraktion haben - auch diese müssen mit einbezogen werden (außer natürlich es ist eine komplett neue Technologie die noch nie jemand benutzt oder dran gedacht hat)
    • Erwartungen können auch "enttäuscht" werden, aber nur ! wenn die tatsächliche MI etwas deutlich besseres als die Erwartung darstellt und der User diesen Nutzen auch sehen kann
    • vermeide also MI die "needlessly different" sind (18th century German philosopher Georg Christoph Lichtenberg, who said, “Ich weiss nicht, ob es besser wird, wenn es anders wird. Aber es muss anders werden, wenn es besser werden soll.” )
    • Regeln dürfen sich aber nicht anfühlen wie Regeln, denen man strikt folgen und im schlimmsten Fall auswendig lernen muss
    • Regeln werden für den Nutzer sichtbar in dem was er*sie tun kann und was nicht
    • Jede Regel ist diskutierbar, es gibt nicht das objektiv richtige oder falsche
    • verwende keine doppelten (mehrfach) Verneinungen

  3. Wie man Regeln erstellt:

    1. Alle Grundregeln die für diese MI wichtig sein könnten aufschreiben. Dadurch entstehen gewisse Grundregeln.
    2. Optional aber empfehlenswert: Regeln visualisieren z.B. in einem Logic Diagram
    3. Mikrointeraktion als Satz aufschreiben. Verben sind Aktionen, Nomen sind die Objekte die diese Aktionen ermöglichen. -> Objekte haben Eigenschaften und Zustände. Die Regeln bestimmen was diese sind. Wichtig für das Auswählen von Verben und Nomen:
      • Jedes Nomen soll einzigartig sein:
      • zwei gleiche Nomen: kombinieren
      • wenn zwei oder mehr Nomen gleich aussehen (z.B. zwei gleiche Buttons) dann müssen sie sich auch gleich verhalten (z.B. wenn der zurück Button geklickt wird kommt man auf die vorherige Seite + wenn man den weiter Button klickt auf die nächste)
      • Objekte die sich unterschiedlich verhalten sollten auch unterschiedlich aussehen
      • das gleiche Nomen darf an unterschiedlichen Stellen nicht unterschiedlich funktionieren (z.B. ein Lichtschalter neben der Badezimmertür sollte genauso funktionieren wie ein Lichtschalter im Bad)
      • die besten MI sind oft die, die dem Nutzer erlauben, viele Aktionen mit wenigen Objekten durchzuführen (fewer nouns to do more verbs)
    4. Unterscheide bei Regeln zwischen Screens und Zuständen: statt ständig von einer Seite auf die nächste zu wechseln, nutze Zustände deiner Objekte, um Änderungen anzuzeigen. Wenn der User durch die Regeln durchgeht, werden sich die Objekte (Nomen) ändern -> Zustandsänderungen. Jeder dieser Zustände muss designed werden + jeder Zustand transportiert im besten Fall Informationen. Jedes Objekt hat mindestens drei Zustände:
      • ein default/Anfangszustand: aktiv wenn der User das Objekt entdeckt
      • aktiver Zustand: was tut das Objekt wenn man mit ihm interagiert?
      • veränderter Zustand: was passiert wenn der User aufhört mit dem Objekt zu interagieren?
    5. Einschränkungen (wsa kann ich/ der User nicht tun?):
      • Welche Input/Output Methoden sind verfügbar? (z.B. Trackpad, Lautsprecher, Kamera,LED...)
      • Welchen Typ/Datentyp/Längenbegrenzungen hat mein Input? (z.B. erlaubt Länge von Passwörtern, maximale Lautstärke,...)
      • Was kostet viele Ressourcen? (z.B. ständige Server-Calls, permanentes Blinken einer LED,...)
      • Welche Daten habe ich überhaupt zur Verfügung? (z.B. über Sensoren, APIs, Geodaten, Internetnutzung, Wetter, Zeit,..)
      • Welche Daten kann ich zusätzlich sammeln und nutzen?
    6. Vermeide Komplexität:
      • Abläufe vereinfachen wo es geht, wenn es nicht mehr geht:
      • Teslers Law of the Conservation of Complexity: "Tesler’s Law, briefly stated, says that all activities have an inherent complexity; there is a point beyond which you cannot simplify a process any further. The only question then becomes what to do with that complexity."
      • wo ist die Komplexität die ich nicht mehr rausnehmen kann?
      • welche Teile davon wird der User selbst kontrollieren wollen?
      • welche Teile kann der Computer übernehmen (typische Tasks: schnelle Berechnungen und Aktionen durchführen, viele Aufgaben gleichzeitig lösen, fehlerloses "Erinnern" an Sachen/Fakten, Erkennen von komplizierten Mustern, Suchen durch große Datensätze nach bestimmten Einträgen)
    7. Schränke Optionen zahlenmäßig ein und biete stattdessen gute Default Lösungen (Vermeiden der "Qual der Wahl") -> Faustregel: Jede Option die der User hat ist mindestestens eine neue Regel! -> für Mikrointeraktionen sollte es eigentlich nicht mehr als eine Hauptoption geben -> jede Änderung/ jede Entscheidung wird die MI wahrscheinlich verändern (in einen anderen Zustand befördern) -> wenn Default Entscheidungen gemacht werde: kommuniziere für den User was diese Entscheidung ist -> wenn eine Entscheidungsfreiheit gegeben ist - beachte wie die Optionen präsentiert werden (Reihenfolgen von Listen, Highlighten von Optionen, Starte mit allgemeineren, einfacheren Entscheidungen, dann gehe ins Detail) -> Frage: ist die Option die ich gebe bedeutsam und sinnvoll? macht es die User Experience interessanter, wertvoller oder angenehm?
    8. Steuerung und User Input: Unterschied:
      • operative Einfachheit: jeder Befehl hat seine eigene Steuerungseinheit (sinnvoll für MI die oft und wiederholt genutzt werden)
      • gefühlte Einfachheit: eine Steuerungseinheit führt mehrere Aktionen durch (sinnvoll für MI die selten oder nur einmal genutzt werden)
    9. Regeln sollten so designed sein, dass sie keinen Fehler erlauben, Fehlermeldungen dürfen nicht angezeigt werden, wenn der User alles richtig gemacht hat, sondern nur wenn das System nicht angemessen reagieren kann.
    10. Nutze Microcopy - Labels, Anweisungen und andere kleine Textstücke um Regeln zu erklären (z.B. Button beschriften, sinnvolle (intutitve) Icons verwenden, ...) -> wenn ein Label oder ein Icon reicht, benutze keine langen Erklärungs/Anweisungstexte!

Feedback

  1. Funktion von Feedback:

    • Verständnis für die Regeln der Mikrointeraktion erhöhen
    • Unterstützung bei dem Aufbau eines Mentalen Modells
    • Aufweisen der Möglichkeiten einer Mikrointeraktion

    • Überträgt Charakter der Mikrointeraktion

  2. Aufbau von Feedback:

    1. Message: soll auftauchen, wenn:
      • Der Nutzer etwas getan hat
      • etwas passiert ist
      • ein Prozess gestartet wurde
      • ein Prozess fortlaufend ist
      • der Nutzer etwas nicht tun kann
      • Feedback soll nach Bedarf gesteuert sein --> Was soll der Nutzer im Moment wissen?
      • Kann eine Persönlichkeit der Mikrointeraktion transportieren --> Bedachte Nutzung von Persönlichkeit wichtig
    2. Frequenz:

      Feedback soll auftauchen bei:

      • Triggerauslöser
      • signifikanter Zustandsänderung in einer MI
      • Erreichung des Endes einer MI
      • Fehler im System
      • Fortschrittsanzeige

      Feedback kann auftauchen beim:

      • Start oder Ende eines Prozesses
      • Start oder Ende eines Zustands oder beim Wechsel des Zustands in einer Mikrointeraktion

      Faustregel: Feedback dort einsetzen, wo es beitragen kann, den Sachverhalt zu enträtseln und die Mikrointeraktion zu erklären

    3. Aussehen: unter Arten von Feedback

  3. Arten von Feedback:

    • Visuelles Feedback:
      • Mehrheit des Feedbacks ist visuell
      • Schlichtes visuelles Feedback besser
      • Soll in der Nähe des User Inputs sein
    • Text - Feedback:
      • Text soll exakt, kurz und klar sein
      • Fehlermeldung soll über Fehler informieren
    • Auditives - Feedback:
      • Sollte eher sparsam verwendet werden
      • Kann ein Alarm oder eine Betonung sein
      • Earcons als Erkennungston
    • Haptisches Feedback:
      • Vibrierendes Feedback
      • Nur in der Nähe des Users möglich
      • Um physische Aktion auszulösen
      • Ersatz für auditives Feedback
    • Sprache - Feedback:

      • Kurz und klar

      • Optionen verdeutlichen
      • Sollte mit einer Aktion enden
      • Richtige Nachricht und Sprachton wichtig

  4. Gestaltungsrichtlinien für Feedback

    1. Überlaste den Nutzer nicht mit Feedback
    2. Feedback ist nicht willkürlich:

      • Starke inhaltliche Verbindung zwischen Trigger und dem Feedback

      • sonst kein Verständnis zwischen Aktion und Ergebnis

      • Kopplung zwischen Auslöser und Feedback als natürliche Erweiterung

    3. Weniger ist mehr
    4. Vorhandene UI Elemente nutzen wie Scrollbars, Cursors, Fortschrittsbalken
    5. Fragen zur Gestaltung von Feedback:

      • Verändert sich der Kontext und damit auch das Feedback?

      • Wie hell/laut/schnell soll der Effekt des Feedbacks sein?
      • Wie häufig soll sich das Feedback wiederholen?

  5. Zusammenfassung Feedback:

    • Feedback soll das Verständnis für die Regeln der Mikrointeraktion verbessern
    • Kann die Persönlichkeit der Mikrointeraktion transportieren
    • Feedback soll nicht willkürlich sein

    • Überlege, welche Informationen der Nutzer wann braucht

Loops and Modes

  1. Was ist ein Loop?

    • zu deutsch Schleife / Kreis = Der Ablauf einer Mikrointeraktion
    • Verschiedene Events wiederholen sich für eine bestimmte Zeit
    • MI eher kurz, Elemente können „weiterleben“
    • Verhalten der Mikrointeraktion verdeutlichen
    1. Loops beeinflussen die User Experience:
      • Parameter von Schleifen können UX beeinflussen:
      • Zu wenige Wiederholungen = abgebrochen, gehetzt
      • Zu viele Wiederholungen = schleppend
    2. Arten von Loops:
      • For – Schleife: bestimmte Anzahl an Wiederholungen wird ausgeführt
      • While – Schleife: etwas wird so lange ein Zustand nicht gegeben ist, ausgeführt
      • Kontrollierte For-Schleife: Wiederholung wird einmal ausgeführt
      • Endlos - Schleife: Schleife wird so lange wiederholt, bis ein Fehler auftaucht
    3. Geschlossene / Offene Loops:

      • Geschlossene Loops:

        • Feedback - Mechanismus ist eingebaut
        • Schleife passt sich selbst an

      • Offene Loops:

        • Reagieren nicht auf Feedback
        • Werden ausgeführt und enden
    4. Long Loops:
      • Erweiterung von einfachen Loops
      • Long loops = andauernde Schleifen, die sich über die Zeit adaptieren
      • Nicht nur auf eine einzige Aufgaben fokusiert
      • MI liefert über Zeit immer neue Erfahrungen

  2. Was sind Modes?

      • Verschiedene Zustände innerhalb einer Mikrointeraktion
      • Sollen seltene Aktionen abbilden  Ausnahmen in einer Regel
      • Je weniger Modes, desto einfacher die Handhabung von MI
    1. pring Loaded Modes:
      • Quasimodes, welche nur bei aktiver Betätigung eines UI – Elements gezeigt werden
      • Sobald Aktion stoppt, stoppt auch Modus
      • Verlangt nicht den Screen zu wechseln
    2. On-Off Modes:
      • Vom Nutzer initiierter Modus
      • dauert nur für eine begrenzte Zeit nachdem die Aktion ausgeführt wurde

  3. Gestaltungsempfehlungen für Modes

    • Für jeden Modus in der Mikrointeraktion ein eignener Screen
    • Eindeutiger Übergang zwischen Modi zeigt die User Position
    • Originaler Zustand soll beibehalten werden
    • Progressive disclosure:
      • Nutzer gewöhnt sich an MI
      • Braucht nicht mehr die volle Unterstützung --> Short cuts oder erweiterte Funktionen zur MI hinzufügen
    • Progressive reduction:
      • Mit der häufigen Benutzung von Mikrointeraktionen, wir die MI für den Nutzer einfacher --> Elemente der MI reduzieren
      • Achtung: Nach längerer Nichtbenutzung könnten zusätzliche Elemente wieder hilfreich sein

  4. Zusammenfassung Loops & Modes

    • Nur ein zusätzlicher Modus, wenn notwendig
    • Zusätzlichen Screen verwenden
    • Loops benutzen, um Lebenszeit von MI zu verlängern
    • Parameter der Schleife können UX beeinflussen
    • Einzelne Aspekte der MI vereinfachen für skilled User

Putting it all together: Zusammenfassung

Schritte um eine MI zu erstellen:

  1. Wo baue ich die Mikrointeraktion ein?
  2. Was ist das Ziel der Mikrointeraktion?
  3. Was sind die Grundregeln die auf diese MI zutreffen?
  4. Wie wird die MI ausgelöst?
  5. Was passiert wenn Aktionen durchgeführt werden? Welches Feedback bekommt der Nutzer?
  6. Anpassen der Regeln unter Berücksichtigung des Feedbacks und des Triggers
  7. Was passiert mit der MI über die Zeit? (Wie oft) wiederholt sie sich? Welche verschiedenen Zustände kann meine MI einnehmen?
  8. Kann ich meine MI noch verfeinern? Habe ich die verschiedenen Prinzipien mit in Betracht gezogen und die umgesetzt die für meine MI passen? -> Folie mit Prinzipien:
  9. Dont start from zero (Nutze die Daten die du zur Verfügung hast)
  10. Use the Overlooked (Gibt es Funktionen/Bedienelemente, die noch mehr tun könnten bzw. noch mehr Wert für meine MI haben? )
  11. Prevent Human Error (Poka Yoke) (Designe dein System so, dass es keine Möglichkeit für den Nutzer gibt, es falsch zu benutzen)
  12. Bring the Data Forward (Zeige die für den Nutzer relevanten Informationen so an, dass er sie direkt auf einen Blick sieht)
  13. Use Nouns + Verbs (Formuliere deine Mikrointeraktion als Satz mit Objekten und Aktionen)
  14. Emphasize the next action (Zeige auf, was der nächste Schritt ist, achte dabei darauf, dass das der Schritt ist, den alle oder der Großteil deiner Nutzer sowieso machen würden)
  15. Do I need Custom Controls? (Brauche ich ein eigens angefertigtes Stück User Interface um meine MI noch prominenter zu machen?)
  16. Is there an invisible trigger for advanced rules? (Kann ich meine MI auf die Bedürfnisse von z.B. power usern oder häufigen Nutzern anpassen? z.B. Tastenkürzel einführen)
  17. Sind meine Texte und Icons intuitiv und so einfach wie möglich?
  18. Kann ich noch auf andere Arten Feedback zur Verfügung stellen?

Prototyp einer Mikrointeraction erstellen:

Quelle: Saffer, D. (2013). Microinteractions: Designing with Details.O’Reilly Media