Designing with Mustard — Anna E. Cook

Writing

Writing on design systems, AI, and accessibility, focused on decision-making, risk, and long-term product outcomes.

Designing with Mustard

Designing with mustard is the future of design. I used to think it was ketchup, but I was wrong. If you're not currently designing with mustard, you should get out of design and tech.<br>The future of design is mustard. Adapt or perish.<br>Just kidding.<br>It would be wild if I actually said something like that, right? Yet here we are, in the middle of constant messaging just like this but with AI instead of mustard.<br>A little context: a few years ago, I wrote a piece about designing with ketchup .<br>It started as a joke. Someone called Webflow the "ultimate" design tool and I responded by making wireframes with a bottle of Heinz, proclaiming that ketchup was the ultimate design tool.<br>As one does.<br>It was ridiculous, but many of you remind me about it, years later. I think it captured a feeling many of us deal with in the tech space. There's some real absurdity here, bold claims without evidence, and utterly ridiculous people selling slop.<br>If they're going to be ridiculous, why can't we be too?<br>Beyond satire, the article went into something that is fundamental to how we build: Tools don't define design . You can use anything — Figma, Webflow, PowerPoint, paper, code, even ketchup — if it helps you think through a problem and communicate a solution.<br>Apparently, we need to talk about this again. Just with a different condiment.<br>Lately, I've been seeing a lot of posts about using AI for design, coding, prototyping, etc. Or vibe coding . Or whatever else we’re calling it this week.<br>The pitch is straightforward: describe what you want, generate something that looks like a product, iterate from there. You don't really need to wireframe. You don't need to think through flows the way you used to. You can just…start generating.<br>I get why that's appealing if you haven't done this kind of work before. If you're used to looking at someone else's prototypes and reacting to them rather than building them yourself.<br>AI–err, I mean, Mustard is spicier than ketchup. Sharper. But underneath, it's the same trick: squeeze something onto the canvas and call the meal made.

Four triangles making up a larger triangle. On the tip of each point is a label. These labels are “role (with a red dot), implementation (with a blue dot), and look, and feel (with a green dot).” An arrow points to the center of the triangle with the label “integration.”

Why do we prototype?<br>Before going further, I want to slow down on something this conversation sometimes skips. Prototypes aren't products. Or demos. A prototype is a question , something you make in order to learn something specific you couldn't learn any other way.<br>Houde and Hill said this back in 1997, in a paper I keep coming back to. They organize prototypes into three kinds of questions:<br>Role — what is this thing for? How does it fit in someone's life?

Look and feel — what is it like to experience? What does it look like, sound like, feel like to use?

Implementation — how does it actually work? What's the structure underneath?

“A prototype that isn’t socialized isn’t a prototype at all, it is just an early attempt at making something: the focus is on the object being made, not the idea it represents. And it’s that human socialization and collective meaning-making that turn an artifact-in-process into a prototype that is refining something outside of itself.”

— Frank Elavsky, On genAI: Was prototyping really a bottleneck?

Different prototypes ask different questions and are used to seek answers.<br>A storyboard might ask about role. A high-fidelity mock asks about look and feel. A coded prototype asks about implementation. There's overlap in all of these spaces, which is part of the reason why people have always struggled so much with job titles and responsibilities in product spaces.<br>Regardless of your job title, the question you're asking determines what your prototype needs to be true to .<br>Your prototype might skimp on details, and that's okay as long as it isn't being shipped as is. A role prototype might live in a PowerPoint. A look-and-feel prototype might live in Figma. An implementation prototype might live in Storybook.<br>So when we talk about AI prototyping, the actual question to ask is: which of these is this tool the best fit for the question we need to answer?

An example of a “role” prototype from What do Prototypes Prototype? It is a storyboard for a portable notebook computer. The paper storyboard was an early prototype of a portable notebook computer for students which would accept both pen and touch input.

Role<br>In Houde and Hill's framing, role is the function a thing serves in someone's life. A role question asks:<br>What does this do for them?

Why does it matter?

Where does it fit into their day, their goals, the tools they already use?

The answer doesn't live in an artifact. It lives in the...