Drinks on the go was a personal project I worked on for a company in the UK in 2013. The business requirement was to conceptualise and design an online drinks ordering service. The project consisted of a UX research phase, a UX Design phase and a Validation phase.
The research phase
This vital first phase in the user-centred design process involves gathering knowledge about the broad business objectives, the user objectives and other relevant aspects such as competitor insight. This stage is often about discovering which constraints are important and establishing a framework for evaluating them. Constraints can best be visualised in terms of three overlapping criteria for successful ideas: feasibility (what is functionally possible within the foreseeable future); viability (what is likely to become part of a sustainable business model); and desirability (what makes sense to people and for people). This knowledge clarifies the design brief and project goals, and informs design decisions later in the project.
The research phase included the following:
- Stakeholder interviews
- Contextual enquiries
- The development of personas and user scenarios
Stakeholder interviews provided me with the following business goals, requirements and insight:
- The business wants sell as many drinks as possible on a daily basis;
- The business wants to target office workers: 20+ year old employees with cash to spare. This type of user won’t necessarily have a credit card. Therefore, we need to cater for purchasing with credits;
- The business model focuses on corporate companies that would purchase drink credits for their employees as a workplace incentive. In order to render a profitable service, a fixed drinks delivery schedule should be defined for each company;
- Employees should be able to top up their credits using popular online payment methods such as credit card or Paypal;
- Users will be registered with their company email addresses to gain access to their customised ordering portal.
After collecting business requirements, the focus was shifted to user goals and needs. Contextual enquiries or field studies involve observing users in the place where they would normally use the product or service. This allows for the identification of the target users and an assessment of their tasks and goals.
Through contextual enquiries I gathered the following on user behaviour and preferences:
- Many office workers take drink breaks to fuel emotional needs, such as escaping from work stress, socialising with people from different areas of the business, and getting a pick-me-up;
- Most office workers are willing to pay for a quick caffeine fix;
- Smokers usually combine smoke breaks with drink breaks;
- Most managers perceive themselves as too busy for drinks breaks. However, if they could order drinks to go and did not have to prepare it themselves, they would take more breaks;
- Most office workers are keen on the idea of an online drinks ordering service;
- Most office workers would like to have a place where they can view and amend their daily orders;
- Most office workers have a set routine. They want to be able to schedule a repeat order;
- Some office workers prefer a variety of health drinks such as herbal teas, juices and smoothies;
- Some office workers who often entertain clients require additional credits to fund drinks for their clients. These users want to be able to place bulk orders.
This qualitative research provided me with insight and allowed me to develop user profiles, personas (archetype users), scenarios, and task descriptions on which design decisions could be based throughout the development lifecycle.
Personas and User scenarios
Throughout the user-centred design process personas are used in reference to the user, by both clients and the entire production team. This prevents all parties from transferring their focus from specific user goals to the generic, elastic whims of the “unknown, mythic user”. Fully realised, defined user personas help the team to understand and focus on user needs and core tasks.
For a project such as this I would normally prepare one or two primary personas, a secondary persona, a buyer persona and a negative persona. However, due to time constraints I opted to include one primary persona and one secondary persona. These were developed through an iterative process. Roughly defined proto-personas were sketched and brainstormed and further refined into more defined personas that could be used to guide the design process.
Richard Jones - a 26 year old web designer - is our first primary persona or archetypal user.
He is a habitual caffeine drinker and loves to take frequent breaks to have a coffee and socialise with colleagues. He is very keen on the idea of an online drinks ordering service, as long as it is fun and he can access the service from his smartphone.
Angie Thompson - 30 year old Personal Assistant (PA) to a very moody Chief Marketing Officer (CMO) Joy Lovegood - is our secondary persona. The secondary persona is someone for whom we will make accommodations so long as the primary persona’s experience is not compromised.
Angie takes care of Joy’s drinks needs. Joy prefers a cup of tea first thing in the morning. She usually only drinks juice on a Monday but enjoys some coffee on days with lots of meetings. When she is in a bad mood she drinks herbal tea to keep her calm. Angie needs an online drinks ordering service that allows her to order something at relatively short notice and to change previously placed orders. Ideally the service should offer tea, coffee and fruit juice. Since Joy prefers Angie to be very punctual, Angie would like to be notified of the delivery schedule and receive her orders on time.
Angie is computer literate, but not on the same advanced level as Richard. She requires a user interface that is uncomplicated and responsive. She needs to be sure Joy’s morning tea will be on time and that she has some beverage options ready for later in the day.
User scenarios describe the activities our personas will perform in order to reach their goals. These become the user performance requirements that inform design decisions.
Richard is keen to try the new online drinks ordering service. He can’t wait to start spending his free credits. Since he is quite computer savvy he expects to find the ordering process easy and even fun. If he finds the process cumbersome he might view it as a challenge but it won’t necessarily be a delightful experience he would want to go through on a frequent basis.
- Richard requires a simple, uncomplicated and fun user interface (UI);
- He wants to be able to track his credit balance and top up since the free credit allowance will most likely not meet his caffeine needs;
- He wants to be able to edit his orders;
- He wants to be notified when his drinks are ready;
- He wants to be able to order multiple drinks so he can buy a round for the guys;
Angie is cautiously optimistic about the new drinks ordering service, trusting that it won’t put extrain strain on her busy schedule. Her boss, Joy is booked in back-to-back meetings and bound to be in a foul mood. Angie is hoping that she’ll find the new drinks ordering service’s UI uncomplicated and responsive. She wants to order a variety of fruit juices for Joy as well as a variety of hot drinks for the next day’s client meetings.
- Angie does not want to waste precious time. She needs to find what she has on her list and place an order;
- She requires online assistance to give her a quick overview of the UI;
- She wants to keep track of her credits balance so she won’t fall short if she needs to urgently place a large order;
- She needs to be able to view and amend her orders at any time;
- She needs to be notified when the drinks are ready for collection.
The design phase
This phase in the project was dedicated to the following design tasks: developing the screen flow and navigation model, sketching the UI and envisioning functionality and behaviour. In keeping with user-centred design practice, most design issues should be discovered and fixed during this phase and not once the service has been launched.
Screen flow and navigation model
The first step involved creating a series of rough sketches and wireframes representing the framework of the product, exploring content, navigation and interactions.
I opted to work iteratively and prioritise selected features in the design. Based on a comparison of Richard and Angie’s goals and those of the business, the following user tasks were addressed in the draft design:
- Placing an online drinks order
- View hot and cold drinks;
- Choose drinks to order
- Edit order
- View credit balance
- Place order
- Additional features include notifying the user about the next drinks delivery, providing access to his/her order history, and additional quick navigation aids such as favourites and repeating of previous orders;
- Although Richard has expressed the need for a mobile interface, this was not included in the scope of this iteration.
Low-fidelity paper prototype
A series of static mock-ups were created, that could be shown to users such as Richard and Angie to learn whether the planned user journey supports their expectations, and reflect how they think and talk about tasks. This type of evaluation allows the UX Designer to collect critical information in an inexpensive way. Ideally it should highlight which functions and features are intuitive and which are not, before any time is spent on higher fidelity prototyping or coding.
The following set of illustrations serve as a walk-through of the draft design solution.
This step-by-step guide automatically launches when Richard or Angie opens the site for the first time. It welcomes an intermediate computer user such as Angie into the site by pointing out aspects of the UI and explaining how to perform important tasks. This can save Angie time and reduce possible anxiety or discomfort.
Task 1: Placing a drinks order
This UI attempts to provide Richard with an easy, fun way to order drinks. The draft design comprises flat colours, an easy to ready typeface (Open Sans) and simplistic, flat iconography. Although this has not been user tested or tracked, it is assumed that Richard will first notice the two beverage categories: hot and cold drinks; followed by the credit balance in the top right hand corner, and then the drinks order and scheduling area in the top left hand corner.
If Richard moves his mouse over the cold drinks category, the area will be highlighted by a colour change. Even though the final colour pallette will be refined as part of the visual design, this draft design uses ‘cold’ and ‘warm’ colours to support and enhance the corresponding categories.
Clicking on the highlighted section causes the cold drinks category to expand to the left of the screen; reducing the width of the hot drinks category while revealing the list of available cold beverages.
On hover, Richard is presented with in-context assistance prompting him to drag and drop a drink onto the desired delivery time slot.
Once he has dropped his first drink onto a time slot, the slot will be highlighted, revealing order details such as price (credits) and quantity. He can view and edit this information at any point, up to 1 hour before delivery, after which the details will no longer be editable. By increasing the quantity, Richard will notice his balance of available credits in the top right hand corner of the interface decreasing to reflect the change.
This part of the interface fulfills Richards need to edit his orders and always view his credit balance. Furthermore, it allows him to top up his credits at any given time by clicking on the ‘Top up’ call to action next to the credit balance.
Richard can continue to add drinks whenever he feels like it. At any point he wishes to add hot drinks to his order he can move his mouse over the hot drinks category to highlight or activate the section.
Clicking on the highligted hot drinks category will expand it to the right, reducing the cold drinks category and revealing the list of available hot beverages. Similar to the cold drinks category, the hot drinks are listed by name, volume and cost and grouped by type.
Richard can now continue to drag and drop hot drinks into his order for the day. He decides to buy a round of drinks for the guys in his team, showing off his generous nature and ability to effortlessly order drinks online.
Next, he decides to drop a hot drink onto the 15:00 slot, where he has already placed an order for a cold drink. This causes the drinks icon to change in order to reflect both drinks categories.
When he views the order detail for this time slot, he can view all items. He is also able to change quantities and remove unwanted items. At this point Richard has successfully completed the task of placing his drinks order for the day. Hopefully this will give him a sense of accomplishment and encourage him to keep using the service.
Other important features highlighted by Richard and Angie that were taken into account, but not fully developed in this design iteration include notifying the user of his/her next scheduled drinks delivery; and enabling the user to repeat previous orders.
By moving his mouse over the notifications icon, Richard can see when his next drinks delivery is due. The ordering system should also allow him to receive notification through push messaging and email.
By clicking on his name in the top right hand corner of the UI, Richard can access his profile, order history, an online help service and log out of his account.
The four icons listed in the menu to the left of the credits balance will enable Richard to view his order for the next day, the previous day, open a calendar to schedule drinks for a specific date and open a list of his favourite drinks - showing him a collection of his most often ordered drinks.
I advised the company to keep testing the draft design solution until all points of friction were been removed. This solution would form the blueprint for the final design specification and guidelines.
The validation phase
The third phase included a series of tests to verify that the decisions taken during the design phase met the goals and needs of the intended audience.
Ongoing heuristic evaluations, usability testing and field studies provide valuable feedback on which upcoming iterations can be based.
Mobile and tablet devices have become ubiquitous in the online landscape and any online service would be incomplete without tailored solutions for these devices – be it through responsive design, a dedicated mobile web site or a native device application. A next logical iteration would therefore have been to explore the user journey on mobile and tablet devices in order to customise the user experience and final solution around the strengths and weaknesses of these devices.