Aligning Goals
Company Goals
One of the most important principles for BentoBox was hospitality. We wanted to create restaurant focused designs while being mindful of industry specificality.
Design Problem
Restaurants needed a way to create and associate multiple restaurant locations, menus, and menu items to each other to be displayed on their online ordering website quickly.
Internal Audit
BentoBox had tried to tackle this goal of associating items, categories, and menus multiple times before. I started familiarizing myself with existing BentoBox's previous approaches and what the differences in these flows were.
Nesting Hierarchy
In BentoBox's Restaurant Menu Builder feature, users would nest each items, categories, and menus to create a hierarchy. Items were always nested under menu sections, which were placed under menus.
TAKEAWAYS
- This top down association is more commonly found in everyday life.
- Hierarchy allowed users to visualize how the information will appear on their site.
- It did not allow users to create the items/menu sections/menus out of order. They had to be made in order of Menus > Menu Sections > Items.
Flat-Level Association
For Products and Catering Products in the CMS, BentoBox was using tags as a method of sorting and grouping items. The user would be prompted to make a list of items first, which would have categories applied to them as tags.
TAKEAWAYS
- Categories and items could be created independently.
- The relationship between items and categories is more of a same level association, rather than nesting & grouping.
- It was difficult to visualize how the items and categories would appear on the public facing website.
User Behaviors & Competitors
I first conducted preliminary user interviews with restaurants who used competitor products like Chownow, Grubhub, and Seamless to understand their content management behaviors.
A common theme was that restaurants often reached out to customer service to manage their content, despite having the access to do it themselves. Most competitors separated out the use case of "managing a live order" and "managing content" into native apps and web apps.
Since a restaurant operator would often only have access to the native app loaded onto the given device, they would contact CS through the app.
Flow Explorations
The exploration first started with a flow that was to focus on reusability of menus across multiple restaurant locations.
This user journey involved the concept of a master menu, which would be shared by default across all locations with an online ordering license. Users could then branch the master to make location specific changes.
While this was useful for multi-location restaurants, the concept became overly complicated to explain to users and single location restaurants.
A revised flow merged the idea of flat-level association with nesting hierarchy, by borrowing the existing menu builder component.Items can be assigned to menus, which then can be assigned to locations. Menus and items are sharable across locations and menus respectively.
Redefining the User
Once I reached out to account managers to collect user testing participants however, I observed that the main user for the BentoBox CMS was actually the Customer Success team. Onboarding Managers would fill out the more complex content structure for restaurants, which the restaurants could modify themselves after initial launch.
Even after the launch of their website, busy restaurant owners would often reach out to their Account Managers to ask for an update to their site.
From here, I refocused the user testing group to be internal.
Findings
- Participants that have not built a catering store and were newer to the CS team would create menus in top down order, preferring to create menus first, then populate that one menu by creating new items. (Nesting Hierarchy)
- Participants that were more senior in the CS team would create all the items first, link the items to menus, then assign the menus to locations. (Flat-level association)
- Both group of users did not immediately figure out that there was more than one way to build menus.
Final Designs
Taking into account that participants were split at an even 50/50 for their menu creation approach, I kept the menu builder component which allows users to associate content in Menu > Items order.
However, I narrowed down the flow so that users would be encouraged to create content in Items > Menu order, so that set up for multiple locations that share multiple menus and items could be faster.
Retrospective
Online Ordering Beta launched to a selection of qualifying customers at the end of August 2019.
So far the familiar UI pattern has been favorably received by both internal team and external customers. We'll continue to measure success on the feature by observing frequency of usage and rate of CS team reach out by our customers, as well as monitoring Fullstory captures.
