My Role

Lead Designer: Discovery, user research, prototyping, UI, usability testing

Team:

Product Managers, Restaurant Operations and Labor Management
Lead Software Engineer, Operations
Senior + Junior Designers

Why is this in my portfolio?

Doing a deep dive into the problem is a mandatory first step to discover the right solution. This is a success story on why I advocate for user lead product development whenever possible.

Discovery

Our design process started with a Discovery Session with a key client’s leadership team. My role was to ask open-ended questions, take copious notes, and look for challenges that might be addressed by thoughtful design.

A recurring theme in the session was that restaurant managers were constantly expected to adapt. They should be proactive about forecasting sales, scheduling staff, and managing operations, but when something goes wrong the response should be immediate. Reporting can identify these problems and quantify the response, but not until the next day. Can we provide that data in real-time, so managers can adapt instantly?

Research

Using the Lean UX Canvas in Miro, my first step was to parse the things I learned in Discovery into actionable insights, and identify the things I knew vs. the things I was assuming. My goal is to identify actionable next steps, and create verifiable research goals. My design team helped here to reality check assumptions, and introduce more clarity.

At this phase our conversation also started veering towards a dashboard. It presented a clear path to real-time display, and had some early interest from clients as many restaurants already relied on wall mounted displays for sharing information on orders.

I then decided on three key research goals. The first was to identify the specific problems managers face, and if those are universal among a variety of restaurant business models. I did this through interviews with a broad group of restaurant owners.

The second was to clarify what KPI's would inform a manager that a day is going well vs. poorly. In Discovery, we assumed broadly that “data” would be useful, but restaurants rely on a nebulous set of data that can vary between organizations - both in what they prefer to use, but also in what they capture.

Lastly, I needed to confirm that data would actually be an effective tool for gut-driven decision makers. It was clear early on that restaurant managers lean heavily on experience and routine, and I assumed they might not want the nerds from a software company telling them what to do.

You won’t know if you’ve solved a problem if you don’t define what the problem is.

Prototyping

My research included a mix of open-ended, non-leading questions as well as varying low fidelity prototypes. I started sessions with conversation around common problems and how they were able to identify and address them. I then transitioned into sharing lo-fi prototypes to pull out more specific feedback on data usage, and gauge their response to viewing information in this way.

Interview questions let me address the first two research goals by building consensus around the key problems managers face:

• Not enough staff on the clock to handle demand and provide quality service

• Too many staff on the clock relative to demand, hurting profit margins

• Some staff going into overtime wages, while others go under scheduled

I used increasingly complex prototypes to evaluate KPI's they used already (if any) to address these problems, and evaluate the relative importance of different KPI's as actionable indicators.

My third goal was clarified as well, as most managers explained they relied on their instincts because it was all they had. They were used to having disparate data sources, with maybe a weekly or daily report at best. All of them indicated that, if available, real time data would be a valuable tool for them to predict how a day may progress. They also felt it would empower less skilled managers, who didn’t have that "gut instinct” yet.

Wireframe progression from empty shell, towards more detailed presentation. I used our existing fonts and design language to not distract customers providing feedback. As our application already heavily relied on tables and simpler UI elements, I also tried not to introduce overly complex visuals. I verified early and often that suggestions in my wireframes could actually be built in our application.

User Interface Design

After several iterations of wireframes, I felt we had enough information to design a high fidelity UI for our initial release of an intra-day dashboard for managers. My research goals had been answered with enough clarity to feel confident that a dashboard was a viable solution, and that I had a set of data points that would work for most users.

During this phase I worked closely with engineering to validate that certain visualizations could be accomplished, and took these findings back to users I had met with earlier. Some compromises had to be made, as some of our desired KPI's would have required substantial technical effort. This also meant shelving an idea for tasks and notifications that did not have a clear user value proposition, and using a simpler strategy for mobile responsive layouts.

I also refined the layout and priority, as several users detailed their thought process for parsing this data during their work day. Seeing it in higher fidelity they described that they'd check labor variance and Overtime first, and if they was OK they'd just move on. They could use scrolling as a way to drill down and make increasinly complex decisions. This also reinforced that managing labor was the easiest lever for them to pull, vs. trying increase sales in the middle of a slow day.

I leaned on my design team for feedback here as well. As graph layouts began to get more complex and data visualization more nuanced, we utilized our weekly Design Critique sessions to pick apart elements and find improvements. As this would be viewed by a distracted manager - on their feet, talking on the phone, pulling out ingredients - some of those early wire frames were closer to a final product than I had expected. In the end I did not stray far from the overly simple design of the wire frame because it proved to be incredibly effective in usability testing.

Initial market release. I relied heavily on my “glasses test” to refine colors and sizing. To quickly replicate a busy restaurant kitchen environment at my desk, I’d walk by my monitor with my glasses off - was it a green day, or a yellow one? Do I need to stop and look, or can I focus on my 10 other priorities?