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)
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.
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.