Trimble Takeoff & Estimation

The problem

Small and mid-sized construction contractors were losing bids they should have won. The takeoff and estimation tools they relied on had grown into sprawling native applications built for a different era of the industry. The people actually doing the estimating were often the newest members of the team, learning the software and the trade at the same time, on projects where a bad bid meant real money left on the table.

Trimble’s answer was Trimble Takeoff: a cloud-based, web-native estimation product built specifically for that preconstruction workflow. My job was to figure out what that should feel like.

Role and team

Sole UX designer and researcher on the team for most of the two-year engagement. I worked alongside three product managers, three developers, a C-suite executive sponsor, and six subject-matter-expert stakeholders who had come to Trimble from estimation and construction backgrounds. A junior researcher partnered with me on synthesis during parts of the project.

Why this project fit me

Before I was a designer, I was a technical drafter. I spent years producing the kind of site plans, intersection drawings, and scaled construction documents that eventually get fed into a product like this one. I know what a stripping area is. I know why a contractor cares about the difference between a linear feature and an area feature. When our stakeholders talked about how estimators actually worked, I was usually the only person in the room who had sat at that desk.

That background shaped how I approached the research and how I pushed back when something felt wrong.

Research

I wrote the interview scripts, conducted the sessions, and synthesized the findings myself. The goal was to map the real estimation workflow, not the one the old software assumed.

Two patterns showed up quickly.

The people doing estimations were often the least experienced on the team. Estimation was where new hires were sent to learn, which meant the tool needed to teach while it worked. The existing products assumed expertise the users did not have.

The workflows were enormous. A single estimation touched reference files, layer organization, site analysis, material takeoffs, report generation, and handoff, often across multiple personas. We could not redesign it as one thing. We had to break it apart.

Breaking the workflow into pieces

I mapped the full estimation process, then worked with the team to decompose it into micro-workflows, each owned by a persona and a job-to-be-done. We scored them on an impact vs. effort matrix in a Miro session with stakeholders, PM, and developers, and used that to sequence the roadmap. The micro-workflow approach let us ship meaningful slices of the product without trying to solve estimation in one release.

The estimation wizard

The signature decision in the product is what we called the Takeoff Guide, a wizard-style panel that walks a user through the estimation process step by step. The analogy I used with stakeholders was TurboTax. You can follow the guide end to end, or you can abandon it and work however you want. It is a scaffolding layer, not a prison.

Early usability tests surfaced two problems with it. Users could not tell when a step was complete, and when they wanted to revisit a step, they could not figure out which tool they were supposed to use. I redesigned the step indicators to show completion state explicitly and added a tool callout inside each step so the connection between the guide and the canvas was visible at all times.

The wizard was aimed squarely at less experienced estimators, which was most of our user base. It turned the product into something that could teach the workflow, not just execute it.

The Site Improvements toolbar

The hardest piece of the product was the Site Improvements toolbar. It controls how a user marks up a site for grading, stripping, and subgrade work, which is technically dense and varies by project type. I spent two weeks going back and forth on designs that were not landing with stakeholders or developers.

I stopped drawing in Figma and built a Miro board instead. I broke the toolbar down into its smallest building-block elements and ran working sessions where the team assembled rough designs together. The collaborative approach surfaced constraints I had missed and gave the developers ownership of the design decisions early. We landed on a working pattern in a week.

The Miro-board working-session format got picked up for other technically dense features after that. It became the default approach on the team when a design problem had too many hard constraints to solve alone.

Outcome

Beta testers consistently reported that the new workflow cut their bid creation time by roughly 40% compared to the legacy tool the product replaced. The feedback was qualitative rather than from a controlled time study, but it was remarkably consistent across the firms testing the product. The MVP shipped in September of 2023 and was presented at Trimble’s Dimensions Conference that year. The product is still being actively developed, and I continue to advise the lead developer informally.

What I took from it

Understanding the existing workflow is the job. The product’s success came from respecting how estimators actually worked, not from imposing a cleaner structure on top of them.

The Miro-board collaborative design process is a tool I reach for now whenever a feature has enough technical constraints that drawing in isolation becomes counterproductive. Shared ownership of constraints tends to produce better designs than solo heroics.

And the micro-workflow decomposition is a pattern I’ve carried into other projects since. Large workflows do not get easier by designing them all at once. They get easier by finding the seams.