Workplace pension self service – Understanding our customers

Unfortunately due to NDA’s I cannot share prototypes, wireframes, updated personas and the designed outcome that contain any internal or confidential information.


The existing application was a business-driven solution, often driven by the sales team. It was an externally developed application, with legacy back end systems and the idea was to bring it in-house so that we could start delivering quickly. It was to be a like for like application with extremely tight deadlines.

We wanted to find out if everything on the existing application was being used and if it was, did it need improving? Having access to >3 million users opened up a lot of avenues for this to happen


Lead UXer from researching, prototyping, testing to implementation.


I carried out a plethora of the following research and testing sessions with our actual users. Some of the more regularly used techniques:

  • Moderated usability testing
  • Unmoderated usability testing
  • Card sorting
  • Competitor analysis/ Benchmarking
  • Competitor testing
  • Tree testing
  • Desirability study
  • Participatory design
  • 1-2-1 interviews

We used all this information gathered to improve parts of the existing application and to choose to not implement exactly like for like. We had more of an idea who we were creating this for and a great foundation going forward.

There were lots of assumptions who our users were. For instance, if you didn’t earn much money annually then you weren’t engaged in your pension. If you were young then you weren’t engaged in your pension. Needless to say, these myths were quickly debunked


When I started working with the development team and business key stakeholders the first thing we did was create proto-personas. This highlighted a huge disconnect and misalignment between who we were creating this product for. Stakeholders had the general consensus that the less well-off someone was the less engaged they were, however, the development team ended up describing themselves. All earning good, way above average money. This was a great message to share first off so that we could all understand that research into who our user truly is. It highlighted a lot of internal assumption and created some great influential advocated to get some real users in. We could then update the proto-personas to be more rounded researched-based personas.


I believe to create great products we must collaborate and that means taking the whole team on the journey with me. UX should be a team ethos and we should all own it.

We created an internal brand that we used to approach the clients to see if we could get some face to face time with their employees. There was an impressive amount of involvement from the clients and within a couple of weeks, we had managed to get someone on one time with over 4 clients and 40 people. We looked at all aspects of the existing application, carrying out a whole range of research techniques and travelled over the country to meet our participants.

I took a corner of the office, which had high traffic, to help visualise all our research and feedback. I placed everything in view. It created such a stir that all the sales team came to visit to see some of the insights we’ve received. I also left lots of post-it’s and pens around which empowered people to comment/ ask questions or highlight issues. This meant nothing was forgotten if I was out of the office.

This was ongoing though-out development and as we were a Scrum team in an Agile environment we would test during sprints and do more face to face research at a minimum of twice a month. To aid with regular testing of new MMF’s (minimum marketable features) we used a couple of unmoderated online tools: Userzoom being the main one and Optimal workshop.

All the data we collected fed into the product development when creating new experiences or even improving existing ones. A few examples of flows and wireframes

Leave a Reply

Your email address will not be published.