BOOKATABLE: TIMELINE VIEW
AUGUST 2013
Bookatable Timeline view
Project introduction
In August 2013 I worked on a 2-month project to add a new way for restaurant staff to view, add and manage bookings in Bookatable’s reservations management app. The Timeline view as it became known allowed restaurant staff to manage bookings for a complete dining session in real time, in a single view and provided an alternative mode of use to the more traditional calendar view.
Audience
The timeline view would predominantly be used by reservation staff either on the restaurant floor or in a booking office, including restaurant managers, waiters and waitresses.
Team and my role
The team at Bookatable working on the booking application was relatively small, comprising myself as a UX designer, a UI designer, frontend and backend dev, tester, scrum master and product owner.
Constraints
Working within and adding features to an existing application and codebase introduces certain constraints whereby we need to ensure that new features added blend and complement what is already there. Adding a new feature or piece of functionality will invariably have an impact on other features, so it cannot be designed in isolation of the whole service. Understanding that service, the legacy technology and the history behind design decision making is challenging for someone joining the project as was the case for myself.
Design process
Research - Observation
I visited a number of restaurants, both a high end Michelin starred restaurant as well as a popular high street pub chain, to observe and interview staff using the reservations application, with the aim of stretching my understanding beyond the basic assumptions I had already formed. I formulated a number of research questions to frame and focus the things I wanted to get out of the observation.
I sat and observed the restaurant staff, considering their space, location, their interactions with other people and the activities they were engaged in. I was looking for how the booking application supported or frustrated the users and how it was used in different use cases from a Maître D meeting and greeting at the door, to a booking office staff member working at a desktop computer, to a waitress interacting with an iPad on the restaurant floor.
When conducting a contextual enquiry I am always on the lookout for the unexpected. For example, in one restaurant the booking staff printed off the calendar view for the dining session, then took out a pair of scissors and some sticky tape and cut up the booking list, rearranged it, stuck it back together and scribbled some notes over the top. When I asked what she was doing, the bookings staff member explained that the kitchen liked to get a copy of the bookings, but the printable view had a lot of information that they didn't need, but also had key information missing such as the diners' dietary requirements. This was an interesting use case to observe and feed back to the Bookatable team.
As well as observing I also interviewed the restaurant staff. We talked quite generally to begin with about their roles, a typical day, pain points and frustrations and then asked them to walk me through common tasks they do in the application. The interviews followed my observation so I was able to dig a little deeper and question things that I’d already seen.
The observations and interviews were captured through photos, hand written notes and audio recordings.
Extracting insights
On returning to the office my primary task was to narrow down and make sense of my data. I captured individual data points such as quotes and observations on post-it notes and used these to look for themes and patterns to then extract informative insights. I created a research wall where I posted everything. The broad themes were then put into a story and shared with stakeholders.
The story described a multi-tasking user standing in a busy restaurant with low lighting conditions and noisy music, greeting a customer whilst trying to maintain eye contact and at the same time scanning the reservations list to search availability, find the most appropriate table and book in the customer with their name and number of diners.
Key takeaways were that when used in-service the app needed to be quick, easy to use under pressure, with partial attention. It should function almost like a heads up display, that affords glances, with quick views of key information and readily available actions.
Sketching
The insights led into a first round of sketching with the UI designer. We sketched task flows for primary functions such as, adding, moving, joining, removing and joining tables, then moved onto mockups with UI components, considering how users might interact with the interface and how elements would move, change and animate. We started with ideas around a menu driven interaction similar to the rest of application, but this felt cumbersome and difficult, particularly with a focus on touch as the primary user interaction.
Designing towards touch really forced us to simplify and decide what was most important - what needed to stay on the screen. Timeline was designed with a much lower density of information compared with other views in the application, showing only table number, time, customer name and covers. It adopted a top-in approach giving a shallow depth of information, but a complete view of all tables over the whole dining session. The lower density of content freed up the canvas allowing the user to interact directly with the booking bricks by either touching or dragging. Secondary functions were backgrounded, particularly where they were more easily accomplished in another view. When a detailed view was required such as the booking form, then modules would slide in and out over the top of the timeline, creating layers.
We created paper prototypes for modelling and testing interactions and then worked with a frontend developer to test the feasibility from a technical perspective by mocking up the timeline in code. We shared the prototypes internally to validate our approach and then revisited one of the restaurants with the demo of the Timeline to share with the client. Based on the feedback received from all corners we then continued to iterate the design to a point where we were ready to take it into development.
Retrospective and lessons learned
The timeline view launched in late September 2013. It was described by the Bookatable CEO as a game changer. I moved on from the company shortly after the release, but anecdotally have since seen the Timeline in use on numerous visits to restaurants.
The research phase of this project was key to me. The only staff who had talked to users prior to this project were account managers. They were talking to customers and receiving feedback regularly which was being filtered through to the product team, but these insights were not built from observation and tended to be largely anecdotal.
I saw these observations as a way to start building more of a user-centred culture as the business tended to look inwards towards its teams rather than outwards to the users. Since I was working on a short contract I wouldn’t be able to see out these changes long-term, but by showing and telling the research and by doing things like creating a research wall where I collected my research artefacts, I would be able to keep research insight and user needs constant in the collective mind of the whole project team.