Quote generator module, at Buildxact

Turning a black-and-white document into a flexible, client-facing editor.



Before - legacy output (left) and after implementing the new quote generator GUI (right) 

‍Overview


‍Role

‍Product Designer (solo design lead on this feature) 


‍Company

‍Buildxact — construction estimating and project management software for residential builders Team: Product owner, engineering squad, myself 


‍Problem

‍The tool builders used to turn a cost estimate into a client-facing quote was a plain, black-and-white WYSIWYG editor with no way to structure, brand or formally close out the document.



‍A quote is often the first professional document a builder sends a homeowner. 


‍For a trade that runs on reputation and trust, how that document looks and reads carries as much weight as the numbers inside it. 


‍As a designer at Buildxact, I owned this end to end: framing the problem, shaping the solution with engineering, and following it through to release.




‍Discovery


‍The existing editor let a builder pull an item list into a quote and paste in a description, and that was it: no cover page, no structure, no visual identity, and no built-in way for a client to formally accept what they were looking at. Competitors were shipping more polished, branded output, and conversations with builders and the product owner confirmed the same underlying gap: builders wanted to look considered and professional, but had neither the time nor the design skill to make that happen themselves.


‍That reframed the brief. The task wasn't "give builders more design tools", it was "let builders look professional without needing design skill themselves." I mapped the quote's full lifecycle, from first impression through to formal acceptance, to work out what the document actually needed to do at each stage, and worked with engineering early to pressure-test what was realistically buildable within the estimating software around it.



‍Design process


‍I designed the module as a flexible document builder rather than a form, built around the moments in a quote's lifecycle that mattered most: persuading, informing, and eventually closing. Working iteratively with engineering, ambition was scoped against what could realistically ship, keeping the feature set tight but complete rather than shipping a half-built version of every idea.

That process landed on five core capabilities:


1. Drag-and-drop section reordering via a side navigation, so builders could structure the story of the quote in whatever order suited the job.

2. A cover image, giving the document an immediate visual identity rather than opening straight into numbers.

3. A choice of design layouts, so different builders and job types could pick a look that suited them without needing a designer.

4. Toggleable sections, letting the same tool flex between a simple quote and a more detailed proposal.

5. A digital signature step, turning the quote into something a client could formally accept in place, rather than a document that just sat in an inbox.




Final feature design


Output stayed deliberately flexible: a builder could push the finished quote straight into the client portal for online sign-off, or export it as a signable PDF to send directly.

The tool needed to fit into however a builder already worked, rather than force a new habit on them.

Impact


The quote letter module brought Buildxact to competitive parity on one of the most customer-visible touchpoints in the product: the moment a builder's own client forms a first impression. It gave time-poor builders a way to present themselves as considered and professional without asking them to become designers, and it fed directly into the client portal work I led at Buildxact, which was ultimately adopted by more than a third of customers.



Learnings


This project sharpened how I think about designing for users who are experts in their own trade but not in design or software. 


The instinct isn't to hand them more tools, it's to encode good judgement into the product so a professional result is the default, not something they have to work for. 


That's a principle I carried into every later project at Buildxact, and one I'd bring into a construction-tech context again.