Lloyds Banking Group
Latest work
A brief overview of some publicly available work
Quick links
Budgeting tools
Mortgage product cards
Zoopla landing page
Pre-populating Agreement in Principle
Mortgage Product Cards
THE PROBLEM
Within our mortgage and remortgage calculator results screen, we previously displayed 30+ product cards to customers when exploring what rates and term lengths they could receive based on their search criteria.
This prevented customers from being able to quickly identify the right deals for them, led to endless scrolling and the cognitive overload on screen prompted customers to drop out of the journey without exploring the rest of our application journey.
-
ContentSquare data identified that less than 50% of users that see the first product card in our mortgage calculator then scroll far enough to even see the third product card.
-
Our competitors like Natwest and Nationwide were already making changes to condense the number of rate cards shown, reinforcing our need for a more condensed view on the calculator.
THE SOLUTION
We reinforced a 'less is more' approach by aiming to show only one product card per term length. Our aim was to improve users understanding of the product cards as well as making it easier for them to compare. Therefore, we also adjusted how we show incentives and we introduced radio buttons within each card to switch between the different product fee options to avoid further duplication.
With this in mind, we cut down 2/3 of what we previously showed users and now have a maximum of 8 product cards showing at one time without compromising on the information provided and comprehension of the cards. Clearly displaying the product fee options and how that would dynamically impact the interest rates, we also highlighted which product fee option would be most economical for a customer based on which deal they were looking at.
In addition to this, another key change we made within our product cards was to stop displaying Total Amount Payable, a long-term estimate based on assumptions about behaviour and interest rates far beyond the initial term. Instead, we replaced this with Total Cost of Deal which shifts this approach by giving a clear, exact figure for what customers will pay only over their chosen product term. This better reflects today's priorities, where rising everyday costs mean customers are focused on short-term budgeting and monthly affordability.
We ran these changes iteratively as A/B tests to assess the impact of our changes to the product cards.
THE IMPACT
Through A/B testing, we identified that our new version of the product cards drove stronger early-stage engagement with our mortgage journey.
-
We saw an increase of 15% in customers who saw our new product cards in our Mortgage Calculator then continue on to start and complete an Agreement in Principle (AIP) which was our primary target metric.
-
For our Remortgage calculator, we saw an 8% increase in conversion of customers viewing the new product cards to then start an AIP.
-
We found about 40% of our users on the page engaged with the product fee radio buttons that we introduced. This shows initially strong engagement, but there is potentially more we could do to encourage further interaction with these options.
IDENTIFY POTENTIAL SOLUTIONS
What are our key opportunities?
PROMOTE MONETARY INCENTIVES
There was a current lack of monetary riding incentives promoted within the application flow. Users are interested in knowing what the hourly rate of pay is and the speed at which they would be paid.
"Only thing that makes me not sign-up is that nothing is said about the payment and how much I can earn. If I have to put my time into this then I need to know if it's profitable for me first."
INSURANCE AND APPLICATION REQUIREMENTS
The type of insurance required isn't specified upfront which creates friction further down the funnel. Users want to know about insurance types and where to purchase it which is currently concealed on the landing page making it less visible for users.
40% of users expressed that they were most concerned with what insurance they need to ride with Deliveroo.
EASIER VEHICLE COMPARISON
The vehicle selection step is a high anxiety point for users. They want to understand the benefits associated with each vehicle type.
4/5 competitors lack specific benefits or informative content to aid user decision-making around vehicle type.
ACCURATE LOCATION SELECTION
The current locations within the selector are too generalised, but by showing users their nearby operational areas we can help to make it easier for users to identify suitable locations for them to ride in.
"The location field is quite lengthy to scroll down and it could be made easier to select a location. If I was able to write the name it would be much easier.”
REORDERING APPLICATION STEPS
The current steps in the flow could be reduced and the content within each could be simplified to lower experienced effort for the user. The steps could also be reordered in a way so that the sections are more closely related to each other.
Reducing form length by adjusting the format of the fields has proven effective with an uplift of 16% in applications submitted during previous A/B testing within the application flow.
LANGUAGE SELECTION
We identified that majority of users would not choose English as their preferred language. The most common languages of potential riders should be available for users in a language selector across the application flow. This aims to improve understanding of the application requirements and provide greater ease for some users in the application process.
Only 40% of users chose English as their preferred language in the application flow.
ACCOUNT CREATION
Majority of users visiting the site have already started an application to be a rider. However, there is no clear route for users to access their application and there is no save feature on applications preventing users from completing it in multiple sessions.
60% of users visiting the apply page have applied to be a rider before.
DESIGN AND VALIDATE SOLUTIONS
What solutions did we design?
We redesigned the application journey and prototyped this for mobile as majority of our applicants use this device. When designing the solutions we kept its applications to desktop in mind. The stages of the application flow that I knew were crucial were given extra prominence in the wireframes of the new flow and the functionality of these new features were considered carefully. We went through rounds of feedback with the client before producing the high-fidelity designs of this new flow. I wanted to create an experience that was seamless by simplifying key stages of the application process like the location selector and vehicle selector whilst reducing the number of steps in the flow. We also wanted to keep it consistent with the brand identity whilst adding some new design elements that followed brand guidelines.
We wanted to test our redesign on real users to see if we could validate our hypotheses of each solution. Our main concerns were with the location selection using the map on Step 1 and how easy users found comparing vehicles on Step 2 to make an informed decision.
We wanted the user testing to answer these 2 questions:
-
Does the new prototype solve and alleviate the identified problem spaces?
-
How does the prototype compare to the current application journey?
We conducted user testing on 10 participants and received a lot of good feedback with 9 out of 10 users rating the experience of completing an application to be 'easy' or 'very easy'.
"I thought it worked well, the whole application process was really easy, it left no room for doubt"
Selecting a different language was 'easy' for all users as they were able to quickly identify the language selector and felt it was a valuable option to have on the site.
10/10 users found the language options useful to have, but wanted a larger variety of language options shown
| Problem space 5
It was clear to 9/10 users that by logging in they would be able to continue with an existing application and could identify the two ways to log-in.
To further prevent duplicate applications, we can detect a duplicate email address used and link users back into their existing application.
"It is quite obvious. There is a login option and a return to application link"
| Problem space 3/4
We improved location accuracy by changing the locations drop-down list into a postcode input field. We also provided a current location option via geopositioning to make this process even simpler.
The route to start an application was not easily identifiable for users. This was a key finding as it impacts the volume of applicants entering the flow. Therefore, we made the primary CTA more instructive with 'Start application' copy.
The locations sorted by proximity was a preferred method of selecting a location for users, but displaying a map proved confusing for 6 out of 10 participants who preferred the simplicity of a location list. Therefore, we had the list open by default and users could swipe to interact with the map if they wanted to.
"It's not clear actually, because the first page that you see is this full map page, I would like to straight away see the nearest location because I'm already giving you a postcode."
Allowing users to select two locations (rather than just one) proved to be an effective way of providing Deliveroo with the transparency they require from their riders in regards to where they will most likely be working.
| Problem space 2
Framing the benefits around monetary gains improved user engagement in this area and the biggest incentive for users present were the rider tips which could be emphasised further.
"Keeping 100% of your rider tips is a really nice incentive to see"
To improve applicant quality we added a 'What you need to apply' section which users deemed as the most valuable content for them on the landing page.
"It's the most crucial part, it leaves out who can and can't work for you"
| Problem space 6
The positive reinforcement messaging once a user selected a vehicle proved ineffective for majority of users as it went unnoticed. It's worth revisiting in A/B testing with alternative executions.
Users did respond positively to the free accident and sickness cover benefit that we promoted at the top of this step.
"Shows that you're covered with personal accident and sickness which is nice, there's nothing unclear and it's straightforward."
| Problem space 1
To help inform the vehicle selection process for users, we included specific vehicle requirements. This helped to guide user decision making in user testing.
3/10 users wanted to know if payment varied by vehicle type as this would impact their decision when selecting a vehicle. Deliveroo cannot provide this information so we highlighted that users have full visibility of the length and route they would take and can accept accordingly depending on the vehicle they own.
"I do have a bicycle and a scooter, it would depend about the price (payment) , if they are the same then great but i would like to know"
| Problem space 1
User commitment is higher on the final step of a form which is why we included personal information requests at the end.
Aside from one comment about the ‘referral code’ field, everything on this page was deemed positive and ‘straightforward’.
DESIGN AND VALIDATE SOLUTIONS
Final Prototype
We delved into the problem spaces with this redesign and validated a lot of our proposed solutions during user testing. However, there are limitations to this research as we were restrained by our sample size to compare the control version of the site against the variation. I would recommend conducting several rounds of A/B testing where we isolate each key change and test it against control to really identify the impact of our solutions against the main KPIs we are trying to target.
The final prototype was created using Protopie
DELIVEROO
Making it simpler for applicants to become riders