Problem Statement

Viola had already developed a personal banking product at this time. Then however an opportunity was identified by the business to possibly solve a persistent problem that is found in small and medium sized organisations.

The management of expenses and collection of receipts has always been a problematic area for these businesses. Petty cash is not an effective solution to this problem and asking employees to request a receipt has often fallen on deaf ears.

A digital business account that sends money to an employee and tracks their electronic receipts was the assumption.

Research & Discovery

Initial research took the form of qualitative interviews with several small business owners in the local area who would offer diverse perspectives. These were semi-formal interviews with open-ended questions which allowed for responses that could be elaborated upon and explored multi dimensionally.

 

We could not influence the interviewees, putting words into their mouths, in order to align with our key objectives. We wanted to obtain their unique emotions and insights from their own business experiences. This data would either strengthen or weaken our assumptions.

 

Our strong assumption was that either the business owner or the principal financial officer were having difficulty running expenses and collecting receipts.

Having a PGCE PCET I was familiar with differing methodologies in order to capture the required information under various scenarios. How to ask follow up and record are skills that I possess and put great emphasis upon.

 

Setting the environment, creating a comfortable and safe space is essential in putting an interviewee at ease. This provides the best likelihood of a positive rapport and meaningful outcome.

Personas

From these interviews, I was able to create three personas. This information reflects the questions asked and and the answers which were received.

 

Here, Kate gives us a good representation of our target audience. She is frustrated and at times weary from continually asking for receipts.

 

We found this a common thread throughout the series of interviews.

Ideation

My hypothesis was that the product was a two-way link between the business and the employee. The business would have control of the main account, from which funds (Top Ups) would be sent to an employee when requested.

 

Funds are spent either by a physical or virtual card or by paying a payee through sort and account numbers. There would be two separate product entities;

  1. Business Owner
    All features including transactions
  2. Employee
    Transactions and top up requests

 

Digital Wiresframes

My early wire sketches progressed to digital versions which allowed for further detail and flow clarity.

 

Many iterations occurred at this critical stage, mainly between the relationship of ‘company’ and ‘employee’, as it involved complexities which were challenging to simplify and collaborate upon.

 

One prime example of a challenge was using the high emphasis term ‘Cards’. Stakeholders had always seen the core relationship in the initiative between the business owner and the cards they would issue. I argued differently.

My Argument

I based my argument on the fact that the relationship between a business owner and their employee was fundamental between people. The card was secondary and only a device to service this problem.

 

Secondly, because we see names of employees initially with their issued cards, it is a reasonable assumption to call these names (labels) employees. This also allowed the logical introduction of a sub navigation; ‘Transactions’; the recording of an employee’s spending.

 

This is an example of how I am able to draw upon my experience to offer a real-life, holistic and user-friendly solution.

System Flow

However, it was at this point I took these Lo-Fi wireframes further and created a more detailed system flow.

 

For the moment they still carried ‘Cards’ in the main navigation, nevertheless my argument was being considered.

Iterations

At this juncture the flow was analysed within the team. It provided a visual cue, a map to whether our objectives and key results were present and could be met. Also what could be achieved as an MVP.

 

This stage was lengthy, involving several changes including the dropping of failure dialogs, top up modals for the use of full draws and the inclusion of the label, ‘Employees’ in place of ‘Cards’.

Prototype

Once we as a team agreed on a useable flow, I began applying myself to a design vision and a prototype.

 

The business owner prototype assimilated a dashboard, its transactions and a detail UI, along with an employees section where a ‘Top Up’ flow was visitable.

 

To finish, the ‘Pay’ section was linked together, illustrating a pay flow. Scheduled payments would be offered in phase two, but for now, account to account payments would be released as an MVP.

 

I purposely used a ‘While hovering’ state here as I originally presented the mobile UI prototype in Figma.

Prototype & Testing

I presented two user journeys to the business’s stakeholders. The first journey was to top up an employee’s card after receiving a request. The second, the user needs to pay £200.00 to a beneficiary.

 

The feedback was positive with just two amendments which were to give the top up notification bell more prominence and the second was to include a ‘Reason for request’ input for the employee.

 

I presented again, but this time to three small business clients.

 

This was done in our main office using a desktop setup. We used Hotjar to track user clicks and identify any pinch points or bottle necks.

 

We found the time taken for each journey was acceptable with minimum false clicks. I asked to mention a positive aspect encountered and something which could be improved.

 

Two users gave positive comments on the bright interface and use of colour, whilst improvements were to include;

  1. Archived statements
     
  2. Display upcoming payments
       on the dashboard

 

Challenges & Retrospectives

The main challenge which arose during this initiative was how I felt about the user’s relationship with the product. It is key in any product that this relationship is intuitive and straight forward.

 

Originally, stakeholders saw ‘Cards’ as a main section label, but I thought this would be a mistake. My argument was that the core relationship of the product is between the business owner and the employees and cards were to facilitate this relationship.

 

I have found that it is always beneficial to negotiate and put your case forward in a collaborative and constructive manner. My viewpoint was ultimately accepted as logical and it provided value to the product. The main themes I reflect upon the most and have learnt as a designer are that there are no criticisms only feedback,  and alternative points of view are always valid.

We need your consent to load the translations

We use a third-party service to translate the website content that may collect data about your activity. Please review the details in the privacy policy and accept the service to view the translations.