I recently had the opportunity to write a first draft for a web application allowing office workers to order hot and cold drinks online. It’s far from perfect, but gives an idea of how this problem can be approached!
Introduction
The aim of this document is to provide a first draft design for an online drinks ordering service aimed at office staff, allowing them to order with hot and cold beverages during their breaks.
It provides a starting point for the design & development of such as system, by detailing the potential business goals of such a service, an overview of the profile, needs and goals of its potential users, a more detailed analysis of the customer users of the system, and a list of the core requirements. A proposed solution for the implementation of these requirements is provided at the bottom of this article.
Business Vision & Goals
The main purpose of this service is to provide a fast, easy to use way for office workers to order hot and cold drinks during their breaks. Thus, the business goals for this project could be described as follows:
Main Business Goals
- To deliver a variety of hot and cold drinks to office workers both quickly and with optimum
accuracy - To encourage repeat use of the service
Secondary Business Goals
- To make the service enticing to potential customers
User Profiles
The two types of users of such a system could be divided in two categories, namely customer users and business users. Their main profile and goals are described below.
Customer Users
Customer
The person that makes the order
- Main goal: to get an order composed of various hot and cold drinks delivered on time at his or her workplace on time and accurately
- Secondary goals: to enjoy using the system
Potential Customer
A person interested in the service
- Main goal: to get a good idea of how easy to use the service is
- Secondary goals: to register for the service as painlessly as possible
Business Users
System Administrator
The person responsible for configuring the system, setting up the pricing rules, maintaining the list of available drinks and offers
- Main goals: to manage the system easily and efficiently; to access various sorts of reports regarding the activity of the system.
Operator
The person responsible for receiving and preparing the customers’ orders
- Main goal: to prepare customer orders accurately and quickly
Deliverer
The person responsible for delivering the customers’ orders
- Main goal: to reach the customers’ workplace on time and to record successful deliveries
Customer User Experience
A series of interviews were conducted with typical office staff around the topic of ordering drinks for the purpose of drinking at work, and of an online drink ordering system. In addition, direct observation was conducted in a medium-size software company with a particular focus on behaviours revolving around coffee drinking and food-ordering. On the basis of this field research, the personas presented below were designed.
Personas
John (Primary)
John is a 23 years old web designer based in central Manchester. He works within a small team of 5 people and has unrestricted access to the internet from his desk. He is a regular coffee drinker, and often buys coffee and other drinks for his colleagues. Each colleague returns the favor on a per-turn basis.
He owns a coffee shop loyalty card and is quite keen on using it. John complains that it is sometimes difficult to know which beverage belongs to whom once they arrive in the office.
Linda (Secondary)
Linda is 52 and works as a secretary for a consultant at Manchester Central Hospital. She works alone in her office. She has limited experience with web applications, but has ordered books on Amazon a few times.
Linda’s boss often asks her to buy refreshments for meetings with his credit card. She does not really enjoy this, as the coffee shop is quite a long way away from the office.
The Experience of Ordering Coffee
Coffee and other hot drinks are most often ordered in a shop such as Starbucks. A typical takeaway coffee-ordering process in Starbucks could be summed up as follows:
- Choosing one or more drinks from the menu
- Ordering the drinks
- Paying for the drinks
- Waiting for the drinks
- Putting required amount of milk and sugar into the drinks
In real-life situations, people always put the sugar or milk themselves in their drinks. The cups are marked to indicate the type of drink they contain.
Context Scenario: Ordering Drinks on Acme’s Online Drink Ordering Service
John arrives at his office on a Monday morning. He catches up with his colleagues and after a short discussion they decide to order drinks on Acme’s website.
Everybody gathers around his desk as he turns up his computer and navigates to Acme’s drink ordering service website. As he used the service before, he is already registered. He navigates to the “menu” page, and proceeds to ordering drinks for himself and each of his colleagues. Once he is satisfied with the order, he proceeds to the “complete order” page, which features a sum up of the order, its total price, and details such as the delivery address, the payment method he entered during a previous visit to the website.
The system asks him if we would like the order to be delivered immediately, or if we would like it to be delivered at a particular time. He picks the “as soon as possible” option, and clicks on the “finish order” button. A new page is displayed, allowing him to monitor in real time the status of his order. He gets confirmations that the payment was successful, and that the operator acknowledged his order, which is estimated to arrive at 10:30. He also receives a confirmation email summing up the detail of his order. Once the deliverer is on her way to John’s office, John receives a text message from Acme’s drink order service letting him now that his order is on its way.
Core Requirements
One of the main aims of the system would be to provide its users with an experience similar to the purchase of drinks in a real coffee shop, but enhanced with the capabilities offered by a web-based platform.
Customer Requirements
Customer
- Login
- View/ browse drinks menu
- Create/edit order
- Select drink from a list
- Select size (small, medium, large)
- Select amount and type of sugar
- Remove selection from order
- Finalise order
- Pick time of delivery
- Get feedback on order status
- View order history
- View/edit user account details
- View/edit personal details
- View/edit payment method details
- View/edit delivery address details
Potential Customer
- Check if service is available at customer’s address
- View menu
- Register
- Enter personal details
- Enter payment method details
- Enter delivery address details
Business Requirements
System Administrator
- Manage stores/locations
- Manage business users
- Manage customer users
- Manage product choice and prices
- View/browse operational reports
- …
Operator
- View/browse orders
- Get new order alerts
- Acknowledge orders and provide delivery time estimation
Deliverer
- Update status of delivery
Interaction Framework
Form Factor & Posture
The way users are to interact with the system is through a web interface provided by a web browser.
According to w3schools.com, the resolution of the screens that will be used to access the system is 1024×768 pixels or higher.
Although we could expect that the main user will be seated at her desk while using the service, it is likely that that several people would look at the interface at the same time during the actual selection of the drinks which compose the order.
Data Architecture
The main objects represented in the system are shown in the entity relationship diagram presented below.
Screenflows & Interface Mockups
A proposed solution for the design of the system is presented in the following interface mockups; please note that these also illustrate the main customer user journeys. The scale of these mockups is 1:1.
Related posts:
- Interface Design and Information Architecture for Enterprise Web Applications: Four Simple Principles
- Outside-in Web Application Development: The advantages of building production-ready static html prototypes as interface mock-ups
- Architecture against Interface Design?
- User Experience, Poststructuralism and Phenomenology: Exploring the User’s World
- Intertextuality and User interfaces as Relational Systems of Representations
You obviously put quite a great deal of thought into the design of this proposed system, but it does not appear an equal level of thought went into how you present it.
The opening is rather dry; not to mention verbose. You should lead rather than close with the images.
I’m confused as to why you didn’t lead with the personas/scenarios and just omit the user profiles. People care about story; not dull lists.
Listing user profiles and customer requirements isn’t doing anything to make this post more interesting.
You’ve taken what I consider to be a pretty cool idea and made it sound dismal and boring.
This document makes it seem like you are getting paid by the word.
Sorry my comments sound so negative, but you are clearly a master of your craft and simply do not come off in a way that is exciting or energizing. In my view, the UX designer should be the person that has everyone else wanting to spring into action. The cheerleader if you will.
I wonder if the purpose of this article was not so much about demonstrating how to present a proposal but illustrate the steps taken and the artefacts produced when designing a user interface.
hi robert and james,
thanks for your comments – as James observed, this is more of a technical documents that’s supposed to help devs to actually build the thing; I pretty much dumped in here so that people can refer to it if they want to
cheers,
pascal