UX / UI Design
Enabled Accurate Estimating for Contractors
Created an estimator in a job tracking application in order for certain users to build accurate estimates for customers.
Tools
Figma, FigJam, Jira
Roles
UX Designer, UI Designer
Client
EQS, Inc (StreamLine)
Project Duration
3 Months
Summary
An electrical contracting company wanted to build job tracking into their proprietary software and needed accurate estimating within the flow of job creation. The company already had a simpler software that was outdated, bloated, and designed for a small team with Apple devices. I was the sole designer for this project, working with a scrum master and developer to overhaul their current app and bring it to the web.
This estimator was built to function as a hub for generating estimates and the foundation of tracking money spent and invoiced on each job. Estimates are the first link of where all financial reports start so it's crucial to add all relevant information and for the numbers to be correct.
Context, Goals, & Constraints
This application is built for contractors. The parent company is a small contractor that specializes in industrial electrical work with some large-scale clients in both the private and the government sectors. Due to the nature of the work most of their jobs are heavily influenced by regulations and contracts set months or years in advance.
The main people using the estimator are highly-skilled electricians that know their clients well. They require precision in any numbers they give their customers and the flexibility to add minimal information. All of this requires the ability to be presented in various reports later in the process.
Persona
I built this main persona based on conversations I had with the team. Before we started designing for this application I had worked on their previous software project by ticket management and version support, so I knew the company's constraints and pain points very well. I had many years of experience answering user questions and handling and prioritizing development, and I've spent time on job sites using the same technology the project managers use. This gives me an exceptional understanding of their needs and restrictions. I've also spent a lot of time listening to the needs of employees in regards to the specific data their customers require.
Design System
We started designing this application from ground up with the Estimator as no exception. I started with no design system or assets and had to create one for consistency and faster iteration for this project and future projects. I asked the developer what tools he was using for the project, researched many different template systems that were compatible with front end, and decided that Shadcn UI was both streamlined and supported our development. I customized this with our own branded colours and styling choices, and ensured that it supported accessibility and scalability.
Design Process
White Boarding
The design started with a fresh look at what an estimating user would require in order to prepare any type of estimate for a customer. I had meetings with the main stakeholder to define exactly what constraints we had and who our main points of user research would be. I drafted all my notes in Markdown (Obsidian), then white boarded the ideas around and condensed some of them into to the notes above.
User Journey
Next I took a look at the customer journey as it was in the current version of the application (please note that these images were blurred in respect to unreleased design that I didn't create). I decided what the main flow throughout the estimating process was and how it could either be improved or completely redone.
I wanted to come into this process as a novice. It's exceptional to have an insight into the process already but sometimes with a beginner's mind you can better understand how a novice would approach building an estimate. The estimator should be simple enough for anyone to approach it and start building immediately.
Flow
After understanding the current process I drafted the flow through the entire process from creating to sending an estimate.
This was important to get correct but I wanted to keep it loose in order to capture the bigger picture. A few questions I kept in mind during this drafting process:
What is the final outcome you want?
What problems do customers have with estimates and can they be resolved through design?
How do you keep this process as minimal as possible but also give a user and their customer the appropriate amount of information?
Wire Framing
Wire Framing came next. Above you can see a detailed version of a later pass of the process. Wire frames were presented to users with a basic prototyping to demonstrate flow, and a lot of crucial feedback helped shape the later versions, including buttons and layouts discussed in the next section.
The old system had a major problem in adding line items. Often when you added a new line item itwould appear at the bottom, which became exceptionally tedious when you had a large amount of lines. The system would also switch to newly created line, requiring instant input instead of letting the user decide when to appropriately add information. Through asking questions it was revealed to be much easier to simply add the amount of lines and then fill in information all at once rather than make sure everything is correct before moving on. We also had lines created below the current line you had selected or at the top if nothing was selected. Buttons for major categories such as labor hours and materials were added that you could "rapid fire" click, and selecting between items was made fluid and fast, a far cry from the old version.
ALTERNATIVE APPROACHES
In the old system there were a few places that the user would either be confused as to where to find information or get lost in the flow if they got distracted, which can happen constantly due to the nature of the work. Some examples of necessary changes are below.
Phase Navigation
Before
After
Phases are not always needed for jobs but some jobs are built on phases and even billed from them rather than on total job completion. Users found it confusing as to where to find Phases and how to see all the relevant information at once, but also needed not be overwhelmed with information. What had previously been a phase selection button became a shelf with larger phase buttons to be easily navigable, both by being larger and by displaying enough information to identify a phase that may be later in the numbered list, so you didn't have to start at Phase 1 and navigate through 34 Phases to reach Phase 35 for example.
Phase information was also condensed into to simple totals, listed by breakdown if relevant, in order to prevent cluttering of the screen.
Adding Line Buttons
Before
After
Building out line items for estimates can become tedious if you have to stop every time and fill out information. Making the easily-clickable "Add a..." buttons makes it easier for the Estimator to rapidly work out what they needed, then to fill in the details later. At first these buttons were absent, and later added in.
Outcomes & Reflections
The final outcome was an implemented release in the application. Above is a current screenshot that does not include the newest design system and fixes, but is live. This project is still currently still in development and not released to the public.
Ultimately this system is designed for faster speed of use, less missed line items (thus less wasted money and time), and the visibility needed by both estimators, office personal, and other project managers.
Users will be able to send customers emails fast and much more reliably as well as tweak any issues with the estimate that the customer may raise. Rejection and change is an important part in any estimation. Users are also able to display estimates to customers in different ways including by Line Item, Phase, Breakdown, and more.
Next time I want the opportunity to discuss the next project more often with users during the entire process. The development team had to build out most of the project before we could present it to actual users, and though we met with them a few times early on I believe I was limited on sample size and testing time. I used my prior knowledge of estimating to help but I believe this can make you biased on certain aspects.
I also would have created a design system sooner. Wire framing is a creative, messy process but the final designs were halted because no system was available.
NOTE: This project is not fully released to the public. Screens are anonymized to protect company information.
More Projects
UX / UI Design
Enabled Accurate Estimating for Contractors
Created an estimator in a job tracking application in order for certain users to build accurate estimates for customers.
Tools
Figma, FigJam, Jira
Roles
UX Designer, UI Designer
Client
EQS, Inc (StreamLine)
Project Duration
3 Months
Summary
An electrical contracting company wanted to build job tracking into their proprietary software and needed accurate estimating within the flow of job creation. The company already had a simpler software that was outdated, bloated, and designed for a small team with Apple devices. I was the sole designer for this project, working with a scrum master and developer to overhaul their current app and bring it to the web.
This estimator was built to function as a hub for generating estimates and the foundation of tracking money spent and invoiced on each job. Estimates are the first link of where all financial reports start so it's crucial to add all relevant information and for the numbers to be correct.
Context, Goals, & Constraints
This application is built for contractors. The parent company is a small contractor that specializes in industrial electrical work with some large-scale clients in both the private and the government sectors. Due to the nature of the work most of their jobs are heavily influenced by regulations and contracts set months or years in advance.
The main people using the estimator are highly-skilled electricians that know their clients well. They require precision in any numbers they give their customers and the flexibility to add minimal information. All of this requires the ability to be presented in various reports later in the process.
Persona
I built this main persona based on conversations I had with the team. Before we started designing for this application I had worked on their previous software project by ticket management and version support, so I knew the company's constraints and pain points very well. I had many years of experience answering user questions and handling and prioritizing development, and I've spent time on job sites using the same technology the project managers use. This gives me an exceptional understanding of their needs and restrictions. I've also spent a lot of time listening to the needs of employees in regards to the specific data their customers require.
Design System
We started designing this application from ground up with the Estimator as no exception. I started with no design system or assets and had to create one for consistency and faster iteration for this project and future projects. I asked the developer what tools he was using for the project, researched many different template systems that were compatible with front end, and decided that Shadcn UI was both streamlined and supported our development. I customized this with our own branded colours and styling choices, and ensured that it supported accessibility and scalability.
Design Process
White Boarding
The design started with a fresh look at what an estimating user would require in order to prepare any type of estimate for a customer. I had meetings with the main stakeholder to define exactly what constraints we had and who our main points of user research would be. I drafted all my notes in Markdown (Obsidian), then white boarded the ideas around and condensed some of them into to the notes above.
User Journey
Next I took a look at the customer journey as it was in the current version of the application (please note that these images were blurred in respect to unreleased design that I didn't create). I decided what the main flow throughout the estimating process was and how it could either be improved or completely redone.
I wanted to come into this process as a novice. It's exceptional to have an insight into the process already but sometimes with a beginner's mind you can better understand how a novice would approach building an estimate. The estimator should be simple enough for anyone to approach it and start building immediately.
Flow
After understanding the current process I drafted the flow through the entire process from creating to sending an estimate.
This was important to get correct but I wanted to keep it loose in order to capture the bigger picture. A few questions I kept in mind during this drafting process:
What is the final outcome you want?
What problems do customers have with estimates and can they be resolved through design?
How do you keep this process as minimal as possible but also give a user and their customer the appropriate amount of information?
Wire Framing
Wire Framing came next. Above you can see a detailed version of a later pass of the process. Wire frames were presented to users with a basic prototyping to demonstrate flow, and a lot of crucial feedback helped shape the later versions, including buttons and layouts discussed in the next section.
The old system had a major problem in adding line items. Often when you added a new line item itwould appear at the bottom, which became exceptionally tedious when you had a large amount of lines. The system would also switch to newly created line, requiring instant input instead of letting the user decide when to appropriately add information. Through asking questions it was revealed to be much easier to simply add the amount of lines and then fill in information all at once rather than make sure everything is correct before moving on. We also had lines created below the current line you had selected or at the top if nothing was selected. Buttons for major categories such as labor hours and materials were added that you could "rapid fire" click, and selecting between items was made fluid and fast, a far cry from the old version.
ALTERNATIVE APPROACHES
In the old system there were a few places that the user would either be confused as to where to find information or get lost in the flow if they got distracted, which can happen constantly due to the nature of the work. Some examples of necessary changes are below.
Phase Navigation
Before
After
Phases are not always needed for jobs but some jobs are built on phases and even billed from them rather than on total job completion. Users found it confusing as to where to find Phases and how to see all the relevant information at once, but also needed not be overwhelmed with information. What had previously been a phase selection button became a shelf with larger phase buttons to be easily navigable, both by being larger and by displaying enough information to identify a phase that may be later in the numbered list, so you didn't have to start at Phase 1 and navigate through 34 Phases to reach Phase 35 for example.
Phase information was also condensed into to simple totals, listed by breakdown if relevant, in order to prevent cluttering of the screen.
Adding Line Buttons
Before
After
Building out line items for estimates can become tedious if you have to stop every time and fill out information. Making the easily-clickable "Add a..." buttons makes it easier for the Estimator to rapidly work out what they needed, then to fill in the details later. At first these buttons were absent, and later added in.
Outcomes & Reflections
The final outcome was an implemented release in the application. Above is a current screenshot that does not include the newest design system and fixes, but is live. This project is still currently still in development and not released to the public.
Ultimately this system is designed for faster speed of use, less missed line items (thus less wasted money and time), and the visibility needed by both estimators, office personal, and other project managers.
Users will be able to send customers emails fast and much more reliably as well as tweak any issues with the estimate that the customer may raise. Rejection and change is an important part in any estimation. Users are also able to display estimates to customers in different ways including by Line Item, Phase, Breakdown, and more.
Next time I want the opportunity to discuss the next project more often with users during the entire process. The development team had to build out most of the project before we could present it to actual users, and though we met with them a few times early on I believe I was limited on sample size and testing time. I used my prior knowledge of estimating to help but I believe this can make you biased on certain aspects.
I also would have created a design system sooner. Wire framing is a creative, messy process but the final designs were halted because no system was available.
NOTE: This project is not fully released to the public. Screens are anonymized to protect company information.
More Projects
UX / UI Design
Enabled Accurate Estimating for Contractors
Created an estimator in a job tracking application in order for certain users to build accurate estimates for customers.
Tools
Figma, FigJam, Jira
Roles
UX Designer, UI Designer
Client
EQS, Inc (StreamLine)
Project Duration
3 Months
Summary
An electrical contracting company wanted to build job tracking into their proprietary software and needed accurate estimating within the flow of job creation. The company already had a simpler software that was outdated, bloated, and designed for a small team with Apple devices. I was the sole designer for this project, working with a scrum master and developer to overhaul their current app and bring it to the web.
This estimator was built to function as a hub for generating estimates and the foundation of tracking money spent and invoiced on each job. Estimates are the first link of where all financial reports start so it's crucial to add all relevant information and for the numbers to be correct.
Context, Goals, & Constraints
This application is built for contractors. The parent company is a small contractor that specializes in industrial electrical work with some large-scale clients in both the private and the government sectors. Due to the nature of the work most of their jobs are heavily influenced by regulations and contracts set months or years in advance.
The main people using the estimator are highly-skilled electricians that know their clients well. They require precision in any numbers they give their customers and the flexibility to add minimal information. All of this requires the ability to be presented in various reports later in the process.
Persona
I built this main persona based on conversations I had with the team. Before we started designing for this application I had worked on their previous software project by ticket management and version support, so I knew the company's constraints and pain points very well. I had many years of experience answering user questions and handling and prioritizing development, and I've spent time on job sites using the same technology the project managers use. This gives me an exceptional understanding of their needs and restrictions. I've also spent a lot of time listening to the needs of employees in regards to the specific data their customers require.
Design System
We started designing this application from ground up with the Estimator as no exception. I started with no design system or assets and had to create one for consistency and faster iteration for this project and future projects. I asked the developer what tools he was using for the project, researched many different template systems that were compatible with front end, and decided that Shadcn UI was both streamlined and supported our development. I customized this with our own branded colours and styling choices, and ensured that it supported accessibility and scalability.
Design Process
White Boarding
The design started with a fresh look at what an estimating user would require in order to prepare any type of estimate for a customer. I had meetings with the main stakeholder to define exactly what constraints we had and who our main points of user research would be. I drafted all my notes in Markdown (Obsidian), then white boarded the ideas around and condensed some of them into to the notes above.
User Journey
Next I took a look at the customer journey as it was in the current version of the application (please note that these images were blurred in respect to unreleased design that I didn't create). I decided what the main flow throughout the estimating process was and how it could either be improved or completely redone.
I wanted to come into this process as a novice. It's exceptional to have an insight into the process already but sometimes with a beginner's mind you can better understand how a novice would approach building an estimate. The estimator should be simple enough for anyone to approach it and start building immediately.
Flow
After understanding the current process I drafted the flow through the entire process from creating to sending an estimate.
This was important to get correct but I wanted to keep it loose in order to capture the bigger picture. A few questions I kept in mind during this drafting process:
What is the final outcome you want?
What problems do customers have with estimates and can they be resolved through design?
How do you keep this process as minimal as possible but also give a user and their customer the appropriate amount of information?
Wire Framing
Wire Framing came next. Above you can see a detailed version of a later pass of the process. Wire frames were presented to users with a basic prototyping to demonstrate flow, and a lot of crucial feedback helped shape the later versions, including buttons and layouts discussed in the next section.
The old system had a major problem in adding line items. Often when you added a new line item itwould appear at the bottom, which became exceptionally tedious when you had a large amount of lines. The system would also switch to newly created line, requiring instant input instead of letting the user decide when to appropriately add information. Through asking questions it was revealed to be much easier to simply add the amount of lines and then fill in information all at once rather than make sure everything is correct before moving on. We also had lines created below the current line you had selected or at the top if nothing was selected. Buttons for major categories such as labor hours and materials were added that you could "rapid fire" click, and selecting between items was made fluid and fast, a far cry from the old version.
ALTERNATIVE APPROACHES
In the old system there were a few places that the user would either be confused as to where to find information or get lost in the flow if they got distracted, which can happen constantly due to the nature of the work. Some examples of necessary changes are below.
Phase Navigation
Before
After
Phases are not always needed for jobs but some jobs are built on phases and even billed from them rather than on total job completion. Users found it confusing as to where to find Phases and how to see all the relevant information at once, but also needed not be overwhelmed with information. What had previously been a phase selection button became a shelf with larger phase buttons to be easily navigable, both by being larger and by displaying enough information to identify a phase that may be later in the numbered list, so you didn't have to start at Phase 1 and navigate through 34 Phases to reach Phase 35 for example.
Phase information was also condensed into to simple totals, listed by breakdown if relevant, in order to prevent cluttering of the screen.
Adding Line Buttons
Before
After
Building out line items for estimates can become tedious if you have to stop every time and fill out information. Making the easily-clickable "Add a..." buttons makes it easier for the Estimator to rapidly work out what they needed, then to fill in the details later. At first these buttons were absent, and later added in.
Outcomes & Reflections
The final outcome was an implemented release in the application. Above is a current screenshot that does not include the newest design system and fixes, but is live. This project is still currently still in development and not released to the public.
Ultimately this system is designed for faster speed of use, less missed line items (thus less wasted money and time), and the visibility needed by both estimators, office personal, and other project managers.
Users will be able to send customers emails fast and much more reliably as well as tweak any issues with the estimate that the customer may raise. Rejection and change is an important part in any estimation. Users are also able to display estimates to customers in different ways including by Line Item, Phase, Breakdown, and more.
Next time I want the opportunity to discuss the next project more often with users during the entire process. The development team had to build out most of the project before we could present it to actual users, and though we met with them a few times early on I believe I was limited on sample size and testing time. I used my prior knowledge of estimating to help but I believe this can make you biased on certain aspects.
I also would have created a design system sooner. Wire framing is a creative, messy process but the final designs were halted because no system was available.
NOTE: This project is not fully released to the public. Screens are anonymized to protect company information.