Pepper Money

Lead Management System

Overview on Pepper Money

Pepper Money is a specialist lender in the Financial Services industry, based in London and Cardiff, in the UK. Pepper are merging with Optimum Credit to become a bigger specialist lender in both first charge and second charge mortgage spaces.

My involvement at Pepper Money

I’m a UX Designer in a team with the Head of UX, Digital Designers and Developers.

I started working for Optimum Credit / Pepper Money in June 2019, first as a UX Developer, and now as a UX Designer. Here’s some of my achievements at Optimum Credit / Pepper Money:

Created a system to be used by Brokers for business services. 

For the first year, I was working on a project to be used by Brokers and our staff alike to quote and service loans from our business to our customers. I created a component library and was a key part of the UX process.

Introduced the Government Design Principles. 

I implemented the Government Design Principles to our designs to keep everyone in the team to the same set of standards. 

Created a lead management system. 

But more on that below…

The problem

My goal for the project was to create a system whereby our internal staff could manage leads for our second charge business. They wanted the system to be simple and easy to use.

The system needed to be effective in several areas. It needed to show staff in an easily digestible way, which leads were the most urgent and which were least urgent based on SLAs. The system also needed to house contact information for the leads and be able to have information entered with scheduling features for internal staff to mark against leads.


1. Create a simple system

We want to create something where new staff don’t have to do much learning on the system to grasp it.

2. Ensure customers are dealt with in the best & quickest possible way

Customers are inevitably busy and we want to be giving them the best service at all times. A clunky system will be slow and harm this goal.

3. Create something that could stand the test of time

I wanted to create something that our internal staff can use for years to come.

Understanding the requirements with User Research

Starting the process

The first step of my user research was to understand exactly what type of research I was going to do, especially given we had limited time to come up with a solution for this. 

User Interviews

Seeing as our users were internal staff, I wanted to use the opportunity to learn more about their needs of the system, how it would be used and how it would fit into their existing processes. I spoke with the Retail team to gather their thoughts, ideas and requirements for the system before doing anything else. This hit the “Start with User Needs” aspect of the UK Government’s Design Principles.

Desk Research

Using the principles of Jakob’s Law, I went about looking at platforms that did similar things in different markets. I checked other lead management software to look at what they did right, what they did wrong and how we can improve the experience for our users.

If I had more time, what would I do next time?

Unfortunately, the scope of the User Research wasn’t quite as much as I’d have liked going into the project. But, if I got the chance with more time to do it again, I would:

  • Do more desk research based around using lead management tools.
  • Get some of our internal staff to trial another lead management software.
  • Interview at least 5 of the internal team. Unfortunately, this wasn’t possible due to demands of the business.

Low Fidelity Wireframing

Multiple options

I wanted to get a feel in a low fidelity way, of which solutions might work best for our internal users for the project, before we started hi-fi prototyping. We have two main pages of the lead management system, but different scenarios in the requirements. I wanted to get a feel of what the internal team liked and what they wanted to see going forward.

Workshopping and iterative design

Once I had the low-fidelity wireframes in place, I workshopped with our internal teams to find the best solution moving forward. We settled on an approach after long discussions on the benefits and drawbacks to each. Once this was done, I wanted to move into high fidelity wire framing and iterative design.

One more helpful feature

After requirements were finalised, we came to these workshops and the internal team realised they wanted to add a feature to schedule calls on the system. However, when I considered what this would mean, I proposed a different solution. I proposed that we add a feature to add the appointment to their calendar, instead of on the system. Here’s why:

  • I was worried that if our internal staff had the system closed, it wouldn’t remind them, leading to missed customer appointments.
  • The current process for our staff is that they use outlook calendars across the team and share these with each other.
  • We were tight on deadlines, so while other options like getting an automated email from the system were possible, this was more work for the developers for not much more reward.
  • Internal staff are asked to have their emails open all day.

The results

The programmes feature is due to go live on the sidekick app shortly in June or July 2021.

What next?

I’m now focused on what happens next. When it goes live, we’ll be looking to have a regular feedback loop with the internal team due to use the systems to manage leads. We’ll send out regular surveys, shadow the staff and do user testing to understand where we are going wrong, what we are doing right and how we can improve going forward.