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.
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.
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.
Product designer - (Me)
Product owner (RBS)
Experience lead (RBS)
Head of mobile (RBS)
Mobile dev team (RBS)
We analysed the existing experience
We explored and prioritised
We sketched and designed
We tested, learned and retested
Underpinned by our design principles
We looked at existing journeys to identify common consumer pain-points, focusing our design strategy around their needs.
We used various research methods and resources to understand the existing experience
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.
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.
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.
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.
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.
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.
We prioritised the key user pain-points and translated them into clear goals and then solutions.
Building a range a experiences and quick prototypes in order to push through the best solutions, based on the key user and business requirements
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.
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.
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
Users know to find the abiltiy to update payees details in ‘Manage account’
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.
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.
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’
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.
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’.
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.
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.
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.
As a result, we created a customer centric and scalable solution
Some of the journeys we tackled
Make payments frictionless and more flexible
Quick access to payments by replicating customer’s mental model
Unifying payment journeys
Reducing cognitive load and user errors
Understanding payment limits
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
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.
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.
A more logical way to handle transactions
Filter through transaction more quickly
Offer a more detailed transaction summary
Create a more scalable filter option
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.
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.
A better way to control cards
Reduce customer service calls by offering a quick and easy way to lock cards
Allow users to limit their card spending
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.
‘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.
Other journeys that were explored
Onboarding - A smarter way to educate users about new features
Research shows current onboarding isn’t very effective. Users tend to skip the - screens instantly.
Make onboarding contextual and progressive
Prioritise the main benefits
Onboarding journeys that are actionable as well as educational
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.
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.