Why I'd let a mobile team diverge from the desktop design system when the rationale is strong, and the order I'd give a design system team so it doesn't cost them.
Parity between platforms sounds like consistency, and consistency is a value I’ll defend all day, but they’re different things, and confusing them is how a mobile team ends up shipping a product that’s consistent and wrong. This came up in a 1:1 with our mobile design lead, and I want to lay out the decision I gave them because I think it generalizes.
The situation is common. A company grows up on desktop, the design system grows up with it, and mobile arrives later with its own conventions, its own gestures, and a platform vendor with strong opinions about what a list or a sheet should look like. Then someone asks the reasonable question: shouldn’t the mobile app look like the desktop app? And a very talented design systems partner, whose job is to think about every surface holistically, reasonably wants the system to cover both. Every one of those instincts is right, and together they push toward parity, which is where we get into trouble.
Consistency is a value I’ll defend all day, and parity is the version of it that gets a mobile team into trouble.
My decision was that mobile owns its destiny. Look, feel, and functionality on the phone belong to the mobile designers, full stop. If the desktop system does something one way and there’s a strong enough rationale to do it differently on mobile, the mobile team makes that call, and if the result is a fork in the design system, an instance that exists for mobile only, that’s an acceptable cost. What I don’t want is the reverse: the design system built holistically in the abstract and mobile told to use it. Usage comes first. The mobile team works out what they actually need and how they’ll use it, and then the system either brings that into the fold or breaks off a mobile instance. The design systems partner isn’t wrong to think across surfaces, and the sequencing just has to start with the people building on the surface.
There’s a practical near-term consequence. When the platform vendor ships a new visual language, as they do every year or so, the highest-quality move for a mobile team is usually to polish toward it, because that’s what the person holding the phone expects, and it’s a better use of a quarter than relitigating questions that belong to a bigger conversation. Our lead had already landed there on their own. My job was mostly to say yes and to make sure the design system side heard the same decision from me.
Which brings me to the order I’d give any design system team in this situation, because “think holistically” is not a priority list. First, the desktop components that are slowing people down today. A system earns its right to expand by fixing the friction in the surfaces already using it. Second, connecting the system to the tools where prototypes now get built, so a prototype pulls codified components instead of approximations. Third, and only then, the platform-wide work: bringing mobile into a shared token structure, which in my experience takes a design system team the better part of 6 months to build before anyone else can adopt it. That gap isn’t a delay; it’s the window the mobile team needs to decide what they want their own system to be.
One more thing I’m taking into crit, on a related note from our growth design lead. As systems get more complete, UI work can lose its art direction, the composition and the pixel-level judgment that a strong designer brings and a component library can’t. Crit is the venue to bring that back, and we’re working out a mechanism so pixel-level feedback doesn’t get skipped in favor of flow feedback. Ownership of look and feel means owning that, too.