Warum nennt der Case keine Kunden- oder Produktnamen?

Der Case ist anonymisiert: echte Arbeit, aber keine Kunden-, Produkt- oder Markennamen, und die Screens sind aus Vertraulichkeitsgründen unscharf dargestellt. Die Industriekunden, die die App einsetzen, nennen wir nur nach Sektor. Im Erstgespräch können wir Vorgehen und Artefakte im Detail zeigen, soweit es die Vereinbarungen erlauben.

Wie funktioniert das Multi-Brand-Theming in der Praxis — und was muss unser Engineering dafür tun?

Komponenten binden ausschließlich an semantische Tokens; diese referenzieren eine Markenschicht, die als Figma Variables mit Modes gepflegt wird. Eine neue Marke bedeutet: einen Modus anlegen, rund drei Markenfarben setzen, Logo tauschen. Tints, Zustände, Schatten und Typografie leiten sich daraus ab. Das Engineering erhält die Token-Struktur und den dokumentierten Prozess und kann Marken ohne Designbeteiligung aufsetzen.

Warum offline-first, wenn unsere Werke WLAN haben?

Weil der kritische Moment die Störung am Schaltschrank ist — Hände belegt, Empfang schwach oder weg. Eine App, die genau dann nicht speichert, verliert das Vertrauen des Technikers. Offline-first mit sichtbarem Sync-Status funktioniert bei gutem WLAN genauso gut; umgekehrt gilt das nicht.

Lässt sich das Vorgehen auf unsere HMI-, MES- oder Instandhaltungssoftware übertragen?

Ja. Die drei Bausteine — ein klar definierter schlechtester Nutzungsmoment, eine Informationsarchitektur entlang der physischen Anlage und ein token-basiertes Designsystem — sind unabhängig vom konkreten Produkt. Sie passen überall dort, wo Bediener unter Druck arbeiten und ein Anbieter dasselbe Produkt an viele Werke oder Kundenmarken ausliefert.

Was hat EN 62402 mit einer mobilen App zu tun?

EN 62402 beschreibt das Obsoleszenzmanagement: wie Unternehmen damit umgehen, dass Bauteile vom Hersteller abgekündigt werden, während die Anlage sie noch braucht. Die App macht genau diese Information im Feld sichtbar — Status, Abkündigungsdatum und empfohlene Nachfolger pro Komponente —, damit die Instandhaltung planen kann, statt bei der Störung zu suchen.

Wie läuft ein solches Projekt mit Beabstracto ab?

Typischerweise in dieser Reihenfolge: Ist-Analyse im Feld mit den Bedienern, Informationsarchitektur und Bedienkonzept, Prototyp und Hi-Fi-Flows je Plattform, Designsystem mit Tokens und Modi, dann der Handoff mit Dokumentation für das Engineering. Wo es der Zeitplan erlaubt, prüfen wir Flows vor dem Handoff mit echten Nutzern.

Industrie · Mobile Instandhaltungs-App (iOS/Android)

Eine Instandhaltungs-App, die am Schaltschrank funktioniert — und unter jeder Kundenmarke.

Für einen Anbieter, der seine App an viele Industriekunden verkauft, haben wir eine Offline-first-App für iOS und Android entworfen, mit der Techniker den Zustand elektronischer Komponenten in Sekunden erfassen und lesen. Ein token-basiertes Designsystem liefert dieselbe App unter vielen Industriemarken aus: Eine neue Marke ist eine Konfiguration, kein Redesign.

Erstgespräch vereinbaren Wie wir vorgegangen sind

Unscharf dargestellter Startbildschirm der mobilen Instandhaltungs-App: Werksfoto, zwei große Aktionsflächen zum Erfassen und Suchen von Komponenten und ein Link zum Scannen

Kunde: Anbieter einer Instandhaltungs-App für Industrieanlagen (anonymisiert, NDA)
Branche: Industrielle Instandhaltung · Obsoleszenzmanagement (EN 62402)
Rolle: Product/UX-Design Ende zu Ende: Feld-Research, Informationsarchitektur, Hi-Fi-Flows, Designsystem, Handoff
Systeme: iOS (HIG), Android (Material), Figma Variables & Modes

Kurz gesagt

Ein Anbieter von Instandhaltungssoftware für Industrieanlagen wollte eine mobile App, mit der Techniker den Zustand elektronischer Komponenten — Lebenszyklus, Abkündigung, Nachfolger — direkt am Schaltschrank erfassen und lesen, und dieselbe App unter den Marken vieler Industriekunden verkaufen. Wir haben das Product-Design Ende zu Ende übernommen: Feldkontext, Informationsarchitektur, Hi-Fi-Flows für iOS und Android, ein token-basiertes Designsystem mit Figma-Modi pro Marke und den Handoff an das Engineering. Die App ist live und wird in Produktion von Herstellern aus Luftfahrt, Automotive, Stahl, Lebensmittel und Konsumgütern eingesetzt; eine neue Marke wird per Modus umgeschaltet statt neu gestaltet.

Wer HMI-, MES- oder Instandhaltungssoftware an viele Werke verkauft, kennt beide Probleme: Die Bedienung muss im schlechtesten Moment funktionieren, und das Produkt muss skalieren, ohne dass jede Kundenmarke ein eigenes Design bekommt. Dieser Case zeigt, wie beides zusammen gelöst wurde.

Zahlen

Die Projektzahlen stammen aus den Projektaufzeichnungen und der Designsystem-Dokumentation; die Marktzahl zum Stillstand ist eine externe Quelle und dient der Einordnung.

~70 / Std.
Komponenten, die ein Techniker vor Ort mit QR-Scan und geführter Fotoerfassung registriert: 1 Modus
schaltet die gesamte App auf eine neue Kundenmarke um — rund drei Markenfarben und ein Logo: 38
Farb-Tokens, dazu eine Typografie-Skala für iOS, Android und Web sowie tokenisierte Schatten: 1,4 Bio. USD
kostet ungeplanter Stillstand die 500 größten Unternehmen weltweit pro Jahr — rund 11 % ihres Umsatzes

Ausgangslage

Was war die Ausgangslage? Ein Instandhaltungsteam, das im Feld nicht sehen kann, was in seinen Schaltschränken steckt — und ein Anbieter, der seine App an viele Werke unter deren eigener Marke verkaufen will.

In einer großen Industrieanlage kann ein einziges ausgefallenes elektronisches Bauteil eine ganze Linie stoppen. Wie teuer das wird, zeigt eine Branchenzahl: Ungeplanter Stillstand kostet die 500 größten Unternehmen der Welt schätzungsweise 1,4 Billionen US-Dollar pro Jahr, etwa 11 % ihres Umsatzes (Quelle: The True Cost of Downtime, Siemens, 2024). Trotzdem wissen viele Instandhaltungsteams nicht genau, welche Komponenten verbaut sind, wo sie sitzen, in welcher Lebenszyklusphase sie sich befinden und ob der Hersteller sie bald abkündigt.

Genau darum geht es beim Obsoleszenzmanagement nach EN 62402: Ein Bauteil gilt als obsolet, sobald der Hersteller es nicht mehr in der ursprünglichen Spezifikation liefert, obwohl die Anlage es weiterhin braucht — und wer das erst bei der Störung erfährt, hat kein Ersatzteilproblem, sondern ein Beschaffungsproblem. Für den Instandhalter heißt das: Jede Komponente hat ein Abkündigungsdatum, einen Status und idealerweise einen empfohlenen Nachfolger. Diese Informationen waren nicht an einem Ort, zu dem der Techniker vor Ort greifen konnte; es fehlte ein verlässlicher Platz, um eine Komponente zu erfassen und nachzuschlagen.

Die Persona ist der Instandhaltungstechniker im Werk. Sein kritischer Moment ist nicht die Demo im Besprechungsraum, sondern die Störung um drei Uhr nachts: Die Linie steht, er steht vor dem geöffneten Schaltschrank, hat die Hände mit Werkzeug belegt oder Handschuhe an, und das WLAN in der Halle ist schwach oder gar nicht vorhanden. In diesem Moment sucht er — statt zu reparieren.

Die zweite Seite der Ausgangslage ist das Geschäftsmodell des Anbieters. Die App sollte nicht für ein einzelnes Werk gebaut, sondern als ein Produkt an viele Industriekunden verkauft werden — jeweils unter deren eigener Marke, mit eigenen Farben und eigenem Logo. Jede Marke als eigene Design-Variante zu pflegen, hätte das Produkt mit jedem Neukunden teurer und langsamer gemacht.

Unsere Rolle umfasste das Product-Design Ende zu Ende: Research und Feldkontext, Informationsarchitektur, vollständige Hi-Fi-Flows für iOS und Android, das Designsystem samt Multi-Brand-Architektur und den Handoff an das Engineering des Anbieters. Der Case ist anonymisiert: keine Kunden-, Produkt- oder Markennamen; die Screens sind aus Vertraulichkeitsgründen unscharf dargestellt.

Unscharf dargestellter Screen der Anlagenstruktur: Breadcrumb oben, eine Liste von Ebenen der Anlage mit Sync-Symbolen pro Zeile und eine Aktionsfläche unten — Die Anlagenstruktur in der App: Jede Zeile ist ein realer Ort im Werk, nicht ein abstrakter Ordner.

Das Problem

Was war das Problem? Eigentlich zwei, die sich gegenseitig verschärfen: Die Komponentengesundheit war im Feld unsichtbar, und das Produkt musste unter vielen Marken skalieren, ohne das Design zu forken.

Komponentengesundheit ist unsichtbar
Was verbaut ist, wo es sitzt, wie alt es ist und ob es abgekündigt wurde — all das war im Werk nicht auf einen Blick verfügbar. Die Folge: Bei einer Störung sucht das Team nach Informationen, statt die Reparatur anzugehen. Und ein Bauteil, dessen Abkündigung niemand kannte, ist im Ernstfall nicht nachbestellbar.
Tippen am Schaltschrank ist langsam und fehleranfällig
Hersteller, Artikelnummer, ERP-Nummer, Position im Schrank: Diese Daten von Hand ins Telefon zu tippen, dauert und produziert Fehler — erst recht mit Handschuhen, schlechtem Licht und einer stehenden Linie im Rücken.
Kein verlässlicher Ort zum Erfassen und Nachschlagen
Die Teams fanden nicht den richtigen Platz, um eine Komponente zu registrieren oder ihren Zustand zu lesen. Die Information lag verstreut und war nicht digitalisiert. Ohne eine Struktur, die zum Werk passt, landet jede Erfassung irgendwo — und ist beim nächsten Mal nicht auffindbar.
Eine Anlage mit Tausenden Teilen lesbar machen
Hallen, Linien, Schaltschränke, Felder, Tausende Komponenten und ihre Abkündigungsdaten: Das Ganze auf einem Telefon scannbar zu machen, verlangt eine Informationsarchitektur, die dem physischen Rundgang entspricht — nicht der Tabellenstruktur der Datenbank.
Offline ist der Normalfall, nicht die Ausnahme
In vielen Hallen ist der Empfang schwach oder nicht vorhanden. Eine App, die beim Speichern eine Verbindung braucht, ist für diesen Einsatz nicht brauchbar. Gleichzeitig muss der Techniker wissen, was gesichert ist und was noch nicht.
Ein Produkt, viele Marken, kein Fork
Dieselbe App sollte unter der Identität vieler Industriekunden verkauft werden. Das Design für jede Marke neu zu zeichnen oder die Codebasis zu forken, wäre nicht skalierbar gewesen — jede neue Marke hätte ein kleines Redesign bedeutet.

Wie wir vorgegangen sind

Wie sind wir vorgegangen? Jede wesentliche Entscheidung haben wir als Problem → Entscheidung → Warum festgehalten, damit Produktmanagement und Engineering nachvollziehen konnten, weshalb ein Screen so aussieht und nicht anders. Die Phasen: Feldkontext und Ist-Analyse, Informationsarchitektur, Erfassungs-Flow, Offline-Konzept, Lesen der Komponentengesundheit, Designsystem, plattformkorrekte Hi-Fi-Flows und Handoff.

1
Feldkontext und Ist-Analyse
Zuerst haben wir den Moment definiert, für den die App gebaut wird: die Störung um drei Uhr nachts, Techniker am Schaltschrank, Hände belegt, kein Netz. Dieses Bild wurde zum Prüfstein für jede Entscheidung — nicht die Demo im Konferenzraum. Daraus folgte das Grundprinzip: Wenn es bei stehender Linie und ohne WLAN funktioniert, funktioniert es überall.
2
Informationsarchitektur, die die Anlage spiegelt
Instandhalter denken räumlich, also folgt die Struktur der App dem Rundgang durch das Werk: Halle → Linie oder Maschine → Schaltschrank → Komponentengruppe (zum Beispiel eine Klemmenbox) → Feld (ein Platz im Schrank) → Komponente. Der Breadcrumb ist der Weg, den der Techniker physisch gegangen ist; jede Zeile in der Liste ist ein realer Ort, nicht ein abstrakter Ordner. Die primäre Aktion — hier erfassen, hier scannen — bleibt mit dem Daumen erreichbar.
3
Erfassen in wenigen Taps: QR-Scan und geführte Fotos
Statt Teiledaten einzutippen, scannt der Techniker den QR-Code am Schaltschrank, dort wo er steht. Danach führt die App Foto für Foto durch die nötigen Ansichten — Typenschild, Außenansicht, Innenansicht, Detail —, damit unter Druck nichts vergessen wird. Ein großer Sucher und ein Auslöser mit einem Tap funktionieren auch mit Handschuhen; ein Live-Zähler zeigt, was schon erfasst ist, ohne die Kamera zu verlassen.
4
Offline-first und ein ehrlicher Sync-Status
Alles wird lokal gespeichert und synchronisiert, sobald wieder eine Verbindung besteht. Damit der Techniker dem System vertraut, zeigt die App an jedem Ordner und jedem Foto, ob es gesichert ist oder noch wartet. Offline ist hier kein Feature, sondern die Grundannahme: Erfassen jetzt, dem Sync später vertrauen.
5
Komponentengesundheit auf einen Blick
Die Detailseite beantwortet über dem Falz die einzigen zwei Fragen, die bei einer Störung zählen: Was ist das, und kann es bald ausfallen? Ein Lebenszyklus-Badge in Grün, Gelb oder Rot steht vor den technischen Daten. Darunter: Hersteller, Teile-, Artikel- und ERP-Nummern für die Bestellung, das Abkündigungsdatum und empfohlene Nachfolger mit Bestand und End-of-Life, dazu Handbuch und Datenblatt als Anhang — ohne die App zu verlassen. Die Startseite beantwortet schon vorher, was Aufmerksamkeit braucht: Anzahl registrierter und abgekündigter Teile ganz oben.
6
Ein Designsystem mit Tokens und Modi
Die Antwort auf „ein Produkt, viele Marken“ war ein Designsystem in drei Ebenen: Primitive (Grauskala, Markenfarbtöne, Feedback-Farben), semantische Tokens (Surface, Background, Text, Border) und Komponenten (Buttons, Listenzeilen, Status-Badges), die ausschließlich an semantische Tokens binden. Die Markenschicht liegt als Figma Variables mit Modes darüber. Ein Modus-Wechsel kaskadiert durch alle Ebenen. Eine neue Marke onboarden heißt: einen Modus ergänzen, rund drei Markenfarben setzen, Logo tauschen — Tints, Zustände, Schatten und Typografie leiten sich ab. Die Grauskala bleibt über alle Marken stabil.
7
Plattformkorrekte Hi-Fi-Flows und Handoff
Wir haben vollständige Hi-Fi-Flows für iOS nach den Human Interface Guidelines und für Android nach Material Design geliefert — dieselbe Journey, jeweils plattformkorrekt umgesetzt. Für das Engineering des Anbieters haben wir den Theming-Prozess dokumentiert, sodass das Team eine neue Kundenmarke selbst aufsetzen kann, ohne ein Redesign anzustoßen.

Unscharf dargestellter Screen der obersten Ebene der Anlagenstruktur mit Werksname, Statusbereich und Sektionen für Hallen und Linien — Navigation, die dem Rundgang entspricht, entfernt die Übersetzung zwischen Bildschirm und Hallenboden.

Unscharf dargestellter Kamerabildschirm der geführten Fotoerfassung mit Bezeichnung der aktuellen Ansicht oben, großem Sucher und Zähler unten — Geführte Erfassung pro Ansicht: Die App sagt, welches Foto als Nächstes dran ist.

Unscharf dargestellter Synchronisationsbildschirm mit Statusbereichen für Fotos und Komponentendaten und einer Aktionsfläche unten — Ein Sync-Status an jedem Ordner und Foto hält das System ehrlich darüber, was gesichert ist.

Artefakte

Alle Screens sind aus Vertraulichkeitsgründen unscharf; die Bildunterschriften beschreiben die Designentscheidung, nicht den verdeckten Inhalt.

Unscharf dargestellter Scan-Bildschirm mit Kamerabild, hervorgehobenem Scanrahmen um einen QR-Code und einem Hinweistext darüber — QR-Code am Schaltschrank statt manueller Suche: Der Techniker scannt dort, wo er steht.

Unscharf dargestellte Fotogalerie mit Kacheln aufgenommener Fotos, jede mit einem grünen oder roten Upload-Status und einer Kachel zum Hinzufügen — Upload-Status pro Foto: erfassen jetzt, dem Sync später vertrauen.

Unscharf dargestellte Detailseite einer Komponente mit Status-Badge oben, Bezeichnungs- und Nummernblock sowie Abschnitten für Nachfolger und Dokumente — Über dem Falz: Was ist das, und kann es bald ausfallen? Status vor Spezifikation.

Unscharf dargestellter Screen mit nach Jahren gruppierten Abschnitten und Komponentenzeilen darunter — Abkündigungsdaten pro Jahr machen aus „Ist das alt?“ eine klare Entscheidung.

Unscharf dargestellter Screen einer Komponentengruppe mit Abschnitten für Felder, Notizen und zugehörige Komponenten, einige mit roter oder gelber Statusmarkierung — Gruppierung so, wie die Teile physisch im Schrank sitzen — nicht so, wie die Datenbank sie ablegt.

Unscharf dargestellter Suchbildschirm mit Suchfeld und zwei Treffern, jeder mit Vorschaubild und farbigem Statuspunkt — Suche nach Teil oder Nummer, mit Lebenszyklus-Status direkt im Treffer.

Ergebnis

Was ist das Ergebnis? Die App ging auf iOS und Android live und läuft in Produktion bei Herstellern mehrerer Branchen — und jede neue Kundenmarke ist seither eine Konfigurationsänderung statt eines Redesigns.

Aspekt	Vorher	Nachher
Komponente erfassen	Teiledaten von Hand eintippen — langsam und fehleranfällig	QR-Scan am Schaltschrank plus geführte Fotoerfassung pro Ansicht mit Live-Zähler
Komponente finden	Kein verlässlicher Ort; Information verstreut und nicht digitalisiert	Navigation entlang der Anlage: Halle → Linie → Schaltschrank → Feld → Komponente
Lebenszyklus und Abkündigung	Unbekannt, bis die Störung sie sichtbar macht	Ampel-Status, Abkündigungsdatum und Nachfolger mit Bestand und End-of-Life über dem Falz
Arbeiten ohne Netz	Erfassung hängt vom Empfang in der Halle ab	Offline-first: lokal gespeichert, Sync bei Verbindung, Sync-Status an jedem Ordner und Foto
Was braucht Aufmerksamkeit?	Suchen statt reparieren	Startseite zeigt registrierte und abgekündigte Teile, bevor der Techniker etwas antippt
Neue Kundenmarke	Design pro Marke neu zeichnen oder forken	Einen Modus ergänzen, rund drei Markenfarben setzen, Logo tauschen — der Rest leitet sich ab

Live auf iOS und Android, in Produktion bei globalen Herstellern
Die App wird in Produktion von Herstellern aus Luftfahrt, Automotive, Stahl, Lebensmittel und Getränke sowie Konsumgütern eingesetzt. Die Kundennamen stehen unter NDA; der Case nennt deshalb nur Sektoren.
Multi-Brand zahlt sich bei jeder neuen Marke aus
Neue Kunden werden durch den Tausch von Tokens onboarded, nicht durch ein Redesign. Das Geschäftsmodell — ein Produkt, viele Marken — trägt, weil das Designsystem dafür gebaut wurde.
Field-first bleibt messbar
Mit QR-Scan und geführter Fotoerfassung registriert ein Techniker vor Ort rund 70 Komponenten pro Stunde (Projektaufzeichnungen). Der Sync-Status an jedem Ordner und Foto hält das System ehrlich darüber, was gesichert ist und was nicht.
Ein Handoff, mit dem das Engineering selbstständig weiterarbeitet
Das Team des Anbieters erhielt ein dokumentiertes System, das es pro Kunde neu einfärben kann, ohne Designer einzubinden — samt Theming-Prozess, Token-Struktur und plattformkorrekten Flows für beide Betriebssysteme.

Was wir gelernt haben

01
Für den schlechtesten Moment entwerfen, nicht für die Demo
Der entscheidende Nutzungsmoment einer Instandhaltungs-App ist die Störung mit belegten Händen und ohne Netz. Wer diesen Moment zum Prüfstein macht, trifft die richtigen Entscheidungen bei Erfassung, Navigation und Offline-Verhalten fast von selbst. Das gilt genauso für HMI, MES-Terminals und Shopfloor-Software: Der Kaufentscheider sieht die Demo, der Bediener erlebt den Ernstfall.
02
Die Informationsarchitektur gehört der Anlage, nicht der Datenbank
Wenn die Struktur der App dem physischen Rundgang folgt — Halle, Linie, Schaltschrank, Feld —, braucht der Techniker keine Übersetzung zwischen Bildschirm und Hallenboden. Softwareanbieter übernehmen oft die Struktur ihres Datenmodells in die Oberfläche; für Menschen, die räumlich denken, ist das der teuerste Umweg.
03
Multi-Brand ist eine Architekturentscheidung, keine Farbfrage
Ein White-Label-Produkt skaliert nur, wenn Komponenten nie auf rohe Farbwerte zeigen, sondern auf semantische Tokens, und diese auf eine Markenschicht mit Modi. Dann ist eine neue Marke eine Konfiguration. Was wir beim nächsten Mal von Anfang an einbauen würden: einen Token-Lint oder Visual-Regression-Check in der CI, damit ein einzelner hart codierter Farbwert keinen Marken-Modus stillschweigend bricht.
04
Offline ist nur glaubwürdig, wenn der Sync-Status ehrlich ist
Techniker vertrauen einer App erst dann, wenn sie an jedem Objekt sehen, ob es gesichert ist. Ein versteckter Sync erzeugt Doppelerfassungen und Misstrauen. Mit mehr Zeit würden wir die Field-Journey instrumentieren — Zeit bis zur Erfassung, Erfolgsquote von Offline zu Sync — und diese Daten in die Flows zurückspielen.
05
Eine Journey, zwei Plattformen — plattformkorrekt statt identisch
iOS nach HIG und Android nach Material zu bauen, kostet im Design wenig und spart im Feld viel: Die Bedienmuster entsprechen dem, was der Techniker von seinem Telefon kennt. Offen bleibt die Qualität der Feldfotos, die stark schwankt; eine leichte Aufnahmehilfe im Gerät (Ausrichtung, Blendung) und eine gemessene Wiederholungsquote wären der nächste Schritt.

Was wir geliefert haben

Feldkontext und Nutzungsszenario (die Störung um drei Uhr nachts) als Entscheidungsgrundlage
Entscheidungslog im Format Problem → Entscheidung → Warum
Informationsarchitektur in sechs Ebenen, die die physische Anlage spiegelt
Erfassungs-Flow mit QR-Scan und geführter Fotoerfassung pro Ansicht
Offline-first-Konzept mit Sync-Status pro Ordner und Foto
Komponentendetail mit Lebenszyklus-Badge, Nachfolgern und Dokumentenanhang
Vollständige Hi-Fi-Flows für iOS (HIG) und Android (Material)
Token-Designsystem in drei Ebenen: Primitive, semantisch, Komponenten
Markenschicht als Figma Variables mit Modes, inklusive Beispielmarken
Dokumentierter Theming-Prozess für das Engineering des Anbieters
Handoff an das Engineering für iOS und Android

Häufige Fragen

Warum nennt der Case keine Kunden- oder Produktnamen?: Der Case ist anonymisiert: echte Arbeit, aber keine Kunden-, Produkt- oder Markennamen, und die Screens sind aus Vertraulichkeitsgründen unscharf dargestellt. Die Industriekunden, die die App einsetzen, nennen wir nur nach Sektor. Im Erstgespräch können wir Vorgehen und Artefakte im Detail zeigen, soweit es die Vereinbarungen erlauben.
Wie funktioniert das Multi-Brand-Theming in der Praxis — und was muss unser Engineering dafür tun?: Komponenten binden ausschließlich an semantische Tokens; diese referenzieren eine Markenschicht, die als Figma Variables mit Modes gepflegt wird. Eine neue Marke bedeutet: einen Modus anlegen, rund drei Markenfarben setzen, Logo tauschen. Tints, Zustände, Schatten und Typografie leiten sich daraus ab. Das Engineering erhält die Token-Struktur und den dokumentierten Prozess und kann Marken ohne Designbeteiligung aufsetzen.
Warum offline-first, wenn unsere Werke WLAN haben?: Weil der kritische Moment die Störung am Schaltschrank ist — Hände belegt, Empfang schwach oder weg. Eine App, die genau dann nicht speichert, verliert das Vertrauen des Technikers. Offline-first mit sichtbarem Sync-Status funktioniert bei gutem WLAN genauso gut; umgekehrt gilt das nicht.
Lässt sich das Vorgehen auf unsere HMI-, MES- oder Instandhaltungssoftware übertragen?: Ja. Die drei Bausteine — ein klar definierter schlechtester Nutzungsmoment, eine Informationsarchitektur entlang der physischen Anlage und ein token-basiertes Designsystem — sind unabhängig vom konkreten Produkt. Sie passen überall dort, wo Bediener unter Druck arbeiten und ein Anbieter dasselbe Produkt an viele Werke oder Kundenmarken ausliefert.
Was hat EN 62402 mit einer mobilen App zu tun?: EN 62402 beschreibt das Obsoleszenzmanagement: wie Unternehmen damit umgehen, dass Bauteile vom Hersteller abgekündigt werden, während die Anlage sie noch braucht. Die App macht genau diese Information im Feld sichtbar — Status, Abkündigungsdatum und empfohlene Nachfolger pro Komponente —, damit die Instandhaltung planen kann, statt bei der Störung zu suchen.
Wie läuft ein solches Projekt mit Beabstracto ab?: Typischerweise in dieser Reihenfolge: Ist-Analyse im Feld mit den Bedienern, Informationsarchitektur und Bedienkonzept, Prototyp und Hi-Fi-Flows je Plattform, Designsystem mit Tokens und Modi, dann der Handoff mit Dokumentation für das Engineering. Wo es der Zeitplan erlaubt, prüfen wir Flows vor dem Handoff mit echten Nutzern.