We stopped designing device setups. We started assembling them.

That worked at ten devices. It did not work at seventy.

A device setup flow is everything between unboxing and a working, configured device. At Ring it was also the most fragile thing we owned: dense information architecture, deep dependencies, dozens of conditional states, long copy, custom illustrations — hand-built, device by device.

Every new product meant a new setup designed from scratch, a new build from scratch, and a new QA pass from scratch. Design was the bottleneck, then engineering was, then QA was. The catalogue was growing faster than any of us could scale, and hiring wasn't going to close the gap.

The bet: one solution that satisfied all stakeholders.

Before proposing anything, I went to every team that touched setup — Product, Engineering, QA, Customer Support, Design Leadership — and asked what a fix would need to do for them. The answers were different, and that turned out to be the point.

One solution had to satisfy all six. A faster design process only helped one of them. A shared system helped all of them — which is why I pushed for a system, and why it got backed.

The system

I audited every existing setup and pulled out the UX patterns that repeated across devices, then defined them as modular functionalities that could apply to any product in the catalogue. Instead of drawing new setups, we assemble them — selecting and sequencing predefined modules, Lego-style.

The part that made it real: I worked with engineering so every design module had a code equivalent. A new setup stopped being a build and became a configuration file. That's where the two-weeks-to-two-days came from — not from designers working faster, but from the handoff mostly disappearing.

Content, solved as a side effect

Every unique screen in a section carries its own predefined assets and copy — either general or device-specific.

Which means when a new device needs no flow changes at all, the designer's entire job is supplying asset URLs and device-specific copy from the Content team. No re-drawing, no duplication, no drift. The consistency number is a consequence of that, not a separate initiative.

What I'd change

Modularity buys speed by removing choices, and that trade is only worth it while the modules stay right. The risk I'd watch harder next time is pattern lock-in — a system this efficient makes it very cheap to ship the existing pattern and quietly expensive to question it. I'd build a scheduled review of the module set itself into the process, not just of the setups it produces.