.png)
Boomin was a property portal and CRM, with a suite of products for estate agents and their customers
UX Objectives
Working on the SmartVal feature, my objective was to reduce the friction points along the user flow of completing a SmartVal application.
This reduces the conversation time, reduces bounce rate and in turn generates business leads for estate agents
Role: UX Designer
Timeline: 4 weeks
Tools: Figma, Maze, HotJar, UXMetrics
WHO?
Homeowners looking to receive an accurate online market valuation on their property
WHAT?
The SmartVal feature allows customers to receive a more accurate home valuation from a local estate agent, by completing a number of steps to gather relevant information on a property's value
WHEN?
Users are able to submit a request for the valuation at anytime and expect to receive a response with 15 mins during business hours.
WHERE?
The majority of customers completed a SmartVal using a mobile device
WHY?
Customers who are able to complete the valuation with little friction have a more accurate property valuation
The Process
.png)
Understanding The Problem
Understanding the data
Discover
As part of a 5-step flow, users needed to choose 2-4 property features, out of a selection of over 80. Using best UX practices, I could identify that the design of this component was likely creating some friction.
When SmartVal was launched, it found a market-fit between homeowners looking for an accurate valuation without the need of an agent visiting their property, along with connecting estate agents to new business leads. This played out especially well for customers during Covid restrictions, who were considering taking advantage of the U.K. governments reduced rates of stamp duty.
The successful adoption of this product meant it both became a crucial feature for Boomin and generated a substantial amount of data.
I focused my attention on this features modal, using the data across Google Analytics, HotJar surveys and recordings and estate agent feedback channels to establish friction points.
Features Modal
The initial problems I uncovered related to:
>50%
Time
Over 50% of users were spending over 1 minute on this step
39%
Return Rate
There was a high return rate to the modal
Define
Defining the Problem
After the initial discovery phase, the insights I gathered were:
Using the How Might We technique, I reduces the solution area to three points.
Developing Solutions
How might we...?
1
support customers to make the best choice for themselves
2
improve users understanding of the minimum & maximum features required
3
reduce the choice overload on users
My design suggestion are:
-
reduce the choice anxiety on users by presenting them with the most valuable features, or most in-demand as default
-
cutting, renaming and consolidating as many features as possible
-
categorising the remaining features either alphabetically or through categorises
-
Hiding features behind tabs or hidden fields
-
Providing instructional copy for the minimum and maximum features required
-
Improving the UI on the search field to encourage its use
-
Improving the behaviour of the CTA button, eg animation to support users understanding of min. and max. selection
Hypotheses
Search Feature
Users are not using the search feature
Naming convention
Users are confused about naming of these features
Choice overload
Users are needing to scroll a long way to discover every feature, especially on mobile
Minimum & Maximum
Users are confused about the number of features they need/can choose
Develop
Design things right
The Develop Stage is where I begin to translate ideas into tangible solutions to test
In order to address the amount of content on this global component, my aim was to reduce and categorise the features.
I ran card sort followed by a tree test to define the information architecture, firstly establishing the test objectives and finishing with a test report.
Tackling Content
Test objectives
-
Do users select from the most-in-demand feature
-
Do they understand certain terms e.g. seaview/coastal, no chain/chainfree, investment property/in need of modernisation
-
Are features placed in correct categories e.g. what is the best category for "swimming pool"?
-
Do most users understand the category names e.g. the "construction" category?
-
How do users define "equestrian"?
-
60% categorised swimming pool as “luxury”, alongside a trend to define it as ”outdoors” (21.72% first choice, 4.34% as second choice).
Analysing the results, I established further questions:
New lines of enquiry
Test findings
Iteration 02
Card sort
Tree test
-
19.35% followed the direct path “Equestrian” with 54.91% choosing “Outdoor spaces” first
-
73.33% chose the direct path for “Investment property” with 16.67% defining it as “In need of modernisation”
-
What is the difference between “investment property” and “in need of modernisation”?
-
How should equestrian be categorised – Location, outdoor or luxury?
-
Would property owners with original wood flooring categorise it as “original features”?
-
Do we need both “coastal” and “sea view”?
Along with addressing the content, I began to address the interactive design of the features component, with my UI designer colleague
Tackling UI
Iteration 01
The initial design concept tested categorising the content alphabetically, hiding content behind tabs.
However, the number of features within each letter was inconsistent and lead to a visual imbalance.
Iteration 2 removed the features from behind tabs, into a continuous single page.
Viewing the design, it was clear that this would involve a lot of scrolling for the user, especially on a mobile device
We needed to find a way to hide and reveal features but not in alphabetical order.
Iteration 3 used an accordian feature to hide and reveal features based on categories defined though the card sorting and tree testing
Iteration 03
DELIVER
Final Design
After a round a user testing and a peer review the final design was decided, with handover documents prepared for the dev team
Retrospective & Next Steps
What went well
Working collaboratively across a multifunctional team is what made this design a success. For example, having a close relationship with the data analyst ensured that I was interpreting the data correctly at the discovery phase and was able to discuss a suitable plan to collect data once the feature was live. Being able to work with colleagues meant a great balance of strengths, variety of perspectives and a healthy environment for critique.
Defining the right problem to solve ensured that I was able to share a clear brief with both my copywriter colleague and my UI designer colleague. During times of creative brainstorming, the brief was a solid foundation to determine the best steps to take. It helped to guide "best guesses" when multiple options were available and was a reference point throughout testing.
Things I would do differently
When the UI designer and I handed off the work, it included a detailed handover document with notes of all the features behaviour, links to prototypes and a detailed component spec sheet. We briefed a lead dev on the project but it was subsequently passed to another to build. The briefing we had provided was unfortunately not passed on and it took us awhile to realise that. We found ourselves repeatedly responding to the same questions during build. In the future, I would book a briefing with whichever developer was assigned to projects as it would have saved a lot of confusion for the whole team and time spent recapping old ground.
