Menu Maker

The Problem We Were Solving

With the advent of order aggregators like DoorDash, Grubhub, and others, customers were having a difficult time managing their point-of-sale menus alongside their delivery menus. There was pain in this area, where too much re-work and duplicate effort was required to set up the different types of menus in tandem. This setup process was too tedious and effortful.

Leading a UX Team

For this project, I served as lead UX designer. I led a team of three UX designers and played a significant role in coordinating between the members of the design team, the product stakeholders, and the three engineering teams working on building the product.

I coordinated with my team of three UX designers, product management, product owners, and engineering to ensure that everyone was on the same page about design efforts.

This was my first experience in being a lead UX designer and working in collaboration with engineering on such a large project. I learned a ton through this experience about mentoring junior designers, collaborating with product teams, scoping design work, and managing changing product requirements.

Customer Brainstorming Workshop

We kicked off the project with a design thinking brainstorming workshop that included several customers in the large-scale restaurant space. The director of our UX research team was the lead facilitator for this workshop, and I played the role of assisting her with the facilitation and preparing relevant artifacts in advance of the workshop.

The workshop was held in a physical space that leveled the playing field. Each participant had an equal voice, despite their official title. There was plenty of wall space in the room for participants to go crazy with sticky notes as they brainstormed ideas.

In this workshop, we walked through the design thinking process. We primed our participants with a presentation articulating the main problem we were intending to solve. Then, we walked them through exercises that got the participants to brainstorm, storyboard, and sketch out ideas as they discussed collaboratively. As the workshop concluded, there was certainly still much work to be done to flesh out the ideas more clearly, but we walked away from it having collected a high volume of diverse ideas. The customers left the workshop enthused!

Personas - Who Uses Menu Configuration Tools?

To understand the different potential users of our application, I worked with product stakeholders and UX research to create four proto-personas prior to our customer brainstorming workshop. I took the four personas to the workshop and we discussed them with our customers to discern, based on our customers’ collective experience, whether or not the proto-personas were accurate, and if they weren’t what we could do to improve them. We refined the personas together, and by the end of the workshop, we had a good sense that our personas were rooted in reality.

I wrote the personas for this project using a tool called UXPressia, a tool for creating UX artifacts. UXPressia enabled me to create these personas quickly so that I could get feedback on them from customers.

We arrived at four personas:

1. The corporate IT menu builder - this was our primary persona. Someone who is more on the technical side, works in the corporate office of a medium-to-large restaurant chain, and has a good amount of expertise when it comes to menu configuration.
2. The end-user - the customer of the restaurant. While this person never actually uses the tool we set out to make, this is the most important person to consider because ultimately all menu configurations are done in service to this persona.
3. The restaurant manager - someone who’s overseeing when things run out of stock, when customers have complaints about the menu, etc. This person is downstream from the menu configuration but ultimately deals with the real-world effects of the menu and thus holds important insights.
4. The corporate marketer - this person has different goals than the other personas that are important to consider such as: running promotions, specials, and seasonal items.

Deeply Understanding Menu Information

In parallel to the workshops and as my team was ramping up, I proactively seized the opportunity to learn more about how menu information works. I quickly discovered just how complex the domain of menu configuration can be. I combed through a number of online menu apps and websites from a variety of large restaurants and as I did so, I analyzed the structure of the information.

An artifact I made in Mural that describes how digital menus are structured and what information we needed to consider for our design. My team and I came back to this taxonomy again and again throughout the project.

Patterns began to emerge across different contexts and I began to understand on a deep level how menu data is best represented and organized. Looking back on it, the knowledge I gained from this research effort was critical throughout the entirety of the project and enabled me to create a vision for the user experience and guide my team.

Whiteboards, Whiteboards, and More Whiteboards!

I worked with a knowledgeable team of product owners and engineers. We revisited the whiteboard on a daily basis as we created shared understanding for this project. Because of the complexity involved, we often found that there was no better way to proceed forward than a simple whiteboarding session and talking things out.

A few pictures of whiteboards that I sketched with my teammates, including both UX and product. This is only a tiny fraction of the whiteboards we talked through to create a shared understanding for this project.

Since I was leading a team of multiple designers and we were working with a large team of engineers, creating a shared understanding was paramount. In the spirit of Lean UX, we got into the habit of whiteboarding as a team before we went too far down one path in our designs, which helped us prevent wasted effort.

Iterative Prototyping

With research, persona-writing, the brainstorming workshop, and initial sketching under our belt, I started to create prototypes to envision a solution in more concrete terms. As you can see in the figure below, the layout and structure of the design changed a good bit from iteration to iteration. (It’s also worth mentioning that these iterations took place throughout the project, they didn’t occur all at once in one stage. Rather, these prototypes took place as the project progressed, overlapping with research and testing efforts.)

5 examples of early iterations of the design. Ultimately, some elements of each of these iterations made it into the final design. The final design wouldn't have been possible without the understanding generated by these earlier iterations.

As a team, we gained more and more understanding of the problem we were trying to solve as these iterations progressed. This new understanding informed the next iterations of the designs.

Sprintly User Research

As we iterated on the design, we tested and validated our assumptions through usability studies. We held a sprintly (once every two weeks) user research sessions wherein we pulled up the latest version of the prototype on one of our laptops and guided a test subject (usually someone internal who didn’t know too much about the project) through the main tasks our app was designed to afford and we observed usability issues as they arose and took note of users’ feedback on the design overall. These sessions were generally planned and conducted by a member of our internal UX research team in collaboration with myself and the product owners to sync up on the main feature or problem we were solving in each sprint.

Customer Feedback Sessions

While the usability sessions were informal and with internal audiences, we also held more formal interviews with customers (people who matched our primary persona). In these semi-structured interview sessions, we showed the latest version of our designs and collected feedback. (This usually involved screensharing over video conference software remotely.) This expert feedback proved crucial in helping us understand advanced user scenarios the software would need to support.

Discovering a Problem with Our Design - The Navigation

At one point in the project, I received some feedback about the navigation of the prototype and I realized that we had a usability problem on our hands. We needed to figure out a better navigation, and we needed to be able to validate that it would work with real users. So, I made a prototype in Axure. I made it possible to click on any link in the prototype so that we could observe people clicking around the prototype in an unstructured way.

I made an Axure prototype to address the navigation problem we discovered in our user feedback. (The teal highlights signify the clickable areas.) Every link in the prototype was clickable.

The prototype was high-fidelity from a functional point-of-view: the breadcrumbs were fully-functional, and all the labels in the UI read as they would if the app were fully-functional. (I accomplished this quickly using variables in Axure.) I prototyped with real data from a real restaurant’s website. I didn’t spend much time styling the prototype because its purpose was to represent navigation and any additional styling would’ve been wasted time and effort. I just needed this prototype to validate my assumptions and I knew I was going to throw it away once the user testing was done.

Card Sort Workshop - Organizing Menu Information

Once the core structure of the application became clearer, I saw that we needed to figure out a way to organize the more granular, low-level information the application would house. I planned a single-day card sort workshop to that end. I recruited 6 participants (internal coworkers with a rudimentary understanding of the domain) and I enlisted two of the junior UX designers on the team to assist me with the facilitation of the workshop.

Alongside two of the junior UX designers on my team, I facilitated a card sort study that asked 6 internal participants to cluster menu information. The main goal of the study was to gather data to address this question: how should information be grouped within each level of the menu taxonomy?

Within fixed categories (i.e. each level of the menu taxonomy), I instructed participants to cluster related information and label each cluster with a sticky note. In effect this was a hybrid card sort - an open card sort inside of a closed card sort. I did it this way because this gave me the data I wanted: how should information be grouped within each level of the menu taxonomy? - this was the main question I was trying to answer.

Using the Results of the Card Sort in the Design

The card sort study proved valuable and informative. After the session concluded, I held a synthesis session with my UX team. I incorporated our insights into the design by delivering a series of panels that took the card sort results into account. I organized the information under three main principles:

1. Consistency across levels of the menu taxonomy
2. Using card sort results as much as possible
3. Information appears in an intuitive order

This resulted in the concept of the Properties Panel, which ended up being an important part of our final design. (This worked in a similar way to how Sketch or Figma’s properties panel works.)

Using the results of the card sort study, I organized the granular menu information into a dynamic Properties Panel. I delivered this as a series of specs, one set of specs per each level of the taxonomy.

Final Product

Employing the research and insights we generated throughout the design process, my team and I delivered a set of high-fidelity mockups to serve as our final design. Of course, designs are never complete, but this set of specs ultimately provided more than enough design for the development team to accomplish their planned featureset and then some! From a visual design point-of-view, the company was using a Google Material-based design system at the time. We used that design system to determine the look and feel of the product and we extended the UI components when necessary.

The final product, a cross-platform web app, used a design system based on Google Material for its look and feel. We created custom components as the necessity arose.

My Role

As a lead UX designer, I contributed heavily to virtually every stage of the project. I played several key roles in this project, including:

• UX team lead
• Advocate for the user
• Information architect
• Project coordinator
• UI designer
• Mentor
• Visual designer
• Design ops strategist
• Design systems lead
• … and probably some other stuff that I’ve forgotten about

Conclusion

I learned a ton from this project experience. As a lead UX designer, I learned through trial and error how to motivate and lead a team of young UX designers working on a complex project tackling a tough problem. I learned as I assisted with a customer workshop, facilitated by an experienced UX research specialist. I saw firsthand how valuable it is to do your research upfront, looking at what exists in the market and analyzing the complexities of real-world solutions. I saw how much more intuitive and well-organized information can be if you use a card sort exercise to gather ideas from multiple people.

We were ultimately successful in designing a simple, intuitive experience for an advanced user in a complex domain. Through the process of continually advocating for the user, we were able to prevent complex code-related concepts from bubbling up into the UI. All in all, this project while complex and challenging was a fantastic learning experience.