Analog Storyboard Sketch 1
Storyboarding and Wireframing
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.
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).
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.