About

Wie wäre ein Leben mit einem Smartphone, dass nicht ständig mit einem um die eigene Aufmerksamkeit kämpft, das stattdessen eher als digitaler Assistent fungiert und die Kontrolle dem Menschen überlässt?

Ein spekulativer Gestaltungsversuch an einem Betriebssystem, zentriert um die Intention des Menschen, ohne Ablenkung, ohne Trigger, ohne manipulierende verhaltenspsychologische Methoden.

Basierend auf den neuen Möglichkeiten maschineller Sprachverarbeitung und einer Neuordnung bekannter Navigationsmuster und Konventionen.

Kontext

„HappyLittleApps“ – das hört sich in erster Linie nach frohen Farben und lustigen Formen an. Aber was steckt noch hinter einer App, die „happy“ ist?

Wir haben geredet über Usability, Accessibility, über Prinzipien guten UX-Designs. Wir sind die UI der letzten 30 Jahre durchgegangen, was war happy, was nicht? Warum haben sich die Ansätze an Software-Design geändert?

Das „happy“ hat jedoch auch eine zweite große Dimension, neben UI/UX. Was steckt hinter den Interfaces? Was ist die Intention einer App oder bestimmter Patterns in einer App. Will eine App deine Daten, will sie deine Aufmerksamkeit?

An der Schnittstelle dieser beiden Dimensionen einer „happy“ App haben wir mit eigenen Ideen Impulse für eine fröhlichere digitale Welt gegeben, jede/r mit eigenem, ganz unterschiedlichen Fokus.

Problem

Um die Aufmerksamkeit ist im digitalen Raum in den letzten Jahren ein großer Kampf ausgebrochen. Für die Unternehmen hinter sozialen Medien (und anderen Apps) bedeutet Aufmerksamkeit bzw. Zeit Wachstum, z.B. durch Engagement oder direkte Umsätze oder Gewinne, bspw. durch Werbung. Für die Individuen bedeutet der Umgang jedoch in erster Linie der Verlust von Zeit. Einher gehen die oft unfreiwillige Aufgabe von Kontrolle und die Schwächung des eigenen Willens in Entscheidungsprozessen durch die Gestaltung ebenjener Apps /virtueller Räume. Wir verbringen viel Zeit im Internet und ärgern uns oft selbst darüber.

Gängige Ansätze dieses Problem zu lösen ist die Einführung von Friction, Mechanismen, die es erschweren diese Aufmerksamkeit und Zeit zu schenken oder es zumindest „nerviger“ machen.

Ich möchte in diesem Projekt erkunden, wie man Apps gestalten kann, die explizit nicht zu mehr Engagement führen, ohne das Nutzungserlebnis mit der Einführung von Friction zu beeinträchtigen.

Ganz nach dem Motto: „Auch die Nichtbenutzung einer App kann Happy machen.“

Theorie und Lösungsansatz

Um zu verstehen, warum wir so viel Zeit am Handy verbringen, ist es sinnvoll sich das ganze System zu verdeutlichen. Was tun wir am Handy? Wollen wir das? Sind wir zufrieden mit unserem Verhalten?

Und vor allem was müssen wir am Handy tun können? Was sind die notwendigen Funktionen?

Kurze nicht repräsentative Umfrage

Aus den Resultaten können wir erste Schlüsse ziehen, die in dieser Form erwartbar waren:

• Die meisten befragten Personen sind mit ihrer Bildschirmzeit unzufrieden
• In dieser Stichprobe scheint es keine starke Korrelation zwischen Bildschrimzeit und Zufriedenheit zu geben (Achtung kleine Stichprobe & nicht repräsentativ)
• Die meiste Zeit wird in soziale Interaktion investiert
• Während Kommunikation jedoch als notwendig angesehen wird, ist die Nutzung von sozialen Medien zwar auf Platz 1 der meist genutzten Apps taucht aber in der Liste der notwendigen Funktionen (fast) gar nicht auf

Mein persönlicher Schluss ist, dass Instagram und co. kaum noch zur konventionellen Kommunikation von Informationen genutzt werden, sondern eher mit dem Konsum von Medien vergleichbar sind, also bspw. eher Youtube ähneln, als Whatsapp.

Kurzer Ausflug in die Theorie

Was steckt also dahinter, dass wir so viel Zeit in Apps verbringen, die wir eigentlich für gar nicht notwendig beachten und mit deren Nutzung wir auch noch unzufrieden sind?

Dazu schreibt Nir Eyal in seinem Buch Hooked und entwickelt das nachfolgende Modell (s.u., Link zum Buch). Nach Eyal beginnt jede Iteration im Aufbau von Routinen (oder Abhängigkeiten, Süchten) mit einem Trigger, ob external, z.B. eine Notification oder internal, z.B. ein Gefühl von Unbehagen oder (sehr wichtig) Langeweile, der uns dazu verleitet eine Aktion durchzuführen, z.B. das Handy zu entsperren. Wenn die restlichen Schritte dieses Hooks gegeben sind und repetitiv durchgeführt werden, können angesprochene Gewohnheiten (ggf. Abhängigkeiten) entstehen.

Der Lösungsansatz beruht in diesem Konzept also nicht darauf Friction auf dem Weg in die App Instagram einzuführen, z.B. wie der Ansatz der Funktion Bildschirmzeit von iOS oder die App one sec, sondern greift einen Schritt früher: Der Gedanke an die App soll gar nicht erst entstehen.

In Nir Eyals Worten: Wir wollen die Trigger entfernen, um einen Durchlauf eines Hooks zu verhindern.

Lösungskonzept

Denken wir weiter an Instagram. Wo fängt der Ausflug in die App an? Sowohl auf Android, als auch auf iOS (ich werde mich von hier an auf iOS konzentrieren) liegt die farbenfrohe Instagram App auf dem Home Screen und lädt schreiend zum Öffnen ein. Genauso wie 27 weitere Apps. Ich denke viele von uns kennen das Gefühl, dass der Daumen eine App geöffnet hat bevor wir richtig darüber nachgedacht haben.

Genau hier können wir eingreifen. Wir wollen, das das Handy ein digitaler Assistent ist, der uns bei einer bestimmten Intention hilft. Das Design der Homescreen Navigation jedoch bietet uns auf dem Weg von Intention zu Aktion unzählige Abbiegungen (Ablenkungen) an. Notifications auf dem Homescreen, unzählige weitere App Icons, kleine rote Notification Signale an den bunten Apps. Dabei können wir mit den neuen Möglichkeiten der maschinellen Sprachverarbeitung diesen Weg überspringen. Wir können sowohl Navigation als auch Aktion aus einem sprachbasierten Interface heraus durchführen. 

Im Prinzip bewegen wir uns damit zurück zu den Wurzeln des Computers, dem Terminal. Wir betrachten moderne Navigationssysteme als Dolmetscher zwischen uns und dem Terminal. Nur: Inzwischen kann das Terminal unsere Sprache. Streng genommen brauchen wir also unseren Dolmetscher nicht mehr.

App: Kommunikation

Ergänzend möchte ich auch eine Vision vorstellen, wie eine imaginäre App Communications aussehen würde, um an deren Beispiel die Integration von App-Navigation und genereller Betriebssystem-Navigation zu veranschaulichen.

Auch hierbei möchte ich natürlich die Trigger entfernen und die App um die Intention des Users /der Userin bauen. Was heißt das genau? Erstens gibt es keinen Grund als Default-Bildschirm die vergangenen (beantworteten) Nachrichten zu sehen, außer mich zu stimulieren mit diesen Personen wieder in Kontakt zu treten (Engagement). Zweitens geht es wieder um die Intention. In diesem Fall ist die Intention (ausgehende Nachricht) Informationen von A nach B zu schicken. Die Wahl des Mediums (Anruf, Facetime, Chat, ...) ist nachrangig, bzw. abhängig von der Information/Intention. Folglich sollte die Folge der Entscheidungen sein: 1. Auswahl Adressat und 2. Auswahl Medium. Momentan müssen wir uns jedoch zuerst für eine App (und Medium) entscheiden (iMessage, Anrufe, Instagram) und dann erst die zu adressierende Person wählen. Hinzukommt die fehlende Konsistenz zwischen den Apps (Whatsapp: Call und Chat App-intern; Apple: Call und Chat verschiedene Apps).

Wir haben also eine App, in der die Beziehung zwischen zwei Personen im Vordergrund steht und in der über verschiedene Kanäle und Medien kommuniziert werden kann. Gleichzeitig bietet diese App keine (unnötigen) Trigger, wie alte Nachrichten. Ungelesene Nachrichten und verpasste Anrufe (etc.) werden natürlich trotzdem angezeigt.

Gedanken zur Usability

Durch das Ersetzen gewöhnlicher Interfaces und konventioneller Navigationspatterns durch ein Sprachinterface laufen wir Gefahr die NutzerInnen zu verwirren. Denken wir zum Beispiel an die Designprinzipen Discoverability und Feedback (nach Don Norman, z.B. hier) oder die Möglichkeit Aktionen zu widerrufen. Hier muss unser Sprachinterface Unterstützung anbieten. Interessante Lösungen bietet bspw. Siri in iOS, wie in nachfolgendem Bild ersichtlich.

Farbgebung und visuelle Gestaltung

Der letzte Punkt, der den Entwurf wesentlich beeinflusst ist die visuelle Gestaltung. Hier möchte ich kurz auf die Farbgebung eingehen: Aus der Verhaltenspsychologie wissen wir, das verschiedene Farben unterschiedliche anregende und emotionale Effekte besitzen. Gesättigte warme Farben, z.B. rote Töne wirken dabei an- und aufregend, Grün- und Blautöne eher entspannend (J. Lopez, 2023 in diesem Blogpost). Naheliegend wäre auch ein Interface in Graustufen. Jedoch kommt dieses sehr trist daher. Deshalb verwenden wir ein Monochromen Blauton als Grundfarbe mit subtilen weißen Akzenten. Andere Farben werden nur verwendet, wenn eine Notwendigkeit besteht, so zum Beispiel bei Fotos oder in Warnungen (bspw. destruktive Aktionen), um die Usability zu erhöhen. 

Wir nehmen das aktuelle iOS als Grundlage und wollen dies weiterentwickeln. Weitere Mittel für eine gute Erfahrung sind die Einführung einer subtilen Dreidimensionalität, um die Usability zu erhöhen, die potentiell unter der monochromen Farbgebung leidet oder aber das Nutzen von Leuchtkanten und „Glows“ um eine entspannte, aber nicht langweilige Atmosphäre zu erzeugen.

Entwurf

Navigation

Die entscheidende Änderung zum jetztigen iOS (und anderen mobilen Betriebssystemen) ist, dass wir auf die Hub-and-Spoke (nach Frank rausch hier) Navigation verzichten und zwischen Funktionen und Apps lediglich über ein Sprach-Interface wechseln. Hierfür brauchen wir neben dem Interface für die Audioaufnahme auch ein Interface für eine Texteingabe. Nicht jede Person kann oder mag in jeglicher Situation sprechen.

Auch der direkte „previous-App“/„next-App“ wechseln, wie beim iPhone gewohnt sollte möglich bleiben für eine schnelle und einfache Navigation. Wir wollen uns an den jetzigen Konventionen von iOS orientieren, um einen imaginäre Einstieg ins neue iOS ohne Hürden zu ermöglichen.

Im Ergebnis bleibt das „nach-oben-Wischen“ vom unteren Bildschirmrand die Haupt-Navigationsgeste. Hierbei landen wir jedoch nicht auf dem Homescreen (den es ja nicht mehr gibt), sondern wir flicken unsere Tastatur ins Bild.

Unsere Navigations-Tastatur weist die Besonderheit auf, dass sie ein großes Inputfeld und vor allem einen großen Send button hat. Visuell „schwebt“ die Tastatur über der geöffneten App, die durch Verdunkelung und Verschwimmen in den Hintergrund rückt und Platz für unser Navigationsinterface freimacht.

Wir brauchen jedoch eine Möglichkeit stattdessen auch die Sprachnavigation aufzurufen. Das lange drücken auf den Power-Button ist nicht mehr geeignet, wie es bei Siri der Fall ist. Die Funktion ist die gleiche, wie bei der Tastatur, sollte also auch den gleichen Interaktionsmustern folgen.

Wir erweitern deshalb die Gestik am unteren Bildschirmrand um ein „Drücken-und-Halten“ (Drücken in diesem Fall ein minimaler Swipe in den Bildschirm rein). Vergleichbar ist die Interaktion in erster Linie mit dem Aufnehmen von Sprachnachrichten oder dem Filmen aus der Fotoeinstellung der Kamera. Wir können, wie bei Siri jedoch auch loslassen, das Interface bleibt uns erhalten.

Das Interface der Sprachnavigation erinnert an Siri in unserer monochromen, durch Leuchtkanten akzentuierten Gestaltung. Wie im vorherigen Kapitel genannt, gibt es (wie bei iOS) eine Art Tooltip am Interaktionselement, um den/die NutzerIn zu unterstützen (Stichwort Discoverablity).

Lassen uns also interagieren. Wir müssen uns zwischen zwei Arten von Aktionen entscheiden, um die wir unsere mobilen Assistenten bitten können: Aktion oder Navigation. Die Aktion ist bereits teilweise im heutigen Siri vorhanden und erfordert vor allem bei Kommunikation andere (strengere) Maßnahmen als die Navigation. Wir müssen nämlich sicherstellen, dass das Telefon richtig verstanden hat, was wir meinen. Hierfür brauchen wir also Feedback, in diesem Fall „ich habe es so und so verstanden“ und die Möglichkeit der Bestätigung. So können wir, wie im unteren Beispiel direkt aus unserer Navigation kommunizieren, aber auch, wie im rechten angeschnitten Screen dann in die Messages App navigieren.

Wir erinnern uns: In diesem Konzept, haben wir zur Reduktion von Triggern und Komplexität alle Kommunikationskanäle (Whatsapp, Mobile, Instagram, ...) und Formate (Call, Videocall, Message) in einer App zusammengefasst – im Endeffekt können wir all diese Möglichkeiten auf die Übermittlung von Informationen von A nach B reduzieren, wobei wir hier genau dieses „von A nach B“ in den Vordergrund rücken wollen.

Visuell erinnert die App in Struktur und visueller Gestaltung wieder an iOS, genauer Phone und Whatsapp. Die entscheidenden beiden Unterschiede: Wir sehen nicht per Default alle unsere bereits beantworteten Nachrichten als erste View (warum auch), sondern lediglich unsere neuen Anfragen (requests), also verpasste (Video-)Anrufe und Nachrichten. Hierbei ist es irrelevant über welchen Kanal diese uns erreicht haben.

Wollen wir über einen bestimmten Kanal mit Person B, z.B. Joana Williams kommunizieren, gehen wir über ihren Kontakt in unsere Kanäle/Historie und wählen den entsprechenden Kanal aus.

Warum Kanäle?
Wäre es wohl das einfachste, wenn es nur einen Video-Call, einen Anruf-Kanal und einen Messenger gäbe, so gibt es in der Realität unzählige, die alle parallel genutzt werden und auch verschiedene Use Cases haben. Da unsere Kontakte also diese verschiednen Kanäle benutzen können wir nicht bspw. alle Nachrichten in einen Chat „kippen“, sondern müssen diesen Kanälen entsprechen.

Wenn wir über die Shortcuts im mittleren Bild Joana erreichen wollen werden wir nicht jedes mal gefragt, sondern kontaktieren sie über unseren üblichen Kanal (den letzten/häufigsten?).

Wir haben also eine Trigger-freie Navigation geschaffen und die Konzepte auch in eine App übertragen. Würde man dieses Konzept fortführen erhielten wir ein Betriebssystem, deutlich stärker integriert mit den Apps, als gewohnt. 

Vision

Da es im Endeffekt darum geht unsere nicht notwendige und nicht gewollte Screentime zu reduzieren (uns selbst wieder in den Fahrersitz des virtuellen Verhaltens zu setzen) muss dieses Betriebssystem auch kein Allumfassendes Angebot an Apps und Funktionen bieten – sondern nur die notwendigen.

Im radikalen Fall gäbe es so also keinen App-Store, wir erinnern uns an die Zeiten des Nokia 3210 – auch hier waren die Funktionen in engem Rahmen vorgegeben – jedoch rundum erneuert und erweitert.

So könnten wir also alle Funktionen einer bestimmten Daten(-transfer)-Art in den jeweiligen Apps integrieren. Das hieße:

• Wir haben eine Communications App. Die Interaktion zwischen zwei oder mehr Personen ist hier der gemeinsame Nenner. Erinner wir uns also an die aus der Umfrage essentielle Notwendigkeit für Online Banking/ Paypal, so könnte die Communications App also auch zum Senden von Geld dienen (vgl. z.B. WeChat)
• Gleiches gilt für unsere Maps App. Denkt man erstmal nur an Orte und Routen könnte ich aich mein Car/Bike-Sharing hier unterbringen oder Find my Frieds/Objects. Der gemeinsame Nenner sind hier die Geo-Daten.

Die essenzielle Frage ist jedoch und bleibt: Ist diese Funktion notwendig?

Reflektion

Ist das Konzept Happy?

Das ist wohl die größte Frage, die ich mir stellen muss, wenn ich das Projekt reflektiere. Am Anfang des Kurses habe ich dabei über fröhliche bunte Interfaces mit lustigen Animationen nachgedacht. Als die politische und gesellschaftliche Dimension von happy jedoch im Verlauf des Semesters in den Vordergrund gerückt ist, habe ich gemerkt, dass es nicht darum geht, dass die App happy ist, sondern, dass die Person, die diese nutzt happy ist. Daraus lässt sich auch dieses Konzept ableiten: Manchmal ist man vielleicht am glücklichsten, wenn man sein Handy gar nicht erst in die Hand nimmt.

Ausarbeitung des Konzept

Stellt sich die Frage, ob es in der obigen Ausarbeitung pointiert genug auf das Problem abzielt. Hier ließe sich argumentieren, dass sich ein Fokus auf die Navigation und das Betriebssystem angeboten hätte, um dieses noch weiter zu durchdenken oder von iOS zu lösen. Andererseits ist es bei solch einem integrierten Ansatz schwierig die Aktionen, die schlussendlich durchgeführt werden sollen, komplett außer Acht zu lassen.

Zudem könnte man meinen, dass das Konzept bereits existiert. Ich nehme vermehrt Bezug auf existierende Betriebssysteme und Anwendungen, wie iOS, Siri, Whatsapp und WeChat. Der eigentliche Kern des Projektes ist es jedoch diese existierende Lösungen so auszuhöhlen, zu separieren und neu zusammenzufügen, dass ein besseren Ganzes entsteht – im Kontext unserer heutigen Nutzungskonventionen.

Mir hat dieses Projekt extrem viel Spaß gemacht – vor allem das stetige Hinterfragen heutiger Lösungen und der Einbezug der Theorien um das _Hooked_-Modell oder die Verhaltenspsychologie. Und auch die Ableitungen aus diesen Theorien für das visuelle Interface, z.B Farbgebung, Typo, Icons, Informationsstruktur, waren eine angenehme Herausforderung.

Appendix: Screencast