Designing with Mustard A designer who previously satirized tech hype by declaring ketchup the ultimate design tool is now warning that the same absurdity is being repeated with artificial intelligence. The author argues that tools like AI for prototyping and "vibe coding" echo the same empty promises, and that the fundamental principle remains unchanged: prototypes are questions, not products, and the tool must fit the specific question being asked about role, look and feel, or implementation. 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. The future of design is mustard. Adapt or perish. … Just kidding. 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. A little context: a few years ago, I wrote a piece about designing with ketchup https://annaecook.com/writing/2021/10/27/designing-with-ketchup . 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. As one does. 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. If they're going to be ridiculous, why can't we be too? 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. Apparently, we need to talk about this again. Just with a different condiment. Lately, I've been seeing a lot of posts about using AI for design, coding, prototyping, etc. Or vibe coding https://en.wikipedia.org/wiki/Vibe coding . Or whatever else we’re calling it this week. 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. 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. 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. Why do we prototype? Before going further, I want to slow down on something this conversation sometimes skips. Prototypes aren't products. Or demos https://productpicnic.beehiiv.com/p/designers-will-never-have-influence-without-understanding-how-organizations-learn . A prototype is a question , something you make in order to learn something specific you couldn't learn any other way. Houde and Hill https://hci.stanford.edu/courses/cs247/2012/readings/WhatDoPrototypesPrototype.pdf said this back in 1997, in a paper I keep coming back to. They organize prototypes into three kinds of questions: 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? Different prototypes ask different questions and are used to seek answers. 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. Regardless of your job title, the question you're asking determines what your prototype needs to be true to . 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. 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? Role In Houde and Hill's framing, role is the function a thing serves in someone's life. A role question asks: 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 person and their context. That's where AI runs into trouble. It's trained on artifacts, not on the lives those artifacts were made for. It can generate something that looks like an answer because it's seen thousands of them. What it can't do is verify whether this answer fits this person — your user, your context, the people you're at risk of excluding. It also can’t challenge design biases because it’s built on them. Yes, it’s a possible answer to a question, but a probable output isn't the same as a correct one. What AI can do is generate something quick to react to while the team does the actual figuring-out together. The artifact isn't answering the role question. It's giving the team a shared object to think against. That's the legitimate use, though less effective. Why? Because we keep letting the artifact stand in for the work https://productpicnic.beehiiv.com/p/vibe-prototyping-isn-t-solving-any-problems-but-it-s-creating-many-new-ones . Getting answers to our prototypes' questions needs people who aren't in the room. They need feedback, relationships, co-design, and research https://productpicnic.beehiiv.com/p/ux-works-through-social-relationships-ai-tools-are-erasing-them . Otherwise, we just generated something without any role or purpose…slop. Look and feel In Houde and Hill's framing, look and feel is the concrete sensory experience of using something — what you look at, feel, and hear while you use it. Look and feel prototypes are where AI prototyping seems useful but it’s actually where its limits get hidden best. AI is good at generating a lot of visuals and commonly designed interactions quickly. A layout. A palette. A few screens to react against. A rough component idea or a snippet of code we can adapt to a context. Essentially, it's the Stack Overflow of 2026. Which means we should not trust it, only react to it. This is also why people think AI is a qualified designer. People who are not trained as designers are used to reacting to look and feel. They receive a prototype, don't dig past the surface level, and approve with some feedback "make it pop" . What AI is not good at is the rest of what look and feel actually covers. This is in part because "look and feel" has always been a half-true framing. It tends to focus more on some mechanisms of how we interact and not others. "Look and feel" is not just the visuals. It is also the sounds, the motion, the haptics, the response timing, the interaction patterns as a whole. A blind user's look and feel might be auditory, or tactile, or rendered in high contrast. A keyboard user's might be the rhythm of tab order, browse modes, and focus states. A user with a tremor might experience it through their hands, in tap targets and pointers. A user with neurodivergence might experience it through pacing, language, and predictability. AI's "default" look and feel is screen-shaped, sighted, mouse-and-keyboard. It's inherently biased and limiting. It optimizes for what fits in a screenshot, because that's the data shape it was trained on. It was trained on the gaps we avoided accounting for. The slice it generates from is real, but partial — and the parts it doesn't generate from are the parts most often left underdesigned. Even within the visual slice, "looks designed" isn't the same as "designed for this." These are the gaps many designers have learned how to fill through deeper systems and infrastructure work, but that work has rarely been appreciated by those who now hype AI as the death of design. Gen AI can be used as a sketch, as long as you know what you're using it as and you understand its limits, costs, and impacts. The risk is letting it convince you the work is accurate, complete, or unbiased. Models only know averages. And no human is average https://www.thestar.com/news/insight/when-u-s-air-force-discovered-the-flaw-of-averages/article e3231734-e5da-5bf5-9496-a34e52d60bd9.html . Design is the edges. It's the human reasoning, strategy, empathy, and collaboration required to think within and beyond our own lived experiences. AI cannot replace that. Implementation In Houde and Hill's framing, implementation is the techniques and components through which a thing performs its function . It's the nuts and bolts that hold the machine together. Implementation is, fundamentally, a question about whether the system holds together. This requires at least some degree of logic and semantics across systems to function. Connecting the pieces together to make things work means there has to be consistency, frameworks, and coherence. And this is where we've seen AI's failures most clearly https://microsoft.github.io/a11y-llm-eval-report/ . AI often outputs something that looks like it works without it actually working. When using AI for code, what we get back usually looks like it probably could be structure. It isn't. In reality, it's a collection of elements arranged in a way that resembles one. Layout. Hierarchy. Familiar components doing familiar things. The moment we start asking basic questions, it falls apart: Why is this here? What happens if this changes? How does this connect to anything else? What is being used to present this? Is it semantically sound, or is it