Analog Storyboard Sketch 1 - Not done by me.
Diners can find/see vacant tables and reserve or occupy them
Diners can browse the menu and enter their order at any time throughout their visit
Cooks receive orders
Servers deliver orders when complete
Diners can signal a need for help at any point in the process
Diners can pay for their order using different options
Staff are alerted to tables that need bussing
Other features as you decide
Paper and Pencil Sketching:
4 Generators / 1 Sketcher
It's good for us all to step outside of our comfort zone, so one of our group members really wanted to take the paper sketching idea by the horns. Her background is in video production, and obviously has a background in storyboarding. We really wanted to capture how the experience of a scenario where a virtually contactless workflow would look.
Review and Feedback
Feedback was well-received as a concept, but consideration should be paid to the outside eyes comment about automation leading to less employment opportunities.
One thing noted was the persons experience as a person positioned in the wait staff; they recommend that we consider making the process of the initial scan prominent for the patron. We had originally assumed that a QR code pasted outside of the restaurant or on the door would suffice, but given the feedback, recommendations for large signage would be preferable.
During this phase we synthesized the pencil and paper storyboard to a digital format using Procreate. We essentially emulated the script developed by the original sketch artist. This phase was done by member of the team who was not involved in the analog sketch storyboard.
Deciding The Actual Workflow of the Prototype
After we reviewed the storyboards, we had to brainstorm ways in which the web app would actually flow. We segregated the experience into sections. As you can see, some sections are purely the experience of the patron, and others of the kitchen and the waitstaff. From here we had to choose two areas to specifically wireframe. From there we decided on the mechanics.
Here's a synopsis of our system works:
1. Patrons scan a QR code before or upon entering the restaurant (either the QR card is on the door or perhaps immediately as they enter).
2. Upon scanning the QR code, the patron's mobile device opens the mobile web app, and they are asked for their party size.
3. Once their party size is selected, they are taken to the table selection area of the web app.
4. Once the table is selected, the patron is instructed to go to their table with their party.
5. Once seated, patrons scan a unique QR code located at the table to retrieve the menu and begin ordering.
6. While ordering, the wait staff receives a notification that a new party has been seated, and they bring the appropriate table service
7. Once their orders are placed, they are sent to the kitchen directly with their table number. The kitchen prepares the patrons' items, and the wait staff delivers the meals when they are completed.
8. While dining at the establishment, patrons may tap the service menu icon and may request what they need from a list of items.
9. The dining experience may end at any time and is handled individually. Patrons can press the "I'M DONE" button to end the dining service.
Review The Prototype Workflow: Choose 2 Segments
After outlining the general design and deciding on mechanics, we decided to wireframe two sequences:
Table Selection and Check-In
Ordering, Server Assistance, and Checkout
We chose these two sequences because they are the most patron-facing, and therefore would matter the most on the overall design. Without patrons, there would be no business.
Reflections, Considerations, Notes, and Take Aways...
We did not storyboard or wireframe the waitstaff or kitchen side of the prototype. This demonstrates that all stakeholders in the entire dining workflow experience different sides of the prototype. For instance, there may be a mechanic for wait staff to know what orders are outstanding for tables to mitigate any kitchen errors (e.g., a situation where an order ticket gets "lost," and the patron never receives their order).
Other thoughts that that came up during the process:
Advanced reservations and table selection for a specific date and time. We did not consider this during our storyboard or wireframe, but should be considered in final design.
We decided to add an emergency button in the assistance tab of the application to indicate that the table needs immediate emergency assistance from the restaurant. This was a last minute “feature” that we decided was a must that didn’t get discussed in the initial planning of the wireframe.
Something we’re considering is the tipping process for wait staff and servers since this “efficient” way of dining reduces the presence and need for wait staff in the overall dining experience and so we’re currently coming up with ways to solve this issue brought up by Josie in the feedback that she gave us. Where does tipping fall in design?
We also had doubts about whether patrons would be able to understand that the assistance tab can be opened with the icon in the middle of the bar. We intend to make a few adjustments and add labels in the following iteration.
Upon reflecting on the color choices of the mid-fidelity wireframe, different contrasting colors should've been chosen. The green and orange combination makes it difficult to view certain elements, especially the menu bar at the bottom.
Lastly, one thing we ran into during wireframing was how patrons moved from table selection/check-in to ordering. Some of us felt that each QR code on the tables was the same, and they'd scan them going through the same workflow:
Scan, Select your table number, order
Others thought the each table would have an individual QR code that sent the data of which table was being served with the menu request, that was ultimately sent to the system when ordering. This seemed to simplify the process and reduce additional steps: