HelloFresh built its product experience around one thing: the meal kit. A recipe, a box, a delivery. The model worked well — until the business started expanding into new product categories that didn't fit that model at all.
The challenge with the Product Catalogue wasn't a UX problem in the conventional sense. It wasn't about a confusing flow or a hard-to-find button. It was a structural problem: the data model underlying the product had been built for recipes, and we were now trying to represent things that weren't recipes. The seams were showing.
Why OOUX
OOUX — Object-Oriented UX — is a design methodology that starts with objects rather than tasks. Instead of asking "what does the user need to do?", you ask "what are the things in this system, and how do they relate to each other?"
The principle is that people think in objects — nouns, not verbs. A recipe. A product. A subscription. When the objects in a system are clear and consistent, navigation and interaction design become much easier to reason about. When they're not, every new feature creates new confusion.
We used OOUX here because the Product Catalogue problem was fundamentally an object-model problem. Before we could design anything, we needed to agree on what things actually were.
The process
1. Clarify the object model. We mapped all the things that existed in the catalogue — or needed to — and gave them clear definitions. What is a product? What is a recipe? What is a meal kit? Where do they overlap, and where are they genuinely different?
2. Map relationships to expose complexity. Once you have objects, you map how they connect. This is where the real complexity surfaced — relationships that had been implicit in the system became explicit, and we could see where the data model was creating friction.
3. Align on CTAs based on object roles. What can a user do with each object, and when? This sounds simple, but it forces clarity on questions that had been answered inconsistently across different parts of the product.
4. Define attributes that drive functionality. What data does each object need to carry? Which attributes are optional, which are required, and which determine how the object behaves in different contexts?
5. Bridge strategy to interface. Only once the object model was solid did we move to screen design — and when we did, the decisions were much cleaner because the foundation was clear.
What changed
The biggest shift wasn't a screen or a flow. It was how the team talked about the product. Having a shared object model meant that when new requirements came in, we could quickly reason about whether they fit the existing structure or required a structural change — rather than just bolting on a new feature and hoping for the best.
OOUX gave us a way to make decisions that held. The outputs were tangible — cleaner categorisation, more consistent navigation, a product that could actually accommodate the business's expansion plans — but the more lasting thing was a methodology the team could keep using after the project ended.