Buildertrend is a complex SaaS platform for residential construction management. For years, core entities—like schedule events, invoices, and bills—were presented using editable field layouts, even when users were simply viewing saved information. This made content harder to scan and interpret, creating unnecessary cognitive load when users were simply reviewing information.
At the start of Q2 2025, design leadership initiated a platform-wide shift toward a clearer interaction model that distinguished editable from read-only content. While I wasn’t formally leading the initiative, I was the lead product designer within the design system space and played a key role in shaping its early direction—coordinating design work across teams, testing user expectations, and helping surface inconsistencies that led to stronger alignment.
The problem
The original UI presented content in a single editable state, regardless of whether users were reviewing or modifying information. This often led to a cluttered, form-heavy experience that made it harder to scan information or understand what actions were actually required. Users had to mentally filter through editable fields and secondary buttons—even when they were just there to view.
We believed that introducing a true view state could simplify the interface for most users, reduce cognitive load, and make important actions more prominent. It would also allow the "Save" action to appear only in editing contexts—eliminating a persistent point of confusion. Usage data backed this up: most entities were viewed far more often than they were edited. And when I ran a pattern prioritization activity, “view/edit patterns” ranked among the top three needs across design teams.
Laying the groundwork
• Created a shared Figma file for teams to drop their view/edit explorations, organizing by feature to increase visibility and understanding of how designers on different teams were approaching introducing view states to their workflow
• Planned and ran usability testing for a group of early implementation features assigned to the design system team—lower-risk areas that gave us space to test creation, editing, and save behavior without impacting high-traffic workflows
• Shared findings and edge cases with more senior designers to help shape early alignment around editability and overflow action patterns—especially in areas like financial workflows where user expectations clashed with existing behavior
• Flagged the growing implementation divergence, which helped catalyze the formation of a formal governance structure
Moving toward alignment
As teams added their designs to the shared Figma file, it became clear that everyone was interpreting view/edit states slightly differently—sometimes in conflicting ways. I helped spotlight those inconsistencies early, prompting conversations across teams about the need for shared direction.
Usability testing surfaced a key disconnect: users overwhelmingly expected “Save” to return them to their previous context (e.g., a list view). However, as we began shaping guidance, deeper conversation with designers working on financial workflows revealed a valid counterpoint—many of those flows required users to take a follow-up action after saving (such as sending an invoice). To account for those needs, our initial guidance leaned toward keeping users on the item after saving, with the understanding that we’d continue to evaluate and iterate based on feedback as the pattern scaled.
With inconsistencies mounting and tradeoffs emerging, design leadership created a cross-functional working group—including directors from design, product, and architecture—to formalize alignment. The group conducted an audit of patterns in flight and made several foundational calls, including:
• Returning users to their previous context after saving (when no further action is needed)
• Elevating “Send” as a primary action in create/edit modes
• Defining editability rules based on item status and context
Looking forward
Implementation is still ongoing, but the foundation is now in place: a shared interaction model and a set of aligned decisions for when and how content should be editable. These decisions are now documented in updated guidelines that help teams introduce view states consistently across the platform.
Helping shape those foundations—especially in the early, ambiguous stages—was a rewarding part of this work. I’m proud to have contributed to something that’s already improving clarity for our teams and will soon do the same for our users.
Takeaways
• Strategic clarity needs structural support. Even thoughtful solutions can falter without the organizational scaffolding to carry them through.
• You don’t have to lead from the front to have impact. By connecting people, surfacing patterns, and elevating misalignments, I was able to influence change at a platform level.
• Impact often starts with initiative. By jumping in early—without waiting for direction—I was able to surface misalignments, create shared tools, and influence the foundation of a platform-wide shift.
