One menu and header for Airtm's Retail and Enterprise platforms
How one web shell brought consumer and business products together, stayed usable at 1366×768, and reached engineering as working components.
Airtm · 2026 · Handed to engineering
Project sheet
- Sole designer
- 1 PM, engineering, Brand
- 1 month to handoff
I set the direction, ran five rounds of exploration and built the components in code.
- Problem
- Two products shared a platform but navigated differently. At 1366×768, the prototype menu left only four of twelve destinations reachable.
- Decision
- Separate global identity, page context and list actions into three layers, using breadcrumbs only where real depth exists.
- Result
- Direction locked after five explorations. Working React components and decision records went to engineering. It’s with them now, and I’m not showing it as shipped.
The problem
The published design system was mobile-first, so on the web each screen solved wayfinding on its own. Page titles differed, breadcrumbs were the default navigation, and a side menu of nine flat items mixed actions with destinations. The two products were drifting apart, with nothing holding them together.
North starEvery screen should answer where am I, what can I do, and what do I have, the same way, in both products.
The constraint
Two products, one platform, and neither could stop shipping while this happened. The system had to serve a consumer wallet and a business payouts tool without either feeling like a guest in the other, and it had to be adoptable by engineers who were not going to read a spec document to do it.
What I tried first
Breadcrumbs as the default way to say where you are, on the grounds that they are explicit and cheap. They are also wrong for this product, which is shallow destinations and linear flows rather than a deep tree, so the crumb was almost always one level long: a control that occupies space to repeat the page title.
The pivot
Three layers, each answering exactly one question, and nothing answering two. A global bar for who you are and what is waiting. A page header for where you are and what you can do here. A toolbar for what you are doing to the list in front of you. Breadcrumbs became opt-in for genuinely deep trees, and linear flows got a stepper instead.
Measured on the hardware people have
At 1366×768, the prototype menu left only four of twelve destinations reachable, with the main money action below the fold. So I made the revision respond to the viewport’s height as well as its width.
Delivered as working components
The team got working React components, their states, and short decision records on where the balance sits, how interactive surfaces share the screen and how the rail behaves. Engineers could read the code instead of a spec.
What I gave up
Per-product freedom. The business app lost the ability to invent its own chrome for a screen that would have benefited from it, and a few page layouts got slightly less room. One system means somebody always gives something up; I made the trade explicit rather than letting each team discover it later.
Outcome
Direction locked after five rounds, a working prototype published for the team, and the components handed to engineering, with the rules written down so the next person does not relitigate them.
The shell, on screen
From the design file handed to engineering. The data is fictitious, as everywhere on this site.