ORDR

ORDR was my first project at General Assembly which focused on conducting effective user interviews, concept mapping and rapid prototyping. I was paired with Paul, a fellow student, who through a series of interviews discovered suffered from short term memory loss. Short term memory lapses can affect anyone at anytime, for most people this it a minor inconvenience or small irritant but for others it is a reoccurring issue which can blight the enjoyment of social activities.

User research

After interviewing Paul, my user for this project I discovered that he often suffered from short term memory lapses causing frustration and annoyance when out socially. Through asking a series of questions I gained valuable insight into how this problem affected his life and what solutions he had used to alleviate the problem. Once i undertood the problem better I was able to formulate a possible solution.

The Problem

Whilst interviewing Paul I asked him about his social activities. 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.

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.

Sketches and user flows

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 my user 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 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 storyboard demonstrating this situation and shared it with my user. Paul agreed by taking away the responsibility of documenting the order removes the need for him to remember it, thus solving the problem of him forgetting the order.

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 then started work on a paper prototype for solution, creating some wireframe showing how the app coould work within the userflow.

User Testing

Low Fidelity

I shared these initial concepts at my 1st critique and received some insightful feedback on some extra features which could improve the app for my user. I discussed the feedback with my user and decided which features I would add to the app.

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 would probably not use it.

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

BRANDING

Using the initial findings I created my first design for the app. The design reflected the colours and imagery from my first mood board. I tested the design on several users and received feedback that although the design worked it didn’t reflect the brand principles I had developed. There were also several usability issues that needed resolving.

2nd Prototype

Based on the feedback from my first prototype I created a second mood board from which I developed a style guide for my next prototype. The design worked on the deign principles of simplicity and fun. I developed a set of guidelines that reflected the brand values and made the app more user friendly.

Clickable Prototype