Problem-solving · Mobile · Multi-brand design system

A multi-brand mobile design system for monitoring component health across industrial plants

How do you help a maintenance technician — standing in front of a control cabinet — see the health of every electronic component in seconds? And ship that as one product many industrial clients can run under their own brand?

Product / UX Designer
research → hi-fi → design system → handoff
iOS & Android
field-first, offline
Domain
industrial maintenance · obsolescence (EN 62402)
The stakes

Unplanned downtime costs the world's 500 biggest companies an estimated $1.4 trillion a year — about 11% of their revenue.

Source: The True Cost of Downtime, Siemens (2024)

The real problem: component health is invisible

In a large plant, a single failed electronic component can stop a line. Yet maintenance teams often don't know what's installed, where it sits, its lifecycle, or whether it's about to be discontinued. When something breaks at 3 a.m., they're searching, not fixing.

The design challenge

Two intertwined problems

01 · Field journey

Capture & read component health in seconds

A technician on the shop floor needs to record, scan and check status fast — hands busy, poor signal, offline-first.

02 · Multi-brand

One product, many client brands

The same app had to be sellable to many industrial clients under their own identity, without forking the design.

03 · Complexity

Make a plant legible

Halls, lines, cabinets, fields, thousands of parts and obsolescence dates — turned into something scannable.

The journey & key decisions

Designing for the technician's reality

Problem

A fault at 3 a.m.: the technician is at the cabinet, hands busy, signal poor.

Decision

Design for the worst moment, not the demo — offline-first, scan-on-the-cabinet.

Why

If it works with a line down and no wifi, it works everywhere else.

Problem

Teams couldn't find the right place to record or read a component.

Decision

Mirror the physical plant in the IA: hall → line → cabinet → field.

Why

Navigation that matches how you walk the floor removes the translation cost.

Problem

Typing part data in the field is slow and error-prone.

Decision

QR on the cabinet + guided photo capture per view, with counts.

Why

Capture in a few taps; trust the system to sync the rest later.

Problem

The same app had to ship under many client brands without forking.

Decision

A token + modes design system; one mode switch re-themes everything.

Why

Onboarding a brand becomes a config change, not a redesign.

The product

The home answers 'what needs attention' before the technician taps anything — counts of registered vs. discontinued parts up top.

Information architecture

Mirroring the physical plant

Maintenance teams think spatially, so the structure mirrors how they walk a plant. The same hierarchy drives navigation in the app — finding a part needs no translation from screen to floor.

  1. 1
    HalleHall— the building / shop floor
  2. 2
    LinieLine / machine— a production line or machine
  3. 3
    SchaltschrankControl cabinet— the physical cabinet
  4. 4
    KomponentengruppeComponent group— e.g. a terminal box
  5. 5
    FeldField— a slot inside the cabinet
  6. 6
    KomponenteComponent— the part itself + its health

The app's information architecture mirrors the plant, level by level.

Navigation mirrors the physical plant, so finding a part needs no translation from screen to floor.

  1. 1Breadcrumb = the path you physically walked: hall → line → cabinet.
  2. 2Each row is a real place in the plant, not an abstract folder.
  3. 3Per-folder sync state — honest about what's backed up offline.
  4. 4Primary action stays one thumb-reach away: add / scan here.
The field journey

Capture that survives the field

From a fault to a resolution, the journey had to work offline, fast, and with hands busy.

1
Failure
line down, 3 a.m.
2
QR-Scan
scan the cabinet
3
Guided capture
photos per view
4
Offline
saved locally
5
Sync
when back online
6
Resolve
health + successor

Capture is guided per view (label, exterior, interior, detail) so nothing's forgotten under pressure.

  1. 1View label tells the technician exactly which shot to take next.
  2. 2Big viewfinder + one-tap shutter — works with gloves, hands busy.
  3. 3Live count (Anzahl) so you know what's captured without leaving the camera.
QR on the cabinet kills manual lookup — the technician scans where they stand.
Per-photo upload state means people capture now and trust the sync later.
Reading health

Component health at a glance

Above the fold it answers the only two questions in a fault: what is this, and can it fail soon?

  1. 1Green / amber / red lifecycle badge — status before specs.
  2. 2Manufacturer + part / article / ERP numbers for ordering.
  3. 3Obsolescence date + recommended successors with stock & EOL.
  4. 4Attached manual & datasheet — no leaving the app to dig for docs.
Obsolescence dates per year turn 'is this old?' into a clear decision.
Grouping matches how parts physically sit in a cabinet, not how a database stores them.
Offline-first

Sync-aware by default

Offline isn't a feature here, it's the baseline. A sync state on every folder and photo keeps the system honest about what is — and isn't — backed up.

The solution that ties it together

A token-based, multi-brand design system

The answer to “one product, many brands” was a design system built on tokens and modes. Components bind only to semantic tokens; semantic tokens reference a brand layer held as Figma Variables with Modes. Switching a single mode (primary, accent, logo) cascades through the entire app. Onboarding a new client = add a mode, set ~3 brand colors, swap the logo — tints, states, shadows and type all re-derive.

Primitive

Raw values: grey scale, brand hues, feedback colors.

references
Semantic

Surface · Background · Text · Border — reference primitives.

  • text/default
  • border/active
  • surface/raised
binds to
Component

Buttons, rows, badges — bind only to semantic tokens.

  • button
  • list-row
  • status-pill
Brand layer · Modes

Brand layer (Figma Variables + Modes): Mode = Brand A / Brand B. Switching one mode cascades through every tier.

Three tiers. The UI never points at raw hex — it points at semantic tokens, which point at a brand layer that swaps per mode.

One component, two brands

Same screen, same components — switching a single mode re-themes everything.

Brand A · #0A9ED5
← Capture component⋯
✓ Synced
Main cabinethealthy
Terminal box ABCend-of-life
Drive unit 611obsolete
Scan code
Brand B · #FF6943
← Capture component⋯
✓ Synced
Main cabinethealthy
Terminal box ABCend-of-life
Drive unit 611obsolete
Scan code
Primary #0A9ED5 → #FF6943 · Accent #065F80 → #1A0680 (+ /10, /30 tints & logo swap). 38 color tokens, a multi-platform type scale (iOS / Android / Web), and tokenized shadows.
FFFFFF
EDEDED
CACACA
949494
565A61
4D4D4D
2E2E2E
010811

Primitive grey scale (8) — stable across brands; only the brand layer changes per mode.

Outcome

Shipped, and scaling by brand

The app went live on iOS and Android and is used in production by global manufacturers across aerospace, automotive, steel, food & beverage and consumer goods (named clients under NDA). New clients are onboarded by swapping tokens instead of redesigning — the multi-brand system pays off every time a brand is added.

iOS + Android
shipped, field-first & offline
~70 / hour
components captured on site
1 mode
re-themes the whole app per brand
  • Mobile (iOS & Android)
  • Material Design
  • HIG
  • Design tokens
  • Theming / white-label
  • Design systems
  • Figma Variables & Modes
  • Offline-first
  • Information architecture
  • UX research
  • Complex / industrial UX
My role & contribution

I owned the product design end to end — and designed the white-label architecture that made the business model work.

  • Led research and framed the field context (the 3 a.m. fault) that drove every major decision.
  • Designed the information architecture for a complex industrial hierarchy.
  • Delivered full hi-fi flows on iOS (HIG) and Android (Material) — same journey, platform-correct.
  • Built and documented the token + modes design system, including the multi-brand theming process for the client's engineers.
  • Handed off a system engineering could re-skin per client without a redesign.
Learnings

What I'd improve next

Prove the theming claim with a contract test

I'd add a visual-regression / token-lint check in CI so a stray hard-coded hex can't silently break a brand mode.

Close the loop on capture quality

Field photos vary wildly. I'd add lightweight on-device guidance (framing, glare) and measure re-capture rate.

Instrument the field journey

With more time I'd track time-to-capture and offline→sync success in the wild, and feed that back into the flows.

Anonymized case — real work, no client/customer/product names. Screens are shown blurred for confidentiality.

Contact