Shift5 web application
An app template built to replace bespoke field applications with a consistent, reusable foundation.
Role
UX Design + Product Management
Product
Web application template
The problem
Field engineers needed to solve customer problems fast, so they were spinning up bespoke applications on the spot for each customer meeting. It worked in the moment, but it got out of control: a growing sprawl of one-off apps that the product engineering team wasn't equipped to maintain. The result was mounting tech debt, inconsistent UI from app to app, and no consistent baseline to build new customer applications.
My role and constraints
I owned this end-to-end, wearing multiple hats at once: I was solely responsible for building and maintaining the design system, creating patterns and a template for the UX/UI design on application pages, and I was the PM for the product engineering team building it — writing and prioritizing Jira tickets based on customer and field engineer input, and keeping sprints full. That dual role meant every design decision was made with an immediate eye toward what was actually gettable into a sprint and built by the team I was resourcing.
Process
I started with an audit of every existing UI in the wild — the many bespoke apps built by both field and product teams — and pulled out the workflows that were actually critical to customers, rather than trying to preserve every one-off feature. From there, I extracted the components that could work across all of those apps and organized them into a set of pages structured so that any of the critical workflows could be accomplished using the same underlying system.
This UI reset and consolidation was also a good opportunity to update and implement a new design system. Built from the ground up with consistent sizing and spacing across every component, each piece was built to fit together seamlessly, regardless of need or orientation. This was the detail that made the system actually work in practice - any engineer could pull components together into a new app without one-off adjustments, making the system buildable instead of endless.
Impact
Customer-facing applications became visually and functionally consistent, regardless of which team or engineer built them. The product engineering team — which I was PMing — went from a sprawl of unmanageable one-off apps to a foundation and component set that let engineers consistently build new customer applications on top of a shared baseline.
I helped drive adoption across both product and field engineering teams. By having a component set and app template, the field team was able to spin up custom apps for customers much more quickly, allowing them to spend more time understanding and solving problems - which will then drive changes and updates to keep the product engineering team's sprints loaded up.
