We need to stop talking about product design in absolutes… there are no rules. Everything is made up. Do what makes sense and feels right.

Don’t shrink the vision to fit the doubt

Design is technical. Always has been.

Introducing the Human Creativity Benchmark. The first eval that scores AI models the way creative experts do.

Taste isn't how something looks. Looks are the shadow taste casts. Rounded corners. Nice typography. The right shade of gray on the right shade of off-white. That's aesthetics. Aesthetics is downstream of taste. Taste is knowing what to build before you build it. It's built on an almost uncomfortable understanding of what the user actually wants, not what they say they want. Steve Jobs didn't sketch the iPod because he loved music players. He sketched it because he understood nobody wanted to manage files. They wanted a thousand songs in their pocket. The device was the answer to an intent, not a spec. Airbnb didn't take off because the design got cleaner. It took off when Brian Chesky flew to New York and photographed hosts' apartments himself, because he understood the real product wasn't the listing. It was trust. Taste led him to the camera before the pixel. Here's what I mean. A recording from @octolane: 1. For a meeting that just ended, the menu shows: Recap. Send follow-up. That's it. Because if the meeting is over, nobody is thinking "how do I join?" They're thinking what did we say, and what do I send? 2. For a meeting that hasn't started, the menu shows: Join Google Meet. Generate prep. Running late. Reschedule. Send pre-meeting note. Different menu. Same button. Because the user's intent is completely different. - Nobody opens a past meeting wanting a Join link. - Nobody opens a future meeting wanting a recap. And yet almost every calendar app shows the same seven options every time, because someone optimized for consistency instead of intent. That's the gap. Taste is building the system that notices: 1. The meeting starts in two minutes and they're still in Slack → they want "Running late." 2. The meeting was 45 minutes ago and nobody showed → they want "Reschedule." 3. The meeting is tomorrow morning → they want a prep note. Because, - Nobody wants to write a meeting note. They want to remember what to bring up. - Nobody wants a "copy link" button. They want to stop being late. - Nobody wants a CRM field. They want to close the deal. The moment a user opens your product and thinks "this is exactly what I was thinking" - that's less about magic and more about the "Taste" compounding over a thousand small decisions about intent. You don't get it from a Dribbble scroll. You get it from sitting with the user. Watching them work. Asking questions that feel invasive. Living inside their frustration for a week. Then removing everything that doesn't serve the goal they came in with. Most teams can't do this. It's slower. It's lonelier. It doesn't fit a sprint. But it's the only way to build something people actually feel. We've spent years obsessing over intent. Every menu. Every empty state. Every micro-moment where a user almost gave up. May 12. The world will know. 20 days from now. 🏎️

The role of design will move from pushing pixels to writing the rules the pixels have to follow. Art direction will eat product design.

Kanye West said this in 2022 on @lexfridman: Lex: "What do you hope your legacy is?" Ye: "To be forgotten. There's ego in memory. Who designed the sidewalk? Who designed the water fountain? Who designed the stop sign? Who designed the stop light? These things are so ubiquitous that the person that designed them is forgotten. If it's a good idea, it's a God idea."

I spent too much time on this: CLARK: My contention is that with Claude’s new design tool, Figma has essentially been rendered obsolete, the canvas-based paradigm is most aptly characterized as a legacy artifact from the era before models could generate production-ready interfaces from inten— WILL: [interrupting] Of course that’s your contention. You’ve never shipped anything and just watched the launch video twice. You just got finished reading some hot take, probably a Twitter thread or whoever’s got a Substack this week, and you’re gonna be convinced Figma’s dead until next month when you actually try to iterate on a flow and realize “regenerate” isn’t the same as “nudge this four pixels.” Then you’re gonna pivot to talking about how the canvas was always just a lossy interface for intent. That’s gonna last until next year when you’re in here regurgitating some take about how design tools are collapsing into a single agentic surface, you know, the post-craft utopia and the disintermediation of taste by foundation models. CLARK: [taken aback] Well as a matter of fact I won’t, because generative design drastically reduces the need for a manual canvas in the first pla— WILL: “Generative design drastically reduces the need for a manual canvas, especially as models get better at reasoning about layout and hierarchy…” You got that from that Figma-is-dead thread, right? The one that went viral last week. Yeah, I read it too. You gonna plagiarize the whole thing for us, or you have any thoughts — of your own — on this? Or is that your thing, you come into a bar, you skim some trending tweets over lunch and you pawn it off as your own idea to impress some founders, embarrass my friend? [Clark is stunned] WILL: See, the sad thing about a guy like you is in about fifty product cycles you’re gonna start doing some thinking on your own and you’re gonna come up with the fact that there are two certainties in building things. One: don’t pick a side in a tool war you’re not actually building in. And two: the people shipping right now are using Claude and Figma and Claude Code before you’ve finished writing your LinkedIn post about which one won. CLARK: Yeah, well I’ll have Claude build my whole product stack, and you’ll still be pushing rectangles around in Figma. WILL: [smiles] Yeah, maybe. But at least I’ll still know how to think when the model’s wrong.

the hard part is finding the right framing at which point the solution is obvious

I think there is 3rd option which tries to balance this, and effectively is the right fit. Right amount of user usage with right amount of design vision. Neither 1 or 2 is correct choice. I’d think everyone in the trifecta is trying to optimize for different things: pm = utility, engineer = feasibility, designer = expression. All of those things alone is not going to result to a great product, but the combination can. But I also think the designers are too insular and by nature have the least defensible position by default. Pm owns the business need, engineering the delivery. Design is there in the middle trying to influence the shape of it. But every now and then a great designer can influence it all, but the influence is earned not inherited.

First thing on the agenda: improve everything

I think we have lost some sense of judgment and moderation when it comes to product building currently. The moment you turn something into a universally celebrated metric, whether that is token burn, prototype count, or percentage of agent-written code, you start losing sight of what actually matters. I have felt the same way for a long time about overusing data and A/B testing to build products. The moment you reduce product quality or productivity to a metric, you stop shipping value and start shipping numbers. A lot of what people are doing with AI makes directional sense. The missing piece is counterbalance: 1. AI should help engineers build better products. Leaderboards and adoption metrics can be useful as directional signals. They do not tell you what is being built, whether it is good, or whether it should exist at all. 2. Users do not care what percentage of your code was written by agents. They care about the outcome. Faster output is useful. Like usually, faster doesn't seem to add to quality, clarity, or stability of products. Power to build should not become an excuse to lower quality bars. 3. LLM-generated prototypes can feel like late-night whiteboarding sessions. They look exciting in the moment and feel productive very quickly. Then a few days later you realize the idea was shallow, distracting, or simply wrong. The same trap shows up in jumping straight to code and solutions more broadly. You may just be building the wrong thing more efficiently. Prototyping has its place. So do clear thinking, good design, and a real understanding of the user’s problem. In terms of activities or momentum, the main quest and the side quest can both feel productive but only one actually moves the mission forward. 4. Adding more to products is still dangerous as ever even if time or effort to add it has gone down. Every addition creates complexity, maintenance cost, and user confusion. New features should be pushed back unless they clearly show it should exist and how it improves the product. 5. Not everything needs to be an agent shaped. A simple scheduled task does not need a full LLM sandbox. Making something agentic because it feels current or impressive does not make it right-sized, correct, or effective. The core ideas are: - even if you can, maybe you should not. - more power we have to build should not reduce our need to think, it should increase it.

maybe you were never meant to be extraordinary. 🧵01/11

further clarification for the angry

some people only think some people do some people think while doing

Ok, hear me out... In StarCraft, players interface has 3 modes: watching the minimap, managing build queues, and controlling units. Why not use this analogy for agentic interfaces? 1) User monitors what's happening (activity, calls, status) 2) User orchestrates the strategy (agents, campaigns, playbooks) 3) User delegates the resources (integrations, libraries, permissions) In Agentic UI, the navigation is built on intent but not features. You don't hunt for "Settings" or "Dashboard." You think "I need to check what's running" or "I need to set up a new campaign" and land exactly where they need to be. Zero friction. w/ @AgenticUi

Linear’s CEO just described the biggest shift in product team structure since Agile. For decades, product work meant: PM defines requirements → designers create specs → engineers translate to code. The middle step, translation, absorbed 70% of the time and created most of the friction. Karri is saying that step is collapsing. AI agents don’t need handoff documents or sprint planning rituals. They need structured context about what matters, what constraints apply, and what success looks like. This inverts the leverage points. The person who captures customer intent clearly now has more impact than the person who translates it into implementation. And the person reviewing agent output becomes the quality bottleneck. Linear built their entire product around this bet: structured entities with clear ownership, context attached to work items, feedback connected directly to issues. It turns out the same system that helps humans coordinate also helps agents know what to do. The teams figuring this out first will have a structural advantage. Everyone else will still be writing Jira tickets that read like riddles.

DESIGNER CAREER ARC