Demos Are Research: What Jordan Singer's Path Teaches Designers
Nov 2026From a GPT-3 Figma plugin to an acquisition to a new kind of role, and my hypothesis about the contract between a button and a model.
Why this is on my mind
Jordan Singer's story is the cleanest example I know of a designer who learned about AI by building small things in public. As a product designer working with models, I wanted to understand what he actually did, not just the legend.
What's true right now
He built tools before it was fashionable. Figma's own writing says that in 2020 Singer tweeted a short video of a plugin he'd made to use GPT-3 to generate design ideas on demand. He went on to found Diagram, which Figma acquired in 2023; Figma described Singer as a long-time community member who had built third-party AI-assisted tools on its platform for years.
The path is self-taught and product-led. A Mercury profile describes him as designer, coder, and founder, and notes Diagram raised a $3 million seed round with investors including Figma Ventures. Dealroom's summary says he taught himself to code and design by reverse-engineering websites and spent four years as a product designer at Cash App.
The role he took is new. After the acquisition, Singer worked on AI at Figma. In an interview at Config reported by the Dive Club newsletter, he called visual search his favorite AI feature that shipped, which began as a mid-project pivot. The same newsletter frames his role as a prototype for an "AI systems designer", someone who works on AI woven through a product so each affordance feeds context to a model underneath, and who prototypes by hacking on top of the Figma codebase. He also stressed that new AI features should feel like they came from the same team as the rest of the product.
I couldn't verify his current role from sources I trust, so I'm keeping this post to what is documented.
What I notice
Two habits stand out: build a small working thing instead of describing it, and show it to people early. Both are cheap now. What's expensive is knowing which demo is worth building.
A contract for one affordance
Illustrative: my own sketch, not a sourced fact.
Take a dismiss chip. A user closes a suggested chip. The contract has to say what that means: not interested, not now, or just in the way. Each reading tells the model something different, and the interface alone cannot tell them apart. Someone has to decide, and write it down. That is the kind of detail that gets decided by accident when nobody owns it, and then shows up as odd product behaviour later.
Three questions per affordance. What does this action tell the model? How strongly should it count? For how long? A chip dismissed once might fade in an hour, while an explicit setting might hold until changed. The answers can be simple, as long as they are chosen on purpose. I would start with defaults that are easy to explain to a user, since a contract I cannot explain is not one I can trust.
My hypothesis
This section is my opinion, not a sourced fact.
Every interface affordance in an AI product has an implicit contract with the model underneath it, and the best designers will specify that contract on purpose.
When a user clicks a button, filters a list, or hovers over an item, that action tells the system something. In a traditional app it triggers a function. In an AI product it can also become context: a signal about what the user wants, which the model uses in its next step. Most teams leave that accidental. A chip a user dismisses might mean "not interested" or "not now." A selection might mean "do this" or "remember this."
The designer's job becomes writing the contract: for each affordance, what does it tell the model, how strongly, and for how long? Get it wrong and the product learns the wrong lessons from perfectly reasonable clicks.
Where I would not trust this
My opinion, based on the tradeoffs above.
Too many contracts is its own cost. If every click needs a written meaning, the design work could grow past what a team can keep up with. I would probably start with the few affordances that most change what the model does next, and leave the rest alone. Starting small keeps the practice honest: a few contracts that are tested are worth more than many that are assumed.
Users may not share my reading. I can write a clean contract, and people may still think the button means something else. That is why the test asks users what they thought each action meant. A contract nobody understands is a spec, not a design. I would treat each mismatch as a bug in the interface wording or the signal, not as a failure of the user to understand.
How I'd test it
Pick one screen in an AI product. List every affordance and write down what context each one currently passes to the model, intentionally or not. Then ask five users what they thought each action meant. The mismatches are your contract bugs.
What would change my mind
If models get good enough at inferring intent from rich context that explicit signaling stops mattering, the contract reduces to "log everything," and design effort shifts elsewhere.
Why the demo habit fits this
My opinion, based on the tradeoffs above.
Contracts are easy to argue about and hard to feel. A small working prototype lets me see what the model does after a click, which a document cannot show. That connects back to Singer's habit of building something small and showing it early. The demo is where a vague idea about signals becomes something a teammate can poke at and push back on.
The expensive part is choosing. Building a demo is cheap now. Knowing which affordance deserves one is not. I would pick the interaction where a wrong lesson would hurt most, prototype that, and let the result decide what gets a written contract. The prototype also gives me something to show the team, which makes the case for writing the contract far easier than arguing it in the abstract.
References
- Figma, AI: the next chapter in design
- Figma, Config 2023: Reimagining where teams design and build together
- Mercury, Jordan Singer: Designer, coder, founder
- Dealroom, Diagram company profile
- Dive Club, Design engineer cowboy
- Dive Club, Introducing the AI systems designer