Ein Produkt, zwei Screens: eine mobile App und die Web-App dahinter gestalten

Die App, die alle sehen

Die App bekommt die Aufmerksamkeit, und das zu Recht. Sie muss schnell, klar und angenehm sein, denn Menschen nutzen sie aus der Tasche, in Eile und ohne Geduld für Ungeschicktes. Der Großteil des Designbudgets und fast die ganze Begeisterung fließen dorthin.

Aber jeder Tipp in dieser App hängt von etwas hinter den Kulissen ab. Jemand muss die Inhalte veröffentlichen, die sie zeigt, Konten freigeben, Support-Tickets beantworten und sehen, was bei Tausenden Nutzern passiert. Ist das zentrale System schwach, wirkt die App sehr schnell nicht mehr magisch, weil die Menschen, die sie betreiben, einfach nicht hinterherkommen.

Das System, das niemand erwähnt

Zentrale Systeme sind selten glamourös. Es sind Tabellen, Formulare, Filter, Rollen und Änderungsprotokolle, die ein kleines Team viele Stunden am Tag nutzt. Die Nutzer sind keine Konsumenten, die die App löschen können; es sind Kollegen, die sie nutzen müssen, ob sie wollen oder nicht. Das verändert die Prioritäten: Klarheit schlägt Charme, Arbeitstempo schlägt visuelle Überraschung, und Konsistenz zählt mehr als irgendwo sonst.

Bezahlbar heute, bereit für später

Kunden wollen meist, dass das zentrale System günstig ist, und das ist berechtigt: In frühen Phasen sollte Geld dorthin fließen, wo Nutzer es sehen. Der Trick ist, es günstig zu machen, ohne es zur Sackgasse zu machen. Die erste Version gestalte ich um die Handvoll Aufgaben, die das Team vom ersten Tag an wirklich braucht, und lasse klaren Raum für Späteres, etwa neue Rollen, neue Module und neue Märkte, ohne davon schon etwas zu bauen.

Dieser Raum ist strukturell, nicht visuell. Eine Navigation, die neue Bereiche aufnehmen kann, ein Rechtemodell, das wachsen kann, Layouts, die eine Tabelle mit zehn Zeilen oder zehntausend verkraften. Wenn es Zeit zum Skalieren ist, wird das System erweitert statt neu gebaut.

Warum die Wahl der Bibliotheken die halbe Arbeit erledigt

Die wichtigste Entscheidung, und die am häufigsten zu leichtfertig getroffene, ist die Technologie und Komponentenbibliothek hinter dem zentralen System. Wählen Sie eine ausgereifte, gut gepflegte Bibliothek, und ein riesiger Teil der Arbeit ist schon erledigt: Tabellen mit Sortierung und Filter, Formularvalidierung, Datumsauswahl, barrierefreie Dialoge, vernünftige Standards. Wählen Sie schlecht oder bauen Sie alles von null, und das Team verbringt Monate damit, Vorhandenes neu zu erfinden.

Deshalb bin ich früh an dieser Entscheidung beteiligt, gemeinsam mit den Entwicklern. Wir wählen eine Grundlage, die zum Stack passt, und dann gestalte ich darin, indem ich ihre Komponenten an die Tokens des Produkts anpasse, statt gegen sie zu kämpfen. Mit einem gemeinsamen Token-Set kann dieselbe visuelle Sprache durch App und zentrales System laufen, selbst wenn sie mit verschiedenen Technologien gebaut sind. Das Ergebnis sieht aus wie ein Produkt, kostet einen Bruchteil einer Eigenentwicklung und ist viel leichter zu pflegen.

Zwei Screens, ein Produkt

Von außen sehen App und zentrales System wie zwei verschiedene Produkte aus. Von innen sind sie zwei Gesichter desselben, und sie funktionieren am besten, wenn sie gemeinsam gestaltet werden, mit geteilter Sprache, Logik und Tokens. Die App bekommt den Applaus. Das zentrale System bringt dem Kunden Ruhe. Ich gestalte gern beides und habe gelernt, dass eine gute Entscheidung, still im Backoffice getroffen, oft mehr zählt als ein schöner Screen vorne.