One shell for two products
Airtm runs two products on the same web platform: a consumer wallet and a business payouts app, built by different teams at different times.
- Role
- Senior Product Designer — direction, five exploration rounds, and the components, built in code.
- Collaborators
- Design team, Product, Engineering, Brand.
- North star
- Every screen should answer where am I, what can I do, and what do I have — the same way, in both products.
In 30 seconds
- 01 · Problem
- Two products shared a platform but navigated differently. At 1366×768, the prototype menu left only four of twelve destinations reachable.
- 02 · Decision
- Separate global identity, page context and list actions into three layers, using breadcrumbs only where real depth exists.
- 03 · Result
- Direction locked after five explorations; working React components and decision records were handed to engineering. Production adoption is not claimed.
The problem
The published design system was mobile-first, so on the web each screen solved wayfinding on its own: different page titles, breadcrumbs used as default navigation, a side menu of nine flat items mixing actions with destinations, and the two products drifting apart with nothing holding them together.
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. The revision responds to viewport height as well as width.
Delivered as components, not specs
Delivered working React components, states and short decision records to the team. The records cover balance placement, competing interactive surfaces and rail behavior. Handoff is documented; production adoption is not claimed here.
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.