PIPELINE TAKEOFF · ALPHA TO BETA · SIMPSON STRONG-TIE
ABOUT THIS PROJECT
Every roof truss Simpson’s software designs is governed by about 1,300 engineering settings. They lived on individual machines, were copied by hand, and when a customer got stuck, Simpson staff fixed it over the phone. I saw that the product that was missing wasn’t a better editor but a place to manage standards, and I defined Design Settings Manager around that: one place for a truss company to create, share, and govern its settings. I set the scope and designed the first release, which is now in build.
MY ROLE
Lead Designer. Product Strategy, Research, Stakeholder Review, Design through Build.
PRODUCT
B2B SaaS · Engineering settings governance · Web app
TIMELINE
Discovery Q3 2025 – in build
RESULT
Scope cleared review intact · In build for Q4 2026
The Challenge
What would it take to make 1,300 settings governable?
GOAL
Make engineering standards easier to trust: clear ownership, visible changes, and less reliance on memory and support calls. Define the product that does that, and get its first release through design review intact.
PROBLEM
Settings work in layers: a Simpson base file feeds a customer’s file, which feeds a project. The three levels looked nearly identical, so designers lost track of which one they were editing, standards were copied by hand, and every question a customer couldn’t answer became Simpson labor. The fix had to change where settings live without changing how people work.
TARGET USER
Truss designers working inside 1,300 engineering settings, and the Simpson staff who had become their support line.
SUCCESS DEFINITION
A standard is created once and reused, not copied by hand. A designer always knows which level they’re editing. Fewer settings questions reach Simpson, measured as support conversations and reuse, not clicks.
The Solution
Manage shared standards, not just individual settings.
The alternative was a better settings editor: faster tasks, and every question still landing on Simpson staff. I made the case for a management layer instead, and for measuring it on support load and reuse rather than clicks. I was betting that truss companies want managed standards more than individual designers want freedom to change things. So every file has one parent: Simpson owns the bases, companies own their copies, and project files hold one job’s exceptions. Each level has an owner, so a change always has a place to live.
On-prem today: settings sit three screens deep in Director.
In the cloud: I placed two entry points in Cloud Director, one into DSM for shared standards and one into project-level settings for a single job.
Research
Two findings broke our assumptions.
I interviewed nine designers and ran a five-person usability study on a prototype I built from the real settings files. Two things changed the design. Nested modals, which the plan said to remove, turned out to be how 4 of 5 designers kept their bearings inside a six-level tree, so they stayed. Search failed for all 5, because adding terms expanded the results instead of narrowing them. Building from the real files also showed that the three base files (US, Canada, Agricultural) share one structure and differ only in values, which is why DSM keeps them as separate bases and makes every other file a copy of one.
The library: shared standards and personal files, with the toggle that controls what designers see.
One library for every standard
Shared standards and personal files sit together, each with a one-line description. The Available for Project Creation toggle decides which standards designers see when starting a job.
A file you don’t own: read-only, differences first, Save a copy as the action.
See what’s different before making a copy
You can edit your own files; everyone else’s are read-only. A file you don’t own opens on what’s different from its base, with Save a copy as the main action.
Compare: old value beside new, section by section.
Show what a copy changed from its base
Compare shows exactly what a copy changed from its base, section by section, with the old value next to the new one. It answers the question designers kept asking: is this still the standard?
Project settings: Modified badges show where a job has diverged from the standard.
Let a one-off stay a one-off
A project-level copy is flagged when it’s modified, so a job-specific change stays in that job instead of forking a standard.
From a six-level tree to sections you can navigate
One tree six levels deep became three panes: named sections, a results list that narrows as you type, and the setting itself. Search highlights matches and breadcrumbs show where you are. I tried Miller columns and rejected them: every level stayed visible, so a deep setting still took six clicks.
Before: Legacy EnvData Tree
Explored: Miller Columns
After: Sections, Search, and Breadcrumbs
Decision held under pressure
Keeping the modals the plan said to remove.
Nested modals were on the list to go. They read as legacy, and removing them would have been an easy win to promise in the review. The study said otherwise: 4 of 5 designers used them to stay oriented, and the designs without them lost people. I kept them and said so in the review, with the study as the reason. A cleaner screen that leaves people lost isn’t actually cleaner. The scope cleared intact, and the effort went into the part that actually failed in testing: search.
The Outcome
Launched, in build, and measured on support load rather than clicks.
STAKEHOLDER IMPACT
Design Settings and Load Template Manager launched at BCMC 2026, and DSM is in build for Q4 2026. The design review cleared the first release intact, and two concepts I prototyped, pinning and Push Changes, went onto the roadmap. Push Changes is the clearest sign the model took hold: for the first time, a standard gets distributed on purpose instead of copied by hand.
ROADMAP
Now: shared and project settings, ownership and read-only states, the Available for Project Creation toggle. Next: customer testing, then roles and permissions, version history, and Push Changes. Later: AI-assisted workflows and platform capabilities.
HOW WE’LL MEASURE SUCCESS
DSM ships inside other apps, so usage on its own can’t tell us its impact. The measure is support load: fewer settings conversations reaching Simpson, and standards reused instead of hand-copied. Customer testing is next. The metrics are defined but not yet collected.
One thing I’d push for earlier: recording which version of a base file each settings file came from. It’s cheap to capture at creation and impossible to reconstruct later, and it’s the kind of argument design has to make early, before the data model is set.
