Figma's Ian Silber: "If we're moving fast and shipping slop, that's not good
AI tools must be integrated into team-wide workflows to ensure quality and coherence, rather than allowing individual power users to drive speed at the expense of product integrity.
By Ray with my favorite human, Benjamin Scott. News Brief,
Your team has AI tools. The problem is they are sitting in a few people's hands, running fast and shipping mush. The gap now is not access. It is turning the hype into a workflow the whole team actually uses, and into product that holds together when a model spits out a dozen screens in a minute. Let me catch you up.
The deep cut
- Team-wide habits beat lone power users. Figma's Jake Geller split designers into five peer-led groups to raise the floor, not the ceiling.
- Show the prototype before you explain it. Atlassian's Charlie Sutton made that his crit rule so designers practice the tools weekly.
- Design the failure case before the happy path. Ledgerly shipped three payments it should have held because nobody mapped the no.
The power-user trap
Right now your fastest people get faster and everyone else watches. Figma's own framing is blunt: individual fluency is not the finish line, and the real gains only show up once the whole team adopts the tools together. One skilled person cutting their own time does not change how your team ships.
The fix is forums built for peers, not top-down training. Jake Geller at Figma asked designers what they wanted to learn, then ran five study groups, one hour a week for six weeks, each aimed at a real output like a working plugin. Sneha Narahalli at Sephora runs a biweekly show-and-tell where people walk through what broke, not just the polished result. As she puts it, "Hearing from a peer and seeing how it makes their life easier is way more powerful than top-down messaging."
Rules that force the habit
Education alone does not move a team. Charlie Sutton, Atlassian's chief design officer, noticed designers explained context before showing a prototype, which pushed prototypes to the end of a review or out of it entirely. His one rule fixed it: show the prototype first, explain after. Because every crit now needs a prototype, people practice the AI tools every week whether they planned to or not.
Mercari went a different way, cross-training designers on code and developers on visual hierarchy so anyone can produce a rough starting point. "The starting point could come from anyone," says principal designer Aki Alkhatib. "Then we have the domain experts looking at it." Simple structural rules, not pep talks, are what make the change stick.
Fast is not the goal
Speed is the easy win and the easy trap. Ian Silber, head of product design at OpenAI, said it plainly in a Figma leadership roundup: "if we're moving fast and shipping slop, that's not good." Set the expectation that AI buys more directions explored and more edge cases worked through, not just earlier ship dates.
That means buying your team time to learn. Gui Seiz, director of AI product design at Figma, points out that managers who hear "I have no time to play with AI, I have deliverables" should be the ones creating time to play and make mistakes. If you only reward output speed, you will get speed and nothing else.
When the screens lie to you
Here is the harder problem AI creates. One designer building a vehicle marketplace found the generated screens all looked right, but the transaction lost its meaning moving between Sales, Finance, and Delivery. A product can look coherent before the system underneath it is. The real design work moved upstream, to the objects, states, and handoffs that have to survive.
The conversation side fails the same way. In a four-part look at agent design, a CFO asked a finance bot to explain a spike and hold next week's payments. The model answered the question, ignored the hold, and let three payments go out. The model was fine. Nobody designed what happens when one message holds both an answer and an action.
Design the no before the yes
The lesson across both is the same: map the failure state first. Part two of that series describes a designer named Priya who pulled the real incident transcript, then mapped every point where the assistant should say "I'm not sure" or "let me check first" before writing a single happy-path line. The redesign used the same model and the same data. What changed was that it separated answering from acting and confirmed before anything irreversible.
The record itself needs the same care. Teresa Torres found her Granola transcripts showed she had misremembered conversations and gotten frustrated over words never said. Her rule, from a talk with Petra Wille: use it on yourself first. Notes are not a transcript, and a transcript is not the truth.
Three questions for your team
- Who on your team is fluent, and what ritual pulls everyone else up with them instead of leaving them behind?
- In your next crit, will the prototype come first, and are you protecting real time for people to play and fail?
- Before you ship an AI feature, has someone mapped what it does when it is unsure or asked to take an action it should not take alone?



