Project Overview
This project focused on improving the integration between MenuWorks and MyOrders, two systems used to manage meal planning and procurement within Compass Group.
​
The goal was to create a more intuitive and structured experience for users generating shopping lists, resolving product mismatches, and preparing data for export into ordering systems.
​
The challenge extended beyond usability improvements. The experience lacked a clearly defined workflow, requiring UX to establish structure across multiple connected systems.
My Role
-
As the UX Lead, I was responsible for defining the end-to-end user experience across the integration workflow.
-
I translated evolving and ambiguous requirements into structured wireframes and user flows.
-
I collaborated with product, engineering, and business stakeholders to align on system behavior and experience direction.
-
I identified gaps in workflow logic and advocated for usability-driven improvements.
Target
Audience
The primary users of this experience were food service operators and procurement teams responsible for managing inventory and placing orders.
​
These users needed:
• Clear visibility into product availability and mismatches
• Confidence in the accuracy of their shopping lists
• A streamlined process for reviewing and exporting data
Project Scope and Focus Areas
The project focused on improving the end-to-end workflow across three key areas:
​
• Shopping List Creation and Review
• No-Match Resolution (product mismatches)
• Export and Integration with MyOrders
​
The work emphasized defining how these components connect into a single, cohesive experience.
Designing in Ambiguity
This project required designing within an undefined problem space, where workflows, system behavior, and ownership were still evolving.Rather than relying on fully established requirements, I helped shape the structure of the experience while aligning stakeholders and identifying gaps in real time.
The Challenge
What I walked into
-
No defined end-to-end workflow
-
No clear product ownership or requirements
-
Design being used to “figure out” the product
What made it complex
-
Multiple sectors with different data structures
-
Up to 50% of items return no match
-
Unknown feasibility of resolving data issues within the system
The team was attempting to design and build simultaneously without a shared understanding of what the product should actually do.
Staring with Concept, Not Reality
When I first began working on the project, there was no confirmed scope of work and no clear definition of what the final product needed to be.
The initial wireframes I created were not grounded in validated requirements,they were concept screens, built from a walkthrough of the current system and early conversations around what the integration could look like.
*Deliverable Artifact(s) No- Match Concept Screens
At that stage, design was being used to:
-
Visualize a potential solution
-
Support internal alignment and sales conversations
-
Fill in gaps where product definition did not yet exist
*Deliverable Artifact(s) No- Match Concept Screens
Because of this, the early designs assumed:
-
The feature could be integrated directly into the existing shopping list experience
-
Users would move seamlessly from creation → review → export
-
Matching issues could be surfaced and resolved within the same flow
​
*Deliverable Artifact(s) No- Match Concept Screens
From a UX perspective, this approach made sense. It preserved familiarity and reduced disruption to the user’s existing workflow. However, what these concept screens ultimately revealed was something more important: 👉 We were designing a solution without knowing if it was technically possible.
*Deliverable Artifact(s) No- Match Concept Screens
What the Concept Screens Actually Accomplished
​
Even though these early wireframes were not build-ready, they played a critical role in the project.
​
They helped:
-
Translate abstract ideas into something visible and discussable
-
Expose assumptions across product, design, and engineering
-
Highlight gaps in system behavior, data structure, and ownership
​
They also surfaced the first major constraint:
👉 The existing system could not be modified in the way the design assumed
(due to limitations around APIs and backend ownership)
​
This forced a shift from:
Enhancing an existing experience to: Creating a separate workflow entirely
The First Realization
This was the point where my understanding of the project changed. What initially looked like a feature design problem turned into something else entirely. We were not just designing an interface.
We were trying to define how the system should behave without a clear understanding of what was technically possible or how different parts of the system connected. The questions shifted from what this should look like to what this actually can be and who is responsible for defining it.
That shift set the tone for the rest of the project.
Quantification
Designing for the Unknown
After the initial concept phase, my first formal task was to design the quantification experience.
In simple terms, this meant allowing users to review and adjust ingredient quantities before exporting their shopping list.
At this point in the project, there were still no clearly defined requirements, no consistent stakeholder input, and no established success criteria. The expectation was to move forward with design while those pieces were still being figured out.
I approached the quantification flow by focusing on what a user would realistically need in order to make decisions at that stage.
I designed a table-based experience that included ingredient details, quantities, and relevant context that would support edits before export.
From a design standpoint, the solution was structured and usable.But very quickly, a larger issue became clear.
*Deliverable Artifact for "Quantification"
Where Things Started Breaking Down
As I began walking through the designs with the team, questions started coming up that no one could answer clearly.
-
What information was actually available from the system?
-
What quantities could realistically be edited?
-
How those changes would impact what gets sent to MyOrders?
-
Whether the data even supported the level of control we were designing for.
There was also little to no stakeholder engagement at this stage. Feedback was minimal, and when it did come in, it was often disconnected from how the system actually worked. This created a pattern where design was moving forward, but the foundation underneath it was unstable.
Shifting from Designing to Structuring
​
This is where I started to change how I approached the work. Instead of continuing to design based on assumptions, I began pushing for requirement conversations and clearer alignment before moving forward. I called out the risk of continuing to design without input, especially in a system where small changes could have downstream effects on data, ordering, and integration.
*Deliverable Artifact explaining the creation rationale at that time.
The goal was not just to improve the design, but to create a shared understanding of what we were building. At the same time, scope began to expand. Requests came in to support shopping list creation within the same experience, which introduced additional complexity on top of an already undefined flow. This reinforced the need for structure.
What This Phase Established
Even though the quantification designs themselves evolved, this phase established something more important.
It made it clear that the core issue was not the interface.
​
It was the lack of alignment across product, stakeholders, and engineering.
​ From this point forward, design became less about producing screens and more about: asking the right questions exposing gaps in logic and data and pushing the team toward decisions that could actually be built
No Match
Forcing Clarity in an Undefined System
As the project progressed, the focus shifted to the no-match experience, where items could not be successfully mapped between MenuWorks and MyOrders. Four main failure types were identified, but there was no clear direction on how users were actually supposed to handle them.
No Match
I created flows and visual examples to show what these scenarios could look like in the product and how a user might move forward. The goal was to turn abstract conversations into something concrete the team could react to. That’s when the gap became obvious.
There was no shared understanding of the expected outcome. Stakeholders couldn’t define whether users should resolve issues, skip them, or export partial lists. At the same time, engineering had not confirmed what the system could support. Design was moving forward without a defined product or technical foundation.
To move things forward, I introduced structure into the conversation.I defined three possible approaches: exporting what works and flagging the rest, requiring all issues to be resolved before export, or a hybrid where the system resolves what it can and the user handles the rest. I grounded each option in real constraints like list size, match failure rates, and user effort.I then facilitated a UX workflow workshop to align stakeholders on what a successful export should actually look like.
That shifted the conversation from ideas to decisions. It also led to deeper involvement from product and engineering, where it became clear that full no-match resolution was not feasible with the current system.This was the turning point where the work shifted from designing ideal solutions to defining what could actually be built.
Alpha
Redefining what is possible
By the time we reached Alpha, the direction of the product had fundamentally changed.
The original expectation was that users would be able to resolve no-match errors directly within the experience before exporting. However, through design exploration and cross-functional discussions, it became clear that the system could not support that level of interaction. The data was inconsistent, and the logic required for reliable resolution did not exist.
As a result, the scope for Alpha was redefined.
The final Alpha experience included:
-
A simplified shopping list flow with reduced steps
-
A dedicated review state before export
-
Clear visibility into match status (matched vs unmatched items)
No-match resolution was intentionally removed, not as a design compromise, but as a decision grounded in technical reality. This allowed the team to deliver a usable, testable experience while establishing a foundation for future iterations.
Beta
Extending the Experience Within Real Constraints
Following Alpha, the focus shifted to refining the experience and addressing additional workflow needs that surfaced through stakeholder feedback. New asks began to emerge, including the ability to:
-
Create and manage multiple shopping lists tied to different time ranges
-
Navigate more flexibly between menus and shopping list creation
-
Improve usability of the existing flow without introducing additional complexity
However, similar to earlier phases, these requests introduced challenges around how the system actually functioned.
Some of the desired behaviors, such as dynamically linking menus to multiple time ranges, were not supported by the underlying data structure. This required careful evaluation of what could realistically be implemented without breaking the integrity of the system.
Instead of forcing solutions that the system could not support, I focused on designing within those constraints.
This included:
-
Introducing lightweight workarounds, such as allowing users to create separate shopping lists tied to specific time frames
-
Exploring navigation improvements like “return to menus” to better support user flow
-
Refining the existing experience rather than expanding it beyond what was feasible.
These updates maintained continuity with the Alpha experience while incrementally improving usability.
What I Learned
This project strengthened my ability to lead through ambiguity. Instead of waiting for clarity, I learned to create it by structuring conversations, challenging assumptions, and using design to surface gaps across product and engineering. It also reinforced the importance of grounding design in technical reality.
Not every solution is feasible, and part of leadership is helping teams understand what can actually be built.
Conclusion
This project began as an undefined concept and evolved into a buildable product direction.
Through design, I helped shift the team from assumptions to decisions, aligning stakeholders around what was feasible for Alpha while setting a foundation for future iterations.
This work reflects my ability to bring structure to ambiguity and drive execution in complex environments.