When we were approached by the owner of one of our favourite bars in town and asked if we could "give him an app" we immediately put our drinks down and got talking.
The frustration he felt most keenly was having to continuously reprint menus every time he wanted to change the price of an item by a few pennies. But as we started discussing how to do it we could start to see many more benefits. We could make the menu accessible by virtue of the fact that users could control text size with a pinch-and-zoom on an iPad screen for people with impaired vision. We could use photographs to showcase the food which would also make it easier to understand for non-English speakers. We could make it update in real-time so that the items on offer were always accurate and customers could place orders directly from their tables. The list goes on and it ends with the most exciting factor - it would just be a neat thing to do. We wanted to be able to go to that bar and order drinks from an iPad at our table ourselves!
Like many projects, the finished product ended up quite a distance from the original idea. In the end, we produced a menu system that customers have used to place tens of thousands of orders.
Research and strategy
The original idea that we were asked to consider was to put together a simple menu that customers could browse themselves with iPads housed on the tables.
Our first decision was to choose whether to build a native app or a website. Factors in that decision included whether or not the system had to be available offline (it did) and if the menu needed to access any other native device functions (it didn't). So, relying on the capability of the app cache to store a simple version of the menu when the device is offline, we opted to build a website: a sort of precursor to Progressive Web Apps (PWAs). Websites are open to all devices so, although the client wanted to use iPads, there was no requirement to do that. We would make it future-friendly by using some basic responsive design techniques. That meant he could switch to other, more affordable, tablets in the future without any requiring a significant re-work. Going with a website also removed the need to release anything via the App Store so ongoing deployment effort and costs are reduced.
We thought about using existing e-commerce software and we went as far as building a prototype with one system but once we started adding the real menu items it became apparent that it wasn't up to the job. For example, in order to let customers order pizzas with their own topping combinations, we had a situation where staff would have to add thousands of potential products to the admin console. That wasn't going to scale. So we proposed building our own.
Design and front-end development
We provided art direction, UX design, and front-end development.
Understanding how to use a restaurant menu is not a problem that we needed to fix for the people using this system. In fact, the real challenge was to make sure we didn't make things worse. We needed to make sure that people understood how to use the iPad equivalent with as little guidance as possible.
For the main menu screen, we used a 3 column layout with the category list pinned to the left of the screen to help people scroll directly to the section they are interested in. The main menu item list was positioned in the centre column and the right column was available for advertising space. Tapping a menu item would take you to a full-screen photographic product details page with the option to add it to a cart
We spent some time trying different typography approaches to find something that would make it easy to scan menu items quickly but also allowed for a slower and more comfortable read for item descriptions. We settled on using the sans-serif font Aaux Next for functional text on menu item names, form elements and buttons. We paired that with an italicised Adobe Caslon for more descriptive text. And just to spice things up a bit we used a blocky Franklin Gothic URW for big, bold section headings.
One of the nice touches we added was a subtle but satisfying parallax effect on the full-screen product photographs.
Application development
We recognised that the underlying structure of this system was closely aligned to an e-commerce store but not exactly the same. In our case, we decided that we wanted to allow people to build and place orders via their iPad but we didn't want to process any payments. The job of our system was to replace the paper menu in the customer's hand and the paper notepad in the server's hand. Once the customer placed an order, the server would still enter the food orders into the pre-existing EPOS system that reconciled payments and sent orders to the kitchen. We'd make that easy for them by providing an order interface on an iPad placed beside their EPOS system. We all agreed that we didn't want to remove the server from the ordering process and allow customers a direct line to place orders with the kitchen. We wanted the customer order to be a prompt for the server to check-in on the customer and make sure they were happy.
Our first port-of-call was to try using off-the-shelf e-commerce software. We got as far as building a prototype and testing it in the restaurant but found it too limiting so we decided to build our own.
Anticipating hundreds of orders in a day, we built an enterprise-level web database application using CakePHP. It supports a customer-facing menu website and a staff-facing console website where bar staff can manage the menu items and process orders.
Usability testing
The test script wrote itself: go to a good bar and order some food and drink. Seemed easy enough! In reality, spending time in the bar with the staff was invaluable. We ironed out issues with making it easy to add products and made changes to the process to fit with how they really processed orders - not how we thought they should.
Staff training
Another real-world challenge of running a bar or restaurant is that staff will come and go over a period of time. We wanted to make sure that the institutional knowledge of how to use the system didn't leave with any particular member of staff. We created a series of training videos and embedded them in the admin console so that ongoing staff training was simple, reliable and consistent.
Results:
The menu system has racked up tens of thousands of orders. Customers, staff and the bar owner are happy with the new menu.
Here's a taster of what they like about it:
Customers
- It’s more exciting to use than a paper menu.
- People who need to view larger print text or images can do so just by using the native iOS pinch-to-zoom gesture.
- The Specials on offer are always up-to-date.
- Customers are more confident placing orders for items they potentially didn’t know or understand because they can look at a picture of the item first.
Bar staff
- Having to say “Sorry, we’ve run out of that” after the customer places an order is a thing of the past.
- The business can update prices without reprinting the entire menu.
- Fewer servers are required to cover tables. The staff who are there can concentrate on making sure the customers are happy rather than dealing with admin.
- Contextual adverts and 'pairing suggestions' allow the bar to up-sell and cross-sell and increase overall sales.
- There are advertising opportunities on the menu that the business can leverage in partnerships with suppliers and other third parties.
- Having an unobtrusive space for high-quality branded product photography is a valuable channel for drinks brands to increase brand and product recognition.
- Sales have increased as customers can easily add optional extras and increase their average spend without having to catch the attention of a server.
And having done all that (thirsty) work, we can confirm that ordering some drinks via the iPad menu is pretty slick and very easy. Some might say too easy.
