UX Case Study: Imagine an app that is driven by both a Contractor’s and a Homeowner’s needs
Spruce App
There are often many “little jobs” that need to be done around the house. Maybe it’s a leaky faucet, a light fixture that needs replacing, or even just a small bathroom that needs painting. These jobs often seem too small and expensive to hire a contractor for, but many homeowners don’t have the skills and know how to get it done by themselves. On the other hand, there are many individuals who may consider themselves very skilled in these areas and who wouldn’t mind earning income by taking on these smaller jobs, but they do not know how to find the work or how to manage clients.
The solution is to create an app that allows homeowners to create listings for smaller jobs around the house and a place for contractors to find and bid on those jobs. The app will manage payments, scheduling, and communication for both the contractor and the homeowner.
Homeowner Research
To get started we needed to understand the needs and wants of our users. We created a list of assumptions about who the users would be and what type of features they could possibly need. We used those assumptions to create a survey for homeowners and distributed it through social media. We asked about peoples expectations and frustrations when hiring a contractor.
From the survey we learned:
- Most people find contractors through search engines and word of mouth
- 30% would hire a non professional, while 55% are open to the idea.
- Reviews and recommendations are very important when picking a contractor.
- Quality of work is more important than the cost.
- Communication is key to a job well done
Contractor Research
We were also able to interview several contractors. Some considered themselves professionals and others did handy work simply as a hobby, but they were all open to the idea of picking up those smaller jobs to supplement their income.
Their main concerns were:
1. They did not know how to find clients
2. They were worried about record keeping and taxes
3. Poor communication with clients can waste time and prevent a job well done
From this research we knew that a major problem we knew we would have to solve was the matter of reimbursement for services. Our survey for the homeowners had several questions asking how much one would expect to pay for specific services (such as painting, or plumbing work). Our responses varied greatly and so we concluded that most people do not know how to place value on specific skill sets and jobs. On top of that the contractors we had interviewed also struggled to place a dollar amount on certain projects, stating that they would need to know all the details of the job before they would be comfortable doing so.
Using the information from our survey and interviews we created a persona for the Homeowner and another for the Contractor. These personas helped us the visualize who our Users are and better understand their wants, needs and frustrations.
We used our research and personas to then begin story mapping and discovering the key features needed to create our minimum viable product. Based on the research, we knew it was essential to include features that would build rapport and trust between contractors and their clients and so we decided to include ways to voice chat, video chat and text message all within the app. As we began adding more and more features, we had a difficult time deciding and agreeing upon any aspects that could be cut. However, we considered every component at that point to be essential and so we moved forward. It wasn’t until after moving on to wire framing that we realized we needed to further discuss the scope of the project and went back to the story mapping step. We decided to cut features such as video and voice chat and decided that the simpler text messaging feature would be sufficient.
Sketches
The team then began sketching up lo-fi wireframes both together and individually. It was important that we made sure our visions for the app were in tune with one another so at this stage we were constantly sharing our sketches and communicating our ideas. We began discussing and testing different color schemes and font types. A style guide began to form and we were feeling confident that we had a solid foundation to begin transferring our designs from pen and paper into Adobe XD.
Lo-fi Wireframing
We decided to design in Adobe XD because of the power and simplicity of its prototyping feature.
I personally took on the task of wire-framing both the on-boarding process and the messaging feature for the app. My goal was to keep the process short and simple so the user could get started without any major delays or obstacles. One decision that took some thought and discussion with the team was whether or not providing a payment method needed to be a required field for the user during account creation. Our concern was that making payment info required would ruin the flow of the on-boarding process and possibly cause people to cancel out of the entire app if they are not given the option to skip this step. However, we decided that because of the nature of the app and the importance of contractors being able to easily receive payment for their labors that we could not make this optional. It was a difficult decision to make, but in the end would eliminate any future payment issues and create a better user experience.
Hi-fi Wireframing
Creating the Hi-fi wireframes was a fairly simple process at this point. We had already decided upon things such as font and color scheme before hand and mainly had to make sure we were keeping things consistent throughout.
We prototyped within Adobe XD to test the flow and usability of the app. I also decided to prototype a couple of micro-interactions to give us a better idea of how those interaction would look.
Based on our user testing, there are several changes that need to be made. One major improvement needed is on the payment screen. Users found that too many payment options for the contractor side of things could get confusing since they are not be confident that using a credit card to receive payments is the best method or even possible to do. This would require further research and additional testing to decide upon the most practical methods. I plan to continue with Usability testing further down the road as well.
