Onefill

A CASE STUDY

Onefill is a visionary product created to help people buy things online through their bank safely and securely.

I am going to use Onefill as a case study to demonstrate my UX processes and practices.

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. The information in this case study is my own and does not necessarily reflect the views of Maxwell Forest.

Understand the problem

One of the first things I try to do is understand the problem we are trying to solve. There are a few techniques to do this but all involve good old fashioned research and asking questions.

You need to research who your users are. Observe them either trying to solve the problem or interacting with the product. These observations should happen in lab conditions and also in the users day-to-day life if possible. What devices are people to use to access your product (people behave very differently on their phone compared to their laptop)? What time are they going to access your product (on the train, at home, at work etc)?

Onefill

What type of product are we designing?

An app for mobile devices.

Who are the main users?

People who are concerned about their safety and security while shopping online.

Where is the product being used?

Wherever people do their online shopping - on the sofa, on the train, in the office.

Why do they need it to exist?

So they can shop anywhere online and feel safe.

How will it be used?

People will shop confidently at their favourite stores using their mobile device.

Conduct interviews and surveys, whatever is necessary to build a robust picture of your potential users.

I conducted a lot of research to help inform the Onefill project. This involved sitting in coffee shops buying people their morning coffee in exchange for 10 minutes of their time through to 1-to-1 interviews with senior banking executives to conducting remote surveys.

This research will reveal a lot of data that feeds into every product decision and will help define product requirements.

I always aim to make sure that anything I do falls into the sweet spot of desirable, viable and feasible. For example, we could personally go round to every person who is about to buy something and make sure they successfully checkout but that wouldn’t be at all feasible!

Content Strategy

Getting your content strategy and information architecture correct is vital. What are the important functions and elements we need to include in the product? What are the business goals? How do we sort the hierarchy of information and make sure only relevant information is shown when needed? One of my favourite methods to capture all of this and to prioritise is card sorting. I ran regular card sorting workshops to break down the avalanche of information required in Onefill. I'm pretty good at writing copy and micro-copy but engage with your copy writer if possible.

Persona creation

At this point you might want to develop personas. They should be informed by your research to be useful. Don't just make interesting stuff up, the personas should reflect patterns you've identified.

There isn't really a shortcut, they come from conducting interviews, surveys, user testing, contextual inquiry and other activities. Personas are important particularly if you are not the target audience.

User journey

I began to outline the user steps of why, when, where and why the user will interact with Onefill.

Ann installs the Onefill app.
Ann goes shopping online using her mobile device.
She finds a TV she wants to buy.
Ann adds it to her basket and decides to checkout.
At that point here credit card balance is surfaced so she knows she can afford the TV.
She continues to checkout.
The credit card she normally uses online is shown clearly. She taps it to continue.

Ann taps confirm on the merchant page.
The payment successfully goes through and she is shown a summary of the transaction.
Ann then sees various payment options including pay with points and monthly payment plans.
Her credit card details are automatically injected into the merchant payment page.

From this I started to explore User Stories which are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile User Stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. They can be written at varying levels of detail (epic = big) and can be split into numerous smaller stories that can be worked on in sprints.

As a user, I want to see special offers so that I can save money.

These user steps and stories fed into the user journey and helped me create the map below as a design artefact.

Once the user journey is mapped we can start looking at what the potential flow through our product could behave.

Sketching

Sketching is such a powerful way to quickly communicate ideas that in my opinion it is still unmatched in its ability to create disposable low fidelity designs. I sketch a lot. Whether it is in my notepad getting my ideas recorded or on a whiteboard to communicate a new type of interface you will generally find me with a pen or pencil in my hand. It allows for less preciousness around any design, everything is so much more disposable in this format and that is exactly what you want at this stage. It also encourages broad feedback ("How do I get there?") as oppose to narrow feedback ("I don't like that font") which again is exactly what is required at this time.

Wireframes

I tend to combine my early wireframes with my projected flow of the product. They inform a rough guide for the layout. They should be clear and simple, no visual design or aesthetics here. They can serve as a good conduit with the stakeholders, signing off on placement/flow (broad feedback) etc rather than getting bogged down in font choice (narrow feedback) etc. Include lots of comments and annotations on them.

Prototypes

Once wireframes have been created (and continued to work on) I began to explore flows and interactions. The best way to do this is by creating prototypes. How do you get from one area to another? I will use Invision for this part which is perfect for providing a holistic clickthrough experience. Where Invision falls short is in exploring micro-interactions - how screen elements act and react with each other. This is where you can really surprise and delight your users. I generally use Principal to do this exploration but it’s a fast moving area and there are lots of alternatives!

Please note I have lots more prototypes but am bound by NDA's around what I can show here.

Testing

How many test participants you involve, how closely your test participants match your actual users, and how many iterations of testing you run are all decisions shaped by budget and time constraints.

Usability testing is straightforward enough that anyone can - and should - experience running one. Being in the same room while someone uses your product is a powerful trigger for creating empathy with users.

I wrote comprehensive reports detailing every interaction the subjects experienced. I created a scoring system and prioritised each finding and logged them back into Jira.

High Fidelity

I tend to start introducing elements of high fidelity design at the prototyping stage this is when you can start applying it to the project to finalise the design of Onefill.