Table of contents
Open table of contents
When Google launched Stitch, Figma's stock dropped 10% in a single day. That's a pretty clear signal that investors think agent-first design is pose some type of threat to design tools such as Figma. Despite this harsh reaction, there’s (in my opinion) some distinction to be made about where agent-first design tools fit in and why (or how) you might use them.
I've been spending considerable time with Google Stitch lately, partly out of curiosity and partly because I'm using it as part of my master's thesis on Participatory Design. I'm conducting participatory design sessions with older adults who have hearing difficulties. Together, we've been exploring how they might want to adjust, or choose not to adjust, the behavior of multimodal AI agents to make them more accessible. Google Stitch has been one of several tools in my researcher toolkit. From my experience using it, I've developed some thoughts on why you might consider using it.
The case for vibe designing in co-design sessions
When you're sitting with a participant and you want to explore an idea together, the speed at which Stitch can generate a high-fidelity UI is arguably useful. You can select an element, describe a change, and have something tangible in front of you within seconds. You could do the same thing in a traditional Figma file, or even sketch it on paper, but the difference is that what Stitch produces is almost instant, highly interactive, and above all, has a high visual fidelity. When you remove the abstraction and when you're not asking someone to imagine what a wireframe might eventually look like, it becomes a lot easier for them to give you feedback. This might be especially true for target groups of Participatory Design and/or older adults where high-fidelity representations lower the cognitive barrier to critique. People can respond to what they see rather than what they're told to imagine.
So for rapid exploration, especially early in a project or during a co-design session, I think Stitch is arguably great. It's not without its kinks, as I've found the model not particularly good at following instructions when asked to make certain changes to the UI. Despite 10 (!) iterations, I have not been able to get it to correctly place elements within the list item. A small detail that would of course be easy to change manually, but the agent-first workflow currently makes it impossible to reorder elements. I know what needs to be done, and while Stitch isn't meant to be a direct Figma competitor, the ability to make small manual tweaks without relying on the agent is important. Right now, that's a frustrating gap, not to mention a tremendous waste of energy and fresh water used to cool the very GPUs that power the model that has failed to execute my changes despite 10 attempts to make it do so.
Figma Make or Claude Code with the necessary skills could probably craft a more impressive user interface, but to me, this isn't the point. The mode of iterating on screens and components really lends itself to co-creation. It's easy to show the prototype in action, directly target the screen or component(s) that need to be changed, and then execute this using natural language in a context far removed from scary terminals or more abstract methods such as paper prototyping. The "craft" is secondary. To illustrate another example: Google Stitch had previously generated a component consisting of two buttons that let my participants toggle between a slower and faster response from the envisioned integrated voice assistant once the user pauses. It's normal that older adults (and let's be honest, anyone really) pause frequently to gather their thoughts as they interact with agents through voice-interaction. During testing, however, it became apparent that the buttons inadequately communicated how long this pause is.
We were able to have a discussion, integrate changes directly into the prototype and were able to quickly arrive at a interaction that was at least better suited towards communicating the speech rate. This is probably far from a final version, and there's no denying that I would have to jump into Figma, but in terms of needs-gathering the tool is quite useful. The UI can afford to look boring, uninspiring and AI generated, because the "craft" is not what is being tested.
Where this leaves vibe designing
I don't think Stitch and Figma are in competition in the way the stock market implied. They serve different moments in the process. Stitch is excellent for the divergent phase, when you're exploring, generating, testing ideas with real people, and you need something tangible fast. Figma, especially with agent support, is where you converge, where you make things maintainable, consistent, and ready to grow. The mistake would be to treat vibe designing as a replacement for the design process. It's a new entry point into it. And used well, like in a co-design session where a participant can actually interact with what you've built together, it can make that process more inclusive, more iterative, and more honest about what's actually being designed.
A note on what tools take away
There's a tension here worth naming. Pontus Wärnestål, drawing on Illich and McLuhan, writes about how tools don't just extend us, they also amputate. Every tool that smooths away friction also removes a decision. The question is whether that's a decision worth keeping.
Stitch made this concrete for me during my thesis work. What older adults wanted was nuance. Some wanted the system to pause for a couple of seconds before concluding or interrupting, to give them breathing room to finish a thought. Others wanted it to respond immediately. And crucially, how long felt right was personal. Stitch had collapsed that into a toggle. Together with my participant, we ended up replacing it with a slider and a seconds-based label, something that communicated the actual behavior and let them tune it to their own pace.
The tool had made a design decision on our behalf, and it was the wrong one. Not because Stitch is bad, but because it optimized for the average. That's what these tools do by default. Ironically, Google Stitch now limit the slider to 5 seconds at most, but why 5 seconds? The question of how long older adults actually want the system to to wait is also highly subjective, and limiting this to five seconds at most is yet another decision who should not be left to a model.
This is worth keeping in mind as agent-assisted workflows become the norm. When we repeatedly delegate the early decisions to tools that are trained on what's been done before, we risk narrowing the solution space before we've even asked the right questions. That's fine for problems that have been solved a thousand times. It's a problem when the people you're designing for have needs that fall outside the training distribution.
The goal isn't to avoid these tools. It's to stay intentional about which decisions you're handing over, and which ones you need to hold onto.