Personas are created to help designers and developers understand who will be using the products they create. When informed by user research they provide valuable insight into the motivations, goals and frustrations of users. And while they are a great tool, for really complicated user journeys, their usefulness can be limited.
We faced these limitations while developing a user experience and interface for Now: Pensions, one of the UK’s largest pension providers. When it comes to a complex system like a pension management tool, the interface depends on far more than the user goals and motivations spelled out in a traditional persona. Someone at the end of their career is going to have a much larger and more complicated set of data behind their pension than someone just starting out. And all of that data needs to be portrayed in an easy to digest way at both ends of the spectrum.
So if relying solely on personas wouldn’t give us enough detail to design the product our client wanted, how could we make them work harder?
Elevating personas with data
Much of the user interface we designed was driven by the stage of the user’s career. We decided to extend our personas into test accounts using realistic data consistent with the persona’s age and savings.
Above
Combining personas with realistic layers of data made a much more compelling prototype
This allowed testers to log into our prototype and assume the identity of the personas, giving them a much more nuanced view of how the product would work in different scenarios. Augmenting our personas with realistic data encouraged our client to think holistically, identify problems sooner and avoid setbacks later in the product’s development. For example, when we added a large transaction history and bigger pension pot to our ‘nearing retirement’ persona, the user interface became cluttered. As a result we invested more time in designing charts and graphs that worked effectively with vastly different data sets.
Taking clever shortcuts to build the prototype
It was clear early on that static prototyping tools like Figma, Invision or Axure weren’t suitable for the amount of data and variability we needed to use. We would have to create hundreds of screens in order to mimic the experience for different personas, eating into the budget and making changes difficult.
Instead, we employed existing open-source libraries of code and UI components to quickly produce a working web app — one that allowed us to test only what we needed to test, with minimal development and maximum flexibility. By taking these clever shortcuts, we could iterate on content design, page layouts and data visualisation using data associated with each persona.
Testers could log in into the prototype and switch between personas at will to see how the interface would react.
Iteration, variation and more insightful user testing
The iterative nature of rapid prototyping meant we could add more data to the personas over time, resulting in a multitude of variables for each. The more data we added, the more we learned about how users interacted with it. User testing and resulting feedback became much more insightful, since testers could select scenarios that were most reflective of their own retirement journey.
These cycles of design and prototyping, rooted in data, meant that a data model for the product emerged before any real development started. Before, in fact, the development partner had even been selected. This meant our client could clearly articulate their ambition to potential technical partners and the final product became easier to realise.
How is the product progressing?
Our work didn’t end with the prototype. We’re now using it to develop a design system and component library for the new product. Thanks to our use of data and thorough testing of many use-cases, ambiguity has all but gone and we are able to produce a visual design that responds to all scenarios. We worked with our client to produce a written specification, which, along with the prototype is helping technical partners understand how the system is expected to work. The prototype continues to evolve as new features and functions come into play.
Ten4 understood our user-centred needs. The complexity of the user journey was captured in the prototype which allowed us to demonstrate our vision to colleagues and industry peers. It gave rise to our UI Kit and is helping us promote the product to the industry before development is completed.
Beyond pensions and fintech
In retrospect, it’s easy to see how a data layer can help create a more rounded prototype for a pensions portal. But will this approach help us with clients in different industries? We think it will. Any digital product or web app can be prototyped more thoroughly with data. The trick—if there is one—is to balance the benefits of working with data against the relative speed of a static prototype.
It might be hard to pinpoint the critical mass, but whatever the sector—arts and culture, science, charity, healthcare and so on—where the user journey is complex, where different datasets dictate different user experiences and where we can synthesise the kind of data the product will use, we’ll give strong consideration to this approach.
So watch this space.
We’d love to hear your story. Talk to John
