Wie gestaltet man eine mobile App?

Kurz gesagt

App-Design ist nicht die verkleinerte Version eines Desktop-Screens. Auf dem Handy gibt es keine Maus und deshalb auch kein Menü, das beim Darüberfahren aufgeht. Der Nutzer tippt mit dem Finger, und der Finger ist ein viel gröberes Werkzeug als der Mauszeiger.

Wenn ich mir einen mobilen Screen ansehe, stelle ich vier Fragen. Sind die Ziele groß genug für den Finger? Liegen die Hauptaufgaben dort, wo der Daumen hinkommt? Was passiert, wenn die Aufgabe unterbrochen wird? Was zeigt der Screen, wenn das Netz langsam wird?

Dazu kommen die Regeln der Plattformen. Apple und Google veröffentlichen eigene Designleitfäden. Und Nutzer bringen Gewohnheiten aus den anderen Apps auf ihrem Handy mit. Eine App, die diesen Gewohnheiten folgt, muss man nicht erst lernen.

• Tippziele: unter iOS 44 × 44 pt, unter Android 48 × 48 dp. Im Web mindestens 24 × 24 CSS-Pixel.
• Navigation: wenige Hauptbereiche, unten und immer sichtbar.

Was auf dem Handy anders ist

Am Desktop sitzt der Nutzer meist und hat beide Hände frei. Auf dem Handy ist nichts davon sicher. Die meisten meiner Designentscheidungen ergeben sich aus diesem Unterschied.

Tippen

Der Finger verdeckt einen Teil des Screens, und den Punkt, den er berührt, sieht der Nutzer nicht. Kleine, dicht gesetzte Ziele führen deshalb zu Fehltipps. Hover, also der Zustand, wenn der Zeiger über einem Element liegt, gibt es auch nicht. Ein Hinweis, der am Desktop mit der Maus erscheint, erscheint auf dem Handy nie.

Das häufigste Beispiel in meinen Audits ist ein kleines Papierkorb-Icon in einer Listenzeile. Das Icon ist klein, und ein Tipp auf die Zeile öffnet das Detail. Der Nutzer will löschen und landet im Detail, oder umgekehrt.

Eine Hand

Wer im Bus steht, hält das Handy mit einer Hand und bedient es mit dem Daumen. Die oberen Ecken sind dann am schwersten zu erreichen. Häufige Aktionen setze ich in die untere Hälfte des Screens.

Einen Hauptbutton wie die Zahlungsbestätigung in die obere rechte Ecke zu setzen, zwingt den Nutzer, das Handy in die zweite Hand zu nehmen. Steht derselbe Button unten in voller Breite, drückt man ihn mit einer Hand.

Unterbrechung

Mobile Nutzung passiert in Stücken. Eine Mitteilung kommt, oder der Nutzer steigt an seiner Haltestelle aus. Ist das Formular bei der Rückkehr leer, beginnt die Arbeit von vorn.

Deshalb teile ich lange Formulare in Schritte und speichere die Eingaben auf dem Gerät. Kommt der Nutzer zurück, sieht er den Schritt, bei dem er aufgehört hat. Bei langen Aufgaben wie einem Kreditantrag oder einem Behördenformular spürt man den Unterschied sofort.

Tastatur und Formular

Öffnet sich die Tastatur, verdeckt sie einen großen Teil des Screens. Ein „Weiter“-Button unten kann hinter der Tastatur verschwinden. Beim Gestalten eines Formulars zeichne ich den Zustand mit offener Tastatur als eigenen Screen.

Die richtige Tastatur zu öffnen, ist ebenfalls Aufgabe des Designs. Im Feld für die Telefonnummer erscheint die Zifferntastatur, im E-Mail-Feld die Tastatur mit @. Eine falsche Tastatur bedeutet in jedem Feld ein paar zusätzliche Tipps. Das beschreibe ich im Muster Tastatur in mobilen Formularen.

Automatisches Ausfüllen lasse ich an. Bei Feldern wie Adresse oder Einmalcode kann das Handy die Angabe selbst vorschlagen. Diese Felder sollte man nicht mit eigenen Komponenten kaputt machen.

Netz

Im Aufzug oder in der U-Bahn verliert das Handy die Verbindung. Das Design muss auch diesen Moment abdecken. Ich zeichne „Lädt“ und „Keine Verbindung“ als eigene Screens und setze in den zweiten einen Button „Erneut versuchen“.

Der gefährlichste Moment ist ein Verbindungsabbruch mitten in einer Transaktion wie einer Überweisung. Weiß der Nutzer nicht, ob sie durchgegangen ist, drückt er den Button erneut. Der Screen muss den Status klar nennen und den zweiten Druck verhindern.

Größe der Tippziele

Ein Tippziel ist die Fläche, die der Nutzer mit dem Finger drücken kann. Das sichtbare Icon kann klein sein, die tippbare Fläche ist größer. Drei Quellen nennen drei verschiedene Maße für diese Fläche.

• 24 × 24 CSS-Pixel. WCAG 2.2, 2.5.8 (AA)
• 44 × 44 pt. Apple, Standard unter iOS
• 48 × 48 dp. Android und Material

Abbildung: Die Quadrate sind auf dieser Seite in CSS-Pixeln gezeichnet. pt und dp sind andere Einheiten, ich stelle sie nur nebeneinander, um eine Vorstellung zu geben.

Apple: 44 × 44 pt

Im Abschnitt Barrierefreiheit der Human Interface Guidelines von Apple steht eine Tabelle. Laut Tabelle ist die Standardgröße eines Bedienelements unter iOS und iPadOS 44 × 44 pt, die Mindestgröße 28 × 28 pt. Apple empfiehlt, auf jeder Plattform die empfohlene Mindestgröße zu erreichen.

Derselbe Abschnitt nennt auch Abstände zwischen Bedienelementen. Um Elemente mit Rahmen empfiehlt er etwa 12 pt, um die sichtbare Kante rahmenloser Elemente etwa 24 pt. Ziel ist, das Risiko zu senken, dass der Nutzer das falsche Element trifft.

Android und Material: 48 × 48 dp

Die Dokumentation von Android Developers empfiehlt für jedes interaktive Element einer Touch-Oberfläche eine Tippfläche von mindestens 48 × 48 dp. Sie fügt hinzu, dass größer besser ist. Die Compose-Dokumentation verbindet diese Grenze von 48 dp mit den Barrierefreiheitsregeln von Material Design.

Fertige Material-Komponenten bringen diese Größe von selbst mit. Eine interaktive Checkbox etwa kommt durch zusätzlichen Abstand auf mindestens 48 dp. Bauen Sie eine eigene Komponente, müssen Sie die Größe selbst festlegen.

WCAG 2.2: 24 × 24 CSS-Pixel

Für das Web und für Apps mit Web-Ansichten gilt der Standard WCAG 2.2 des W3C. Das Kriterium 2.5.8 Zielgröße (Minimum) liegt auf Stufe AA. Es verlangt, dass ein Ziel mindestens 24 × 24 CSS-Pixel groß ist.

Das Kriterium hat fünf Ausnahmen. Es gilt nicht, wenn kleine Ziele mit genug Abstand stehen, wenn ein anderes passendes Bedienelement dieselbe Funktion hat oder wenn das Ziel ein Link in einem Satz ist. Ausgenommen sind auch Bedienelemente, deren Größe der Browser bestimmt, und Fälle, in denen die Darstellung wesentlich ist.

Es gibt auch ein strengeres Kriterium: 2.5.5 Zielgröße (erweitert). Dieses Kriterium auf Stufe AAA verlangt 44 × 44 CSS-Pixel. Das W3C empfiehlt, dieses strenge Kriterium für wichtige Links und Bedienelemente anzustreben.

Welches Maß nehmen?

Für mich sind 24 Pixel die Untergrenze, 44 und 48 das Ziel. In einer nativen iOS-App nehme ich 44 pt, unter Android 48 dp. In einer webbasierten oder plattformübergreifenden App wähle ich 48, weil das über beiden Plattformen liegt. Mehr dazu im Muster Tippbereich.

Ist ein Screen voll, versuche ich zuerst, die Aufgaben auf dem Screen zu reduzieren, bevor ich Icons verkleinere. Ziele zu verkleinern ist meist die Antwort auf die falsche Frage.

Unterschied zwischen iOS und Android

Die Regeln der beiden Plattformen ähneln sich, sind aber nicht gleich. Nutzer wechseln nicht täglich vom iPhone zu Android. Deshalb erwarten sie die Gewohnheiten ihres eigenen Handys.

Thema	iOS	Android
Tippziel.	44 × 44 pt als Standard.	Mindestens 48 × 48 dp.
Navigation unten.	Tab-Leiste, schwebt über dem Inhalt.	Navigationsleiste, drei bis fünf gleich wichtige Ziele.
Zurück.	Standard-Zurück-Button, oben.	Zurück-Geste oder Taste des Systems.
Titel.	Großer Titel, wird beim Scrollen kleiner.	Titel in der oberen Leiste.

Wie Zurück funktioniert

Der größte Unterschied liegt beim Zurück-Verhalten. Apple empfiehlt, den Standard-Zurück-Button zu nutzen und nicht „Zurück“ darauf zu schreiben. Nutzer wissen, dass dieser Button eine Ebene zurück in der Informationshierarchie führt.

Unter Android ist Zurück Sache des Systems. Laut Android Developers haben die meisten Geräte eine physische, softwarebasierte oder gestengesteuerte Zurück-Funktion. Deshalb rät die Dokumentation, in der App meist keinen eigenen Zurück-Button einzubauen.

Mit Android 13 kam die vorausschauende Zurück-Geste. Beim Zurückwischen sieht der Nutzer eine Vorschau, wohin er zurückkehrt. Ab Android 15 laufen diese Systemanimationen in Apps, die die Unterstützung aktivieren, standardmäßig.

Titel

Laut Apple hilft der Titel dem Nutzer zu bestätigen, wo er in der App ist. Apple empfiehlt, Titel unter 15 Zeichen zu halten, damit Platz für die anderen Bedienelemente bleibt. Der große Titel wird zum Standardtitel, sobald der Nutzer zu scrollen beginnt.

Unter Android steht der Titel in der oberen App-Leiste. Laut Android Developers trägt diese Leiste meist einen Titel.

Im Deutschen ist diese Regel oft eine Herausforderung. „Meine Kontobewegungen“ hat 21 Zeichen, „Umsätze“ nur 7. Weil deutsche Wörter durch Zusammensetzungen lang werden, schreibe ich Titel schon im ersten Entwurf kurz.

Gemeinsames oder getrenntes Design?

In Teams mit begrenztem Budget gehe ich gern mit einem Design auf beide Plattformen. Marke und Inhalt bleiben gleich. Navigation und Zurück-Verhalten folgen auf jeder Plattform deren eigener Sprache.

Navigationsmuster

Die Navigation sagt dem Nutzer, wo er in der App ist und wohin er gehen kann. Auf dem Handy nutze ich vor allem drei Muster: die Tab-Leiste unten, die Stapelnavigation und das Menü.

Tab-Leiste unten

Die Hauptbereiche der App liegen unten am Screen und sind immer sichtbar. Apple empfiehlt, die Tab-Leiste für Navigation zu nutzen, nicht für Aktionen. Für eine Aktion auf dem Screen empfiehlt Apple die Werkzeugleiste.

Außerdem empfiehlt Apple, die Zahl der Tabs klein zu halten und einen Tab „Mehr“ für überzählige Bereiche zu vermeiden. Inhalte in versteckten Tabs sind schwerer zu erreichen. Unter Android wird die Navigationsleiste auf schmalen Screens für drei bis fünf gleich wichtige Ziele empfohlen.

Dazu kommt eine Regel zur Sichtbarkeit. Laut Apple kann der Nutzer vergessen, in welchem Bereich er ist, wenn die Tab-Leiste ausgeblendet wird. Die einzige Ausnahme ist eine modale Ansicht, die die Tab-Leiste vorübergehend verdeckt.

Stapelnavigation

Der Nutzer geht von der Liste ins Detail, von dort in ein Unterdetail und mit Zurück wieder hinaus. In einer Banking-App von der Kontenliste zum Beleg einer einzelnen Buchung zu gehen, ist ein Beispiel für dieses Muster.

Hier achte ich auf die Tiefe. Ist der Nutzer vier, fünf Screens tief, muss er mit einem Tipp in den Hauptbereich zurückkommen. Ein Tipp auf den Tab unten erledigt das.

Hamburger-Menü

Das Menü hinter dem Icon mit drei Strichen spart Platz, hat aber einen Preis. In der NN/g-Studie von 2016 nutzten mobile Nutzer versteckte Navigation in 57 % der Fälle. Im Design, das sichtbare und versteckte Navigation kombinierte, lag der Wert bei 86 %.

Derselbe Artikel empfiehlt, bei vier oder weniger Hauptlinks diese sichtbar zu zeigen. Auch ich verstecke Hauptbereiche nicht hinter dem Hamburger. Ins Menü kommen nur selten genutzte Seiten wie Einstellungen oder rechtliche Texte.

Im Beispiel unten sehen Sie denselben Screen auf zwei Plattformen.

Ein Screen, zwei Plattformen

iOS

‹Zurück

Meine Karten

• Girokarte•••• 4821
• Kreditkarte•••• 0937
• Virtuelle Karte•••• 5512

ÜbersichtKartenZahlenProfil

Android

Meine Karten

• Girokarte•••• 4821
• Kreditkarte•••• 0937
• Virtuelle Karte•••• 5512

ÜbersichtKartenZahlenProfil

◁ Zurück: Geste oder Taste des Systems

Derselbe Banking-Screen auf zwei Plattformen. Wählen Sie iOS oder Android: Tab-Leiste, Zurück und Titel ändern sich. Die Screens sind Beispiele und stammen aus keiner echten App.

Inhalt und Farben bleiben auf beiden Screens gleich. Anders sind die Form der Tab-Leiste, das Zurück-Verhalten und die Position des Titels. Sieht der Nutzer die Form seines eigenen Handys, muss er nicht überlegen, was zu tun ist.

Wie gestaltet man eine mobile App?

1. 1. AufgabeWas der Nutzer auf dem Handy erledigt
2. 2. AblaufReihenfolge der Screens, auf Papier
3. 3. WireframeMit einer Hand, in echter Größe
4. 4. PrototypAuf dem Handy, mit dem Finger
5. 5. TestMit Netz und Unterbrechungen

Abbildung: Mein Prozess für mobiles Design in Kurzform. Die sieben Schritte unten beschreiben denselben Prozess genauer.

1. Schreiben Sie die Aufgabe auf. Welche Aufgabe will der Nutzer erledigen, wenn er die App öffnet? „Ich bezahle meine Rechnung“ ist eine Aufgabe, „Finanz-App“ ist keine. Ich schreibe die drei wichtigsten Aufgaben in je einem Satz auf.

2. Zeichnen Sie den Ablauf auf Papier. Für jede Aufgabe zeichne ich die Reihenfolge der Screens als Kästen. Hier fallen die Entscheidungen der Informationsarchitektur: Welcher Bereich wird ein Tab, welcher ein Unterscreen?

3. Machen Sie das Wireframe in echter Größe. Beim Wireframe halte ich den Rahmen auf Handybreite. Ziele zeichne ich von Anfang an mit 44 oder 48 Einheiten. Später zu vergrößern, bringt das Layout durcheinander.

4. Probieren Sie den Prototyp auf dem Handy aus. Ein Prototyp, der am Computer gut aussieht, fühlt sich in der Hand ganz anders an. Ich öffne den Prototyp auf dem Handy und nutze ihn mit einer Hand und im Stehen.

5. Zeichnen Sie die schwierigen Zustände. Leere Liste, Lädt, Keine Verbindung, Fehler. Jeder ist ein eigener Zustand und geht als eigene Zeichnung an die Entwicklung.

6. Testen Sie mit Nutzern. Ich gebe ein paar Personen die Aufgabe und schaue zu, wie sie sie auf dem Handy erledigen. Ich notiere, wo sie stocken und wo sie danebentippen.

7. Passen Sie an die Plattform an. Das gemeinsame Design gehe ich für iOS und Android getrennt durch. Zurück-Verhalten und Navigationsleiste trennen sich in diesem Schritt.

Wenn Sie gerade mit App-Design anfangen, überspringen Sie die ersten beiden Schritte nicht. Es ist verlockend, sofort Screens zu zeichnen. Sind Aufgabe und Ablauf aber nicht klar, dienen schöne Screens der falschen Arbeit.

Häufige Fehler

Das Desktop-Design verkleinern. Ein dreispaltiges Panel in eine Spalte zu reihen, ist kein mobiles Design. Auf dem Handy muss man neu entscheiden, welche Aufgabe zuerst kommt.

Die Hauptaktion in die obere Ecke setzen. Bleiben Buttons wie Speichern oder Senden in der oberen Ecke, sind sie mit einer Hand schwer zu erreichen. Die Hauptaktion gehört in die Nähe des Daumens.

Nur mit Icons navigieren. Nicht jeder weiß, was ein Icon ohne Label tut, deshalb setze ich in Tabs unten einen kurzen Text unter das Icon.

Leere und fehlerhafte Zustände vergessen. In der Designdatei ist jede Liste voll. Im echten Leben ist die Liste eines neuen Nutzers leer, und dieser Screen prägt den ersten Eindruck.

Das Zurück-Verhalten der Plattform brechen. Verlässt die System-Zurück-Geste unter Android die App unerwartet, verliert der Nutzer seine Arbeit. Gibt es beim Verlassen eines Formulars ungespeicherte Eingaben, sollte die App zuerst nachfragen.

Nur auf neuen Handys testen. Das Team nutzt meist neue, schnelle Geräte. Ein Teil der Nutzer kommt mit einem kleinen, alten Handy und schwacher Verbindung.

Meine Notiz

Das Problem, das ich in mobilen Audits am häufigsten finde, hat mit Unterbrechung zu tun. Der Nutzer verlässt die App, kommt zurück und beginnt von vorn. Das Team sieht das am Tisch, im Test ohne Unterbrechung, nie.

Auf Platz zwei kommen die Verbindungszustände. Das Lade-Icon dreht sich ewig, oder es erscheint nie eine Fehlermeldung. Ich zähle diese Screens zum eigentlichen Design und zeichne sie im ersten Entwurf.

Und das empfehle ich: Nutzen Sie das Design jede Woche einmal auf dem Handy, in der U-Bahn oder beim Gehen. Die meisten Probleme, die Sie am Tisch nicht bemerken, zeigen sich dort.