Series C
One shared system across
iOS, Android, and Web.
A consumer social app on three platforms, with a design team that had just grown fast and a product that was quietly coming apart.
- Situation
- Consumer social app on iOS, Android, and Web. The design team scaled faster than the product’s structure.
- What I owned
- System-level decisions across three platforms, alongside shipping feature work.
- What changed
- One versioned token source replaced ad-hoc UI decisions. Drift stopped compounding.
What was true before
The app was a consumer social product shipping across iOS, Android, and Web. The team was strong and moving fast. They had no shared model for how interfaces should behave, scale, and ship.
Inconsistent UI was the symptom everyone could see. The cause was that every team re-decided the same things, on three platforms, with nothing to inherit. Exceptions accumulated until they became the default.
Three decisions
01
Built the system layer inside the shipping work rather than beside it, so it was validated against real product complexity as it was built.
02
Made design decisions a versioned source of truth that all three clients consumed, so token changes shipped like code changes.
03
Standardised component anatomy and states early, so variation happened by rule instead of by interpretation.
What it survived
The usual failure mode is a system built beside the product: complete, documented, and adopted by nobody. This one was built inside the shipping work, so by the time it was ready to adopt it was already in the product.
Designers converted their own live screens into system examples rather than being handed a library. New surfaces inherited the token layer, the component rules, and the platform logic by default, which is what made the drift stop compounding with every release.
What this means for you
If engineering is shipping faster than design decisions settle, more design hours will not close the gap. Someone has to decide what becomes the standard and what gets cut, release after release, while the roadmap keeps moving.
That is what a Design Partner engagement is for.
When the cause is unclear,
start with Problem Mapping.
When one area needs to move,
run a Product Sprint.
When the product keeps changing,
bring in a Design Partner.
