Background

For the last 5 years, the RBS mobile app has been ‘setting the bar’ in customer expectations.

New additional features however, are complicating user journeys. Journeys that were relevant and simple to access are now becoming more complicated or obsolete. We needed to reinvent the navigation and refine the IA to prioritise what’s important for customers, whilst maintaining a frictionless experience.


 

The brief

  • Take a long view (18 months) of the roadmap and determine how the IA can accommodate the upcoming features without becoming bloated.

  • Focus on known pain points - Navigation & Payments.

  • Research and learn of others’ pain points and prioritise.

  • Take into account business priorities and constraints.

  • Propose how rollout could be phased based on feature dependencies, user/business priorities and logical sequencing.

  • Deliverables to include assets for development for Android and iOS, working closely with RBS mobile development team throughout the process.

  • Use the opportunity to start a definition of how the new brand will look in the mobile banking app.

 

My role

Spanning the product design process end to end my responsibilities included:

  • Workshopping with the client to gather insights and requirements.

  • Conducting research and analysis to gain a deeper insight.

  • Leading collaborative ideation sessions.

  • Sketching, wireframe, designing and building prototypes, defining and animating interactions and transitions.

  • Conducting user testing and presenting findings to validate and iterate on solutions.

  • Communicating and rationalising design direction to product owners, dev and key stakeholders.

  • Championing collaboration between our team and RBS mobile development to ensure alignment on direction, understanding of business needs and technological constraints.

  • Crafting high fidelity visual designs and defining the application of a new brand to the app. via a new design system.

  • Preparing all assets required for all device types for Zeplin to support development through build to post release.

The team

Product designer - (Me)
Experience designer
Project manager

Product owner (RBS)
Experience lead (RBS)
Head of mobile (RBS)
Mobile dev team (RBS)

 

Our approach

 
Screen Shot 2018-09-24 at 17.30.58.png

1

We analysed the existing experience

Screen Shot 2018-09-24 at 17.30.58.png

2

We explored and prioritised

Screen Shot 2018-09-24 at 17.30.58.png

3

We sketched and designed

Screen Shot 2018-09-24 at 17.30.58.png

4

We tested, learned and retested

 

Underpinned by our design principles

 
Help me discover useful features
— navigation
Make my frequent tasks frictionless
— payments
Educate me in context
— on boarding
 
 
Give me answers before I even ask
— Help & Support
 
Delight me with relevance
— personalisation
 

 

1.

We looked at existing journeys to identify common consumer pain-points, focusing our design strategy around their needs.

RBS_existing_journey.png

1.1

We used various research methods and resources to understand the existing experience

 
Core tasks with current app_ethnographic.png

Ethnographic studies

Aside from revealing the core tasks performed by customers in the current app the ethnographic study revealed people’s associated feelings with these tasks highlighting that balance checking, transaction tracking and purchase guidance are fundamental in giving users a sense of control.

IMG_4181.JPG

User interviews

Listening to users and learning of their financial position, life stage, responsibilities and needs from the bank helped clarify pain points and frustrations as well as the positive interactions and friction free experiences they have with the bank.

We learned for example that the simplicity of the app. is seen as a key benefit for some users. These insights help keep the ‘personas’ relevant and solutions on track to meet user needs.

 
natwest_branch2.jpg

In branch interviews

In branch was most revealing as we had a whole range of people, from students that were very disconnected from their finances to tradespeople who had never used the app, to time -poor business people and then retirees that prefer the personal aproach of the branch.

One of the wider business objectives for RBS is to increase mobile adoption and reduce the need for branches.

So learning from all these demographics is key.

competitor_feature_analysis.jpg

Competitor analysis

We conducted some high level competitor analysis at the beginning of each sprint to align the team and generate any thoughts and insights that might help steer us in a particular direction. This included looking at how direct competitors tackled similar usability problems and innovative solutions used by indirect competitors.

 
 

1.2

Some of the pain points we identified

 

Payment journey - confusing and too many options upfront

Discoverability of useful features - more menu is ambiguous to users, and has become a dumping ground for new features.

Finding specific transactions - users find it hard to find specific transactions and understand why some recent transactions may not be shown due to them being ‘pending’.

Card control - users that have needed to cancel their card feel there should be an easier way to do this. This paired up with a business objective to reduce customer service calls.

Broader learnings

Ideas can land on the BAU roadmap from many areas of the business, there is a need to find some way of validating ideas or assumptions before they go to brief.

One method we proposed was to fromulate some kind of hypothesis backlog that all requests from the business would go through, this could also be a place where ‘side learnings’ from user testing could be captured, essentially giving a backlog of not just buisness generated hypothesis but also learnings direct from users.

 

2.

We prioritised the key user pain-points and translated them into clear goals and then solutions.

 
Working wall from discovery to prototyping

Working wall from discovery to prototyping

 

2.1

Building a range a experiences and quick prototypes in order to push through the best solutions, based on the key user and business requirements

 
sketches_wires.jpg

Sketching, Wireframing & Designing

Ranging from solo ideation sessions to time boxed design studio skecthing sessions we generated many ideas. These were then refined and worked up into designs using Sketch.

 
prototyping.jpg

Prototyping

Ranging from low fidelity paper prototypes to high fidelity click through animated prototypes we used pen and paper, Sketch, Principle and InVision to build for testing.

 

3.

Putting our solutions infront of users to learn iterate and validate

We conducted a number of rapid, low-cost user tests, which then led up to two face-to-face lab testing exercises with existing and new users.

 

Tree testing with OptimalWorkshop.com

Results from first and second round of tree jack testing

Results from first and second round of tree jack testing

 
Screen Shot 2018-09-24 at 17.30.58.png

Assumption

Users know to find the abiltiy to update payees details in ‘Manage account’

 
Screen Shot 2018-09-24 at 17.30.58.png

Learnings

50% of users failed to navigate to ‘Manage account’
_

Most chose manage payments
_
Labels in the account menu lack clear differentiation causing users to second guess and more than often end up in the wrong place.

 
Screen Shot 2018-09-24 at 17.30.58.png

Action taken

By collating all tasks related to paying someone and giving the clear label of ‘Pay’ we retested with a 96% success rate second time round.

The primary use for this was to test and vidate IA designs and assumptions and learn from user behaviour how our IA could adapt to match the mental models of our users.

Common themes

When looking at the results, we identified a common theme, while not significant in individual tests, accumulatively it was clear there was an issue.

It became apparent that the bottom bar navigation item ‘Products’ was confusing users. The solution to this was to change the label ‘Products’ from a passive label to an active label ‘Apply’ to help diferentiate from existing products and new products.

As a result, during the second round of testing we saw higher percentages of positive paths taken across all tests and no instances where the user was wrongly clicking on ‘Apply’

Retrospective

Treejack testing was great to validate or help define IA but its after the fact of knowing there is a need fro the particualr feature. 

Part of the work was to reduce bloat in the app, and this feature had been on the roadmap for feature parity reasons only, arguably we had not validated whether users actually wanted this feature in the first place. This might be achieved if there was a way to release beta app tests to a defined user base and watch behaviour over time. Either way, there was no evidence from user interviews, reviews or feedback that indicated this as a need.


Guerilla testing

Creating quick tests to help steer the solutions on the way to higher fidelity prototypes was really valuable in validating some patterns and assumptions.

This test was to test users behaviour when presented with two versions of the same journey. 1. Making a payment with a single entry point that branches out once the user starts typing a name. vs 2. Making a payment with two entry points up front, ‘Saved payee’ or ‘New payee’.

Learnings

People felt more comfortable with the two entry points up front, however, this lengthened the journey as they were forced to make a choice where in prototype A the app could have made it for them.

Guerilla testing.JPG
 
 
natwest_branch.jpg
 

In-branch testing

These were the most revealing and challenging tests, both for the prototype and for the moderator. Many people who were in branch were there because they did not use the app, this challenged the designs the most but equaly kept us fccused on the user, its easy to assume a pattern will work when you work in the field or product design every day, testing in the wild with non tech savy customers is the key to creating highly useable and accessable products.

 
 

Lab testing

In person in London and remotely with support from local moderator in Edinburgh; We set these up to learn more about customers experiences with the bank and the app and to test high fidelity prototypes which we iterated on from the learnings gained for re testing.

Testing in a controlled environment allowed us to carefully monitor the users behaviour and gauge their responses to new interactions, this led us to simplifying and decluttering the interface even further, focusing the user on the task one step at a time. Copy was a key actor in helping them understand the journey and this was a great way to test comprehension with some interesting regional insights gained from the split between Edinburgh and London.

 
lab_user_testing.jpg
 

As a result, we created a customer centric and scalable solution

 

4.

Some of the journeys we tackled

 

Payments journey

 

Objectives

Make payments frictionless and more flexible

  1. Quick access to payments by replicating customer’s mental model

  2. Unifying payment journeys

  3. Reducing cognitive load and user errors

  4. Understanding payment limits

 

Outcome

Surfacing ‘Pay’ on the home screen
Existing journey - Users go into the account they’re paying from then choose the function, such as Pay, to complete their task
New journey - Using the ‘Pay’ Quick-link allowed users to access payments much faster and in the most logical path.

Reframe payments to ‘Who’ not ‘How’
Existing journey - Payments split into several separate journeys.
New journey - Grouping payments in one area minimised confusion and duplication for users shifting the paradigm from buisness to user. Who do they want to pay, not, how do they want to pay.

Focus the user on the task at hand
Existing app - The user is overloaded with a range of tasks per screen.
New journey - Breaking down the journey into 1 primary task per screen - allows the user to focus more clearly and complete the task quicker

 

Primary navigation

Navigation_homescreen.001.jpg

Problem

Key journeys such as ‘Pay’ and ‘Transfer’ are currently hidden.
Analytics show that the current bottom bar isn't properly utilised.
Testing shows that features in the ‘more’ tab are not well utilised and almost redundant.

Objectives

Make features more discoverable and get more value from the bottom bar
Simplify key journeys and create ‘shortcuts’
Reserve the tab bar for high value features
Avoid hiding features in the ‘more’ menu
Make sure currently ‘hidden’ features are located where users expect to find them
Create an experience that feels more personal


What we learned

Users prioritise ‘account balance’ over any other data points

From the ethnographic study, we learned that users primary tasks involved checking the balance of their accounts.

We hypothesised that the current account tile was cluttered and could work harder to display the balance.

We used a preference test to guage opinion on 3 variants which showed a clear favorite.

A rapid 3 second test on usability hub to test information recall validated both our assumptions and the users preference.

With the new account tile designs giving clearer higherachy to the screen we were able to test bringing the entry point to pay and transfer up to the home screen

The task priority results of the ethnographic study, supported by the design principle ‘Help me discover usefull features’, formed our hypothesis that users wanted to be able to make payments easier and quicker.

The challenge was to balance adding new UI elements to one of the busiest pages of the app while prioritising high user value features. The designs tested well, with users welcoming these key tasks being brought to the fore.

It would be interesting to perform larger scale testing over time in a beta app. 

The ‘Accounts’ label restricts the IA

To make the more tab redundant features that were hardly utilised, and features that had higher priority than reflected in the IA were tested and repositioned according to the user’s mental model. This brought to light an opportunity to surface priority features in a ‘Home’ tab.

During testing, users responded well to the ‘Home’ label as a place to navigate into accounts as well as surfacing other important actions.

The ‘Products’ label is confusing to users

Most users found ‘Products’ label very confusing, and associated it with a number of different features. Relabelling the tab to ‘Apply’ performed much better during testing.

 

Transactions

transactions.jpg
 

Objectives

  1. A more logical way to handle transactions

  2. Filter through transaction more quickly

  3. Offer a more detailed transaction summary

  4. Create a more scalable filter option

Outcome

Quick access filters
Existing journey - currently hidden from view behind a filter dropdown. While research and insights told us this was a needed feature, the live data showed it was rarely used. In branch testing revealed that users were unaware of the feature showing that its discoverabiltiy was causing the issue.
New journey - The new design surfaced the filters on the top level of the transaction screen and tested well with users.

Pending transactions and future dated payments
Existing journey - There was no way to view the breakdown of this information in the live app. Customer service data revealed that this was an ongoing issue despite the inclusion of ‘Available balance’ and the inclusion of an explanation as to how pending transactions affect your balance.

Part of this was an issue with the time lag of sometimes 48 hours for visa to register a payment (unlike mastercard). However, where the data was available we identified that we would be able to provide a better understanding to users as to how much money they actually had available to them in there account.

New journey - We were designed a solution where the total opending and future transactions were rolled up into there own screen driven to from the top of the transactions list.

This tested very well with users and time will tell if it reduces confusion to users and in turn calls to custtomer services.

Filter transaction
Existing journey - Only ability to filter by date.
New journey - We used this opportunity to test users appetite for category filters and date range filter. This tested well however there is some more work to be done on categoristation. Users were unclear as to how these would work, if they would be autoatically assigned and if they could create their own categories.

 

Card control

Card-control.jpg
 

Objectives

A better way to control cards

  1. Reduce customer service calls by offering a quick and easy way to lock cards

  2. Allow users to limit their card spending

Outcome

Card lock
Existing journey - No option to lock card, only the help section directed to call customer services.
New journey - Tree testing revealed 60% of users would navigate to help to cancel their card while 40% navigated to manage account. This showed that card control should be accesable from help as well as within the account management area as the function was a paradigm shift for many customers, moving from them ‘needing help’ to perform the function to them learning that they have the controll themselves.

Spending limit

‘As a user i want to be able to limit the amount of money i can spend per transaction so that i can have better controll over my money’.

Testing revealed that the majority of users felt it was a very usefull feature.

As this feature was born from anecdotal evidence unlike the card controll which has hard data from the call centre, we would have ideally done a partial rollout through a beta app to gain some more quantatative data and perhaps some user interviews to gain some qualatative insight into how its being recieved and whether to move forward with it or not.

 

5.

Other journeys that were explored

 

Onboarding - A smarter way to educate users about new features

Onboarding.jpg
 

Problem

Research shows current onboarding isn’t very effective. Users tend to skip the - screens instantly. 

Objectives

  1. Make onboarding contextual and progressive

  2. Prioritise the main benefits

  3. Onboarding journeys that are actionable as well as educational

  4. Use as a place to surprise and delight with the new brand

What we learned

Engaging the user at the appropriate time is the main challenge
Almost all users dismissed the ‘on load’ onboarding with no recolection as to what it was for.

Users don’t want to be interupted, they have specific tasks in mind when opening the app

Contextual onboarding gave much better results than ‘on load’ onboarding

The most effective was when the onboarding of a feature was direclty related to the task being performed and when it was actionable as opposed to passive.

The style and treatment of the supporting visual can be the diference of a failed test or a succesfful test.
Initially we presented users with heavily branded ionboarding in the NatWest illustrative style.

This was seen as advertising by the majority of users and they were blind to them.

We addressed this by including user interface designs in place of these which improved results.

Next steps

We took our learnings to the business and dedicated a stream of work in BAU to take the task of onboarding into a wider app wide review.