Workplace Forms
Facebook
Also known as the KMS, this is a web application used to visually program a customer's makeline to produce the food on a given menu using specific ingredients and recipes.
Traditionally, for a restaurant/chain, there is no KMS. Much of the work to create recipes and menus that are then assembled at various locations is done with pen, paper, spreadsheets, etc. It's a completely broken and disjointed systems. The Hyphen KMS is a customer's gateway into a wholistic and integrated tool for this use. But because the Hyphen makeline is automated and requires instructions to properly assemble food, when a customer builds out their recipes and menus, they are actually programming the makeline. In addition to the features for parity, the Hyphen makeline requires some additional information around ingredients, their quantities per recipe, and the type of mechanism needed for dispensing.
Extend the brand identity into the coorporate customer realm and create kitchen management system that provides a way to capture automation-related ingredient information while facilitating the traditional processes of recipe, menu, and line build creation but in an integrated and wholistic approach.
Product Designer
Including: Creation of design system, information Architecture, User Research, Visual Design, Interaction Design, Prototyping
MVP deployed to first pilot users across the country.
Currently engaging with users for feedback to be leverage in the next iteration.
For the first few months, lots of exploration was done for each part of the KDS. The initial focus was around finding a reasonable way to present orders and ingredient supply levels on the same page. They are both needed by the user at the highest frequency, so navigating away wouldn't work.
Additionally, the unique challenge presented by the robotic hardware is that more information was needed for ingredients than simply how full the hopper was. Each ingredient has a physical location on the makeline, and some make lines are a hundred feet long or more. So the location of the ingredient also needed to me visible, otherwise the operator would make extra trips back and forth between the makeline and storage facility at the restaurant.
The KMS is composed a few databases that build on top of one another to ultimately resolve into a line build. A line build is a restaurant's way of identify what ingredients are needed for all the recipes in a menu at a given location and where those ingredients live on the makeline.
This is an example screen of the ingredient database. The composition is straight-forward. On the left are the ingredients, and on the right are its specific attributes. These ingredients can be used in the recipe database, which in turn can be used in the menu database.
There are also a makeline and location database which intersect the journey at the end during the line build.
Once the user has created all they necessary parts of a menu (ingredients, recipes, makelines, locations), they can begin the process of assembling a them into a menu with a line build.
The line build process is fairly simple, with the menu database as the entry point. Once they being building a menu, there are only 3 steps.
First, they choose the locations at which they'd like to make the food. Second, they choose what will be made via recipes from their database. Third, they assign the ingredients in the recipes to different hoppers (the bins that hold the food) on the makeline.
The last step is the most complicated due to the handful of different datatypes, the multiple ways of visualizing the physical space, and the way in which food is assigned to a hopper that all must live together on the single page.
As part of the UX work, many flows were created in Figma and linked to the documentation for everyone's benefit. This is an example of what they typically look like.
In this particular flow, the user has reached the last step in the menu build process and must assign an ingredient to every hopper on their makeline.
There are a number of ways this could be approached, but the decision was to start with the click ingredient + click hopper target method. It was low LOE for software and visually the simplest to understand of the options we considered.
Once all the mocks and flows are completed, our design/handoff process included documentation as you'd imagine. We used Notion at Hyphen for this work and this an example.
I would create a source of truth living document that the engineers and product managers etc could refer to. It included all high fidelity mockup work, all the flows, sub-component breakdowns with notations, and any logic or policies needed fully implement the design.