Construction & restoration · ERP
Creating consistency across a complex operational platform
BlueTeam was an established enterprise platform serving a U.S. commercial restoration, construction and roofing business. It supported roughly a dozen operational domains—from projects and work orders to finance and customer visibility—across management, operations, field teams and customers. Features had evolved through engineering-led implementation, interaction patterns varied across modules, and the team lacked a shared view of how the product worked end to end.
Making a complex system understandable
The challenge was larger than inconsistent screens. Multiple roles depended on connected workflows, but understanding the full system meant navigating the product and reconstructing decisions from scattered knowledge. Before recommending UI changes, I needed a clearer picture of the workflows and dependencies that held the platform together.
I spent close to my first month mapping BlueTeam’s main user journeys, working with the Product Manager and a backend engineer. To my knowledge, this was the first comprehensive flow map of its kind for the platform. It became a shared reference for discussing features and helping colleagues understand the product without relying entirely on screen-by-screen explanations. Its usefulness was observed rather than measured through onboarding metrics.
Standardize without interrupting delivery
A full UI rewrite or replacement of the existing frontend library would have disrupted ongoing delivery. Working with frontend engineers, I took an incremental approach: introducing shared conventions for typography, spacing and buttons before extending them to inputs, modals, layouts and recurring interactions. I built a Figma component library using atomic-design principles and applied published components to new feature work.
Work Orders provided a practical opportunity to replace ad hoc interaction patterns, including inconsistent inline search, with clearer modal and selection behaviors. Standardization required some initial engineering effort, but it gradually gave the team a common vocabulary for designing and implementing features. Engineers began spotting inconsistencies and questioning exceptions themselves—an observable sign of adoption, though not evidence of quantified development-time savings.
Making 'done' explicit
The interface was only part of the problem. Jira tickets often specified data fields and implementation details without fully defining user behavior, conditional logic or edge cases. Missing expectations then emerged during QA or user acceptance testing, when revisiting them was more disruptive. I proposed a Behavior-Driven Development pilot to bring those decisions forward.
For the Notes feature, I worked with the Product Manager to document more than 40 Given/When/Then scenarios across approximately 13 pages. These scenarios gave engineering and QA a shared reference for expected behavior under different conditions. During implementation, I observed fewer tickets returning for clarification and less repeated back-and-forth, which the Product Manager acknowledged. This was a feature-level pilot, not a verified company-wide rollout or a measured decrease in defects.
Impact: a shared understanding of core product journeys; more consistent UI and interaction patterns without a platform rewrite; clearer behavioral requirements for engineering and QA; and stronger cross-functional alignment. These are qualitative outcomes, not instrumented productivity gains.
