Josh Rubenoff

Design Exercise : WaiterRate

WaiterRate component library

The brief

While there are many ways to rate and review restaurants, these are not focused on evaluating individual waiters.

Design an experience where diners can submit positive comments and constructive suggestions for the waitstaff, and waiters can use this feedback to both improve and help to secure new employment.

You ​should​ ​provide​ all ​of​ ​the​ ​following:

  • A​ ​brief​ ​overview​ ​of​ ​your​ ​thought​ ​process​​ ​and​ ​how​ ​you​ ​decided​ ​to​ ​tackle​ ​the​ ​problem.​ ​Rough sketches​ ​and​ ​rejected​ ​ideas​ ​that​ ​show​ ​your​ ​thought​ ​process​ ​may​ ​be​ ​useful​ ​to​ ​include​ ​here.
  • A​ ​description​ ​of​ ​your​ ​solution,​ ​including​ ​wireframes​ ​or​ ​diagrams​​ ​to​ ​illustrate​ ​if​ ​necessary. Explain​ its ​strengths​ ​and​ requirements,​ ​and​ ​why​ ​you​ ​made​ ​certain​ ​design decisions​ ​or​ ​tradeoffs.
  • At​ ​least​ ​one​ ​high-definition​ ​mockup​ ​or​ ​prototype​​ ​showing​ ​important​ ​interaction​ ​or​ ​UI​ ​details​ ​of your​ ​solution.
  • Anything​ ​else​ ​you​ ​think​ ​is​ ​important/interesting​ ​to​ ​include.

Most​ ​of​ ​all,​ ​we’d​ ​love​ ​to​ ​see​ ​an​ ​exciting,​ ​imaginative,​ ​and​ ​interesting​ ​design​ ​that​ ​shows​ ​off​ ​how​ ​you approach​ ​design​ ​problems​ ​and​ ​your​ ​personal​ ​style.


This design exercise for a potential employer took about eight hours. I tried to strike a balance between fulfilling the brief’s requirements and accurately portraying my process.

In this exercise, I tried to demonstrate how I like identifying edge cases and error states, exposing team assumptions, and working to reduce a project’s uncertainty. This can be a time-intensive way to work, so I usually make prioritization decisions through research insights and a healthy back-and-forth with colleagues.

Since I had neither of the above, I erred on the side of accurately portraying my working style, at the expense of spending longer on the exercise than I expected.

User archetypes

I started off by identifying three types of users:

These reminded me of the “primary user / buyer / benefactor” archetypes from my previous roles in healthcare and government.

For example, when I worked on electronic medical records, the buyer and the user were two separate entities: hospital IT staff and doctors. However, the software’s primary benefactors were patients, a totally different group.

For the product to be successful, designers needed to keep all three archetypes in mind.

Product pitches

I realized that the product could offer very different value propositions depending on the type of user you focused on.

So I came up with four product pitches, each with a different primary user.

  1. For managers: A SaaS performance management tool for restaurants. Once managers purchase a plan for their restaurant and collect ratings from patrons, they can see which of their waitstaff are delivering the best service, and make personnel decisions accordingly.

    Selling to managers would ensure that waitstaff will adopt the product, but I didn’t like how this would reduce leverage among waitstaff, who I believe are already underpaid in many parts of the country.

  2. Patrons: A Yelp-style site specifically for rating quality of service. Patrons could leave public reviews of waitstaff without their consent or the restaurant’s. (However, like Yelp, we could let restaurants “claim their page” for greater control over their image.)

    This idea has the lowest friction for patrons, but I disliked the community dynamics it encourages. Providing a forum like Yelp to trash businesses is one thing, but a platform designed to criticize specific employees and call them out by name is another.

  3. For waiters: LinkedIn / Dribbble for waitstaff. Waiters could create their own profiles with testimonials from patrons, while hiring managers could pay to post new jobs or source good candidates. With this idea, waiters are in total control of the feedback they receive, and negative comments can stay private if they so choose.

  4. For third parties: A waitstaff reputation API that complements location intelligence data. We could collect patron reviews privately, sidestepping the toxicity of the previous idea, and license the data to sites like Foursquare and Yelp. Developing a comprehensive dataset of waitstaff service quality could produce all sorts of interesting, valuable insights, like the ability to compare average waiter ratings across restaurants.

    For many reasons, I wasn’t sure how this idea could gain traction. To start, why would restaurants be incentivized to participate?

I chose to go with the third pitch, and focus on helping waiters. I liked how this concept empowered a group that, at least to my limited knowledge, doesn’t have a ton of leverage.

But it comes with a few big questions. For example: would managers let their waiters request reviews that the manager might never see? And how would the product guide patrons through the increased friction required to provide substantive, meaningful reviews?

I decided that these problems, though significant, would be worth the effort to solve in the context of the broader vision.

Research plan

After deciding on a pitch, I wrote up an outline of what I’d try to uncover through research if this were a real project.


I’d want to learn two things from waiters. First, does this product solve a real need? Would positive patron feedback actually be helpful in finding new work? Are they willing to accept and improve upon constructive negative feedback?

Second, how equipped are they to take advantage of the product? Are they familiar with using online platforms like LinkedIn to market themselves, and if not, how much will we need to teach them? Do they have a desktop / laptop at home, or do they only own a smartphone? If the latter, how quickly does their data plan run out each month?

I would try and interview waiters from a range of ages and restaurants: from young people starting out in their careers to working-class waitstaff supporting families.

I might ask them questions like:


For hiring managers, I’d want to confirm whether patron testimonials would be a valuable data point in their hiring process. How important is quality of service compared to factors like years of experience and previous responsibilities?

I’d also be interested to learn how they’d feel about the prospect of their own waiters using the product.

I might ask them questions like:


I assume patrons would be the least incentivized to adopt the product. If they’re inclined to write online reviews, they likely do so on Yelp or Foursquare already. Why would they take the time to rate their waiter on a separate service, much less give them helpful and constructive feedback?

I’d want to learn more about what incentivizes patrons to praise or criticize waiters, whether to their friends or the manager. I’d also recruit Yelp and Foursquare users to learn their motivations in writing reviews at all.

I might ask them questions like:


Finally, I’d ask my colleagues a few questions to better understand our business and technical constraints.


The Market

“How might we?” questions

For the sake of completing the exercise, I made the (huge) assumption that user research would validate all of the user needs mentioned in the product pitch.

I then generated a list of “How might we…?“ questions, to use as a basis for brainstorming sessions.

Basic product expectations




Data quality / community management



Other topics


Normally, I’d spend 5–15 minutes brainstorming solutions for each “How might we…?” question. But for the sake of time, I decided to focus solely on the rating flow for patrons.

First, I made up a few rough criteria for judging waitstaff: communication, rapport / friendliness, accuracy, domain knowledge, and hospitality. 1

From there, I brainstormed a few solutions to the “Basic product expectations” questions for patrons.

Brainstorming notes.

I decided that a series of closed-ended questions, accompanied by free-text fields to explain poor ratings or provide testimonials for good service, had the best chance of giving waiters insightful feedback. We could add UI microcopy below our free-text fields to help patrons give constructive criticism.

Then, I sketched out a user flow, using Ryan Singer’s component flow shorthand.

Excerpt of user flow View at full size

Visual design

I used this user flow to create a component library in Sketch with all the UI affordances I’d need. Given how long I’d already spent on the exercise, I spent very little time on visual exploration or a logo.

Component library

I hypothesized patrons were most likely to rate waiters on their phones either during or immediately after the meal, so I mocked up a webpage on an iPhone 8 screen.

Sample mockup for an iPhone 8 screen

Assumptions and risks

Throughout this process, I added to a list of assumptions I’d made and risks I might need to mitigate.

In a real project, I’d plan to validate these with further research and testing.



Personal experience

I have very little experience thinking through the incentives and dynamics of multi-sided marketplaces, and yet I’ve assumed that the above research and brainstorming questions are the right ones to ask.

To confirm I’m on the right track, I’d want to read books like Platform Scale and Matchmakers to learn more about these types of products.

Other risks I didn’t explore due to time constraints

  1. In a real project, I’d ideally have arrived at these questions through research.