Product deisgner
Natwest thumbnail-V2.png

NatWest online application form

Project Background

The Royal Bank of Scotland was going through a digitalisation process across both their RBS and NatWest subsidiaries. As part of this process they wanted to increase their onecard application form conversions. onecard is a business card targeting medium to large companies with over 2 million pounds in annual turnover. Its focus is to allow greater control over credit limits, purchases and expenses, via their mobile app.

The existing application forms were built on legacy platforms and also existed in paper format, so this project was about upgrading to a modern online application form, and increasing its conversion rates.

1_About+your+business.jpg

Project Details

Live preview: https://app.one-card.natwest.com/

Duration – 3 weeks

Team – 3 software engineers, 1 product manager and me

My role – Gathering UX/process requirements, running workshops, wireframing, iteratively designing solutions and presenting to stakeholders

Tools – Sketch, InVision, Photoshop

Deliverable – Redesigned online application form


Research

I ran stakeholder interviews to gather insights about the existing requirements as well as how users interacted with the legacy system based on analytics data:

  • Only 6 applications per month were completed on the legacy platform

  • 83% of users dropped out of the online application form journey

  • Only 4% of completed applications came through the legacy onecard application form (64% were paper applications and 32% were through other online systems)

  • The first form step had a 50% drop out rate

Online form pain points

  • Error messages were not shown close to the relevant form fields, leading users to get stuck in a long page where the error was not obvious

  • The online form did not support some features such as setting up direct debit mandates and multiple signatories, therefore people still had to use paper forms for the missing features

  • Users had to re-enter the same information multiple times throughout the application journey (e.g. if a signatory wanted a physical card then their information needed to be entered again)

IMG_1266.jpg

Information Mapping

After gathering all the requirements I ran an information mapping workshop with our product team. The workshop involved identifying various use cases. These use cases helped to guide the team in choosing a set of questions for the application form.

I ran an information mapping workshop where I randomly stuck all the proposed questions on a whiteboard regardless of their categorisation in order to map them out with the team. This exercise helped us to step back and re-examine the logic of how questions should be grouped together and which themes the question groups fall under.

IMG_1250.jpg
onecard revised questions.jpg

Sharing the Findings

After the workshop I shared our findings with stakeholders for their feedback and to further iterate over the structure of the form questions.

Design Phase

After agreeing on a generic information structure, I created some initial wireframes. The wireframes allowed me to get feedback from the engineers before investing into designing high fidelity interfaces for more than 20 pages. There were many existing components which needed to be reused where possible, so that it was consistent with other newly designed RBS/NatWest forms.

Wireframe Iterations

During the wireframing process I further refined the design to include conditional branching so that users were only presented with questions which were relevant to their responses. For example if a signatory answered that they wanted a physical card, then an additional set of question asking for banking details and extra personal details would be shown to them.

9_Direct Debit confirmation.png

Direct Debit Mandate

We went though multiple iterations and feedback loops of what information should be collected and displayed in the Direct Debit Mandate section in order for it to comply with the law.

I was keen to simplify this feature therefore I proposed to auto-fill fields that were captured earlier in the flow and not ask the user to repeatedly fill in the same data.

Designs

RBS/NatWest already had a design library that consisted of already established components UI and interaction guidelines. It was important to re-use the components and interaction behaviour as long as it served the specific propose. This ensured that all the other RBS/NatWest forms were consistent and felt that they belong to the same brand.

Grouping Related Information

Users think in batches, and too long forms is harder to "digest". By creating logical groups will help the user to make sense of the form faster.

Using field length as an affordance

The length of the field suggests the length of the answer. I employed the fields that have defined character number like  postcode, day/month/year.

User Testing

We tested the prototype with 6 existing RBS/NatWest business banking users. We chose people with a mixed number roles varying from marketing senior manager to personal assistant. It was important to test how people from different departments and hierarchy levels go through the same application flow, since various people will end up using the form.

Findings:

  • Users were confused about the difference between authorised signatory and programme administrator roles and responsibilities in the application. 

  • We found out that the signatory for Direct Debit might not be already added in the application, therefore it was crucial to capture Direct Debit signory separately.

  • People did not understand that after pressing submit CTA in the last application step they still will have to sign the application via AdobeSign.