Disziplinen 02 · Mobile Apps
Mobiles Design macht jede Entscheidung sichtbar. Der knappe Raum zwingt Hierarchie, Navigation und Interaktion, sich ihren Platz zu verdienen. Ich erkunde iOS und Android als eine Aufgabe — Interface-Konzepte und funktionierende Prototypen, die Gestaltung und Umsetzung als eine einzige Disziplin behandeln.
01 · Was das ist
Eine App, die Menschen auf dem Telefon öffnen: das Interface, die Abläufe zwischen den Screens, die Zustände, an die beim Zeichnen niemand denkt, und die kleinen mechanischen Entscheidungen, durch die sie sich anfühlt, als gehöre sie auf das Gerät — und nicht wie eine zusammengedrückte Website. Gestaltung und Umsetzung sind hier eine Aufgabe, nicht zwei — was vor allem an den Nahtstellen zählt, denn an den Nahtstellen gehen bei einer Übergabe Dinge verloren.
Der größte Teil der Kosten einer App steckt nicht im Zeichnen. Er steckt in den Entscheidungen, die fallen, bevor irgendetwas gezeichnet ist, und in den Zuständen, die erst auftauchen, wenn etwas schiefgeht.
Abläufe, nicht Screens
Ein Screen ist schnell gezeichnet und billig zu diskutieren. Ob eine App etwas taugt, entscheidet der Weg zwischen den Screens — und was auf dem Zweig passiert, über den niemand nachdenken wollte.
ein Daumen
Ein Telefon wird gehalten, meist mit einer Hand, oft schlecht. Die primäre Aktion liegt innerhalb des Bogens, den ein Daumen erreicht; die destruktive ganz bewusst nicht.
dynamische Schriftgröße
Jemand hat sie aus gutem Grund in den Systemeinstellungen festgelegt. Layouts werden so gebaut, dass sie mitwachsen, statt sie abzuschneiden — das Abschneiden ist der häufigste Barrierefreiheitsfehler auf einem Telefon.
lokal zuerst
Arbeit im Zug ist trotzdem Arbeit. Was lokal gespeichert wurde, wird als gespeichert angezeigt, was den Server noch nicht erreicht hat, als ausstehend — und keines gibt sich als das andere aus.
zwei Plattformen
Zurück ist auf der einen Plattform eine Geste und auf der anderen eine Leiste; die primäre Aktion sitzt an anderer Stelle. Der Plattform zu entsprechen ist kein Kompromiss am Design — es ist Teil davon.
das Release
Bauen, einreichen, warten. Das Listing vorzubereiten und eine Einreichung durchzubringen ist eine eigene kleine Disziplin, und ein Review-Prozess erlaubt nicht alles — das wird früh benannt statt später ausdiskutiert.
02 · Die Zustände
Fast jede App wird in dem Zustand entworfen, in dem alles funktioniert hat: Die Inhalte kamen an, das Netz war da, das Konto existierte. In den anderen vier entscheiden Menschen tatsächlich, ob sie die App behalten. Alle fünf werden gezeichnet, bevor irgendetwas gebaut wird.
Der erste Screen, den fast alle sehen — und den fast niemand gestaltet. Er muss sagen, wofür das hier ist, und genau eine nächste Handlung anbieten.
Geformt wie das, was gleich kommt, damit das Layout nicht springt, wenn es eintrifft. Ein Spinner mitten auf einem leeren Screen sagt nichts außer: bitte warten.
Der aus dem Pitch-Deck. Er ist der einfachste der fünf, und er ist der Grund, warum die anderen vier übersprungen werden.
Was fehlgeschlagen ist, in Worten, und was sich dagegen tun lässt. Nie ein Code, nie ein Achselzucken, und immer ein Weg zurück, der nicht das erzwungene Beenden ist.
Ein wahrer Satz für jeden Screen. Was im Cache liegt, bleibt lesbar und ist als Cache markiert; was eine Verbindung braucht, sagt das. Ein Spinner, der nie zum Ende kommt, ist der Grund, aus dem Apps gelöscht werden.
03 · Die Methode
Jede App, die sich lohnt, beginnt als diese Abfolge — ausgeschrieben und durchgestritten, solange Streiten noch nichts kostet. Das dauert einen Nachmittag, und es ist der günstigste Nachmittag des Projekts.
04 · Worauf ich prüfe
Gleiche Größe, gleiches Gewicht, beide Spalten. Zu wissen, wo die Kanten eines Builds liegen, ist genauso eine Designentscheidung wie alles innerhalb davon.
05 · Die Fragen
Weil zwei Apps, die im selben Satz beschrieben werden, in ihrer tatsächlichen Komplexität eine Größenordnung auseinanderliegen können — und eine bloße Screen-Zahl das meiste davon verdeckt.
Was das treibt, ist kein Geheimnis. Wie viele Screens es wirklich sind, sobald Leer- und Fehlerzustände mitgezählt werden. Ob etwas gespeichert wird, und wo. Ob sie mit einem System sprechen muss, das bereits existiert. Ob es einen Login gibt — und damit ein Konto, das sich wiederherstellen lassen muss. Ob sie in einen Store geht oder in beide. Und wie lange eine Review-Warteschlange dauert, wenn sie dort ankommt — was niemand in der Hand hat. Diese sechs Fragen sind der Ort, an dem das Nachdenken tatsächlich beginnt.
Einen Teil dessen, was eine App braucht, und nicht alles davon — es lohnt sich, genau zu benennen, was wozu gehört, statt beides zu verwischen.
Was sie beweisen: Interface-Arbeit, Ablaufgestaltung, Tastatur- und Screenreader-Disziplin, das Zeichnen jedes Zustands statt nur des glücklichen, und die Gewohnheit, aufzuschreiben, warum eine Entscheidung gefallen ist. Was sie nicht beweisen: Store-Einreichung, Gerätefragmentierung und ein Release, das in der Review-Warteschlange von jemand anderem endet. Der ehrliche Test: Öffnen Sie einen beliebigen der zehn Builds und lesen Sie seinen Interaktionscode — warum der Fokus dorthin geht, wo er hingeht, was bei einer langsamen Verbindung passiert, was der Reduced-Motion-Pfad tut und warum. Das ist dieselbe Arbeit, im Browser statt im Store, und sie läuft genau jetzt.
06 · Die Arbeiten
Keines davon ist eine App. Es ist die Interaktionsarbeit, aus der eine App besteht, alles eigeninitiiert, und jedes ist live — mit einem Text darüber, was sich gewehrt hat.
Vollständig per Tastatur bedienbares Interface · 2026. Eine Befehlspalette, die sich wie eine verhält: Fokus gehalten, solange sie offen ist, Pfeiltasten, Scroll gesperrt, Fokus beim Schließen zurückgegeben.
Touch und Pointer · 2024. Pointer Capture sauber umgesetzt — ein Ziehen, das nicht abreißt, wenn der Finger das Element verlässt. Genau das ist der Fehler, mit dem jeder handgebaute Slider ausgeliefert wird.
Gezeichnetes Interface, keine Assets · 2022. Fortschrittsringe und Zähler in SVG gezeichnet statt als Bilder ausgeliefert, auf einem gemeinsamen Observer statt einem pro Element.
Die zehn Builds ansehen — alle eigeninitiiert, alle live, alle mit offenem Quellcode.
Mobile Apps
Eine App gibt es hier noch nicht, aber jedes Prinzip auf dieser Seite — Zustände, Abläufe, Tastatur- und Screenreader-Disziplin — läuft bereits in den zehn. Die Projekte zeigen dieselbe Disziplin in der Anwendung.
