Case Study: Feast Time

For our first project at General Assembly we were asked to design a mobile app that would help out the classmate sitting next to us. So I turned around to Aaron to find out what element of his life I may be able to assist and he told me straight away of a common frustration that he found himself wishing there was a mobile app to help with only last night. Aaron is, by his own admission, a good cook but finds it very hard to keep track of timing all the distinct cooking processes that are going on during the preparation of his meals. So to boil it down to problem and solution statements…

The Problem

Aaron is a keen and ambitious cook who finds it hard to simultaneously time to perfection the cooking of every dish that makes up an entire meal.

The Solution

An app that comprises clearly distinct multiple independent timers that alert Aaron to when key operations in the meal cooking process require action.

User Research

in the kitchen with Aaron — contextual enquiry

In order to gather more information to understand Aaron’s problem in detail I invited Aaron into the kitchen at General Assembly to ask him some questions about his motivations — wants, needs, goals, intents — and also his habits, frustrations and delights in the kitchen. In the spirit of contextual enquiry ideally we’d be conducting the interview in his own kitchen while he was cooking but, while that wasn’t possible, being in a similar environment and performing relevant actions helped him access his memory more reliably.

Aaron’s description of the meal that he prepared for he and his girlfriend’s dinner at home the night before certainly backed up his claim of being a good cook. It was a complex menu of various items and certainly sounded absolutely delicious! I discovered that a primary pain point in his cooking process is that he currently resorts to using multiple devices, anything to hand in his flat that offers a single timer function (e.g. phones, laptop, tablet) to time a single item each. These take up valuable space in his extremely compact kitchen and hinder a highly focussed, organised, fast paced evening activity that he regards as sacred, meditative and cherished ‘me time’, providing him great satisfaction on completion. He also informed me that he almost never shared his recipes or documented his culinary works of art and engaged in social media as little as possible.

Concept Mapping

I distilled the information gathered in the interview into key words and phrases, wrote on post-it notes and continually rearranged them on a wall to draw out dominant themes to guide the app’s development.

Themes start appearing

From this I created a digital concept map that isolated key topics, sub-topics, established cross-links and clarified priorities. This acted as a high level reference point from which to establish what the app’s functionality would be.

Concept map

User Profile

Referring to my user research notes and concept mapping I developed the following list of Aaron’s key personality traits and relevant habits that I could refer back to help keep the design process user centred.

He is a highly experienced cook

He is an organised perfectionist

He values cooking as a relaxing solo activity

He consumes and creates a minimal quantity of social media content

Ideation & Sketches

An immediate concern that sprung from my user research was that Aaron hates having to clean hands to touch devices he currently uses as timers so I had doubts that a mobile app would be the solution to his problem. Maybe a piece of hardware designed for the task would be more suitable? I noted this challenge as I evolved initial ideas through sketching on paper. These visualisations were progressed through numerous feedback discussions with Aaron where he told me which ideas he thought would help him and why others didn’t work for him.

Being someone who takes a very precise approach to his cooking I presented him sketches of an app that was a detailed multi-event timer into which he would enter every timed element of the numerous recipes that make up a meal and the app would automatically work out the scheduling for every event requiring action. He told me that the data entry required in this design was far too laborious and would never work for him. Indeed his recipes were just too detailed. Cooking is a highly involved activity and the app’s functionality would need to be as quick and easy to set as possible.

Aaron’s requirements

Access the functionality of the app as quickly as possible make efficient use of his time

Set-up multiple timers as quickly as possible so he can get on with manual food preparation

Plan a schedule for events so he can focus on preparation tasks and/or relax when he has time between events

Minimum contact with his phone while cooking so he doesn’t have to wash cooking materials from his hands more than necessary

Know when the next event alarm is due to guide his pace and help him prioritise other activities he’s involved in

Taking my inspiration from audio and video editing software design, a world familiar to me from years of past experience in the field, the core of my solution would be a visual timeline screen scrolling from right to left over a vertical line that symbolises the present moment, a ‘now’ line, or ‘play head’ as it would be referred to in typically anachronistic studio industry parlance, referencing the bygone mechanisms of audio tape. Events would be visualised as labeled horizontal bars, like events in video editing and audio sequencing software. Tap and hold would allow them to be moved forward and backwards through the timeline to orchestrate their position and order in the timing of the entire cooking session. As the start and end points of these event bars (representing ‘start cooking an item’, ‘stop cooking an item’) moved over the ‘now line’ they would trigger an alarm and pop-up message. Progress through the timing plan could be checked visually on the timeline and numerically in the countdown timer read at the bottom of the screen.

Aside from the challenge of timing his meal preparation my user research found that Aaron is frustrated by constantly having to default to a time consuming internet search to look up cooking details for staple dishes and to convert imperial to metric measures.

I presented my design, which did not recognise the more recently discovered problem mentioned above, to a small group of fellow students and a teaching assistant who suggested various functions that they thought might improve the app:

Clarify & refine navigation

Add duration & completion time

Import of recipe data from cooking websites

OCR image to text capture for recipe books

Include option to store information on sessions and events

Share this info and photos of completed meals, either privately or publicly

“Not for Me!”

A simplified timeline screen

When I presented sketches for designs incorporating the functionality proposed by the group he only had interest in only the first two of the suggestions the group gave, stating that the rest were “not for me”. I focussed subsequent development on only features that he sanctioned.

It became apparent that my plans of integrating functionality to quickly access staple recipes and convert metric/imperial measures in my app design needed to be jettisoned as they would compromise usability and were tertiary to its goal. The user’s journey needed to be as simple as possible, and the interface clear and uncluttered.

My key aim was to simplify through iteration. My major challenge was to reduce the functionality to a minimum not to expand it to an maximum at the expense of usability.

User Flow

I drew up a story board to communicate the user journey and this informed the development of a user flow depicting the completion of one key task; to enter information to set timing for a single menu item event.

Basic user flow

From this simplified user flow I created a full user flow to develop and clarify the app’s functionality and expose issues.

Full user flow

Testing & Iteration

I created a scale paper wire flow to test with Aaron. Feedback was on the whole good but I acted on his comments and removed some elements. A label above the ‘next event countdown timer’ display was removed as the information it conveyed was already available on the same screen in the timeline.

Test, iterate, simplify and improve - then do it again! And again! And again!

Screen flow

A Few Weeks Later… Going Hi-fi

Once the screen flow was set I created a low fidelity prototype in Marvel to test with Aaron. You can try this out yourself here. He liked the basic functionality so, a few weeks later it was visual design week — a perfect time to add some delight to my first project by improving its usability further and making it look great at the same time.

Timeline — landing screen in high fidelity

Aaron’s modern cooker and kitchen in stainless steel reflects his refined aesthetic so although the gradient background of steely grey down to heated reds at the bottom was appropriate, I needed to add some colour accents to reference his love for variation and of course his colourful menu items. During the last tests on the low fidelity prototype by various student users as well as Aaron it became clear there was no need for both pause and start buttons so these were replaced with a single button that does both. Aaron needs a hand free to be constantly manipulating items as he cooks and he uses his phone in his right hand if necessary while multi-tasking. With this in mind I placed the two most used buttons, the start/stop button and add an event button, in the easiest placement for the arc of the thumb’s movement for one handed use while keeping the phone as securely held in the palm as possible.

Further Iteration

Event edit screen

I found an interesting calendar app called Dials and noted the circular analogue clock-style interface with events positioned around a central disc. This gave me a few ideas. In my design a similar time disc would be used for the event edit screen, the disc colour unique to the event within the session and auto generated from a fuzzy recognition of the event label, i.e. red peppers, green for green vegetables, red peppers, aquatic grey-blue for fish, etc. The reason for this was to introduce a consistent and easily recognisable visual label for the event at the earliest juncture so that when the event alarm goes off in the same colour Aaron won’t have to read the text label to remember what action an alarm call for, lightening the cognitive load while the pressure is on. The same colour is consistent for the individual event bars on the timeline screen.

Although I had reservations about the usability of Dial’s novel design for the use as a multi event calendar, I saw in it a way to incorporate a way to delay the start of the event to position it within the timeline structure of all the different events that make up the whole meal. The black line around the circular time read out element represents the length of the event in shorthand, displayed exactly in the central numerical readout. By pushing small white tab at the start of this line the event start is pushed forward. The end of the event, represented by the large white tab can be pushed around the dial to extend the entire duration. The dial is logarithmic in that the same distance of movement at the start represents very fine adjustments, at the end of the rotation very large adjustments. Testing validated this as a natural affordance.

A drop-down menu of all the possible reasons Aaron might divide the timing of the event, the three he used most frequently were shown as tabs. He and other test subjects considered it natural and acceptable to appropriate the closest label to a different task if necessary.

Prototype

Next Steps

My design was given the thumbs up by Aaron but later he gave a caveat; “Maybe bring the gradient contrast down a notch”, he said “but the do look super cool!” Of course I’d be happy to change those gradients ‘in the next sprint’ I said — a hypothetical proposal as our project time was up, but a valuable piece of user information nonetheless.

Another thing to address is the calibration of the timeline grid where a logarithmic rather than linear scale would give detail at new the ‘now line’ but crucially afford being able to see far enough ahead to plan. If you look closely you can see this to be problem in my hi-fi screen shots where all the events appear in a period of only a few minutes.

Outcome

For now my app had fulfilled the design brief through multiple cycles of sketching, presenting and critique with my user remaining engaged throughout to validate progress.

An app that comprises clearly distinct multiple independent timers that alert Aaron to when key operations in the meal cooking process require action.