TouchBistro creates a suite of software for restaurant management. The admin program is a cloud-based web app that houses all the information required for a restaurant owner or manager to run their business. This project was twofold; users could create their restaurant’s menu on their point of sale, but not in the cloud, so firstly we wanted to give users the ability to create their menu while not physically being in the restaurant. The second part was to create the ability for enterprise restaurant businesses with multiple restaurant locations or multiple chains to be able to create and edit their menus.
As I said, this is actually two separate problems in one. The reason these projects are so linked is that once the concept of menu management had been created for a single restaurant venue, a very similar concept would be created for enterprise companies with multiple venues. The difference between the two would be that enterprise menu management would have a few additional features and would require giving users the ability to manage their different locations in a way that made sense for their business. For example, every restaurant is required to pay taxes and price items, but what happens when you have two restaurant locations in two different areas, with different taxes and different prices?
From a technical standpoint there were a lot of limitations in this project. First of all, TouchBistro’s admin program already exists. It’s several years old, uses a code base that needs to be changed completely, and was designed by full stack developers. So, we now need to create the beginning of this completely new product that will eventually replace this outdated product, which gave me a lot of autonomy and creativity in the project. But due to the fact that this change will happen over such a long period of time, it still has to work with the existing product. So, we needed a way for users to navigate between these two products seamlessly, even though they’re two separate front ends.
Another major problem that limited the design was that the point of sale, which is what a waiter or waitress would use to input orders in the restaurant, is where all menu management capabilities currently live. We aren’t able to remove it, because it is something users need, so we are somewhat limited to its current capabilities.
The product manager and I interviewed about twenty restaurant managers and owners from our current customer base. We asked them about how they set up their menu currently, and what do they like or dislike about it. For owners with multiple venues we asked what exactly they would need from this feature in order to run their restaurant in the best possible way. This could have been based on experience with previous point of sale systems or based on what they do separately from TouchBistro, such as using separate spreadsheets or products. We felt we had interviewed enough users when we weren’t really getting answers that we haven’t heard already. We also got several of these users to be our beta testers later on in the project.
I created a wireframe for the general skeleton of the product, the tables, and the forms. For the most part, all areas of menu management would look more or less the same and follow the same information architecture. A user can only get to a page via the main menu, and from there they can only create or edit items. As you can see, there isn’t really much depth to the user flow. Due to that my wireframes were very general, but my major focus was the scalability of this product. I needed to make sure that if we added or removed components or features, the design wouldn’t be negatively affected. Especially since many of the decisions I made at this point would also apply to completely different sections of the app, which we’ve yet to redesign.
My other concerns were that the mobile experience of the existing app is poor and that accessibility was not considered when the app was initially created. Now that I had free reign, these became of upmost priority for me. If any new or confusing features came up half way through the project, my coworker and I would resort to drawing our ideas on a whiteboard. But this is mainly something that we did on and off throughout the project due to unforeseen scope.
I began with a few different designs for the skeleton. It involved getting some stakeholder buy in for us to proceed. Thankfully, the one that I felt said “TouchBistro” was the one that resonated with our stakeholders as well.
I created countless mockups for each section of menu management and enterprise menu management. The general look and feel of the product also had to go with the updated look of the point of sale. Once this was more or less decided by my coworker and I, I created pattern libraries for both products so we could ensure consistency in the UI. Consistency, scalability and overall simplicity in the UI and UX were what I focused on; these are all the things the original product lacked. There were points where I had to make minor changes to the mockups because of something new we learned or due to some kind of technical limitation, but for the most part I was quite familiar with the product and its scope, and due to its scalability, there weren’t too many issues.
The enterprise design is almost identical to the non-enterprise design. The only difference is a few added features, and because of those features, users need to be able to add multiple prices to the same item for example. Because that price will vary based on location.
I’m pleased with my focus on scalability and accessibility for this product. I feel that I succeeded in those areas. And I’m glad that our users could play such a large role in this project. They got to really test out this feature and give us their feedback so we could improve on it.
The largest limitation that changed the scope of my designs was the fact that menu management on the cloud had to line up with menu management on the point of sale; this means the form fields that were used, how each section was organized in terms of information, and the sections themselves. I had a lot of say in other aspects of this project, but the organization of each section or task for the user could have been drastically different if we had the opportunity to research and change it.