top of page

Financial institution


This financial institution has begun its journey to digitise itself, this first step being to digitise its most popular product. The economic climate and the need to change their approach to capture customers in a post pandemic world has caused them to address how they can digitise their current 14 page paper application to an end to end digital experience.


UX Designer

UI Designer
User researcher


5 months

November 2022 - 2023

This case study is both a representation of what I have done during this project but also a record for myself to record and remember each project I have partaken in. This can result in rather long pages so I shall start with a reflection of the project and then dive into it. 

*This product was conducted under an NDA and so the assets seen below have been stripped of logos, and their colours and design elements have been changed to protect the client. The accompanying design artefacts are also recreations without in depth information.


This project was difficult, and one of my first projects where I was the sole designer. But it did teach me a lot,

  • It reinforced just how powerful atomic design systems can be when implemented properly, this allowed me to make sweeping changes through the entire onboarding flow by editing our components rather than going through pages individually.

  • How important setting up sprint rituals are, these allowed not just myself but my entire team to be on the same page and allowed me to connect key stakeholders together to get fast results which improved communication between teams and allowed me to work asynchronously which gave me more time to work and greater flexibility to work on the upcoming priorities.

That being said it also showed me where I have more room for improvement and as I continue to work though the project these are areas I want to improve. 

  • Communication: Between myself and stakeholder but also to reach out to my team for more support when I'm struggling with capacity to work.

  • Influence: Being able to sit down with stakeholders and easily show them the benefits of working or following certain established user patterns. 

The Approach

For this project a small team was engaged, a Lead Experience Designer, a Business Analyst and myself. We joined a larger product team from the client with a large number of developers and a product owner, we also worked very closely with a stakeholder team to establish our milestones within the project.


We began the project with a discovery where we:

  • Undertook workshops to understand their business

  • Conducted a competitor analysis

  • Understood their business processes and practices

This was a great opportunity to develop my consulting skills. I lead an ice breaker session as part of the initial 'Discovery'. The ice breaker session was called 'Rabbit Holes'. In this activity I get all those involved to draw a rabbit that somehow represents them. This activity has a few purposes;

  • first being by having the rabbits represent them we learn small things about them, like their favourite hobby, food, or their background

  • Secondly and more importantly we will continue to use these cards throughout the project. When anyone feels that we are off topic for a meeting they can hold up their card and declare rabbit hole to bring us back on track.

Untitled - Frame 1.jpg

The 'Discovery' phase was expedited due to tight timelines on this project. We had achieved what we needed in this stage and this allowed us to move forward in the 'Inception stage.


The Inception was a week-long process where we took our understanding and research gathered in the Discovery to run a goal setting workshop with the business. The goals of this segment of work is to:

  • Discuss and rank priorities for the upcoming work.

  • Evaluate the original timelines and make the necessary changes​​

  • End up with an achievable road map for milestones

Untitled - Frame 2.jpg

It is during this section of work that we begin to dive into design. As these projects had aspects of agile and continuous development, we needed to start compiling a design approach for the project. Working closely with the frontend developers where we found design limitations and cooperatively worked together to find the best approach to design.

This institute had a variety of design guidelines from a range of products, but they shared very little in terms of design language and also ranged in age. I was given the guidance from their branding and marketing teams to use these and merge the range of design elements from their other guidelines to form a modern and minimal design guild. But to keep the existing branding colours. 

I found that the existing design guidelines did not meet AA accessibility and pushed for this to be a goal for design with this new design system. This product focuses primarily on the elderly and typically the older someone is the more susceptible they are to situational disability. 

I took on the task of reconciling their existing design guidelines from their divergent product range. Then recombined and redesigned them to make a new design guideline that focused on digital first approach looking at web apps and mobile. But incorporating a AA accessibility bench mark and responsive design.

I took an atomic approach to designing the new guidelines. This is a practice that I endorse as it allows designers to make sweeping changes across the user journey and keep consistency. Taking the lead on this allowed me to continue to practise my Figma skills making components, and variants. Due to the tight deadlines of this project, it caused the lead designer and myself to work asynchronously allowing me to take creative ownership of the designs within the design guidelines.

The first priority for design was

  • the most commonly used components first, these will need to be fully resolved before development starts will make up the bulk of stories in the upcoming sprints, not just the making of these but implementing them in pages to complete are MVP.​

These buttons make up half of the forms main capabilities are integral for each page, being the smallest building blocks to an end to end experience.  

button P new.png
Unchecked new.png
Button S new.png
Checked new.png
Button T new.png
Input fields

These fields allow users to input information and complete any tasks on the form and make up the rest of the core functionality of the form. The ones seen here show all of the variants excluding error states.

Input free text new.png
Input dropdown new.png
Radio button new.png
Radio button new 3.png

Colours are an important part of the design process and allow us as designers to sign to users what is usable and what is information. We used the company's brand colours where we could achieve AA accessibility and found solutions where we could not.

This colour guide also has enough scope to encompass the needs of accessibility in design and can also cover our error states.

The colours seen here have been modified to protect client information* 

Colour mapping.png

This is an example of atomic accessibility for the radio buttons. I chose to enlarge the radio button to help those who struggle with smaller instructions on screens but also because this is much easier to highlight when this element is selected, focused, hovering or clicked. This is also done as a variant collection allowing my design team to change their component on the go and we can make sweeping changes across all these components and keep consistency throughout the user journey.

example of accessibility.png

User testing

Bringing this product to a digital market and expanding the customer segment, means that there is a lot of new ground to break for this company and for this product. Among these were user testing, with a radically new approach to presenting the information and wanting to attract a new customer base means the design approach and information presented should be validated to ensure we can get the customer engagement we want before going live. 

To prepare for the user testing I asked for additional help to lay the groundwork and to conduct user tests. It was unlikely that I would have the capacity to build a functional prototype and testing script on top of my everyday responsibilities. I was able to delegate the testing script to an experience designer who specialised in research and set up recurring check ins to get updates and help redirect them where necessary and help them gain a better understanding of what we wanted to test and tailoring the prototype to the script. 

Are goals for this user test was to validate our hypotheses

Hypothesis One

Users will be able to navigate from start to end with little difficulty.

  • We expect some friction on

    • Payments page​

    • Declaration page

Hypothesis Two

We expect that the majority of users will not have used a product like this in the past and some may have issues comprehending the concepts and terminology used in this application.

I used the design guidelines I had previously created to develop a functional high fidelity prototype for the user tests, this was modelled on our finished product milestone and included several pages that still needed more time to have their designs fleshed out, the purpose of including these pages were to test the financial concepts and understanding of users opposed to the functional design of each of these pages. 

Untitled - Frame 3.jpg

We performed 8 tests 6 with users found through askable and 2 previous users who abandoned the old process to validate our hypotheses. We tested users across our target market aiming at people between 55 and 79 years of age from different work backgrounds and of different levels of wealth. 

Our findings validated our hypothesis but also revealed additional points of friction in our user flow and highlighted additional areas where users lacked understanding.


Hypothesis one "Users will be able to navigate from the beginning to the end with minimal assistance"

Declaration page​

We also expected issues on the declaration page as it did not follow typical user patterns which we raised during the planning phase.

We found that close to half the users found this page confusing and needed directive advice to continue. This was due to non typical user patterns, the results of this did enable ​us to follow established user patterns later.

Payments page​

We expected issues on the payment page because we introduced lots of payment options which many would not expect here. We also introduce payment instructions and legal language that continue on the success page.


Indeed we found this to be true and a surprising range of ​misconceptions about each payment method.

Success page​

The friction on this page came from the users understanding of the next steps and ensuring payment for the application.

They found the next step instructions to be vague and close to 1/4 of users did not know if their accounts were the correct type or that they would likely need to contact their banks to arrange large sums to be transferred. ​

Many were also confused about continued contact with the institute as much of their communication was still via post, many found this unacceptable given the amount of money they were hypothetically investing. While email capability was on the road map it was still out of scope for this user test. 

A lack of transparency in the processes also added to a lot of confusion and questions.

Hypothesis two "Users will struggle "

Financial products

None of our testers had heard of this financial product before which was a bit of a surprise we expected that at least one would have heard of it before (excluding those who abandoned the original process)

Financial concepts and understanding

The basic concepts of this product were fairly easy to grasp for many, but we did find a few users with low financial and technological literacy struggled. 7 of our 8 participants were able to identify the differences within the product as they experimented with the time horizon and payment frequency. 

Government information

We also expected issues with understanding of government policy found within the application. Not a single one of our users was able to correctly guess the amount of the tax free threshold or had knowledge of SAPTO. 

We also found some of the government mandated questions made users uncomfortable. Many thought that the government should not have such transparency into their money. 

Payments page

There was an inconsistent understanding across the board on how different payment options work and how secure they were. There was also very little understanding that moving large sums of money would require their banks to be notified and how to assess if they are using the correct account. 


This project had a range of challenges, and I was not able to overcome all of them, and while frustrating I do believe that I've learnt from them. 

  • Design by democracy 
    This project used a comity of stakeholders to decide how the onboarding process would look and due to scheduling the people who sat on this comity changed frequently leading to rehashing the same point over multiple session and generally a slow approval process. A solution to this project to create and maintain a decision and change log to record the choices we made for design and why these were chosen. This did not work as well as first thought, there was very little engagement from stakeholders to stay up to date with the documents and they continues to bring up outdated decisions in the meetings.

  • Waterfall meets agile
    The teams within the business were split in how they operated. The product team worked in agile and business team worked in waterfall. As the team was very small communication filtered between the two teams using me as the main medium for messages. This created a lot of friction and was in my opinion a rather large risk as I was unable to make every meeting held by either side of business due to other meetings i need to be in or to be able to get work done for either team. I attempted to solve this problem by setting up a recurring meeting between these two side of the business and by creating a co-working space in Miro where they can add upcoming work items, priorities them and then use the time in the meeting to discuss, unpack and seek advice from subject matter experts to reach an informed decision.  

  • Technical limitations
    The tech stack used comprised almost entirely of legacy software that was unable to change without major overhauls to the backend systems. This required us to design with those in mind but lead to quite a few unneeded and unusual form fields that could not be removed until much later down the line. This was particularly difficult because one of the main goals of this digital transformation was to reduce time to submission to around 10 minutes to match the time of other similar products. 

bottom of page