The Problem of Customization
May 2022 - August 2022
Overview
One of my main projects during my time at kiosk software company GRUBBRR was working to develop a solution for a problem referred to as “nested modifiers.” This issue was based in the problem of making one selection in the food ordering process (think ordering a burrito bowl) causing you have to make further selections, choosing from a set of modifiers to customize your first selection (thinking toppings for your burrito bowl), which can then go on somewhat infinitely (think types of salsa, cheese, and meats, the followed by meats). This problem was an issue for a lot of GRUBBRRs clientele including multiple national and international chain restaurants, which have been anonymized for non-disclosure purposes.
The Company
The Team
Soda Doan and Allie Pultorak, UI/UX Designer and UI/UX Design Intern
2+ Product Owners
Problem Description
The original UI for GRUBBRR’s nested modifiers, or order selections that were nested within other selections (think burrito bowl > toppings > salsa > type of salsa > amount of salsa) had each additional selection appearing as a pop-up on top of the previous one. Our job was to make a clean fix to this issue that could also be standardized across any restaurant that might want to use our software.
Experimental Sketching
In revising the previous solution, we were inspired to think outside of the box, and explore unique solutions. We did this in iterating through various sketches, some of which are pictured here, including one of the foundational sketches for our largest design solve, the smart and selective use of indented accordions.
Creating a Flow and Solving Inconsistencies
While looking at the design work previous people had put in place before my arrival at GRUBBRR, it became clear that the problem of nested modifiers was being handled on a restaurant-by-restaurant basis, instead of being standardized across all of our clients. This means that our developers had to create different algorithmic solvers for each restaurant and in some cases for each food item, which cost the company both time and resources.
In order to stifle my own confusion with the nested modifiers problem and to avoid inconsistencies as we continued our design process, I created a flow chart (seen below) to best visualize each step in the nesting, and provide clear rules as to when items should be broken down into an additional nested step. After months of this iterating through potential designs, prior to my even coming to the company, the product owners were finally able to ticket the design solution shown in the flow chart with its clear examples and definite rules.
GRUBBRR Nested Modifier Rules Flow Chart
Big problems require big solutions, hence the flow chart is a bit extensive as it should provide a solution for each use case, which means the actual flow chart is a bit too large and too detailed to feature here.
In its place, a simplified view is shown to the left.
High Fidelity Prototyping Solutions
The solution for the nested modifiers arises out of a few individual design elements designed by myself and my co-designer, combined into a set of rules. These design elements are broken down and labeled below.
The use of these design elements are dictated by the rules indicated in the flow chart and as the restaurant would deem necessary. Given the possible complexity of a situation regarding nested modifiers, we developed many different use cases for a variety of GRUBBRR’s restaurant clientele.
Starting Simple: Burgers
One of our more straightforward examples appeared in the case of a national burger chain. With the only modifiers in the burger item being buns and toppings, both of which are optional, the customer is not required to make too many choices. This example shows our solution in its most basic state. offering accordions for both the bun and toppings options.
Getting More Interesting: You Pick Two
Our user case gets more interesting for deli franchise’s ‘You Pick Two’ menu item. In this scenario, the item appears in builder mode, indicated by the top banner showing the user two steps that must be completed before ordering. In addition to the accordion solution from before, this situation also calls for our variant buttons, which can be seen on the dressing, allowing the customer to choose different sizes without having them navigated to a different page, as well as indented accordions, as shown in all modifiers under the “Choose your first item” section.
Finishing Complexly: Asian Diner
In our most intricate example, we portrayed a family bundle order from an Asian food chain, the first portion of which is shown above. This example offers an extensive builder mode, each filled with individually difficult steps. A combination of almost all our design elements: accordions, indents, variant buttons, and quantity counters, are all used in this build in order to make an easier ordering experience. In comparison to the original solution, now customers are able to see clearly the source of each step and interact accordingly without being forced to different pages.
Prototyping In Motion
The prototypes shown above look even better in action. Check out the two simpler examples, chose specifically due to their quick and simple nature for another look into how our team reached the solution.
Starting Simple: Burgers
Getting More Interesting: You Pick Two
Key Takeaways
Be Clear About the Product Flow
Learning how to create a flow is important, especially when it can take so many different directions. In this project, the creation of our flow chart was crucial in making our product function clearly.
Keep Design Consistent
From the users’ perspective, having different buttons and imagery is confusing, and muddles their psychological flow when making decisions. Creating our standard elements such as variant buttons and accordions, allows users to become comfortable using our product.
Understand the Value of Team
Working with a multi-disciplinary team full of differing perspectives can be complicated, so it proves important to keep everyone feeling heard and understood. Once the product owners and developers understood our flow more completely, we were able to mesh much better as a team, and benefitted from each other’s input.