Project

Role

Research // User Experience // Concept & Prototype // Design System

Background

Version 1 of WonderBill was an app which allows customers to manage their bills, subscriptions and other outgoings by connecting their accounts directly to the app, so everything is in one place.

There were many fundamental issues with this old proposition including:

1. No Open Banking capability
2. Nothing to make a customer come back more than once a month
3. Inaccurate data so customers still need to check their bank account
4. No basic budgeting features such as income or payment methods
5. Dashboard was not useful
6. No bill archive

Background

WonderBill 2.0 was an overhaul of the proposition and a full redesign of the app. This included building an app that’s engaging and accurate by extending the proposition from ‘bill management’ to ‘bill management, household management & budgeting’. As well as re-envisioning all key flows with a focus on increasing engagement and retention, and by creating sticky habits in the way people manage their household finances.

Research

To begin, we started to run interviews each week with different segments of people from various combinations of age, income, free time and living situation to understand how each group currently managed their household finances. We wanted to know what this process looked like, what they felt was missing and what their biggest headaches were.

We quickly started to see patterns that spanned across all of these different segments and some of the biggest issues started to become clear.

Research

Some recurring issues were, keeping on top of your finances takes time because it’s such a manual process. It’s hard to keep track of where your money goes and so it’s hard to judge if you’ll run out of money by next payday. Due to multiple bank accounts and bills spread across multiple bank accounts it’s very difficult to have visibility over what you can actually spend vs what’s in your account.

Another issues we encountered time and again was people being caught out by unexpected expenses such as a bill you only pay once a year or an event such as a birthday.

Once we started to develop high level hypotheses around these issues, we tailored our questions to try and validate them and to dive deeper into each area.

Analysis

The goal was to create a product which would give customers back control, time and peace of mind by providing them with everything they need to manage your household finances with little effort.

It would provide one convenient place for everything related to their household, meaning they were always in control and organised without having to think about their bills. They would always know when and how their money has been or will be spent. Reducing the fear of being overcharged by providers or not having enough money in their account for upcoming bills. The app should be secure, accurate and can be trusted.

Analysis

Open banking will mean users can add all their bills automatically in one go and they will be able to view the frequency and cost all in one app. We can notify a user when their next bill is due, if they have enough money to pay and what they have left. They will be able to see their spending velocity as the period progresses which will predict if and when they will run out of money or if they are on course to save. This will remove the worry of overspending or being caught out. They will be able to view their data by pay cycle and see their projected outgoings and incomings in order to stay organised.

Prototyping

By the end of this initial discovery phase, we had enough insights to focus our findings, refine our assumptions or come up with new ones and decide on the core user needs we want to fulfill. We then tried to identify where to begin. There is always a lot of uncertainty in early stages and it can be hard to know how to start.

We started to think about what the rough structure of the app could be. This involved working through user journeys and trying to get a high level structure of the app. It’s good to start with a core screen where some of these main ideas will feature as once you start playing around with layouts, it often happens that he architecture of the system changes.

We decided that the best place to start would be the Transactions section. As this would be the place that a user would spend most of their time and feature most of the core functionality, so we could build out from there.

Prototyping

We made our ideas tangible with quick prototypes and tested them out as soon as possible. The goal was to test our hypotheses and the solutions quickly iterating fast to validate our concepts. This process is quite lengthy and involved us reworking user flows and information architecture as we discovered more insights about the problem and usability.

Around this time we also started to outline what would appear in the MVP this way as we were working quickly we wouldn’t be designing high fidelity mock ups of things we may not need until much further down the line.

Prototyping

Once we thought we had something solid we started to work  on more hi-fidelity designs. As with the wireframes we started with one core screen to try various styles, iterating until we landed on a few things we liked.

We wanted the app to feel more mature and raise the level to that of apps like Monzo and Revolut. Going for a clean, legible look, with a simple, recognisable brand colour

Had some discussions about how this look and feel would work as a scalable brand. What is the tone of voice, what would marketing look like. Right now it’s hard to answer that question until we find out more about who are users are. Some of the more branded screens were kept very neutral so later we can start to add more character to them where appropriate.

Prototyping

Once we were happy and wanted to move forward with this look we needed to scale it across a lot of screens and do this quickly. I started work on some simple design components in Figma which would eventually scale in the WonderBuild design system. It was beneficial to introduce this early because it would greatly speed up how fast we could design and iterate but also keeping a high level of quality.

Benefits of creating a set of design components early:

1. Efficiency: Instead of repeatedly designing components from scratch, Design Systems enable designers and developers to reuse components and thereby increase efficiency. Which is great when you are building fast. It means you can put designs together more quickly.
2. Consistency: Design Systems introduce a shared set of principles and rules to build components. When you have 3 designers all working simultaneously inconsistencies will start to appear very quickly. Not just visual but with usability. Working this way we can reduce that likelihood, as it's a set of rules we can all work to.
3. Scale: Increased efficiency and consistency lead a company to build faster products at scale. We are also encouraged to think of the app as a system rather than as individual screens. So as it scales we don’t sacrifice usability or quality.

Implementation

We moved to a product vertical structure for the development of the new app. Each vertical was responsible for a different area of the product.

1. Augmentation: Responsible for solving new problems.
2. Iteration: Responsible for the improvement and growth of existing solutions. 

Each vertical has a full team including design, font-end and back-end engineering and a product manager. Working this way means each vertical can work autonomously, at speed and is responsible for the whole end to end process. Subsequently they aren’t held back by top level decision making. Everyone understands the problems we are trying to solve and is empowered to go and solve them.

My role within this structure was lead designer in the Augmentation vertical and responsible for maintaining and improving the design system across all verticals.

Results & Findings

Ongoing user testing of the app has been extremely positive so far. With 90% of testers giving the app 4 out of 5.