The problem
Despite being fundamental to taking any action as a user, the log in experience for the Rated People website had several glaring issues. It was one of those things that we all knew needed to be fixed, but had never managed to find the time.
Rated People has two users types, homeowners and tradespeople. For the most part logging in as a tradesperson worked well enough but the homeowner side had several issues. Chief of which; most homeowners didn’t know their password!
Context
Account creation for homeowners happens when they post a job on the site. There’s no dedicated sign up page, it’s integrated into the job posting flow. This means sign-up has to be as light as possible in order not to harm conversion through that funnel. Over time, and through a number of experiments, tests and MVPs that were never iterated on (shocking I know!) we’d ended up with something that really didn’t work well.
In order to keep conversion high, the ‘add password’ field was positioned at the end of the flow after the account was created and the job posted. Effectively it had become an optional field😬. Whilst this had a positive effect on top level conversion it created the undesirable second order effect that homeowners didn’t have a password but did have an account. To log in, they’d have to go through a forgotten password flow, despite having never set a password. You can see why that might not be ideal!
Scenario: homeowner finds a great tradesperson, gets a job done that they’re really happy with and wants to leave a review to spread the word but can’t log in as they don’t have a password. They’re prompted to use the ‘forgotten password’ flow, but know they didn’t set one. They get confused, can’t be bothered with it and the review is never published. So the homeowner has had a really positive experience with the brand that ends with frustration and the tradesperson doesn’t get their positive review and it harms the building of their business. No bueno.
To be clear, the reason an account is desirable is so that homeowners can liaise with tradespeople using our messaging platform, check reviews and ratings and, of course, add their own reviews and ratings once their job has been completed.
Whilst possible to handle this stuff through CRM and special tokenised links, it’s much better to do this as a logged in user (obviously). Future plans to get involved in payments and VOIP calling make it mandatory.
So then, the goal of the project was to integrate a light-weight account creation flow that wouldn’t harm conversion but would mitigate the knock on effects described above. To measure, we’d be looking at:
- No effect or positive effect on job post funnel conversion
- Increase in the number of homeowners logging in
- Increase in the number of reviews aded by homeowners
- Reduced customer service issues reported regarding log in
Constraints
The log in architecture for both homeowners and tradespeople is the same, so any changes would impact both user bases. We only had a limited amount of backend resource so anything that required their help would have to be minimal.
Process
We kicked off the project with a workshop (or was it just a long meeting? Is there really a difference?), in the room we had myself (design), a product owner, a couple of developers and somebody from marketing. After thoroughly understanding the problem (see that wall of text up there ^ ) we analysed a few different approaches.
We looked at three options
- Classic account creation (just ask for a password when collecting email address) but knew this negatively hit conversion
- A kind of 2 factor authentication method that sends a pin code to users mobiles so they can log in
- A magic link approach where a password isn’t required and a tokenised link is sent to an email account to log in.
Whilst the 2 factor approach had merit, the technical constraints we had meant that we didn’t have the capacity to build it. Besides that, we felt the magic link suited our requirements better - we could leverage the existing ‘forgotten password’ logic and repurpose it with only light development work.
Even better, it would have no impact on our tradespeople customers, they would still be able to log in as normal with their password, with no additional steps.
It’s worth expanding upon this - a magic link would be ideal for homeowners as they are less likely to even WANT to set a password, and logging in with email is super convenient. Tradespeople use the service much more, so having the speed advantage of a password log in (especially using a password manager) was critical.
As mentioned, the log in component is the same for both customer types, so the unique design challenge was to allow for both magic link log in and password log in without confusing anybody.
Results
Within the first 6-8 weeks the results were good, we saw no decrease in the main funnel conversion - may have been slightly up but it’s hard to measure as we’re looking at month on month and year on year averages, rather than a traffic split across the same period.
Homeowners logging onto their accounts increased by an enormous 55% and as a result we saw a good increase in the amount of reviews coming into the platform.
Anecdotally customer service has reported less log in based queries but we don’t have hard data on that to track, but it seems to have done the trick.
What would I do differently
This was a successful project but there’s usually things that could have been done better. In this case I think the big one would have been simply to fight harder to get log in prioritised and have fixed it much earlier. Additionally it would have been more sensible to introduce the changes in a more thoroughly tested way, which would have reduced the risk in switching.
