Turned a P1 bug into three 0→1 products, cutting mobile configuration from 30 minutes to 5 and creating builder patterns the broader platform later adopted.
*ServiceNow · 2019 - 2023 · first designer on the mobile developer platform, three products from 0→1
The problem nobody owned
Our mobile configuration tool was sold as no-code. But to customize a card, developers had to hand-edit JSON in system records, and reopening the tool afterward corrupted their work. Engineering owned the schema and product owned the patterns, while a remote team kept refactoring underneath both.
Developers were working in the gap between them. Every release cycle went to absorbing the breaks instead of building what they asked for.
This P1 bug was nasty.
What I saw
The team responded to the P1 by shipping forty more predefined patterns. That treated the symptom. Developers didn't want more choices, they wanted to build their own, and no number of presets would close that gap.
I read it as a missing product, not a missing pattern. So I proposed a small WYSIWYG card builder on a newer stack. It was a real fix for a real bug, and also a test of whether this team, this stack, and this interaction model could ship 0→1.
The code was using API calls that allowed us to worry less about underlying changes
The app builder that followed started with the same WYSIWYG vision. Then a deeper engineering estimate moved it from 9 months to about 24, and the deadline held. Product management made the call to pivot to a configuration-first experience that mirrored the mobile platform's schema.
It wasn't my first choice, so I looked for the problem underneath it. What developers were stuck on was never the missing canvas. It was confusing information architecture, terminology only experienced ServiceNow developers understood, and no way to learn the platform. Configuration-first could fix all three on time, and my job became making the compromise the product.
Who I pulled in
Card Builder was built by two engineers, a PM, and me, running our own morning standup so we could iterate daily. Six weeks in, we were split between three models for live preview and had debated for two weeks.
I hand-coded a working prototype over a weekend in HTML, CSS, and JavaScript. Under real interaction it exposed each model's latency trade-offs and gave engineering something concrete to cost. It settled the debate in 45 minutes.
This was my handcoded prototype in 2019, well before AI generators existed.
For App Builder, four customer design partners met with us weekly for ten weeks, seeing a new prototype every Friday. They changed the product in ways we hadn't predicted: nested screen flows, conditional navigation in the first release, and a staging step before anything reached production. The sponsor was the business unit building the platform's citizen developer experience, which wanted mobile inside it.
App Builder visions, revised every Friday across ten weeks with four design partners.
What changed
- Shipped Mobile Card Builder in six months on its original scope, cutting configuration time from 30 minutes to 5 and taking pro-code development out of the path. Its property panels, live preview, and publish flow became the template every later mobile builder inherited.
- Secured funding for Mobile App Builder from the business unit building the platform's citizen developer experience, on the strength of Card Builder and a series of vision prototypes.
- Shipped Mobile App Builder on its nine-month deadline from funding approval, as a configuration-first builder with rebuilt information architecture, plain-language terminology, and platform education built into the tool.
- Built a working concept that unified over a dozen separate builders under one entry point, with shared preview, shared publish, and handoffs between tools. I handed it off when I moved to core platform work; another team later launched parts of it in ServiceNow Studio -- particularly consolidating the builder tools into one interface.
- Turned the mobile builder patterns into the design language for web configuration across the platform.
Where this led
The mobile platform taught me that fragmented tools were rarely isolated UX problems. The corrupted cards, the growing preset library, and the dozen separate builders each traced back to separate teams, schemas, and product assumptions. Our organizational boundaries had become product boundaries.
That lesson followed me into the core platform. The same pattern appeared across Workspaces, and it became the foundation of the interoperability program.
What I'd tell a leader facing this
Treat systemic friction as a missing platform capability. If a recurring bug requires "more of the same" manual fixes, it’s rarely just a bug -- it’s a signal that a product is missing. Rather than pitching a massive overhaul upfront, ship a focused MVP. Prove the architecture, team dynamics, and developer experience first, and let that initial success justify the larger investment.
Solve organizational boundaries, not just interfaces. When an ideal technical solution conflicts with a deadline, pivot to addressing the underlying root cause. If identical friction points keep surfacing across multiple tools, it’s almost never a design flaw. Look at who owns the systems on either side of the gap and align the teams before you try to redesign the UI.