Quote Tool

My role

• UX & Design lead

• Product strategy

• Project management

The team

• 2 designers

• 6 developers

• 4 content researchers/writers/testers

• Product manager

Duration

• 6 months to pilot with 20 users

• 9 months to alpha launch to 1000 users

• 12 months to beta to the full user base

Why build a quote tool?

Operating a marketplace at MyBuilders scale means we see a lot of issues that arise on home improvement projects. Sometimes the tradesperson-homeowner relationship breaks down and can’t be fixed, leaving the homeowner to find and pay someone else to finish, repair, or rip out and re-do work.

In 2018 we came to the conclusion that the most effective way to solve this problem would be to insure the homeowners jobs. MyBuilder could offer an insurance policy that guaranteed the work as agreed, and ensure it gets completed to standard for a small margin.

But to insure a job we need details of the scope of work and the costs - i.e. a quote. This is where the idea for Quote Tool started.  

The market

We knew this was a good problem to solve, as our research showed no one else has done a good job yet. Most quoting tools on the market are line-item population tables or connect to large materials pricing databases. In fact, most started as invoicing tools that added quoting features by essentially changing the document title from ‘invoice’ to ‘quote’. This does not produce a good quote, and the tradesperson still has to spend a lot of time inputting their quote details manually.

All the existing tools do is make it look tidy and add up the numbers. We knew we wanted to add invoicing, but also recognised this was not the place to start. Instead we chose to focus on the real issue to solve here: the quote.  

The users

We spoke to over 30 tradespeople about how they quote and collected samples from as many as we could. The best quotes were always hand-written and took a very long time to create. Because the barrier to quote creation is so high we learned many don’t bother, or provide quotes with only a high-level scope of works leaving both tradespeople and homeowners open to issues should anything not go to plan.

We also embedded customers into the project team. Our head of Trade Quality was an ex-tradesman who had a passion for quoting in detail, who along with the VP of Engineering and myself became the project leadership team. We also hired another tradesperson who became a core member of the project team and our go-to candidate for testing prototypes internally.

The challenge, and our goals

Quoting is difficult to do well. An accepted quote forms a contract of works, so it is important the output is an accurate reflection of what will be delivered. A written quote can take anywhere from an hour to several days to complete; tradespeople need to perform a site visit, take notes, write those notes up into a specification and produce costs for what it will take to deliver. The writing is the most time consuming part, and for most tradespeople writing skills are not high in importance, and for many English is not even their first language. 

One of our goals was to make adding detail frictionless for tradespeople. Whether you’re fixing a tap or building an extension, adding all the necessary detail is the most time consuming part.

We also wanted this tool to be primarily used on a mobile in the field, so the quote could be built while surveying the job, avoiding duplication of note taking and writing as separate workflows  

The solution

The key to getting this right was the content. We learned a lot on our previous Post a Job project where we wrote a set of conditional questions in a decision tree to draw out the details for every major type of job posted.

Taking learnings from that process we decided the right approach was to create a task for every conceivable thing you can do in the building industry (that you would put on a quote) and create a schema containing a set of conditional details for every little thing you might do for that task. Some tasks could be grouped up into projects, providing a hierarchy that made it more efficient to select everything you might be doing in a renovation or extension project for example, without having to hunt around for each individual task.

Our earliest prototypes were form-like pages, full of switches, toggles, lists and controls that allowed the detail of a job to be specified with no typing on a mobile phone.  

Amassing the knowledge for this content was a massive undertaking which involved lengthy workshops with tradespeople of every specialism to ensure we covered the level of detail they thought acceptable. Later we formed a dedicated content team who took over the research, writing and input of this content into a typeScript schema that powered the whole tool.

Early prototypes 

Once we had a reasonable prototype with enough data to allow test coverage on a single trade, we bought in people from that trade to test the experience. We learned a little about what types of fields they struggled to understand, and a lot about how to structure the content differently to optimise the experience. This early prototype gave a vertical slice of the intended experience but the feedback was overwhelmingly positive. They immediately saw the benefit and how much time this could save them. 

Other areas that took a while to get right included:

• Content discovery
  Finding what you’re looking for quickly via search or browsing, intelligent suggestions and categorisation. 

• Quote structure

  • Pricing
    Single price for the quote or by task. Additionally allowing those to be broken down by labour & materials. 

  • Pricing schedule
    Single payment, deposit and balance, or staged payments with full customisation of milestones and amounts.  

  • Quote terms
    Details such as the job address, what facilities will be needed on site to complete the works, site access hours, and contract terms we wrote in collaboration with Trading Standards. 

• Preview and delivery
  Finalised quotes can be previewed before they are generated. Once finished they can be sent to the customer. 

• Viewing and acceptance
  Customers can view the quotes online and feedback or accept right there. Once accepted a signed PDF contract is emailed to both parties. 

• Invoicing
  Once quoting was feature complete enough we moved onto invoices. Making it easy to generate invoices from a quote payment schedule, or manually write one up.

• Navigation
  Once another document type was introduced we needed to change the navigation model. This was done through housing documents inside Jobs - an organising container with metadata that is passed down into the documents created inside. This also helps enable other future features we planned to introduce. 

• Design system
  As we moved closer to a product that felt stable we began to work on a design system that made prototyping and front-end development much faster. 

• Testing & iteration
  We user-tested the app through every phase with customers. We launched an MVP within 6 months, launched to an alpha group 3 months later, then released the tool as a beta to the platform a further 3 months after that. Learnings are taken from data and user sessions constantly to improve the experience whilst developing new features continues today.

Project success

The Quote Tool has been a massive success, and we’ve had nothing but extremely positive feedback The Quote Tool has been a massive success, and we’ve had nothing but extremely positive feedback from users who commit to trying it out. We firmly believe we have built the world’s best quote tool for tradespeople.

The biggest lesson from launching was in marketing and expectations around adoption. It turns out it’s very hard to convince professional users to change tools. Tradespeople generally aren’t very tech savvy, and once they learn something that works they tend to stick with it. We needed to change the user intent in order to convince them to really give it a try.

This tool can be used for any job - on or off platform, and is completely free for MyBuilder members to use. At the time of writing invoicing has yet to launch. We suspect this piece of the puzzle will provide significant uplift as it will continue to be free for members, delivering additional value many are paying for elsewhere today. In addition we planned a marketing campaign based around knowledge centre advice that helps up-skill tradespeople as to the importance of good quoting, and how it benefits them and their customers. All this meant we had to think longer term than we were planning to reach desired levels of adoption.

At time of writing we were seeing over 600 quotes sent a day, with about a quarter of those being accepted by their customers online within a week (an expected percentage).

Product backlog 

Some future plans include adding job expenses to roughly track profit and loss on jobs as they progress - helping tradespeople make more informed decisions along the way, and get better at pricing more accurately in the future.

There’s an iOS app already, but only a PWA for Android, so we still need to make that available on the Play Store to be installed natively. Then the idea is to move onboarding from the marketplace into the tool itself and package it up with a free trial and subscriptions model to market and sell as a standalone service, for anyone, not just MyBuidler users to enjoy. International rollout with content and data localisation will follow with potential to integrate with sister companies in other markets.

Design stages

Follows a small selection of screens from major milestones along the 18 month journey, that shows where we started and how our thinking and UX evolved over time. These stages are not literal project stages, just convenient groupings for the purposes of this visualisation.

Stage 1

Our earliest wireframe prototypes were trying to solve the problems of task hierarchy and organisation. We explored concepts of creating ‘spaces’ (e.g. a room, the roof, or a garden) that became containers inside which you could build out the tasks, allowing more targeted pricing. A ‘task basket’ was another idea we explored that allowed you to select all the tasks you might want to add for a job or space in advance (like a survey), before fleshing out the detail.

Stage 2

In this phase of the project we considered more of the navigation around and through a quote. We envisaged each quote having it’s own menu slide out from the side, freeing up space for specific tasks in the main UI. We were still considering spaces as an organisational fundamental but began categorising these spaces into groups (interior, exterior & grounds) that allowed us to be more intelligent with task suggestion.

Stage 3

By this stage we had doubled down on the hierarchy and started to solve the navigation issues created by our content organisation approach - nesting tasks within tasks, within tasks. We attempted to visually show how many levels deep inside tasks you had navigated and created populated quote content views to reflect this hierarchy and display the connected nature of the tasks in the job.

Stage 4

Taking a step back outside of the quote, we began to think of the ‘job’, inside which multiple quotes and versions can live. We also explored adding the final missing piece of the quotes - pricing schedules, terms and conditions and different ways of previewing your finished quote before sending.

Stage 5

By this stage we were thinking beyond the quote. We started thinking about the larger vision of having invoicing and expenses. We made ‘sitemaps’ to understand the full scope of functionality and group them into a logical navigation for the app. At the time we thought it would be useful to create a CRM for customer data that had interconnected data throughout the system. We later simplified a lot of this thinking down to a model that requires less mental overhead and far less navigating around.

We envisioned a tab-bar navigation to get around the app, and a weave of cross-connected data through the major sections with dashboard-like analytics. Unfortunately the complexity of this model confused our users and made it feel more suited to enterprise than a tradesperson. This insight helped us to think through the detail about how we wanted different document types to interact. We then drastically simplified the whole model down quickly to something more understandable.

Stage 6

This version of the app represented our beta launch to the entire user base. We’d standardised the simpler document model (just quotes at the time), and process of editing the quote as a workflow within a stepped process. A job had a continuously editable quote object that you could ‘export’ as different versions of completed quotes to send to customers for feedback or approval.

Stage 7

This final stage is where we introduced invoices as a document type, meaning we needed to rethink the existing document model. Based on previous ideas, we used the job as the unifying container. As part of a major component and styles consolidation exercise we introduced a new design system that standardised hundreds of components into a more manageable and flexible system. We used colour-coding to help differentiate the document types and indicate what you were editing/viewing at any given time.