Mobil denken: Einsatzort, Daumen und Screens

Worum es geht

Dario ist im 3. Lehrjahr bei der Valbau AG in Landquart. Die Poliere schreiben ihre Tagesrapporte auf Papier und tippen sie abends im Büro ab, rund 45 Minuten pro Tag und Person. Darios Auftrag: eine App, mit der Rapporte direkt auf der Baustelle erfasst werden.

Seine erste Idee liegt nahe: Das bestehende Rapportformular aus dem Intranet hat 22 Felder auf einer Seite. Man könnte es einfach kleiner machen und aufs Handy bringen. Dann begleitet Dario einen Polier einen Vormittag lang auf eine Baustelle in Schiers, und die Idee ist erledigt. Der Polier trägt Arbeitshandschuhe, steht in grellem Sonnenlicht, hält das Handy mit einer Hand, weil er in der anderen einen Plan hat, und wird alle drei Minuten unterbrochen. Im Untergeschoss hat er kein Netz.

Eine mobile App ist kein kleiner Desktop. Sie wird an anderen Orten, in anderen Haltungen und mit anderen Zielen benutzt. In dieser Lektion lernst du, vom Einsatzort her zu denken: Du analysierst die Nutzungssituation, leitest daraus wenige, fokussierte Screens ab, legst Hauptaktionen in den Daumenbereich und planst eine Navigation, die man ohne Nachdenken bedienen kann. Das alles passiert, bevor du ein Framework öffnest. Genau das wird im üK und im Kompetenznachweis auch erwartet: erst Konzept, dann Code.

Was am Smartphone anders ist

Stell dir vor, du sollst ein Rezept für ein Picknick schreiben statt für eine Restaurantküche. Die Zutaten sind ähnlich, aber alles muss transportierbar sein, mit einer Hand gegessen werden können und darf bei Hitze nicht kaputtgehen. Mit Apps ist es genauso: Die Technik ist verwandt mit dem Web, die Bedingungen sind völlig andere.

Daraus ergibt sich der Grundsatz Mobile First: Du entwirfst zuerst für den kleinsten, schwierigsten Fall und erweiterst dann für grössere Bildschirme. Wer vom Desktop aus verkleinert, schleppt Felder und Funktionen mit, die unterwegs niemand braucht.

Den Nutzungskontext erfassen

Bevor du Screens zeichnest, beantwortest du fünf Fragen. Am besten nicht am Schreibtisch, sondern dort, wo die App später benutzt wird.

• Wer? Rolle, Erfahrung mit Smartphones, Sprache, Sehvermögen.
• Wo? Draussen, drinnen, im Fahrzeug, im Keller. Licht, Lärm, Netz.
• Wann und wie lange? Kurz zwischendurch oder konzentriert am Stück? Wie oft am Tag?
• Womit? Eigenes Gerät oder Firmengerät, iPhone oder Android, Handschuhe, Schutzhülle.
• Wozu? Welche zwei oder drei Aufgaben müssen schnell und fehlerfrei klappen?

Dario hält seine Beobachtungen in einem Kontext-Steckbrief fest:

Kontext-Steckbrief Rapport-App (Beobachtung Baustelle Schiers)
Wer:     Poliere, 35 bis 60 Jahre, sicher im Telefonieren und Fotografieren
Wo:      im Freien, teils grelles Licht; Untergeschosse und Tunnel ohne Netz
Wann:    mehrmals täglich kurz (Fotos, Notizen), Rapport am Feierabend auf der Baustelle
Womit:   Firmengeräte: iPhone 13 und robuste Android-Geräte, oft mit Handschuhen
Wozu:    1. Tagesrapport erfassen  2. Mangel mit Foto dokumentieren  3. Rapport absenden

Jede Zeile führt später zu einer konkreten Designentscheidung. «Handschuhe» bedeutet grosse Schaltflächen. «Kein Netz» bedeutet lokale Speicherung. «Mehrmals täglich kurz» bedeutet, dass die App beim Öffnen sofort dort weitermacht, wo der Polier aufgehört hat.

Daumenbereich und Touch-Ziele

Halte dein Handy mit einer Hand und versuche, mit dem Daumen alle Ecken des Bildschirms zu erreichen. Die Mitte und der untere Bereich gehen mühelos, die oberen Ecken nur mit Verrenken oder gar nicht. Diese Zone nennt man Daumenbereich (Thumb Zone). Bei grossen Geräten ist der bequeme Bereich kleiner, als die meisten denken.

+---------------------------+
|  schwer     schwer   schwer|   oben: Titel, Infos, selten genutzte Aktionen
|                           |
|  mittel     mittel   mittel|   Mitte: Inhalte, Listen, Formularfelder
|                           |
|  leicht     leicht   leicht|   unten: Hauptaktion, Tab-Leiste
+---------------------------+

Daraus folgen drei Regeln:

1. Die Hauptaktion eines Screens (Speichern, Absenden, Foto aufnehmen) liegt unten, gut erreichbar.
2. Gefährliche Aktionen wie Löschen liegen nicht direkt neben der Hauptaktion und brauchen eine Bestätigung.
3. Informationen, die man nur liest, dürfen oben stehen.

Wie gross ist gross genug?

Ein Finger ist kein Mauszeiger. Beide grossen Plattformen geben deshalb Mindestgrössen für antippbare Elemente vor:

pt (Points) und dp (density-independent pixels) sind geräteunabhängige Einheiten. Ein Gerät mit vielen Pixeln pro Zoll zeichnet ein 48-dp-Element mit mehr echten Pixeln, damit es physisch etwa gleich gross bleibt, rund 7 bis 9 mm. Auf Android gilt: Bei 160 dpi ist 1 dp genau 1 Pixel. Allgemein:

Pixel = dp × (dpi ÷ 160)

Beispiel: Gerät mit 420 dpi
48 dp × (420 ÷ 160) = 48 × 2.625 = 126 Pixel

Auf iPhones gibt es feste Faktoren (@2x, @3x): 44 pt sind auf einem @3x-Gerät 132 Pixel. In React Native und Flutter rechnest du gar nicht in Pixeln, sondern direkt in diesen geräteunabhängigen Einheiten. Eine width: 48 in React Native bedeutet 48 dp bzw. 48 pt.

Die Mindestgrössen sind Untergrenzen für normale Bedingungen. Mit Arbeitshandschuhen trifft niemand ein 44-pt-Feld zuverlässig. Dario legt deshalb für die Rapport-App eine eigene Team-Regel fest: Hauptaktionen mindestens 56 dp hoch, mindestens 8 dp Abstand zwischen antippbaren Elementen.

Lesbar bei Sonne

Kontrast ist auf der Baustelle keine Stilfrage. Die Web-Richtlinie WCAG verlangt für normalen Text ein Kontrastverhältnis von mindestens 4.5 : 1. Im Sonnenlicht reicht auch das oft knapp. Setze auf dunkle Schrift auf hellem Grund (oder umgekehrt), Schrift ab 16 pt für Fliesstext, keine hellgrauen Hinweistexte und keine Information, die nur über Farbe transportiert wird. Ein roter Rahmen allein reicht nicht, es braucht auch einen Text wie «Pflichtfeld».

Wenige Screens, klare Navigation

Navigation beantwortet zwei Fragen: Wo bin ich? Wie komme ich weiter und zurück? Auf dem Smartphone haben sich wenige Muster durchgesetzt, die alle Nutzenden kennen. Erfinde hier nichts Neues.

Ein Stack funktioniert wie ein Stapel Teller: Jeder neue Screen kommt oben drauf, Zurück nimmt den obersten weg. In den meisten Apps werden die Muster kombiniert: Die Tabs bilden den Rahmen, und in jedem Tab gibt es einen eigenen Stack.

Achte auf die Konventionen der Plattformen. Android-Nutzende gehen mit der System-Zurück-Geste oder -Taste zurück, iPhone-Nutzende wischen vom linken Rand. Material Design (Google) und die Human Interface Guidelines (Apple) beschreiben diese Muster genau. Beide lohnt es sich einmal durchzublättern.

Schritt für Schritt: Dario skizziert die Rapport-App

Schritt 1: Die Hauptaufgaben festlegen. Aus dem Steckbrief übernimmt Dario die drei Aufgaben, die schnell und fehlerfrei klappen müssen: Tagesrapport erfassen, Mangel mit Foto dokumentieren, Rapport absenden. Alles andere (Statistiken, Profil, Archiv) kommt nicht in die erste Version.

Schritt 2: Screens ableiten. Pro Hauptaufgabe ein Screen, dazu der Einstieg. Für jeden Screen hält er Zweck und Hauptaktion fest:

Schritt 3: Navigation festlegen. Die vier Bereiche sind gleichwertig und werden ständig gewechselt, also Tab-Navigation unten. Von der Baustellenliste führt ein Stack zum Baustellendetail. Das Foto wird in einem Modal aufgenommen, weil es eine kurze, abgeschlossene Aufgabe ist.

Schritt 4: Den wichtigsten Screen als Wireframe skizzieren. Dario zeichnet den Rapport-Screen auf Papier und überträgt ihn danach in Figma:

+-------------------------------+
| Rapport  Mo, 05.10.2026       |  oben: nur Information
| Baustelle: Schulhaus Schiers  |
+-------------------------------+
| Arbeitsstunden   [  8,5   ]   |  Felder in der Mitte,
| Personal         [  4     ]   |  je mindestens 56 dp hoch
| Material         [ ...    ]   |
| Bemerkungen      [ ...    ]   |
+-------------------------------+
| [     RAPPORT SPEICHERN     ] |  Hauptaktion unten, volle Breite
+-------------------------------+
| Baust. | Rapport | Fotos | Send|  Tab-Leiste
+-------------------------------+

Schritt 5: Gegen die Kriterien prüfen. Dario geht seine Skizze mit einer Checkliste durch:

• Hauptaktion im Daumenbereich? Ja, unten über der Tab-Leiste.
• Touch-Ziele mindestens 56 dp? Ja, auch die Tabs.
• Mit einer Hand bedienbar? Ja, bis auf das Tippen in die Felder.
• Kontrast? Schwarze Schrift auf Weiss, Hauptbutton dunkelblau mit weisser Schrift.
• Weniger als fünf Tabs? Ja, vier.

Schritt 6: Mit echten Personen testen. Er zeigt den Papierprototyp zwei Polieren und lässt sie «einen Rapport für heute erfassen». Ergebnis: Beide suchen das Datum oben und wollen es ändern können. Dario macht das Datum antippbar. Fünf Minuten Test haben einen Umbau nach der Programmierung erspart.

Typische Fehler

1. Das Desktop-Formular verkleinern. 22 Felder auf einem Screen sind auf dem Handy eine Scroll-Wüste. Frag bei jedem Feld: Braucht es das unterwegs wirklich, oder kann es das Büro ergänzen?
2. Hauptaktion oben rechts. «Speichern» in der Kopfzeile ist am Desktop üblich, mit einer Hand aber kaum erreichbar. Lege sie unten in den Daumenbereich.
3. Sieben Tabs oder ein Hamburger-Menü für alles. Mehr als fünf Tabs werden unübersichtlich, ein Drawer versteckt Hauptfunktionen. Reduziere auf das Wesentliche.
4. Nur am Schreibtisch testen. Sonne, Handschuhe und Unterbrechungen merkst du nur vor Ort. Ein halber Tag Begleitung bringt mehr als eine Woche Vermutungen.
5. Plattform-Konventionen ignorieren. Wer auf Android die Zurück-Geste nicht sauber behandelt oder eigene, unbekannte Gesten erfindet, verwirrt die Nutzenden.

Zusammenfassung

• Eine mobile App ist kein kleiner Desktop: Platz, Eingabe, Umgebung, Netz, Akku und Unterbrechungen sind anders. Entwirf Mobile First.
• Erfasse den Nutzungskontext (wer, wo, wann, womit, wozu) vor Ort und leite daraus Designentscheidungen ab.
• Touch-Ziele mindestens 44 pt (iOS) bzw. 48 dp (Android), mit Handschuhen grösser, mit Abstand dazwischen.
• Die Hauptaktion gehört in den Daumenbereich unten, gefährliche Aktionen nicht daneben.
• Tabs für gleichwertige Hauptbereiche, Stack für Liste und Detail, Modal für kurze, abgeschlossene Aufgaben.
• Wenige, fokussierte Screens schlagen viele halbfertige. Teste Skizzen früh mit echten Nutzenden.