Discovery Phase

 User research

After interviewing Paul I discovered that he often suffered from short term memory lapses. He was often out with friends and family but he sometimes had the problem of remembering peoples orders, whether it be in a restaurant, coffee shop or pub. Paul said he can get distracted when waiting to be served which then causes him to forget the order that he has just asked his friends for. Through asking a series of questions I gained valuable insight into how this problem affected his life. Once I understood the problem better I was able to formulate a possible solution.

The Problem
Paul can forget what have ordered if he gets distracted whist queing.

The Solution

To design an app that helps Paul recall the order so he gets the order correct.

Concept mapping

Once the problem and solution had been defined I developed a concept map using the information gathered from my interview.

The concept map let me see clearly some of the common issues relating to this problem. I shared the concept map with Paul's and asked him more specific questions on some of the points that the concept map highlighted.

From this second discussion and the concept map I was able to identify the pain points associated with the problem. Once I had defined the pain points I started work on identify the user goals which could solve those problems.

Pain points

• Forgets peoples orders
• Loses place in the que
• Pen and notebook not always available

User goals

• To remember the order
• Keep place in the que
• Keep a record of the order

Defining the problem

USER STORIES

Once I had I identified my user goals I began to focus on the how to successfully achieve those goals. Through my interviews and discussion with Paul I discovered that he would sometimes write orders down to remember them. This was a crucial insight as it helped shape my solution to the problem, the app needed to be simpler than writing things down in a notebook. If the app was too time consuming or complicated it may solve the problem but it wouldn’t be useful.

I then sketched out a user story so which  helps to create a simplified description of the users requirements with the app.

USER FLOW

I came to the conclusion that the onus on writing the order should be put on the people placing the order and not Paul. The app should be a simple tool that collects data from existing platforms like Facebook messenger. This eliminates the need for Paul to write the order down whilst keep and easily accessible copy of it. It would also save time as Paul could collect the order data whilst in the que, this would solve the problem of getting distracted when in the que as he would not be required to remember anything as the app would log the data for him.

I created a simply user flow based on a scenario from my storyboard. From this user-flow I created the first sketch of the app and how these would related to the user-flow. I added an extra feature that Paul could resubmit the order whilst at the bar. This solved the problem of Paul losing his place in the que if he had to change the original order.

I created a second user-flow demonstrating the new features and how they would help the user achieve the goal. The biggest challenge was to keep the app simple. If the app became more complex than simply writing an order down my user wouldn't use it.

PAPER PROTOTYPE

From my second user flow created paper prototypes demonstrating how the new features would work on the app. I then tested the prototype with my user giving him predefined tasks which took him thought the journey reflected in my second user-flow. The below video shows the app could work with Facebook messenger within the userflow.

Developing the Solution

User testing

I tested my paper prototype with Paul and made some interesting discoveries. The first was that there should be a function to quickly retrieve an existing order and the second was that you may need to change the order at the bar if the drink wasn't available.

I then iterated my initial design into some low fidelity wireframes which
I re-tested with Paul.

The testing was successful but also highlighted scenarios were extra features on the app would be of benefit. For example if an order was small and needed to be taken down quickly a quick note function should be available. The next stage was to move to a mid-fidelity prototype, this is when i started to consider the branding the app should have.

MID-FIDELITY BRANDING

The first step was to start researching and looking into which applicable qualities my brand could have so I could understand my brands personality. I decided to name the app ‘ORDR’ as it reflected the purpose of the app of ordering in a simply easy way.

Brand principles
Through my research and some brand affinity mapping I was able to identify seven clear brand principles which I could start basing my design on.

Mood boards
I developed mood boards which gave me a visual guide to a possible look and feel for the brand whilst developing a style guide.

Delivering the Solution

Clickable prototype

The below prototype reflects the user accessing an existing group, requesting an order, amending that order and then saving that to the group.