The Problem

A platform that provides menus for people with dietary requirements needs a dashboard to allow local restaurants to update their menus and view customer analytics.

The Solution

Making a platform that’s easy to learn and quick to use will help restaurants meet the needs of customers with specific diets.

Overview

Role: Research Lead
Team: Project Manager, UI Lead, UX Lead, Research Lead
Project Timeframe: 2 weeks
Tools: Figma, Zoom, Trello, Miro, Canva

For those with special dietary requirements, the idea of going out to eat can be exhausting. As a vegetarian myself, I’m familiar with the routine- as soon as someone suggests a few places to eat, I’m immediately comparing menus and counting how many ordering options I’ll have. Depending on how well I know the people I’m eating with, I may not even want to disclose that I’m vegetarian out of fear I’ll make them feel inconvenienced.

Our client for this project was the Founder CEO of Eat Unbound, an existing platform that provides menus from local restaurants to help people with dietary requirements find where and what they can safely eat.

While the customer-facing side of the platform was already up and running, they needed a dashboard that would give restaurants the control to upload and update their own menus.

Research

Before meeting with our client for the first time, our team conducted research on Eat Unbound and some of the restaurants listed on the platform, as well as a competitive analysis of similar platforms. We discovered that Eat Unbound is currently focused on restaurants in Arizona, where our client is located. We used all of this research to inform the questions we would ask at our kickoff meeting.

During the meeting, our client acknowledged how busy restaurant owners are and emphasized that ease of use would be key for the restaurant-facing side of the platform. He also explained that this side of the platform would create a sense of ownership for restaurants by giving them control over their menus and thereby increase the trust that users have in Eat Unbound.

Our team determined that the restaurant-facing dashboard would need to function very similarly to online ordering platforms, so we reached out within our personal networks to interview restaurant owners and managers who had experience maintaining online menus.

The UX Lead and I carefully drafted our questions for the interviews, and as Research Lead I conducted 5 of the 7 interviews we secured. Afterwards, we affinity mapped the interview results with the rest of the team.

For the most part, the interviews confirmed our client’s hypothesis that restaurants would want a dashboard that’s easy and quick to use. However, we were surprised by how many of the interviews preferred using desktop apps- 80% of those who had a preference chose desktop over mobile.

Early on, our team had thought that restaurants might prefer mobile platforms for convenience, but as we conducted interviews we learned that most people preferred editing menus on a larger display.

At this point, we decided to prioritize the desktop version of the dashboard since the time constraints of the project didn’t allow us to develop a mobile version as well.

The UI Lead and Project Manager created two user personas to help guide the focus of our ideation.

With Nina, the focus was on speed and ease of use; with Ryan, a desire to be inclusive of his customers with dietary restrictions.

Ideation

With the two personas in mind, our team conducted a design studio workshop to sketch out ideas before beginning wireframes.

A sketch of a possible dashboard layout

The main elements we decided to keep from the design studio workshop:

• A “Quick Add” section for easy access to the most used functions

• Highlighting menu photos throughout the platform rather than being too text heavy, to reflect what the customer will see on their side

• A pill design for the dietary restriction tags

With the Menu Editor, the UI Lead added a sidebar element so that users can edit items without leaving the page. Here too, she was prioritizing efficiency for the user’s task.

She also added a “Public View” feature in the sidebar so that the user can see how their menu item looks from the customer’s perspective. Of the users we interviewed who had experience editing menus in ordering platforms, 60% mentioned experiencing glitches and not having their changes reflected on the customer’s side. This feature provides reassurance for the user and saves time by showing them what the customer sees without having to check from an individual account.

The UI Lead also designed filters for dietary restrictions that the user can apply while viewing all the items they’ve entered into their menu. It includes a feature to show additional information about the selected dietary restriction to provide a quick reference for the restaurant.

The filtering system was inspired by the customer-facing side of the platform that our client had already developed. Once a customer indicates what dietary restrictions they have, the platform will filter out any item they’re unable to eat.

In addition, the UI Lead created an “Archived Items” section to help prevent users from having to re-enter items removed from the current menu.

At this point, we had a check-in meeting with the client to present him with our work so far, including interview takeaways, sketches from the design studio workshop, and early stage wireframes.

Once the client confirmed we were all on the same page, we moved forward into developing a high fidelity clickable prototype.

Prototype

The prototype was focused on showing the dashboard’s three main tasks:

1. Editing the current special

2. Adding a new item

We got some great feedback about the ease of use too:

Speaking of ease of use, we had a 100% success rate for all 3 tasks across all 3 users!

Obviously, it wasn’t just compliments that we got out of usability testing. Our users gave us a lot of helpful feedback to help us fine tune the details of our prototype.

For example, the vegan user pointed out that if the vegan dietary label is highlighted, then the vegetarian, egg free, and dairy free labels should all automatically be highlighted. This was a great tip to help save time for the restaurants who are using these labels.

One user pointed out that filling in the dietary labels to highlight them actually ended up having the opposite effect and emphasized the only label that isn’t actually highlighted.

This was a great example of our team maybe being too close to the design, and we needed that outside perspective to kind of zoom out a little bit and see things in a different light.

Another user pointed out that having the dietary labels filled in distracted them from finding the Save button because the color pulled their eye away.

At this point, we started to realize that having filled in versions of the dietary labels might be causing more distractions than the benefits it offered.

That same user also pointed out that we were using filled in dietary tags in the editing sidebar but not on the main part of the page, so it suggested that they served different functions.

This was the kind of observation that made complete sense when the user pointed it out, but it had never crossed our minds despite how much time we had spent analyzing the design as a team.

The user also commented on how the info icon that provides information on the definitions of the dietary labels didn’t catch their eye when it was the same color as the text, so they didn’t realize they could click on it to see more information.

We followed their lead on this and used the highlighting color to separate it from the text.

And finally, the vegan user pointed out that while most people already know that meat, eggs, and dairy aren’t vegan, there are common cooking ingredients that a lot of people don’t realize aren’t vegan, like honey, gelatin, lard, and ghee.

So we listed those out to provide more quick references without the restaurants having to click on anything for additional information.

After the prototype was updated according to the usability testing results, we presented the entire project to the client. As Research Lead, I explained the secondary research, competitive analysis, user interviews, and usability testing findings to him. He was thrilled by our team's work!

Next Steps

While the prototype is almost all built out, there are a few sections that were not designed due to the time constraint of the project, such as Settings, FAQs, and Help. If we were to continue working on this dashboard later on, we would need to tie up those loose ends before handing off the prototype to the development team.

Until then, we’re excited about the future of the Eat Unbound dashboard!