CAD · Estimation Workflow
Trimble Takeoff & Estimation
Redesigned core estimation and takeoff flows for civil engineers and preconstruction teams. Layer management, photogrammetry, and 3D site modeling rebuilt around how the work actually gets done.
The problem
Small and mid-sized contractors were losing bids they should have won. Their takeoff and estimation tools had grown into sprawling native apps built for another era. The people doing the estimating were often the newest on the team, learning the software and the trade at the same time. On those jobs, a bad bid left real money on the table.
Trimble Takeoff was the answer: a cloud-based, web-native estimation product built for preconstruction. My job was to figure out what it should feel like.
Role and team
I was the sole UX designer and researcher for most of the two-year engagement. I worked with three PMs, three developers, a C-suite sponsor, and six subject-matter experts who had come to Trimble from construction and estimation. A junior researcher partnered with me on synthesis.
Why it fit me
Before I was a designer, I was a technical drafter. I spent years producing the site plans and scaled construction documents that get fed into a product like this one. I know what a stripping area is, and why a contractor cares whether something is a linear feature or an area feature. When stakeholders talked about how estimators actually work, I was usually the only person in the room who had sat at that desk. That shaped how I ran the research, and when I pushed back.
Research
I wrote the scripts, ran the interviews, and did the synthesis myself. The goal was to map the estimation workflow people really used, which was different from the one the old software assumed. Two patterns showed up fast.
First, estimation was where new hires got sent to learn, so the people doing it were often the least experienced on the team. The tool had to teach while it worked.
Second, the workflow was enormous. A single estimate touched reference files, layer organization, site analysis, takeoffs, reporting, and handoff, often across several people. We couldn’t redesign it as one thing. We had to break it apart.

Breaking the workflow apart
I mapped the full process, then worked with the team to split it into micro-workflows. Each one belonged to a persona and had one job to do. In a Miro session with stakeholders, PMs, and developers, we scored every micro-workflow for impact against effort and used the scores to sequence the roadmap. That let us ship useful pieces without trying to solve estimation in one release.

The estimation wizard
The biggest design decision was the Takeoff Guide, a wizard that walks you through an estimate step by step. I described it to stakeholders as TurboTax for takeoff. You can follow it from start to finish, or leave it at any point and work your own way.
Early testing turned up two problems. Users couldn’t tell when a step was done, and when they went back to a step, they couldn’t find the tool it needed. I made the completed state obvious and added a callout in each step pointing to the right tool, so the guide and the drawing canvas stayed connected. Most of our users were less experienced estimators, and for them the guide turned the product into something that taught the workflow while they did it.

The Site Improvements toolbar
This was the hardest piece. The toolbar controls how you mark up a site for grading, stripping, and subgrade work. It is technically dense, and it changes with the type of project. I spent two weeks on designs that weren’t landing with stakeholders or developers.
So I stopped drawing in Figma and built a Miro board instead. I broke the toolbar down into its smallest building blocks and ran working sessions where the team put rough designs together themselves. The sessions surfaced constraints I had missed, and they gave the developers ownership early. We landed a working pattern in a week. The team went on to use the same format for other dense features.

Outcome
Beta testers consistently told us the new workflow cut their bid creation time by about 40% compared with the legacy tool. That is what testers reported, not a controlled time study. Still, it was consistent across the firms testing it. The MVP shipped in September 2023 and was presented at Trimble’s Dimensions conference that year. The product is still in active development, and I still advise the lead developer informally.
What I took from it
Understanding the existing workflow is the job. The product worked because it respected how estimators already worked instead of imposing a cleaner structure on them. When a feature has too many hard constraints for one person to solve, I now reach for the Miro working session. And I learned to look for the seams in a big workflow. It doesn’t get easier when you design all of it at once. It gets easier when you find where it comes apart.