Builder Bridges
Collapsed five mobile tools into one, then built a working concept that joined over a dozen platform builders, which another team later launched in part as ServiceNow Studio's single builder interface.
ServiceNow · 2023 · first designer on the mobile developer platform, designing the connective tissue between builders
One entry point, shared publish, and a handoff between builders, running end to end.
The problem nobody owned
By the time Mobile App Builder shipped, the platform had over a dozen builders.
Certain evidence started to surface up:
- A researcher showcased the swivel-chairing that CSM customers needed to traverse through to get their assets and experience up and running. This included groups of builders that handled experience layer, handled logic layer, handled data layer, and the connections in between.
- Another research came in: customers who care about mobile enablement now had 5 products to choose from: Mobile Studio, Mobile Card Builder, Mobile App Builder, Mobile Publishing, and the foundational Mobile Platform. Customers had uttered the fatigue of tooling here.
- Mobile App Builder needed to lean more on UI Builder (web app builder) to design responsive web pages surfaced up in the mobile app client.
Each builder came from a different team hosting with its own mental model, its own preview, its own publish flow, and its own story for permissions and versioning.
Every team owned its builder, but there was no cohesive vision around Nobody owned the holistic narrative between them.
Efforts for configuration pane patterns also needed alignment. Configuration panes around UI elements were owned by component authors in UI Builder, while they were owned by the Mobile Builder team in all the mobile builders -- so alignment was hard to enforce. Ownership was partly outsourced, and the governance model UI Builder had published was rarely followed, so nobody owned how configuration was presented. The program gave exposure to the variety of patterns that needed to be cohesive so that developers swivel chairing between these tools have familiarity.
Developers lived in that space. Building one mobile experience meant crossing five tools, relearning the same concepts in each, and knowing which team's product did which job. They kept asking for one environment. What they got was our org chart.
Every builder had an owner. The bridge between them did not.
What I saw
Each product had earned the next. Mobile Card Builder proved the patterns and earned Mobile App Builder. Mobile App Builder earned funding from a much larger business unit to keep investing in mobile. The obvious use of that funding was another builder.
I read it differently. Every new builder added another preview, another publish flow, and another set of terms, and the cost didn't live inside any one of them. It lived in the transitions. Designing builders one at a time had created the fragmentation, so designing the next one well wouldn't fix it.
So I changed the unit of design from the builder to the connective tissue between builders, in three moves:
- One entry point that routed developers by intent into the right builder
- Shared primitives for preview, publish, permissions, and versioning
- Handoff paths so moving between tools didn't mean starting over
Who I pulled in
Inside mobile, the team behind Mobile Card Builder and Mobile App Builder was already working from a one design system, one information architecture, and one three-month release cadence across three products. That made the first move possible:5 mobile tools behind one entry point, with each tool's landing page one click from the others, because developers had told us they wanted everything in one place.
Across the platform, I had no team and no mandate. So I found the product and content designers closest to the problem, and we started crafting a shared library we could publish to our partners. A product designer from the admin team saw it early; she wanted a comprehensive launch point for all the tools. A researcher joined as a consultant to guide the research itself. This wasn't a sponsored effort, just a group of people I brought together to build something greenfield.
I then put together a Figma prototype leveraging those configuration patterns to surface up different tools in a similar environment. Certain environments had a "lite" version of the builder (composed of quick tooling -- I call this the "bridge") and a destination to the full builder. The bridge itself was proposed to be owned by the same team. This helped users swivel-chair between builders faster to iterate on the same artifact without needing to navigate through a starting point and browsing for the artifacts they needed to configure.
The concept later debuted at an internal hackathon, but didn't win. The team that did win showed a more AI-forward features on top of a directionally similar diagnosis (in all fairness, our hackathon team didn't know using AI was how to win). It was additional validation we used: Two teams, working separately, had reached the same conclusion about fragmentation. I took that as the stronger result.
As there's been awareness of the Builder Bridges project, engineering resources were dedicated to spike the product.
What changed
Turned five mobile tools into one suite with a single entry point, one design system, and one three-month release cadence across three products.
Built a working concept that joined over a dozen platform builders under one entry point, with shared preview, shared publish, and handoffs between tools.
Handed off the concept when I moved to core platform work. Another team had written more concrete requirements and used it in workshops.
launched part of it in ServiceNow Studio, consolidating the builder tools into one interface.
Turned the mobile builder patterns into the design language for web configuration across the platform.
Status, plainly: the mobile consolidation shipped; the platform concept stayed a concept on my watch; the Studio consolidation shipped through another team, without me in the room (my work heavily influenced that direction).
Where this led
Builder Bridges was the last thing I designed on mobile, and the first time the thing I was designing was the platform rather than a product. It also made the pattern impossible to unsee. The corrupted cards, the growing preset library, and the dozen separate builders all traced back to one cause: separate teams, separate schemas, separate assumptions. Our organizational boundaries had become product boundaries.
When I moved to the core platform, I found the same pattern in Workspaces, this time from the side of the people fulfilling requests. It became the starting point of the interoperability program.
What I'd tell a leader facing this
- Look at the seams before the screens. When every tool has an owner and customers still struggle, the problem is in the handoffs nobody owns. Map who owns each side of the gap before you redesign anything.
- Don't fund the next point tool by default. Once you've shipped three of something, a better fourth rarely helps. The connections between them usually do.
- Build it to leave your hands. Without a mandate, a working concept travels further than a deck, even after you move on. Mine lost the room it debuted in, and parts of it shipped anyway.