Greybox

Ein physisches Detox-Gerät, das Menschen dazu bringt, das Handy wirklich liegen zu lassen.

Greybox ist ein eigenständiges Gerät mit LED-Ring, Display und Drehregler. Man legt sein Smartphone in die Erkennungszone, stellt eine Fokusdauer ein und startet. Greift jemand während der Session in die Zone, reagiert das Gerät sofort: rotes Licht, Ton, und die Zeit verlängert sich. Die Konsequenz ist physisch spürbar statt wegwischbar.

Auf einen Blick


Rolle	Solo – Konzeption, Interaktionsdesign, Hardware-Prototyp, 3D-Modell, Web-Demo
Zeitraum	Okt 25 - Feb 26
Kontext	Semester Modul zu Mensch Maschinen Kommunikation
Methodik	Design Solutions: Konzeptuelle Modellierung → Informationsarchitektur → Interaktionsarchitektur → Interface-/Informationsdesign → Sensorisches Design
Tools	Figma, Arduino, Autodesk Fusion 360, Astro, Tailwind CSS, Obsidian
Ergebnis	Funktionsfähiger Hardware-Prototyp + interaktive Web-Demo + dokumentierter Designprozess

Meine drei wichtigsten Beiträge

Ein vollständiges Interaktionsmodell aus Nutzungskontextanalyse abgeleitet
- von der Anforderungsermittlung bis zur maschinenlesbaren State-Logik.
Ein Feedbacksystem entworfen: Licht, Ton und Zeit als Sprache des Geräts.
Das Konzept in drei Medien überführt: Arduino-Prototyp, 3D-Modell, interaktive Web-Demo.

01 Problem & Ausgangslage

Warum Software-Lösungen hier nicht reichen

Digitale Fokus-Apps scheitern an einem strukturellen Problem: Sie laufen auf genau dem Gerät, von dem sie ablenken sollen. Jede Sperre ist zwei Taps entfernt vom Umgehen. Es gibt keine soziale und keine körperliche Reibung.

Greybox verlagert die Kontrolle deshalb aus dem Smartphone heraus in ein separates physisches Objekt. Die Regel gilt nicht mehr, weil eine App sie durchsetzt, sondern weil ein Gerät auf dem Tisch sichtbar mitzählt.

Was ich betrachte und was bewusst nicht

Im Scope: das Gerät selbst, seine Zustandslogik, sein sensorisches Feedback, die Erkennungszone
Schnittstellen: Smartphone als abzulegendes Objekt
Bewusst ausgeschlossen: Cloud-Sync, Nutzerkonten, Statistik-Auswertung über längere Zeit

02 Nutzungskontextanalyse

Wer nutzt so ein Gerät und wozu?

Erhebung des Nutzungskontexts nach ISO 9241-210 entlang von vier Dimensionen: Benutzer, Aufgaben & Ziele, Umgebung, Ressourcen.

Durchführung von 4 Interviews.

Hauptpersona

Mara Hellwig, 22, Studentin Technik-Niveau: hoch, Smartphone dauerhaft griffbereit

Mara arbeitet an ihrer Hausarbeit und merkt, dass sie alle paar Minuten reflexartig zum Handy greift, ohne erdenklichen Anlass, sondern eher Reflexartig. Fokus-Apps hat sie ausprobiert und nach zwei Tagen deaktiviert. Sie sucht keine Motivationshilfe, sondern eine Hürde, die sie nicht in zwei Sekunden wegklicken kann.

Aufgabenmodell – Hauptaufgabe


Benutzergruppe	Studierende / Wissensarbeitende
Aufgabe	Ununterbrochen fokussiert arbeiten
Vorbedingung	Nutzer sitzt am Schreibtisch, Smartphone liegt außerhalb der Hand-Zone
Teilaufgaben	1) Modus wählen 2) Fokusdauer einstellen 3) Session starten 4) Zone während der Session nicht betreten 5) Bei Störung: Feedback und Zeitstrafe verstehen 6) Session-Ende abwarten und Objekt entnehmen
Nachbedingung	Der Nutzer hat eine ablenkungsfreie Arbeitsphase abgeschlossen

Nutzungsszenario

Mara startet eine 25-Minuten-Session. Der LED-Ring pulsiert ruhig. Nach sieben Minuten greift sie reflexartig in die Zone – der Ring blinkt rot, ein kurzer Ton, der Timer verlängert sich um 30 Sekunden. Sie zieht die Hand zurück. Als die Zeit abgelaufen ist, wechselt der Ring auf ruhiges Pulsieren: Die Box wartet jetzt darauf, dass sie das Handy bewusst entnimmt.

03 Anforderungen

Aus Nutzungskontextanalyse und Aufgabenmodell habe ich Erfordernisse abgeleitet und in prüfbare Nutzeranforderungen überführt.

Beispiel für die Ableitung

Erfordernis: Der Nutzer muss merken, dass eine Störung Konsequenzen hat. Nutzeranforderung (NA7/NA8): Der Benutzer muss am System erkennen können, dass eine Störung registriert wurde und welche Konsequenz das auslöst.

Auszug aus dem Anforderungskatalog

ID	Anforderung
NA1	Der Benutzer muss erkennen können, welcher Modus verfügbar ist.
NA2	Der Benutzer muss auswählen können, welcher Modus aktiviert wird.
NA3	Der Benutzer muss erkennen können, wo die Zeit eingestellt wird.
NA4	Der Benutzer muss auswählen können, wie lang die Session dauert.
NA5	Der Benutzer muss erkennen können, wo der Start-Befehl ausgeführt wird.
NA7	Der Benutzer muss erkennen können, wenn eine Störung registriert wurde.
NA8	Der Benutzer muss erkennen können, welche Konsequenz ausgelöst wurde.
NA9	Der Benutzer muss erkennen können, wann die Session beendet ist.
NA10	Der Benutzer muss am System erkennen können, dass der Timer bei 0
NA11	Der Benutzer muss am System erkennen können, dass jetzt der Gegenstand entnommen werden darf.
NA12	Der Benutzer muss erkennen können, welcher Platz/Teilnehmer verstöße hatte (optional).

Interaktionsspezifikation

Teilaufgabe	Handlung des Benutzers	Reaktion des Systems	NA
Modus wählen	Wählt Timer oder Reminder	Display markiert Auswahl	NA1, NA2
Dauer einstellen	Dreht den Encoder	Zeit und LED-Preview aktualisieren sich	NA3, NA4
Session starten	Drückt den Encoder	Countdown startet, LED-Ring pulsiert	NA5, NA6
Störung	Greift in die Zone	Ring wird rot, Ton, Zeit verlängert sich	NA7, NA8
Session-Ende	Wartet bis 00:00	Ring wechselt in Warte-Puls	NA9, NA10
Entnahme	Nimmt das Objekt aus der Zone	Sensor erkennt Entnahme, System springt zurück	NA11

04 Informationsarchitektur

Aufgabenobjekte statt Screens

Die Architektur ist nicht aus Bildschirmen gedacht, sondern aus den Objekten, mit denen der Nutzer tatsächlich umgeht. Daraus ergeben sich Attribute, ausführbare Funktionen und die Navigationsstruktur.

Aufgabenobjekt	Attribute (Auszug)	Funktionen (Auszug)
Fokus-Session	Modus, geplante Dauer, Restzeit, Verlängerung gesamt, Anzahl Verstöße, Status	einstellen, starten, pausieren, fortsetzen, abbrechen
Zone (LED-Ring)	Zonenstatus, LED-Farbe, Sensorstatus	überwachen, Störung erkennen, Feedback ausgeben
Regelset	Verlängerung pro Störung, Feedbacktyp, Strenge-Stufe	auswählen, anpassen
Feedbackelement	Art, Intensität, Bedeutung	Warnsignal, Erfolgssignal, Statusanzeige

05 Interaktionsarchitektur

Die State-Logik als Kern des Geräts

Das gesamte Verhalten ist auf fünf Zustände reduziert. Jeder Zustand definiert genau, was der Nutzer sieht, was er darf und was er bewusst nicht darf.

BOOT ──click──► SET ──click──► RUN ──0:00──► WAIT ──Entnahme──► SET
                                  │  ▲
                              click│  │click
                                  ▼  │
                                 PAUSE

Zustand	Zweck	Nutzer sieht	Nutzer darf	Nutzer darf nicht
BOOT	Einstieg	`Click to START`	klicken	Zeit ändern
SET	Zeit wählen	`MM:00`, LED-Preview	drehen, klicken	pausieren
RUN	Countdown	Restzeit, LED-Progress	pausieren, Reset (long-press)	Zeit ändern
PAUSE	Unterbrechen ohne Reset	Restzeit eingefroren	fortsetzen, Reset	Zeit ändern
WAIT	Sperrzustand nach Ablauf	`00:00`, ruhiger Puls	Objekt entnehmen	per Tastendruck raus

Zwei Regeln, die das System tragen

Input-Regel: Zeit lässt sich ausschließlich in SET ändern. Kein Zustand kann sich selbst untergraben.
Exit-Regel: WAIT endet nur durch ein reales Ereignis am Sensor, nie durch einen Knopfdruck. Sonst wäre das ganze Konzept optional.

Zwei Modi

Timer: Nutzer stellt eine Fokusdauer ein, das Gerät zählt herunter.
Reminder: Über das RTC-Modul löst das Gerät zu festen Uhrzeiten aus

06 Interface- & sensorisches Design

Ein Gerät, das ohne Text auskommt

Das Display trägt nur die nötigsten Informationen. Die eigentliche Kommunikation läuft über den LED-Ring, den Ton und die Zeit selbst.

Signal	Bedeutung
Ruhiges Pulsieren	Session läuft, alles in Ordnung
Abnehmender Ring	Fortschritt – wie viel Zeit noch bleibt
Rotes Blinken + Ton	Störung erkannt, Zeit wurde verlängert
Ruhiger Puls bei 00:00	Fertig, aber noch gesperrt – Entnahme erforderlich

Gestaltungsentscheidungen

Ein einziges Bedienelement (Drehen + Drücken) statt Tastenfeld: weniger Lernaufwand, weniger Fehlbedienung.
Strafe als Zeit, nicht als Punktzahl: Die Konsequenz trifft genau die Ressource, um die es geht.
Keine Erfolgsmeldungen, kein Gamification-Layer: Das Gerät belohnt nicht, es hält nur den Rahmen.

07 Prototyp & Umsetzung

Hardware

Komponente	Funktion
Mikrocontroller	Steuerung der State-Logik
LED-Ring	Zonendarstellung, Fortschritt, Feedback
Display	Timer, Modus, Zustandshinweis
Rotary Encoder	Zeit einstellen, bestätigen, pausieren
RTC-Modul	Zeitbasis für den Reminder-Modus
Sensorik	Erkennung von Belegung und Störung in der Zone
Buzzer	akustisches Warn- und Abschlusssignal

3D-Modell

Gehäuse in Autodesk Fusion 360 modelliert – Zonenfläche, LED-Aussparung und Displayträger als eigene Körper, um Licht und Anzeige sauber zu trennen.

Das Gehäuse bestand aus Holz.

Das Grundgehäuße (unterer Teile) aus Massiverem Holz, wie von einer Kiste
Der oberer Teil, für das Display bestand aus dünnerem, Lasergeschnittenem Material.

Alle Bauteile wurden miteinander verklebt und Zusammen genagelt.

Interaktive Web-Demo

Die vollständige State-Logik ist als Web-Demo nachgebaut, sodass sich das Gerät ohne Hardware bedienen lässt. Umgesetzt in Astro und Tailwind CSS mit beiden Modi und der kompletten Zustandsmaschine.

🔗 https://pixelninja0.github.io/greybox-demo/

08 Ergebnis & Reflexion

Was entstanden ist

Ein funktionsfähiger Hardware-Prototyp mit vollständiger Zustandslogik
Ein 3D-Modell des Gehäuses
Eine interaktive Web-Demo
Eine durchgängige Dokumentation vom Nutzungskontext bis zur Umsetzung

Was ich gelernt habe

Das Zusammenbauen war gar nicht einfach. Vor allem der Teil mit dem Sensor
Das code war anfangs noch überschaubar, verlor über zeit jedoch an Übersicht

Was ich anders machen würde

Mir mehr Zeit mit dem Bauen einplanen.
Den von Anfang an gut Strukturieren

Nächste Schritte

Die nächsten Schritte wären, aus dem Prototypen ein fertiges Produkt zu bauen, weitere Nutzergruppen hinzuziehen und eine Aufwändigere Usability Studie durchführen.
Für den Rahmen des Projekts bildet der Prototyp jedoch das Ende.

Anhang

Diese Seite ist eine verdichtete Übersicht. Die ausführliche Prozessdokumentation mit allen Zwischenständen, Anforderungen und Iterationen liegt auf Anfrage separat vor.