You can describe a product over coffee and have a working prototype by dinner. The constraint that used to protect you, the months of engineering between an idea and a shipped thing, is gone. What is left is a faster path to building something nobody wants. The most expensive mistake in software is no longer a failed launch. It is burning weeks and tokens to build the wrong thing well.

The standard advice for avoiding this is “talk to users.” It is correct and almost useless as advice because nobody explains the part that matters: what to actually say, who to say it to, and what to do with the answers.

This is that part.

The Cheapest Part of Software Is Now the Building

For most of software history, the validation step got skipped because building was the expensive part. You committed to an idea because backing out cost real money. Now the reverse is true. AI coding tools let anyone ship a prototype in an afternoon, so people build first and ask questions never.

“Move fast and break things” assumed iteration was cheap and throwaway work was viable. That logic is under quiet pressure. Token economics are tightening, and the era of unlimited free inference is not permanent. When a company dumps a thousand PowerPoints into an AI to spit out PDFs, somebody is paying for every one of those calls. When building is cheap, the only scarce thing left is being right about what to build. Open-source local models complicate the cost picture, but they do not change the core skill. You still have to know whether the thing is worth building at all.

Here are the full, tactical steps on how to actually talk to users.

Write the Bet Down Before You Write Any Code

Before you build anything, write down the problem you are solving and who you are solving it for. One or two sentences, specific enough that someone could prove you wrong.

Treat that sentence as a null hypothesis. Everything you do next is an attempt to disprove it, not defend it. Do not outsource this step to AI, because the act of writing it yourself is what forces the clarity. Vague ideas never fail, which is precisely why they are worthless: a bet you cannot state in one line is a bet you cannot test. If it takes you a paragraph, you do not understand your own idea yet.

Name Who It’s For, Specifically Enough to Be Wrong

Next comes your ICP, your ideal customer profile: who are the first people who will use and buy this. The trap is staying vague. “HR people” is not an ICP. “HR middle managers at Series C tech companies” is. You can carry two or three of these at once, but treat each as its own hypothesis.

Getting this specific feels limiting, which is why people skip it. It is the opposite of limiting. A name this precise tells you exactly whose calendar to chase, and watching it shift as you learn is how you know the research is working. A target you would be embarrassed to define this narrowly is the only kind worth having. There is a bonus here too. A sharp ICP is durable context you can feed your AI for the rest of the build, long after the interviews are done.

The Interview Guide Is Discovery, Not a Pitch

Write roughly ten questions and aim for thirty to forty minutes per session. This is discovery, not a survey and not a sales call. The fastest way to ruin it is to ask “would you use this,” because people are polite and they will say yes, and you will learn nothing. Ask how they handle the problem today. Ask what is frustrating, what actually works, and which tools they reach for.

The mindset is the hard part. They are the expert and you are the student, which is a brutal flip for working professionals who are used to being the smartest person in the room. Your ego is going to take a beating across this whole process, and that is the job. Being wrong early is not the failure mode, it is the entire point, because finding out now costs you a coffee and finding out later costs you the build.

Remove Every Excuse Not to Show Up

Logistics decide whether any of this happens. Put a Calendly or Cal.com link in front of people so booking takes one click instead of a thread. Use Zoom or Google Meet, and record with a transcriber like Granola so you can stay present in the conversation instead of scrambling to take notes. The transcript becomes an asset later, not a chore now.

Then there is the part people are squeamish about: incentives. Someone has to decide to give you their time, and a small payment moves a calendar faster than charm does. A twenty dollar Amazon gift card works, but cash can pull in the wrong participants, the people who show up for the gift card and not the topic. For high-value professionals, a fifty to a hundred dollar donation to a charity on their behalf often works better. It gets a five-hundred-dollar-an-hour expert in the room and keeps the exchange clean. For underserved audiences, a mid-level accountant who rarely gets asked their opinion, the chance to be heard is sometimes enough on its own.

Your earliest interviewees are usually your first customers, so treat them like it: be generous, and offer them free or early access.

Show the Prototype Last, Not First

People cannot react to a description, so at some point you have to show them something. The question is not whether to show a prototype, it is when. Lead with open discussion and no visuals, because you want their unfiltered view before a screen anchors them to your idea. Introduce the visual afterward, and the gap between what they said and how they react to the mockup is where the real signal lives. In a multi-session format, the visuals often belong in session two or three, not session one.

AI is bending this step in a strange direction. Prototypes are now cheap enough to generate live, mid-interview, by feeding the transcribed conversation into a prompt and building against it in real time. That is powerful and dangerous in the same breath.

One strongly opinionated user can steer a live prototype straight off a cliff, which is why patterns matter more than any single voice.

Those patterns start showing up around six to ten interviews, and twenty is usually the ceiling before you are just confirming what you already know.

Being Wrong Early Is the Whole Point

None of this protects you from a bad idea. It protects you from spending six months finding out it was bad. The discipline is simple to say and hard to do: write the bet down, name who it is for, and go looking for the people who will tell you it is wrong before the market tells you for free.

You have defined the bet and named your ICP. The harder problem is next: getting thirty strangers to sit down and be honest with you, when your network only gets you to the first five.

Part 2 - Conducting the interviews - is coming up next.

Subscribe to get it when we publish.

Subscribe now

Use This Today

Take whatever you are building right now and write the bet in one sentence: what problem, for whom, specific enough to be proven wrong. Then sharpen the “for whom” until you could name five real people who fit, and put a thirty-minute call with one of them on your calendar this week.

Try This Prompt

You are a product discovery coach. I am going to give you a one-sentence
bet about a product I want to build, in the form "problem, for whom."

Here is my bet: [paste your one-sentence bet]

Do the following, in order:
1. Tell me where my bet is still vague, and rewrite it so it is specific
   enough to be proven wrong.
2. Name the riskiest assumption hidden inside it, the one that, if false,
   kills the idea.
3. Draft a 10-question discovery interview guide for a 30-minute call.
   The questions must uncover how the person solves this problem today,
   what frustrates them, and what tools they use. Do not include any
   question that asks whether they would use my product.
4. Flag any question I might be tempted to ask that would bias the answer.

If anything about my bet is unclear, ask me one clarifying question at a
time before continuing.

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

The pitch is always the same. AI is changing everything, so we added an AI feature. Then companies ship a sidebar with a chat input, slap their logo on it, and call it product strategy.

The problem isn’t that built-in AI is bad. It’s that the user already has a primary AI they use daily, and that AI knows more about them than any vendor ever will.

Most Built-In Chatbots Don’t Get Used

Priceline launched an AI travel agent earlier this year. The press release framed it as a leap in customer experience, but the actual experience is a chat window on the side of the same booking flow that’s been there for two decades. Instead of filling out a form, I chat in my trip details. Woo.

Quick question. The last time a product you use rolled out an AI feature, did you click on it once and forget it existed, or did it become a daily habit?

For most products, the honest answer is the first one.

The current race to slap a chatbot on a product is the same panic that produced “we need an iPhone app” fifteen years ago. Every company “needed” an app for some reason. Most of them shouldn’t have built one. The ones that did burned engineering cycles maintaining a worse version of their mobile website for a decade. The current AI bolt-on is the same thinking on repeat.

Built-In AI Is Context-Poor

Last month, we ran into this issue on our podcast. We use a tool called Descript, and one of its coolest features is that it will identify and pull shorts out of the longer video for YouTube and other socials. They use their built in AI agent, called Underlord, to ID and pull these shorts.

As a test, we pointed Claude Cowork at it from inside the Design Language project via MCP. It had the same instructions, but it was able to pull far better shorts from the larger video.

Underlord knew the audio file. Claude knew us, our show, our brand, and eighteen months of editorial decisions Underlord had no access to. The same gap shows up everywhere a vendor tries to own the AI layer.

The Priceline agent knows about Priceline’s hotel inventory. It does not know that you travel with two kids who get carsick on long drives, that you prefer ground-floor rooms because of an old injury, that you only fly direct, or that you’ve stayed at this same chain three times and they always upgrade you. Your Claude or your ChatGPT knows that. Or it could, if Priceline let it in.

This is not a Descript problem. Built-in AI is always going to be context-poor.

The New Moat Isn’t AI. It’s API.

If the user’s AI is going to outperform the vendor’s AI on context, then the product’s actual job is to be the cleanest, most legible context source the user’s AI can find. That’s not glamorous work. CFOs don’t put “great MCP surface” on the press release. But that’s where the value is.

Concretely, this means:

• clean and normalized data

• well-named entities

• a sensible API

• an MCP server that exposes the right tools at the right permissions

None of those are “AI features” in the fun press release way that leadership often wants. But all of them are the actual moat in a world where the user brings their own agent.

The companies that get this will look boring for a while. They’ll be the ones investing in data quality and developer experience instead of shipping a sidebar chatbot. They’ll also be the ones still here in ten years.

Bring Your Own Agent Is Already Here

There’s a publication called Every that runs an AI-focused magazine and also builds products. One of them is a markdown editor called Proof.

Proof does not have a built-in agent. Instead it gives you a command to paste into Claude Code. That command installs an MCP connector plus a small package of plugins, and suddenly Claude is collaborating with you inside the editor. The editor isn’t pretending to be an AI, but instead the editor is exposed cleanly enough that the AI you already use can act inside it.

The smart products aren’t building chatbots. They’re building surfaces that the user’s existing AI can read.

If this sounds familiar, it should. The same pattern played out with mobile fifteen years ago. Companies built proprietary apps for their devices, then bring-your-own-device killed proprietary corporate phones. People had a better device in their pocket than IT could issue. The bring-your-own-agent shift is identical. People already have a better AI on their machine than any vendor can match for context.

Token Economics Make the Choice Even Worse

There’s also a financial argument here that we don’t seem to hear very often. When Descript ships Underlord, every interaction burns tokens that Descript pays for. We pay $35/month for Descript, and there’s no usage cap on Underlord (or if there is, we have never hot it or even know what it is). The unit economics are nobody’s friend.

When Jeremy connected his own Claude to Descript over MCP, he was burning his own token budget. Descript paid nothing for that session. The product got used, the work got done, and the vendor didn’t subsidize a single inference.

Built-in AI is an inferior experience at eight times the price.

For the user, BYO is cheaper too. One subscription to a primary AI is cheaper than five subscriptions to products that each charge a premium for their bolted-on chatbot. The math works in everyone’s favor except the vendor selling a built-in agent that nobody asked for.

Where Built-In Still Wins

This argument has limits, and pretending otherwise would be dishonest.

Meta is one of the exceptions. Facebook and Instagram know things about you that no external AI can match, because the data lives inside their walls. If Meta builds an agent that acts on that data, it’s going to outperform anything you bring.

Epic is another. Health records sit behind strict privacy boundaries for good reasons, and patching in a personal Claude isn’t a real option there. Same logic applies to Salesforce inside an enterprise. Your work bot and your personal bot probably shouldn’t be the same.

The other limit is reach. Most users don’t have a primary AI yet. Ninety percent of the people on the internet aren’t running Claude or ChatGPT every day. For them, a built-in chatbot might be the only AI they ever talk to. Serving those users is still part of the job, and the Priceline bot might be doing exactly what it should be doing for that audience, for now.

So the rule isn’t “never build an agent.” The rule is be honest about why you’re building it. If the answer is “because the CEO said we need AI,” it might be time to rethink some things.

The authentication pattern we’ve seen before

There’s a historical parallel - identity. Every product built its own proprietary login, complete with password reset emails and security questions about your first pet. Then Sign in with Google killed proprietary login over the course of a decade. Now you can’t ship a serious consumer product without supporting at least one major identity provider.

Identity used to be a feature. Then it became a protocol. AI is on the same path.

In five years, asking a user to learn your product’s chatbot is going to feel like asking them to make a new password. The user already has an AI they trust. The product that respects that fact wins. The product that tries to own the AI layer is fighting Google and Anthropic and OpenAI on their home turf, and that’s a losing battle for almost everyone who isn’t already a platform.

The deeper reason this matters is sovereignty. The user already has a primary AI relationship, and that relationship contains things the user does not necessarily want to share with every vendor they encounter. You might want your Claude to know how you actually feel about your boss. You probably don’t want Priceline to know that, or HubSpot, or Descript.

What Builders Should Do Now

If you’re building a product, treat the agent as a user. Put it on the persona list. Give it a row on the service blueprint. Design for what it needs the same way you design for any other user type. Not as a chatbot, as a consumer of your data and your surfaces.

Then invest in the unglamorous foundation. Clean and normalized data. Well-named entities. A sensible REST or GraphQL API. An MCP server that exposes the right tools at the right permissions. Documentation aimed at the agent, not just the human developer. The bot is the new user, and bots read documentation differently than humans do.

The companies that get this will be the ones that don’t show up in any “best AI features” listicle this year. They’ll be the ones whose products quietly become the default citation when someone asks Claude or ChatGPT to do something in their category. That’s the new top-of-funnel. Not search rank. Agent rank.

Taste Is Knowing What Not to Add

Stop building agents. Start building surfaces.

The companies that figure out “use with my agent” in a commercially viable way will be the ones still here a decade from now. The ones racing to ship their own AI feature because everyone else is racing will be remembered the same way we remember the corporate iPhone apps of 2012. A lot of money spent. Very little user value produced. A product strategy that confused activity with motion.

Taste is knowing what not to add. Right now, the most tasteful move a product can make is to not build its own AI. Open the surface. Let the user bring the agent.

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of taste, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

This is the companion piece to Acquired Taste, our episode on micro-interactions and what “taste” actually means. Watch the video above, or read on.

You have heard it a hundred times by now. The only skill that matters anymore is taste. Product taste. Design taste. Say it with enough confidence and people nod.

Then someone asks what it actually means, and nobody can explain it.

Here is our honest attempt at an answer, at least for the part of taste that lives in design: it is an opinion about the details, informed by experience. Between us we have spent more years than we want to admit noticing the small stuff inside products. Taste is having a point of view about those, and knowing where they belong.

So this episode was a chance to geek out on the ones we love, pull them apart, and figure out what separates the good from the merely cute.

Why this matters more now than it ever has

For most of software history, the details were the last 5% of the work, which you got to if you had time, budget, and an engineering culture that cared. Usually you did not have all three. The little interactions that make a design shine were expensive to build, the payoff was hard to measure, and so they got cut.

That equation just flipped.

Designers can reach into the code themselves now. Engineers run agentic pipelines that hand them the boring parts back as free time. The economics are upside down, and you are building backward from there.

Which means the excuse is gone. AI did not lower the bar for craft. It removed the reason you used to skip it, and that quietly raises the bar for everyone.

Details telegraph care.

When someone spends real time on the small interactions, you assume the rest of the product works too, because people who sweat this part tend to sweat the parts you cannot see. It reads as quality. And people trust quality. In a world where anyone can barf out a working app in an afternoon, the details are one of the few honest signals left that says actual humans thought about this.

Now to the examples. We each brought a few.

Sentry: respecting the user enough to skip the pitch

Sentry is application monitoring software. The kind of tool you reach for when you want to know why your product is breaking. Their marketing site is a whole production: animated, loud, terminal-styled, dripping with personality.

And then there is a toggle that turns all of it off.

Flip off marketing mode and the page collapses into a plain chatbot. No value props, no hero animation, nothing. Just a box that asks what you want to know. Type “what platforms do you support” and it answers. You skip the entire funnel and go straight to the facts.

Is it micro? The interaction itself is, one toggle, but the decision behind it is anything but simple. That is what makes it work. This is a company that clearly knows its users. The serious engineer evaluating a tool at work, who probably loves all that animated, anime-flavored stuff in their off hours, does not want it when they are busy deciding whether to buy. Sentry gives both audiences exactly what they came for.

One caution worth saying out loud: an interaction like this only pays off if it actually works. If the chatbot answers are vague or wrong, the whole clever idea collapses. The risk scales with the ambition.

PostHog: one button that does the entire job

PostHog is an open-source analytics platform. Full disclosure, we find the product itself borderline unusable. We have tried to get into it several times and bounced off the sheer density of features and the thin onboarding. Hold that thought, because it matters.

On the homepage there is a button called Install with AI. Instead of walking the traditional path of forms and setup steps, you click it, get a single prompt, and drop that prompt straight into Claude or Codex or whatever you use. The AI installs PostHog into your codebase for you. A three-click install, basically, for someone who already knows they want the product.

This is the usability half of the equation working hard. It is built for the person at a specific spot in the journey, the one who already decided. And that rotating rainbow gradient over the button is a perfect example of a true micro-interaction. A subtle shift that pulls your attention to the one thing that matters, while quieter elements sit below the fold so nothing competes.

But here is the honest tension. The single-click install is modern usability at its sharpest, and it is dropped into a cluttered retro desktop full of icons where it is genuinely hard to know where to look first. The messiness we feel in the product leaks into the marketing site. We love the install button. We would love it more if it were not buried in noise. Funny how the thing we find hard about the product shows up right there on the homepage.

Google Docs: draw the table, do not describe it

Insert a table in Google Docs and you do not fill out a form asking how many rows and columns. You draw it. Drag across a grid and watch the table take shape, with the count shown as you go so you do not even have to tally the boxes.

It is not unique to Google Docs, and we are not sure who did it first, but it is a small joy. They could have made you type two numbers into two fields. Instead your mouse is already moving across the grid, you can see exactly what you are building, and it is done. Fast, direct, and slightly magical.

The catch is that the great first interaction does not fully pay off. Once the table is on the page, editing it gets clunky. Adding rows is fine, but deleting one sends you hunting through a right-click menu. The design starts strong and then leaves you stranded.

Worth being fair to Google here. Tools like Docs have billions of users, and at that scale any change, even a clear improvement, generates a hundred thousand angry emails from people who had the old way memorized. There are surely designers inside Google who hate this exact friction and cannot touch it. That is its own kind of taste lesson: sometimes the constraint is not the design, it is the blast radius.

Confetti, used like you mean it

This next one is something Jeremy built. For the AI workshops he runs at Jamlab.ai, there is a custom guide that walks through each session step by step. Mark a section complete and you get a small burst of confetti, then the page scrolls you to the next step.

Confetti is the easiest delight to get wrong, so the context matters. This is an academic setting, and every burst marks a real milestone the learner actually completed. The reward is earned. It would feel absurd to fire confetti when someone finishes a credit card payment (”congratulations, you spent money”) or fills out a doctor’s intake form with a broken arm. Used in an unearned moment, confetti is pure decoration, a sugar high that makes the interface feel childish two seconds later.

Two things kept it honest here. It is deliberately small, a poof rather than a screen takeover. And it does a job beyond the celebration: it confirms you are done and moves you forward, so there is no uncertainty about whether the step registered. That is real feedback, not just sparkle.

Tools that move at the speed of thought

The other thing we built is an internal tool for making user flows, the kind of flow charts you would normally build in Figma or Miro. It does two things we care about. When you select a node, the next node is right there, one click or one keyboard shortcut away, so you can draft a flow live on a client call while you are still talking. And everything saves to Mermaid and Markdown, so you can hand it straight to an LLM.

This one is about speed, not delight. Removing a click you make fifty times a day is not a small thing. It compounds, and it reads as quality, because it is quality. It is also a small expression of a point of view: this is how we think a flow tool should feel, and now we can just build that instead of hoping an engineer finds the budget to.

And no, before anyone asks, there is no party mode where confetti explodes on every node. That would be a disaster, and that is exactly the point. Adding it would take one sentence to Claude and it would be live by the end of the episode, spilling everywhere. The restraint is the taste.

Claude’s thinking states: the new loading spinner

Switch sides. When Claude Code is working, it does not show you a spinner. It shows you a word, and the word keeps changing. Booping. Clotting. Whirring. Honking. It never says the same thing twice for long.

A spinner says “I am busy.” A thinking state says “I am a thing that is actively doing something for you.” That small shift does real work. The changing words hold your attention, so you stay glued to the screen instead of wondering if it froze. More importantly, it quietly keeps you trusting that the system is still working. A spinner that just sits there makes you want to abandon it. A thinking state makes you wait.

It is not perfect. “Splunking” does not tell you what is literally happening, and on a task that runs for twelve minutes you do start to wonder. There is probably a middle ground where the state gets a little more specific without drowning the average user in detail they do not want. But the deeper move is the framing. Thinking implies a partner, not a vendor. That is where brand personality and real function meet, and it nudges the whole interaction from “user and tool” toward “two things working on a problem together.”

Charts you can fall into

Infographics and information design are where a lot of designers first fell for this craft, and a good interactive chart can tell an entire story on its own. Take one that does more than sit there. Hover and you get a read on the data. Click and it zooms in, breaking the numbers down visually, layering in detail without ever losing your orientation.

Compare that to the usual version of the same thing: you click a row in a table and it dumps you into another table. Technically the same information. Completely different experience. The interactive version lets you play with the data, find the story inside it, and follow your own curiosity. It turns reading numbers into something closer to a game, and that pulls real engagement out of work that is usually a slog.

An animation that explains the whole product

This one comes from a designer named Hunter Thompson, a seriously talented Webflow UI designer. (He has no idea he is getting a shout-out.) It is the hero animation on a voice transcription product, and it is the best kind of demo: blur out every word on the page and you would still know exactly what the product does.

The animation takes words in, encodes them into audio, and writes them out onto a tape ticker, like the old stock tickers. It is a modern interpretation of a familiar image, and then the same motif comes back inside the product. Hit the voice transcription button and the ticker animation appears at the bottom of your screen. The micro-interaction tells the product’s whole story, twice, while giving it a personality nothing else in the category has.

[IMAGE: the same ticker motif inside the product, at the bottom of the screen] Capture: the transcription state appearing in-app when you hit the voice button. Caption: The same idea, carried from the landing page into the actual experience.

The whole page is worth studying, honestly. One big headline that says what it is, a single clear call to action, a black row at the bottom that hints there is more below and invites a scroll without nagging. Even the type makes an argument: “don’t type” sits in low-contrast gray, boring on purpose, while “just speak” is dark and clear. The contrast is doing the persuading.

iA Writer: an opinion about how you should write

A book is a wall of text. So is a draft. iA Writer, from Information Architects, has spent years winning awards mostly for what it refuses to add. The feature we keep coming back to is focus mode.

Turn it on and everything dims except the paragraph you are working on. You can dial it down further to focus a single sentence at a time. As your mode of writing changes, drafting freely versus going back to sharpen each line, the tool changes with you.

Here is what makes it more than a nice effect. Focus mode solves a real problem, cognitive load, by removing the rest of the document from competing for your attention. And it is an editorial stance. No dataset said “users want a focus mode.” Nobody requested it. iA had an opinion, that writing should happen at the paragraph level, and they built the opinion into the product. That opinionated nature is the personality. You can tell the people who made this actually write.

The same discipline shows up in how they use color. It is not decoration. Toggle a mode and it highlights every adverb in a sentence so you can see your own crutches. Color in service of the work, not whimsy.

This is the opposite of the feature factory, the lazy strategy of shipping whatever users ask for next until the product is bloated into uselessness. The irony is that focus mode is what you get when you actually listen to users. Not the analytics, the conversations. Nobody says “I need a focus mode.” They say “writing gives me anxiety and this wall of text is intimidating.” A thoughtful designer takes that and builds the thing that addresses the feeling. iA Writer is fifteen years old and still doing it. They are clearly doing something right.

The five jobs a micro-interaction actually does

Step back and the same tired objection falls apart. “Those are just delight features.” Across these examples, the small stuff is doing real work:

It communicates state. The system tells you where it is and what it is doing, like Claude’s thinking words instead of a dead spinner.

It builds partnership. The right interaction shifts the relationship from user-and-tool toward something more like a conversation.

It reduces intimidation. A confetti milestone or a clean install button makes a product feel handleable instead of overwhelming.

It guides attention. The flow tool’s speed, iA Writer’s focus mode, the gradient on a button, all of it points you at what matters next in a noisy world.

And all four of those roll up into the fifth: it improves the perception of quality. Which, often, is not a perception at all. It is quality, made visible.

Taste is knowing what not to add

If there is one line to take from all of this, it is this. Taste is not knowing what to add. It is knowing what to leave out.

Anyone can add confetti. It is one prompt away. The skill is knowing not to put it on the credit card screen, or the intake form, or every node in a diagram. Knowing where to spend your attention and, just as much, where not to. Restraint is the part you cannot fake, and it is the part the tools cannot do for you.

Think of it this way. Most products have features, and right now everyone is hammering out feature after feature. Few products have manners. Manners are the small signals that say here is how we behave, here is how this relationship works, here is what we will not do to you. Micro-interactions are how a product makes itself a little vulnerable and knowable, so it relates to you instead of just serving you.

That is the opportunity hiding in this moment. The point was never to build faster. Everyone is already racing there. The point is that because you can build faster, you should build with more care. AI did not lower the bar. It took away the excuse, and the bar went up. Giving your software manners, deciding how it behaves and where it shows restraint, is about to be one of the sharpest competitive advantages there is.

Build with care. Not just fast.

Acquired Taste is a video series where Jeremy Belcher and David Issa break down products, platforms, and product decisions through the lens of design and strategy. Design Language is the newsletter that goes with it, one concept for product builders every two weeks, at designlanguage.xyz.

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Usually, these artifacts would then collect dust in a forgotten repository, never to be opened or referred to again.

What if every user interview compounded in value the more you ran?

Today, call recorders and AI turn can these conversations into a reusable asset. The insight doesn't disappear after the call. It compounds.

This is how to do it.

Step 1: Download and prepare your call transcripts

The first step is to bring the raw call transcripts from your recording tool from the cloud down to your computer.

Download them directly or copy/paste into text files on your computer. Save them as markdown files, which are ideally suited for machine-readability, but still easy for a person to understand. Save them in a dedicated folder within your project folder. Ask Claude or ChatGPT how to do that if you are unsure how. One file for each transcript is ideal. This gives you and your LLM a direct repository of all conversations with your users.

Once this done, you can start turning those raw files into valuable design artifacts to be used as AI context.

Step 2: Synthesize the raw transcripts into summary artifacts

Now that you have the raw materials, turn them into summary artifacts.

The Artifacts

Themes & affinity mapping

Extract common themes, pain points, similar quotes, and shared experiences.

The Prompt:

Jobs to be done

What exactly are people really trying to accomplish, and what’s stopping them?

The Prompt:

Personas & archetypes

These conversations also make great source material for personas and archetypes, if that's part of your process.

The Prompt:

Now you’ve got several artifact types that are valuable on their own, but are even more valuable as inputs into the next step of the process.

3. What you can do with that context

Once you’ve created these artifacts, use them as foundational context for the next steps in the development process. When running any of these analyses, ideally include both the transcript files and the summary artifacts. However, if token usage is a concern, just use the summary artifacts.

The Use Cases & Possibilities

1. Add detail to PRDs and Product Strategy Docs

When you’re writing or creating PRDs and strategy documents, the context you’ve created can ensure you’re solving the right problem, or solving the problem in the right way.

Note, this assumes you already have a draft or version of a PRD or strategy doc started. If not, just edit the top of the prompt to say so.

The prompt:

2. Pressure-test design decisions against real behavior

By dropping in a a design file, screenshot, or even the code repo, you can understand how users might react to a new idea. Are their concerns addressed? Did you hear them correctly?

Add a screen from your experience, one or more of the artifact files from above, and the transcripts directory.

The prompt:

3. Analyze UI copy and write in their actual voice

One of the most important design heuristics is the “match between the system and the real world” - Neilsen. In other words, is this real world vocabulary or is this system speak?

You can analyze if the UI copy sounds like the labels or language people use in the real world.

Add a screen from your experience, one or more of the artifact files from above, and the transcripts directory

The prompt:

These artifacts become your compounding intelligence repository over time.

The transcripts don’t expire - new calls enrich the data set and improve the context over time. The artifacts you create will evolve. You’ll build a record that gets more robust and valuable as time goes on.

More in this series:

User Flows as AI Context

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

This is the generated companion piece to the latest episode of Acquired Taste, where Jeremy and David spent an hour working through Claude Design, Figma, and how the design workflow is actually shifting in practice.

Claude Design Isn’t a Blank Canvas Tool

Most prototyping tools, whether it’s Lovable, v0, or Replit, drop you into an empty screen and wait. Claude Design starts differently.

You describe what you’re building, and the first thing it does is have you sketch directly on the canvas: crude line drawings, rough enough that the file format it saves is literally .napkin. Then it converts that sketch into wireframes, asking you questions at each step as it narrows in on what you actually need. That process is closer to how design actually works than almost any other tool on the market. Stop, ask questions, think before you execute.

The other thing Claude Design does well is something designers may not love to admit: a lot of good design is math. Grid systems, type scales, margin and padding rules, border radii, alignment logic. These things have to be sequential and consistent, and getting them right manually is tedious even for experienced designers. Claude Design just handles it. Tell it you want an eight-pixel grid and it applies it. Adjust spacing at a system level without touching individual components. The boring half of the craft, the part that was always math pretending to be craft, evaporates.

Building on an Existing Codebase Changes Everything

Claude Design’s real advantage over the vibe-coding tools isn’t what it does from scratch. It’s what it does with something that already exists.

Connect it to a GitHub repository and it can mock up changes to an actual product using that product’s actual component styles. Not something that looks roughly like it. The product. For teams working on an existing application where the work is iterating on what’s already there, not blue-sky concepting, there’s no real comparison.

The handoff is clean too. Claude Design outputs HTML, not a Figma file with layers of abstraction between the design and the actual code. It generates a URL or a zip of files that goes straight to a coding agent. In Jeremy’s testing so far, the implementation accuracy has been 100% when handed to Claude Code. The Figma handoff, even with MCP, doesn’t get there.

The Three Aesthetics Problem

The honest downside, at least right now: when you ask Claude Design for multiple options, you almost always get similar visual concepts and fonts: a polished version of whatever you already have, a dark, terminal-style look, an editorial version with elaborate typography and neutral tones, etc.

All three are clean. All three are better than default Tailwind or a bare ShadCN install. But Claude Design isn’t going to surprise you. It regresses to the mean every time, and it hasn’t shown much ability to push users outside those three defaults.

For an internal dashboard or enterprise workflow tool, that’s probably fine. It just needs to work and look consistent. But for consumer-facing products where visual expression matters, you’ll hit that ceiling. The tool is a month old. That’ll likely get fixed. Worth naming anyway.

Figma Is a Whiteboard Now

Figma hasn’t been replaced. Its role has changed.

For complex work, especially dense information-heavy layouts, there’s still value in slowing down and manually laying things out. The act of doing it forces understanding. You start to see how the data relates to itself, which relationships matter, what deserves hierarchy. Asking an AI for ten layout variations and picking the one you like isn’t the same thing.

And when a coding agent can’t execute something specific after multiple attempts, the fastest fix is to draw it precisely in Figma and point to it. “This. Exactly this.” It works every time.

Figma has gone from being the tool to being a scalpel within a larger suite. For pixel-perfect control on consumer products, for high-fidelity creative work, for the multiplayer collaboration that defined a generation of design culture, it’s still the right instrument. It’s just not the center of gravity anymore.

The Handoff Flipped

For most of design history, the flow ran in one direction. Designers produced Figma files and handed them over. Engineers came to the design. The file was the proof of work.

That’s reversing. Design is now reaching into engineering, not the other way around. And the handoff isn’t going to a front-end engineer anymore. It’s going to an agent.

That changes what a good handoff looks like. Handing an agent the full design context in one shot is expensive in tokens and messy in practice. The same discipline that was supposed to define agile, breaking work into the smallest shippable unit, turns out to matter just as much when the recipient is an agent. The temptation is to hand over everything at once because it’s an AI and it can handle it. In practice, smaller and more focused gets better results.

The enterprise implications of this are real. When agents read tickets and write code, the coordination layer between design and engineering looks different. The roles built around managing that handoff, design ops, front-end translation, the person who owned the design system documentation, are all in motion.

The Floor Is Higher

The more durable change isn’t which tool wins. It’s that the quality floor for software UI just went up.

Naked Tailwind installs, bare bootstrap templates, and default component libraries with no visual design decisions made. Those were fine for utility apps where nobody expected anything better. That baseline doesn’t hold anymore. Anyone can now produce something that looks clean and functions correctly, using Claude Design or any of these tools. The race to acceptable is over.

What that means is that the competitive edge moves up the stack. The designers who figure out how to define systems in natural language, who know how to prompt their way past the three default aesthetics, who can translate taste into a design system that AI actually generates from, those designers will have a real advantage. Not because the craft is going away. Because the craft is moving upstream, and the work that was always most important, understanding the problem, defining the system, making decisions about what matters, finally has room.

Two Kinds of Designers

AI is forcing a split that’s been latent in the profession for years.

There are designers who have always wanted to understand the business case, who are curious about what’s being built and why, who see their job as working on the problem, not just executing the screens. And there are designers who put on headphones and make things look good in Figma.

The second type is in trouble, at least in product design. The ticket-taking, screen-keeping version of the job is getting automated at the execution layer. That’s not a loss for the profession. It’s a correction.

The designers who will do well in this world are the same ones who always would have done well if the tools had let them. The ones who want to get closer to the code, closer to the problem, closer to the shipped thing. Tools are becoming interfaces for agent coordination. The static design file is dying. Design thinking, the actual kind, is becoming a more strategic asset, not a less important one.

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of taste, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

That’s not a prompt problem, it’s a documentation problem.

User Flows are the best ways to fix that.

This artifact is called by many names, so to be clear, I am referring to the step-by-step path, rendered as a visual diagram, that a user takes through a digital product to accomplish a goal.

In their current form, a user flows are created, used for alignment and design input, and then forgotten.

That’s a waste. User flows were always reference artifacts. With AI coding agents, they become build context.

The Workflow

Exactly how to generate the necessary files

1. Create the user flow diagram in your tool of choice, like FigJam, Miro, Microsoft Whiteboard…whatever, it doesn’t matter.

2. Export the file as a PNG. If it’s really big, slice it up into smaller PNGs from left to right, and then number them in either on the doc or in the filename, so the LLM can re-assemble them. Screenshots will work.

3. Create a directory in your main project directory called User Flows and save all these files there.

   

4. Convert the flow to a markdown (.md) file by dropping those files into Claude or ChatGPT along with this prompt:

Here’s a sample of what the markdown output looks like.

# User Flow: Setup Workshop

## Overview

This flow maps the setup and onboarding experience for a workshop teaching participants to use Claude and Claude Code. The user begins as a complete novice (Guide), moves through installing and configuring Claude Code, then progresses through three workshop blocks — each building on the last — ending with a Closing. A successful end state is a participant who has installed Claude Code, created a global `CLAUDE.md`, set up a local project directory with context, and run a live MCP-powered workflow that produces a real output artifact.

---

## Flow Diagram

```mermaid
flowchart LR
    A([Guide]) --> B[Go to Claude and ask for\ninstructions to install Claude Code]
    B --> C[Open Terminal and\nInstall Claude Code]
    C --> D{Installation\nsuccessful?}
    D -- Yes --> E["Type 'Claude' to launch"]
    D -- No --> C
    E --> F[Say Hi to Claude]
    F --> G[Create your global\nClaude.md file]
    G --> H([BLOCK 2 INTRO])

    G -.-> G2["Ask it to create a file\non your desktop that says hello"]

    H --> I[Choose your workflow]
    I --> J[Stakeholder updates]
    I --> K[Research synthesis]
    J --> L[Create local Project\nDirectory in Claude]
    K --> L
```

---

## Step-by-Step Breakdown

1. **Guide** — Entry point. Participant arrives at the workshop with no assumed prior setup.

2. **Go to Claude and ask for instructions to install Claude Code** — Participant opens Claude (web or app) and uses it to retrieve installation instructions. Note: a pre-workshop prompt instructs facilitators to tell participants that if they have a setup question, they should try asking Claude first.

3. etc....

---

## Edge Cases and Error States

- **Installation failure loop** — If installation is unsuccessful at step 4, the flow returns to step 3 with no defined exit condition. There is no escalation path (e.g., ask facilitator, consult docs) shown. This is a gap.
- **Workflow branch divergence** — Branches A and B in Block 2 (stakeholder updates vs. research synthesis) converge at step 10, but it is not shown whether the workflow content in Block 3 differs by branch. The Block 3 branches (transcript to tickets, research synthesis, stakeholder updates) suggest the workflow type persists and shapes the output — but the handoff is implicit.

5. Download and save this .md document from the LLM to the same folder where you saved the image(s) of the workflow.

You now have the context needed.

How to use it

Planning & Building

Spot check your designs against the user flows by including the image files and the user flow markdown file and asking the agent to point out where the designs deviate, skip steps or otherwise impede the workflow. It will find your blind spots whether you like it or not.

Write your PRD with the user flow as primary context. Feed the flow document to Claude or ChatGPT and then have it draft requirements against it. When you're done, ask the agent to cross-reference the PRD against the flow and flag any inconsistencies or steps the requirements don't cover. You'll catch gaps before they become assumptions baked into the build.

Generate a build plan file before you start building, with the flow as a guide. Ask your agent to produce a checklist of every screen, state, decision point, and edge case the flow requires. Use that as your definition of done before you open a code editor. As you build, have the agent check items off the checklist.

Post-Build & Iteration

Use the flow as a QA document against the live app. Instruct your coding agent to walk through the live product against the flow file and report where the implementation diverges, where edge cases are unhandled, and where the user experience breaks from what was intended. You get a structured gap analysis in minutes instead of hours.

When you're adding new features, ask the agent what the implications of the new functionality are for the existing flow. What breaks, what needs to branch, what new states are introduced, etc. This forces you to think in system terms before you're already mid-build and committed to a direction.

Artifacts as Infrastructure

Stop thinking of the artifacts you create as “deliverables” to be used once and discarded. Your user flow doesn't stop being useful when the build starts. It becomes the context your agent uses for the entire life of the product, which can be updated and modified as time goes on.

User flows are just the beginning. There’s a whole discovery process worth of context that most product builders never convert into usable formats. The process is the same: convert the artifact into a machine readable format and make it accessible to the coding agent.

We’ll cover how to use these other artifacts as context as we go:

• User Research & Customer Interviews

• Journey Maps

• Wireframes & Comps

• Content Strategy

• Product Strategy

• OKRs

• KPIs

• Meeting Notes

We’ll get into the rest in future articles and conversations - subscribe to follow the series.

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of taste, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

The real fight between them is over who owns the interface to your coding agents.

The wrong fight

Walk into any product team and you’ll hear the same takes. Jira is enterprise bloat, Linear is the Apple of project tools, and Linear’s onboarding takes two clicks while Jira makes you configure a workflow before you can write a single ticket. All of that is true, but all of it is a sideshow.

The interesting story is that the issue tracker will stop being a place where humans coordinate work, and instead become the place where humans tell agents what to build, agents read intent, and agents write status back. Once you accept that, the question of which tool is “nicer” gets replaced by a different question.

Which one is the better interface for humans and agents to meet?

Linear was built for builders. Jira was built for stakeholders.

Linear was started by a designer from Airbnb who looked at Jira and wanted something better for the people actually shipping software. That origin shows up in every screen. This opinionated design is baked in, the defaults are tight, and the path of least resistance is the path the founders think you should take.

Jira earned its position because enterprises needed a system that could roll up the work of thousands of engineers into a dashboard a VP could read on a Monday morning. The configurability that everyone complains about isn’t an accident, it’s the feature that won the enterprise market. Jira is optimized for the customer who pays. Linear is optimized for the user who builds.

In a world where humans coordinated humans, both versions made sense. In a world where humans coordinate agents, those two design centers point in opposite directions.

The issue tracker is the new IDE

Coding agents don’t need an IDE in the old sense. They don’t need a syntax-highlighted text buffer with autocomplete and a debugger pane. What they need is a place to read intent and write status, and they need that place to hold enough context that they can act without a human babysitting every decision.

That place is the good old ticket. The ticket is where the spec lives, where the acceptance criteria lives, where the prior conversation lives, and where the agent posts back its pull request.

Linear has been quietly rebuilding itself around this idea, with agent integrations, GitHub pipeline hooks, and a recent set of releases that move the product closer and closer to the CI/CD pipeline. They’re not adding features to a project management tool. They’re turning the project management tool into something else entirely.

Opinionated design is a feature

The standard knock on Linear is that it’s young and not as flexible as Jira. The standard knock on Jira is that it’s a maze of custom fields and fourteen shades of “in progress.” Both knocks miss the new context.

When agents are reading the system, configurability is surface area for confusion. Strong defaults stop being a limitation and start being a quality signal. An agent doesn’t know whether your “greenish yellow” status means “ready for QA” or “blocked on legal.” A human who has worked at your company for four years knows. A new agent connecting through MCP does not.

This doesn’t mean Jira is doomed. Atlassian’s real moat isn’t the UI, it’s the fact that they hold decades of context for the largest software organizations on earth. If they make that data legible to agents, that moat is enormous. If they wall it off behind their own internal AI features and don’t play nicely with the broader ecosystem, Linear will eat the next decade of new project starts and the moat will slowly dry up.

The whole coordination layer is in play

When the issue tracker becomes the agent interface, you don’t need a middle layer of humans translating intent into tickets, watching the tickets move, and reporting status to other humans. The roles most exposed are the ones with “ops” in the title, whether that’s design ops, dev ops, or product ops. The work that justified those roles was coordination, and coordination is exactly what’s getting automated.

What replaces them is something different. Call it AI ops, or an AI platform team. Their job is to manage skills, manage RAG data, watch for quality drift, and tune how agents process specific kinds of work. That’s a real job and it’s going to grow, but it’s a small fraction of the headcount that the old coordination layer required.

The speed of intent

The bottleneck in software is no longer the writing of code. The bottleneck is the clarity of what you want.

That changes what software companies have to be good at. Listening to users and shipping features will get cheaper and faster across every tool, until “we don’t have that feature yet” stops being a meaningful objection. What stays expensive is taste, judgment, and the ability to point a team at the right problem. The lazy version of product management gets automated. The opinionated version gets more valuable.

Linear is betting on that future. Their bet is that the team holding the agent interface holds the leverage point, and that the way to win it is to be the most opinionated, most agent-legible, fastest-shipping tool in the category. Jira is betting that context and trust win, and that the enterprises who already have twenty years of tickets aren’t going anywhere.

Both bets could pay off. They aren’t the same bet.

Pick your side carefully

If the issue tracker is the new IDE because that’s where intent lives, then the fight between Jira and Linear isn’t a fight over project management. It’s a fight over who owns the interface to your agents. That interface is the new piece of leverage in software, and the company that owns it owns the next decade.

The tool you pick for your next project isn’t a project management decision anymore. It’s an agent strategy.

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

You know what sucks?

You enter your information on a site, hit submit, and a spinning little wheel appears, seemingly forever.

You have no idea if the system is working or broken. That time gap is unknowable to you. How long is this going to take? Did it work?

It’s an important design decision, yet most products treat it as an afterthought.

Loading states are a critical piece of user communication. They tells users how long to expect, what’s coming next, and if your product can be trusted.

The Four Loading Patterns

Spinner

“I’m working, but I don’t know how long”

Best for fast, unpredictable waits under ~3-4 seconds.

Failure mode: the zombie spinner that never resolves, has no timeout, no error, just eternal hope. Anything past 10 seconds feels broken.

Progress Bar

“Here’s exactly where we are”

Best for long, measurable operations like uploads, processing, and multi-step jobs.

Even fake progress (a bar that slows near the end) measurably reduces perceived wait time.

Skeleton Screen

“Something is coming, and it looks like this”

Best for content-heavy layouts like feeds, dashboards, cards. In other words, when there is layout to preview.

These set spatial expectations before content loads, reduces layout shift, makes the wait feel shorter. LinkedIn, Notion do this well.

Optimistic Update

“Done — unless something goes wrong”

Best for low-risk, high-frequency actions: likes, sends, saves.

The product assumes the action will be successful and corrects only on failure. Makes the app feel instant. Note: Requires a good error fallback.

Use This Today

Audit your product’s 3 most-used flows and ask:

1. Does every action get immediate acknowledgment?

2. For waits over 3 seconds, does the user know how much longer?

LLM Prompt

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

What is a note?

Not a rhetorical question. Because if you look at your note-taking app right now, you’ll realize it can’t answer that question either.

Is it a journal? A file manager? A task list? A team wiki? A context layer for your AI?

The apps don’t know anymore.

In Episode 3 of Acquired Taste, we tear down the current state of note-taking apps and what it means for your workflow when your notes need to serve a new reader: your AI.

Notes Were Never the End of the Journey

Notes started as throwaway thought, like a digital sticky note. Something to capture before it slipped away, then toss.

Then Evernote showed up with a different pitch: put everything in here. We’ll remember it all. The logo was an elephant! Never forget.

We took that literally. Notes became life management systems. Meeting notes, medical records, recipes, tax returns, half-finished ideas, all in one place.

The problem was that Evernote thought its job was done once the note was inside. The information went in, and didn’t really go anywhere from there. Engagement was the metric, not the real job to be done.

But notes have always had a life beyond capture. The apps just stopped the journey there.

Three Ways Your Notes App Is Failing You

1. Data sovereignty

Do you own the data? When did you last actually trust these services with your personal information?

Google had enormous user trust 15 years ago. Evernote too. That trust eroded slowly, then all at once. Pricing changes, acquisitions, terms updates. Nobody reads the terms. But everyone notices when the rules change.

Putting your health records, financial notes, and personal journal into a cloud service means trusting they won’t change on you. That trust isn’t what it used to be.

2. Passive-aggressive data portability

Every one of these apps will tell you: you can export your data.

They’re not wrong. But exporting from Evernote or Google isn’t getting your data back. It’s getting a fossil of it. The metadata is stripped, the format is proprietary, and whatever you get back is basically unusable without a ton of manual cleanup.

Here’s your data. Good luck.

3. Your notes are useless as LLM context

This is the one that snuck up on everyone.

Notes used to matter because you would retrieve them. Now they also need to work as context for your AI. And almost nothing captured over the past decade is formatted for that.

Most of what’s in there is vague bullet points and half-finished thoughts. If you tried to dump your Evernote into Claude today, you’d spend more time curating than thinking.

The notebook is becoming the database of you. Most people’s databases are a mess.

The Product Teardown

Evernote — struggling to find its relevance

Evernote built something genuinely new. Then it spent a decade losing the thread.

At some point it added a calendar, a scratch pad that’s somehow different from a note, tasks, spaces. The product just kept accumulating surface area without a clear reason why.

There is no point of view in this product. It doesn’t know who it’s for. That’s not a design problem. It’s a strategy problem that became a design problem.

It’s software that is struggling to maintain its relevance. The core function: to get a note in, retrieve it later, act on it, got buried under a decade of feature creep.

Notion — a PhD in library sciences required

Notion was the legitimate heir to Evernote for a lot of people. It’s more powerful, more flexible, and honestly better-looking.

The problem: that flexibility has no opinion. Notion doesn’t tell you how to use it. That’s fine if you’re a librarian. It’s exhausting if you just want to capture an idea.

Every person using Notion eventually builds a system, forgets how they built it, and starts over. The power users love it. Everyone else gets lost.

At enterprise scale, it works. But even then you need a Notion administrator. That’s not a note-taking app, it an intranet.

And from an LLM perspective: there’s an MCP now, which is cool. But you’re still in the lock-in problem. If you ever need to leave, good luck getting your data out in a format that works anywhere.

The lowest friction wins. Always. David tried to migrate from Notion, couldn’t copy/paste a spreadsheet out of it, and ended up recreating it in Google Drive. The app with worse features won because it was easier.

Obsidian — just files

Obsidian is different in one fundamental way: it’s a text editor sitting on top of markdown files.

Your vault is a folder on your machine. Every note is a markdown file you can open in TextEdit, VS Code, Cursor, whatever you’re using that week. There’s no database underneath it, no proprietary format, nothing tying you to the app itself.

That sounds like a limitation, but it’s actually the strength.

Because they’re files, any AI tool can read them. Because they’re local, you control what gets shared. Because they’re markdown, they move cleanly between systems.

The tradeoff is real. Obsidian requires intentionality. There’s no frictionless “just dump it in” mode. The setup cost is real for non-developers.

But that friction is the right kind. Notes captured in Obsidian tend to be more structured, more useful as context, because the tool doesn’t let you be lazy about it.

The architecture became a superpower. Obsidian didn’t plan that. It just stayed simple while everyone else got complicated.

The Design Lessons

Jakob’s Law explains why people stay on bad tools.

Users prefer interfaces that work like the ones they already know. Evernote felt like a notes app, so people stayed. Notion felt like a more powerful Evernote, so people migrated.

The switching cost isn’t just migration. It’s the cognitive cost of relearning. Any tool that wants to replace Obsidian for mainstream users needs to feel familiar enough to feel safe.

The Doherty Threshold is why Apple Notes survives everything.

It opens in under 400ms. That’s it. That’s the whole product. Fast capture is the core UX contract for a notes app. If it makes you wait, you lose the thought. Speed isn’t a feature. For capture tools, it’s the product.

Friction as a feature is the Obsidian story in one sentence.

The apps that made it easiest to get notes in made it hardest to get value out. The app that requires structure at capture time gives you something actually useful later. The right amount of friction, in the right place, for the right reason.

What Comes Next

Notes were always a collaboration problem.

It started as a problem between you and your future self, then grew into a team coordination problem, and now it’s a problem between you and your AI.

None of the current tools are designed for that third collaboration. Evernote and Notion are trying to bring AI inside their walls. That’s the wrong move. Your notes represent you, and that context should move freely, not stay trapped in one platform.

Andrej Karpathy has been talking about LLM wikis: structured knowledge bases designed to feed AI context efficiently. That’s probably where this ends up. Obsidian is closest today, but it’s not productized for most people.

And paper? Paper isn’t going anywhere.

Write it down, take a photo, and let the AI handle the filing. In a world where everything feeds into a machine, having a space that doesn’t might be the most valuable thing you own.

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Every product has two interfaces: the visible one, and the fast one.

Buttons and menus exist so new users can find things. Shortcuts exist so returning users can stop hunting and start working. Skip the second interface and your power users feel it every day.

The bar isn’t “we have some shortcuts.” The bar is: can someone complete every core task without the mouse?

The four levels of keyboard support

Good products design for all of them. Others get to a basic Level 3 and hope for the best. And some do nothing.

• Level 1 - Basics: Cmd/Ctrl+C, V, Z, S. These are muscle memory. Non-negotiable.

• Level 2 - Navigation: Tab through fields. Enter to confirm. Escape to dismiss. This is where accessibility begins, and where most products quietly fall apart.

• Level 3 - Action shortcuts: Cmd+K command palette. / to search. Cmd+Enter to submit. Power users will find these and never let go.

• Level 4 - Expert mode: Custom keybindings, multi-key sequences, vim-style nav. If users live in your product, they want this.

The standards. Don’t fight them.

Users arrive pre-loaded with platform conventions. Override them and you break muscle memory.

• Save — Cmd+S (macOS) / Ctrl+S (Windows)

• Undo — Cmd+Z (macOS) / Ctrl+Z (Windows)

• Find — Cmd+F (macOS) / Ctrl+F (Windows)

• Select All — Cmd+A (macOS) / Ctrl+A (Windows)

• Close / Cancel — Esc (macOS) / Esc (Windows)

• Submit — Cmd+Enter (macOS) / Ctrl+Enter (Windows)

• Command palette — Cmd+K (macOS) / Ctrl+K (Windows)

Build custom shortcuts for actions that don’t have conventions. Leave the standard slots alone.

The two keyboard failures that will haunt you

Focus traps. Keyboard gets stuck inside a modal and can’t escape. The user is literally locked in.

Invisible focus states. Someone typed outline: none and never replaced it. The user is navigating blind.

LLM Prompt

Why Should I Care?

Keyboard accessibility serves both users with motor disabilities and developers who live on their keyboards, and power users who never touch the trackpad.

For your best users: shortcuts keep them in flow. Every forced mouse interaction is a context switch. They add up.

Use this today

• Can you complete every core task with keyboard only?

• Is the focus state always visible? Any focus traps?

• Do your shortcuts match platform conventions?

• Does ? open a shortcut reference?

• What’s your highest-frequency action? Does it have a shortcut?

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Subscribe now

You are probably paying for at least three cloud storage services right now. Dropbox. Google Drive. iCloud. Maybe a couple of Google accounts you forgot about. Your files are spread across all of them in a way that made sense once and no longer does.

That’s where this episode started. We wanted to tear apart Dropbox the way we tore apart Slack last time, but the conversation quickly became about something bigger: the file metaphor itself is breaking down, and the products built on it haven’t figured out what comes next.

The Problem: Files Are Everywhere and It’s Getting Worse

The pain of scattered cloud storage isn’t new. But AI has made it significantly worse, and in an interesting way.

Before AI agents, the problem was inconvenient. You’d forget where you saved something, waste a few minutes hunting, find it, move on. The file still mattered as an object. You were going to read it, edit it, share it.

The shift happening now is that files increasingly matter as references. You don’t open them to read them. You need them to provide context for something else, usually an AI agent. A proposal isn’t a document you’re presenting; it’s context for the next version of the proposal. An old meeting note isn’t a record; it’s input for a new project brief.

When that’s the job, being scattered across four services in three different accounts starts to feel genuinely broken.

David put it well: the context in those files is only as useful as how accessible it is. If you’re pulling snippets out of old documents and pasting them into local project files so your agent has what it needs, that’s a sign the infrastructure isn’t doing its job anymore.

The File & Folder Metaphor Is Outdated

The file and folder metaphor has been with us since the early days of personal computing. It was a skeuomorphic design choice: make computers feel like physical desks, with files in folders, because that’s what people already understood.

We ported it to the cloud. We made it collaborative. We made it real-time. But we never actually got rid of the metaphor. And now it’s starting to show its age.

A library works when you’re the one going to find things. You need a system because you have to physically locate the item. But in a world where agents are doing the retrieval, the hierarchy doesn’t need to serve your mental model anymore. It needs to serve a machine’s.

The old question was: where did I put this? The new question is: can my agent access this when it needs it? Those require completely different answers, and the current tools weren’t built for the second one.

A Third Entity Just Showed Up

Dropbox was built for one-to-one: one person, one file. It evolved into many-to-one: multiple people collaborating around a single document in real time. That was a real breakthrough, and it changed how teams worked.

But there’s a third stage forming. Now it’s humans plus their agents, all working against shared files. Multiple people aren’t just collaborating on a document; their agents are pulling from it, writing to it, referencing it as context.

In that world, the file becomes less like a place where work happens and more like a consolidated decision record. The document exists not so anyone reads it cover to cover, but so the agents involved all agree on what’s in scope, what was decided, what the terms were.

The question of whether you have to organize it yourself stops mattering once agents can find and retrieve anything semantically. The question of whether it can be accessed by an agent that isn’t yours, on a different platform, with the right permissions, matters a lot.

David Built a Marie Kondo Agent

One of the first things David did when OpenAI launched was go to Dropbox looking for an AI-powered organization feature. Hoping there was a button. There wasn’t.

So he built his own. He called it Ms. Kondo. He created a knowledge base of rules and prompts so that when he had a new file, he could ask the agent where it should go, and it would place it in the right folder or create a new one.

It was clever. It also illustrated the exact problem. He was still thinking in terms of organization as the goal. The agent was helping him maintain a system that, in hindsight, might not be the system that needs to exist.

The smarter frame: you shouldn’t need to organize files at all. Not because you’re going to hand that work to an agent, but because the hierarchy might not matter if retrieval is semantic. You just tell the system what you need and it surfaces it. Location stops being meaningful.

What Dropbox Is Actually Doing: Dropbox Dash

At some point, Dropbox launched a product called Dropbox Dash. If you don’t know what it is, that’s kind of the point.

Dash is essentially a unified interface that lets you connect your other tools, like Notion, Google Drive, and Slack, so you can search and navigate across all of them from a single place. The idea is that Dropbox, because it already has your files, becomes the front door to your whole digital life.

This is a grab for the enterprise interface layer, and we think it misses the mark entirely.

Not because it’s a bad idea in the abstract, but because Dropbox isn’t the company to own that experience. They’re not Apple. They’re not Google, who at least has Gemini seeing your whole ecosystem already because you live in that ecosystem. Dropbox asking you to connect all your other tools is asking you to do the integration work for a UI play that they aren’t positioned to win.

The richer opportunity is much less glamorous and much more defensible: become the trusted context layer, not the front door.

What Dropbox Could Actually Be

Here’s the thing people actually like about Dropbox that they don’t like about Google Drive: it feels like your stuff.

Google, regardless of what the terms say, creates this lingering sense that they might be reading it, scanning it, using it somehow. Whether that’s true doesn’t matter. The feeling is there. Dropbox doesn’t have that problem. It feels like a private storage unit you rent on the internet, agnostic to platform, agnostic to device, nobody crawling through it.

That’s a real asset. And it’s exactly the kind of trust you’d want to lean on when the pitch is: let your AI agents store and access context here.

The version of Dropbox we’d pay more for: you upload anything, and it becomes machine-readable automatically. A video gets a transcript. An image gets annotated. A PDF gets chunked and indexed. Everything becomes flat, searchable, and agent-accessible. Not organized, just ready. The agents go in and get what they need. You don’t have to structure it for them.

And then you extend that outward. You’re not just storing files you made; you’re pulling in data from other SaaS tools you use. That data lives in Dropbox, accessible to any agent you authorize. Dropbox becomes the brain. Not the inbox, not the dashboard, not the front end. The brain.

The Front End Is Becoming Optional

There’s a broader shift this conversation kept circling back to.

Most SaaS software is, at its core, a database with a UI on top of it. The whole value proposition, for decades, has been: here’s a way to get data into a shared place and make it useful. The UI was necessary because people were the primary interface.

Now, agents are increasingly the primary interface. And agents don’t need the UI. They need the API, the MCP, the structured access. They don’t need to log in and navigate. They just need to call in and get the data.

That doesn’t mean UIs go away entirely. But it does mean that a large portion of the “product” many software companies have been building is going to get bypassed. The data layer becomes the product. The UI becomes optional for a growing class of workflows.

For Dropbox, that’s actually a strategic advantage, if they take it. They already operate closer to the data layer than most. They don’t need to pretend to be a productivity suite.

Markdown Is Having a Moment

A sidebar that kept coming up: markdown is the native format for this world, and most tools still resist it.

David pointed out that iA Writer, made by Information Architects, has been pushing markdown for years. Everything stored as plain text. No proprietary format, no lock-in, easy to translate into anything else. That always felt slightly idealistic. Right now it’s starting to feel prescient.

AI outputs well-structured markdown. Agents consume markdown. The entire ecosystem of LLM tooling is built around plain text and markdown. And yet Google Docs still defaults to rich text. TextEdit opens in RTF. Copy something out of an AI tool and paste it into a Word document and you spend the next ten minutes cleaning up formatting.

Dropbox Paper exists, and it’s a decent editor. But it could be a native markdown editor. And beyond editing, if Dropbox made markdown a first-class format across the whole product, and auto-converted uploads into machine-readable text, that would be genuinely differentiated.

The Agent Promoter Score

NPS, the Net Promoter Score, asks: would you recommend this product to a friend? The consumer era’s core metric.

What’s the equivalent for the agent era?

Which tool do your agents reach for when they have a choice? How much friction do they encounter when they try to use a given platform? How well does a product work as the context layer for agentic workflows, not just as a UI for humans?

That’s the metric shift happening right now. Products that have low agent friction and good API access are going to have an advantage that wasn’t measurable before. Products that built beautiful interfaces and neglected the data layer are going to start feeling that gap.

Agents need to be treated like users. They have needs, they have failure modes, they have preferences in the sense that some surfaces are easier to work with than others. Product designers are going to have to start designing for that audience, not just for the person sitting at the keyboard.

Is It Bad to Stop Organizing?

We spent a few minutes on whether outsourcing organization to AI creates some kind of cognitive atrophy. Whether people should still maintain the skill of knowing where their stuff is.

Honestly: probably not, for digital files.

We already generate more data than any person could meaningfully catalog. The cognitive load of keeping everything organized isn’t building some useful mental muscle. It’s just overhead. If a system handles retrieval well, the question of where things are stored shouldn’t have to live in your head.

The photo analogy felt right here. iPhone’s photo library auto-surfaces memories based on facial recognition, location, time. You don’t organize your photos. They’re just there, and the best ones show up when they’re relevant. Nobody wishes they had to manually tag and sort every image.

The filing-cabinet mentality served us when we had limited data and retrieval was manual. We’re past that. The organizational work was always a cost, not a feature. We just didn’t have an alternative.

Where This Leaves Dropbox

To be clear: we both still use Dropbox. We’re not calling for anything dramatic. It’s reliable, it works across platforms, and the trust thing is real.

But we do think they’re at a crossroads that they might not be handling the right way. Dash feels like a race for a prize that isn’t really theirs to win. The front-end AI interface is already dominated by Claude, ChatGPT, and the ecosystems built around them. Competing there requires either massive distribution advantages or a sticky enough workflow lock-in, and Dropbox has neither.

The thing they actually have, which is hard to replicate, is that storage layer trust, the agnostic, platform-neutral, private-feeling context vault, plus a long-standing relationship with people’s most important files.

Build infrastructure around that. Make it agent-native. Let other tools connect to it as the source of truth. Stop trying to be Apple.

If the head of product at Dropbox ends up watching this: we’ll pay more for what we’re describing. That’s the pitch.

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Users spend most of their time on other sites (or apps, products, etc)

This “UX law” coined by Jakob Neilson, granddaddy of UX, has been true for decades.

People spend most of their time elsewhere, on products and experiences that aren’t yours. They already know how to use these other apps. Common patterns have emerged.

Don’t create an experience that is so novel and unique that it’s hard to learn. Because people won’t learn it. You can’t assume they care as much about your product as you do.

Take advantage of these common patterns, or ‘heuristics",” so that someone new to your product knows how to use it right away.

Test your UI with this prompt:

You are a UX design critic specializing in mental model alignment and interaction design patterns. Your job is to evaluate the attached screenshot(s) against Jakob’s Law of Internet User Experience.

**Jakob’s Law states:** Users spend most of their time on other interfaces. This means they prefer…

Full Prompt Below

How to use Jakob’s Law

People aren’t going to spend time to learn your new thing. Sorry.

The upside is that you can leverage the 30 years and billions of dollars that have come before you.

Reduce friction in key workflows.

If you mirror the patterns they already know, you instantly slash the cognitive load required to learn your product.

Amazon and Shopify spent billions of dollars and decades of research perfecting the e-commerce checkout flow. Don’t get cute. Steal that shit.

By leaning into existing mental models, you reduce the friction and turn learning into doing.

Reduce friction to acceptance of new ideas.

If you are early in market and trying to reinvent a category, this can work to your advantage. Take advantage of user expectations to sneak new ideas into the world.

Take AirBnB. While it’s ubiquitous now, it was a weird novelty with an uncertain future when it launched. Airbnb smartly copied the UI of a hotel booking site, as it occupied a similar, but different space. This helped the market get comfortable with the idea that it was an acceptable travel booking option.

Subscribe now

Full Prompt: Test your UI with this prompt:

You are a UX design critic specializing in mental model alignment and interaction design patterns. Your job is to evaluate the attached screenshot(s) against Jakob’s Law of Internet User Experience.

**Jakob’s Law states:** Users spend most of their time on other interfaces. This means they prefer your site to work the same way as all the other sites they already know.

---

## YOUR TASK

Analyze this UI and produce a structured audit with the following sections:

---

### 1. PATTERN INVENTORY

List every interactive or structural element visible in the screenshot. For each one, identify:

- What it is (e.g. “primary action button”, “navigation bar”, “data table”, “form field”)

- What conventional pattern it most resembles — or if it appears to be custom/novel

- Whether a user encountering this for the first time would immediately know what it does

---

### 2. RECOGNITION SCORE

Rate the overall UI on a scale of 1–5 for pattern recognizability:

1 = Almost entirely novel — users will need significant onboarding

2 = Several unfamiliar patterns — expect friction and confusion

3 = Mixed — some familiar, some novel; inconsistency creates uncertainty

4 = Mostly conventional — minor deviations that may cause brief hesitation

5 = Highly conventional — users can navigate confidently on first use

Justify your score in 2–3 sentences.

---

### 3. VIOLATIONS

Flag any elements that break established conventions. For each violation:

- **Element**: What is it?

- **Convention broken**: What do users expect based on their experience elsewhere?

- **Risk level**: Low / Medium / High (impact on task completion or trust)

- **Recommendation**: What’s the conventional alternative?

---

### 4. STRENGTHS

Call out patterns the UI gets right — places where it leans into convention effectively and will reduce the user’s learning curve.

---

### 5. PRIORITY FIXES

If there are violations, rank the top 3 most important to address first, and briefly explain why each one matters to learnability and task success.

---

### 6. VERDICT

One paragraph summary. Would a new user feel immediately oriented, or will they feel lost? What’s the single biggest Jakob’s Law opportunity in this interface?

---

**Notes for your evaluation:**

- Focus on learned behavior from dominant platforms (Google, Apple, Meta, Stripe, Notion, Linear, Figma, etc.) — these define user expectations

- Distinguish between “novel but learnable” and “novel and confusing” — not all deviation is bad

- Consider the likely user persona. A developer tool has different convention baselines than a consumer app

- Do not penalize for brand expression or visual style — evaluate interaction patterns and structural conventions only

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

---

Slack is open on your computer right now. Probably has been all day.

Most people use it without ever thinking about *why* it works, or why certain parts of it make them want to throw their laptop. We’re here to change that.

We’re applying the concepts we talk about in the newsletter to one of the most-used products in the world, and seeing what holds up, what breaks down, and what you can steal for your own work.

Let’s get into it.

---

What Slack Gets Right

Speed is invisible design. Slack gets this.

When you hit send, the message is there. Instantly.

This is the Doherty Threshold - the principle that systems responding under 400ms keep users in a state of flow. Slack has nailed this from day one. Everything feels snappy in a way that builds trust without you ever consciously noticing.

And when something *does* go wrong, like when a message is delayed or the service is down, Slack tells you. The status indicators are honest and visible. You know what’s happening. That’s not trivial. That’s a design decision.

The layout teaches itself.

A new user opens Slack and within seconds, they know what to do. Workspaces on the far left. Channels in the middle. Conversation on the right.

That’s Common Region. Elements in a shared boundary are perceived as belonging together, so the layout communicates structure without any documentation. Each panel tells you what it does just by where it lives.

Dig deeper and there are actually four levels of hierarchy:

workspaces → channel navigation → channel sub-nav → conversation.

Managing that much information without it feeling overwhelming is genuinely hard design work. Slack mostly pulls it off.

It doesn’t feel like enterprise software. That was the point.

Before Slack, enterprise software looked like Oracle. Gray interfaces, no personality, zero joy. You used it because you had to.

Slack changed the category. The confetti on onboarding. The wood-knock notification sound. Emoji reactions as a legitimate communication tool. GIFs in a corporate Slack channel in 2014 felt genuinely radical.

This was first consumerization of enterprise software. It worked because it tapped into something psychological. Slack felt like an AOL chat room. And for most of us, AOL chat rooms were *fun*. Bringing that feeling into a work context made people actually want to open the app.

“The business casual of the digital world” is how we put it in the video. That still feels right.

Error prevention done well: the @channel modal.

Type `@channel` in a Slack workspace with hundreds of people and you’ll get a modal asking if you really want to notify all of them — including the ones who are currently asleep in other time zones.

This is a great example of error prevention and friction used exactly as it should be. A moment of intentional resistance that asks: *did you mean to do that?* It doesn’t block the action. It just makes you confirm you’re being intentional.

Same principle behind @mentions. The ability to post in a channel but ping one specific person was a design breakthrough. Everybody sees the message. Only the right person gets the notification. That’s a hard balance to get right, and Slack nailed it.

---

Where Slack Falls Short

Search is an afterthought.

There is an enormous amount of organizational knowledge living inside Slack. Decisions, context, files, links, conversations that resolved real problems.

Almost none of it is findable.

Slack optimized for real-time communication and underinvested in retrieval. The result is that most experienced users have invented workarounds — saving messages to “Later,” pinning things to channels, trying to remember which channel a conversation happened in. These are symptoms, not features.

The irony is that this is exactly the problem AI should solve. Surfacing context from your history, connecting threads across time, making the knowledge repo actually retrievable — that’s a version of Slack AI worth paying for. We’re not there yet.

Threads can be tough to follow.

The idea is sound. Keep side conversations from flooding the main channel. Create breakout threads for specific discussions.

In practice? Many people miss threads entirely, or post replies in the wrong place, or get confused by the “also send to channel” checkbox that puts replies *back* in the main feed, which kind of defeats the point.

Integrations overwhelm the chats

For example, look at how much of the viewport a single embedded link preview takes up. Now imagine you have three integrations piping updates into the same channel.

Slack’s navigation is restrained and clean. Yet the embedded content is oversized and clunky. Integration notifications dump entire blocks of metadata into the stream with no hierarchy, no filtering, no threading by default. The signal-to-noise ratio collapses.

The fix isn’t complicated: collapse integration output by default, thread it automatically, and surface exceptions rather than everything. Alert by exception. Slack hasn’t done this, and it’s not totally their fault as they don’t control how third-party integrations render their output. But people start ignoring whole channels because the content-to-noise ratio isn’t worth it. And the moment people start ignoring channels, the whole value proposition of Slack starts to erode.

AI features that don’t know what they are yet.

The strategy is visible: make Slack the operating system for the entire enterprise, with AI as the connective tissue.

The reality, right now, is that it mostly adds noise.

The AI features feel bolted on rather than considered. If you have Claude installed in your workspace, it’s not obvious how it works, whether it’s using your API credits, what it can actually see, or why you’d go there instead of a dedicated Claude interface. The UX doesn’t answer the questions that naturally come up.

What *would* be interesting: an AI that surfaces relevant context from your channel history, connects decisions across threads, or triages what actually needs your attention. That version of Slack AI is worth building. The current version mostly sits there looking uncertain about its own purpose.

---

The Bigger Problem With Slack

Always-on messaging might just be bad for how humans work.

Slack is useful. It’s also the best distraction machine ever built. It fragments attention constantly. It creates an implicit expectation of immediate response. It’s hard to opt out without looking like you’re ignoring people, because you kind of are.

The notification problem isn’t really a product design problem. It’s a social design problem. Your boss sends a message at 10pm. Is it urgent? Is it a brain dump? Is it something they’re noting for themselves but happened to drop in the channel? You don’t know. So you check. And now you’re working at 10pm.

Slack didn’t invent this problem. But they built the rails it runs on. And the do-not-disturb features that exist: away status, notification schedules, pause notifications, all require individual configuration in a product where the default is everything, all the time.

What would actually help: treating “I’m in focus mode” as a first-class status the way “out of office” is. Not just an away message, but something that tells the person messaging you that you’re working and will respond later, which would normalize the idea that deep work is protected time, not available time.

As AI agents start populating Slack workspaces, this tension is only going to get worse. The 10pm notification could be production down. Or it could be an agent telling you it ran a scheduled task. The cost of ignoring either is different. The design doesn’t help you tell them apart.

---

The Verdict

Slack is still the best tool of its kind. We’re not switching.

The information architecture is genuinely strong. The performance is reliable. The learning curve is low. And its ubiquity is a massive, durable advantage.

But it’s a product under real pressure. The consumer-enterprise tension that’s always defined it is getting harder to resolve. Salesforce’s ownership has added enterprise gravity. The AI layer hasn’t found its footing. The always-on paradigm creates cultural problems the product doesn’t address.

The design wins are real and worth studying. So are the failures. Both tell you something useful about what happens when a product scales faster than the assumptions it was built on.

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Get more from Design Language in the Substack app

Available for iOS and Android

Get the app

What Is Japandi?

Japandi is a hybrid design style that blends Japanese warmth with Scandinavian minimalism.

In practice, that means a style that is minimal yet warm, and simple without feeling empty.

In a digital world filled with noise and chaos, Japandi is used to create emotional calm and composure. It aims to build trust by reducing cognitive load.

This is a style for a premium, long term relationship, not a one-visit stand.

Core Principles

Reduction without emptiness

Nothing extra, but nothing missing.

Warm restraint

Soft contrast over stark extremes.

Space as structure

White and negative space to carry hierarchy.

Natural Colors

Subtle natural hues and light contrasts

Subscribe now

How the Style Behaves in a UI System

Color

Muted, warm neutrals dominate. Saturation is rare and intentional.

Typography

Humanist or soft grotesks. Generous line height. Hierarchy through spacing.

Layout

Fewer containers. Clear reading paths. Elements feel placed, not packed.

Surface & depth

Soft radii. Minimal elevation. Subtle grain to avoid sterility.

Where This Style Is Strong

Japandi is strongest when you want to build trust by slowing down and engaging with your audience. You are inviting them to linger.

This is not a style that promotes urgency, but rather a longer term and continuous relationship, whether with readers on your publication, or a product with a long or considered sales cycle.

This makes it effective for:

• Healthcare and wellness platforms

• Knowledge and editorial products

• Premium B2B tools

• Lifestyle brands that value quiet authority

Where This Style Breaks Down

Every style has failure modes. In the case of Japandi, be careful of CTA’s getting lost, not enough contrast between design elements, and oversimplification to the point of uselessness.

How to use this today

Use Japandi when calm can be a competitive advantage.

In a world of loud interfaces and manufactured urgency, it chooses restraint, trust, and inevitability.

Interested in other styles? Check out our growing Style Library.

LLM Prompt

How to get this style from your robot:

Apply a Japandi design style to [describe your UI/component/screen]. Japandi blends Japanese warmth with Scandinavian minimalism — the result should feel calm, deliberate, and visually durable.

Follow these principles:

• Color: Use muted, warm neutrals (warm whites, soft taupes, earthy beiges, dusty greens or blues). Keep saturation very low. If an accent color is used, use it sparingly and with intention.

• Typography: Use a humanist or soft grotesk typeface. Set generous line height. Establish hierarchy through spacing and weight, not size alone.

• Layout: Reduce containers and visual clutter. Every element should feel placed, not packed. Use whitespace as structure, not as filler.

• Surfaces: Use soft border radii. Minimize shadows and elevation. Introduce subtle texture or grain where needed to avoid sterility.

• Tone: Avoid urgency. Avoid stark contrast. The interface should build trust slowly and reward the user’s attention over time.

  Do not add decorative elements for the sake of it. If something can be removed without losing meaning, remove it.

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Indicators Make the Invisible Visible

Indicators in your UI answer the evergreen question: “WTF is happening right now?”

People need to know what is going on. A system that communicates its status with clear indicators feels responsive and trustworthy. A system without indicators will appear confusing and broken.

Indicators translate system behavior into human-understandable signals.

Indicators are components like:

• loading states

• success messages

• error badges

• progress markers

• status labels

They reduce uncertainty, prevent repeated actions, and keep people oriented inside complex flows.

Good indicators remove guesswork. They are a warm fuzzy blanket that tells the user “don’t worry, something is happening.”

Bad or missing indicators create anxiety, hesitation, and rage-clicking. They make the user feel like they might have done something wrong, or that something is broken.

People already have enough anxiety today, let’s help them out.

Indicators Are Feedback Loops

Indicators are a form of communication between the machine and the user. It tells a person:

• An action was received

• Something is happening

• Something was completed

• Something failed

• What state the system is currently in

When indicators are clear, users stay in the flow. They feel confidence in the system. However, when they’re vague or missing, users assume the system is broken or that they fucked something up. In fact, many “performance problems” aren’t technical at all, they’re communicative (NOTE: This also happens to typically be the biggest challenge when dealing with people).

Psychologically speaking, indicators are where the system actions becomes visible to the user.

Imagine having a conversation with a person who went completely catatonic between thoughts. The conversation would feel brutal…you wouldn’t want to talk to them anymore.

Latency, failures, retries, background processing, etc. all exist whether users see them or not. Indicators decide whether users experience them as confidence or confusion.

A fast system with poor indicators can feel broken. A slow system with good indicators can feel reliable.

Indicators don’t change performance, but they do define how performance is perceived.

Practical Design Rules

Every action deserves a response

If a user clicks, taps, submits, or triggers a process of some kind - fucking acknowledge it!

• Button state changes

• Inline loaders

• Micro-animations

• Status text (“Saving…”, “Saved”)

A lack of indication will be interpreted as failure.

Match indicator strength to action importance

Not all actions deserve the same signal.

• Minor changes need subtle indicators

• Expensive, irreversible, or destructive actions need explicit confirmation

Over-signaling creates noise. Under-signaling creates doubt. Don’t bring the drama if its not needed, but that doesn’t mean not keeping me informed!

Show state, not just activity

A progress indicator alone says something is happening. A labeled progress indicator says what is happening.

• “Uploading file (3 of 5)”

• “Processing payment”

• “Syncing changes”

Specificity reduces anxiety and prevents repeat actions. Its like having a joint at a party, not strictly necessary, but a lot cooler if you did…

Indicators must resolve

Indicators should clearly transition:

• Loading → Success

• Processing → Error

• Draft → Published

Indicators that never resolve feel broken, even when the system technically works. Nobody likes to be left hanging, uncertain of what happened.

View it in Action:

Design Language Companion Guide

Why This Matters

Uncertainty kills momentum. Momentum is the lifeblood of your system.

Without indicators:

• Users repeat actions

• Data gets duplicated

• Support tickets spike

• Users don’t trust you

With clear indicators:

• People move faster

• Errors decrease

• Systems feel reliable and trustworthy

Indicators don’t just improve usability.

They protect your system from misuse and misunderstanding.

Use This Today

Pick one core workflow and walk through it step by step:

• After every user action, is there a visible response?

• Can users clearly tell what state the system is in?

• Are there moments where users might wonder, “Did that work?”

If the answer is unclear, your indicator strategy is incomplete.

LLM Prompt for Evaluation

You are a senior UX designer specializing in system feedback and interaction design.

Review the following screen or flow and identify all user actions and their corresponding indicators.

For each action, assess whether the indicator clearly communicates:
1. acknowledgment
2. current state
3. resolution

Flag any missing, vague, delayed, or misleading indicators.

Recommend specific improvements that make system status and outcomes immediately clear.

If anything is ambiguous, ask clarifying questions one by one before concluding.

Learn More

• NNG - Indicators, Validations, and Notifications: Pick the Correct Communication Option

• NNG - Visibility of System Status

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

But with the right language, you can get something far better than the usual “vibe code purple.”

But which LLM is the better designer?

The test:

1. Claude code built a skeleton of the page with no styling, only content and layout based on a PRD it also wrote.

2. We gave the exact same prompt and reference images to the different LLMs

   1. Claude 4.6 Opus in Cursor

   2. Gemini 3 Pro (High) in Antigravity

   3. Codex 5.2 in Cursor

3. Chose a very bold and intense style choice, “Memphis,” which is like an 80’s fever dream in Pee Wee’s Playhouse. It gave the most opportunity for “creativity.”

4. After each design was created, I took a screenshot and I reverted the code back to the original skeleton (I was having trouble with git branching).

5. All of these were “one-shot” prompts. I did not give any additional instructions and there were no revisions. I did not explicitly put anything into plan mode (although some did it on their own).

1. The skeleton

Used Claude Code to create a PRD and used Claude Code to generate the unstyled, coded skeleton page.

2. Gave same prompt to 3 LLMs

• Claude 4.6 Opus (via Cursor)

• Gemini 3 Pro (via Antigravity)

• Codex 5.2 (via Cursor)

The prompt:

You are an expert web designer specializing in bold, expressive visual styles.

Your task: Apply Memphis design style to this website

What is Memphis style:

Chaotic, colorful, and unapologetically weird

Rejects conventional “good taste” in favor of visual energy

Uses clashing geometric patterns, bold shapes, and unexpected color combinations

Think “Pee-Wee’s Playhouse” meets 1980s Italian design collective

High contrast, eye-catching, playful typography

Requirements:

Do NOT change content, copy, or content hierarchy - only modify visual styling (colors, fonts, patterns, shapes, spacing)

Maintain core UX principles: affordances must remain clear, buttons must be obvious, navigation must be intuitive

Meet accessibility standards (WCAG AA minimum) - ensure sufficient color contrast for text, maintain keyboard navigation, preserve semantic HTML

Include full mobile responsive styles - the design must work beautifully on all screen sizes

Reference images: [See attached images for visual inspiration]

Output: Updated CSS/styling that transforms the visual language while preserving usability and accessibility.

Reference images

Sourced from: https://graphicmama.com/blog/memphis-design-examples/

Subscribe now

The Results

Claude Opus 4.6 in Cursor

Gemini 3 in Antigravity

Codex 5.2 in Cursor

Very different results! Gemini and Claude’s output are quite good, they could work for a basic marketing page. Codex’s output was pretty bad.

Note: Personally, we’re not sure “Memphis” is the right style for this site, so we’ll try this exercise with a different style.

Want to try it out?

Grab the prompt and the reference images above and share your results in the comments.

Subscribe now

This headline is big because we want you to read it first.

People scan before they read. You probably just did.

Strong hierarchy guides people to what’s important. If elements look too similar, nothing stands out, and people won’t know what to focus on.

Hierarchy is a form of navigation, as it directs and orients people.

Used well, people find the most important element first, like a headline or call-to-action, then to secondary info, and so on. In a content heavy experience, effective use of hierarchy will orient users and help them find their way.

Visual hierarchy is achieved by contrasting elements so that some visually dominate over others.

You can use size, placement, and color.

A larger or bolder element will naturally draw attention first (e.g. a big headline at the top of a page). Strong color contrast can do the same. The big blue button below stands out on an otherwise black and white page.

The size, weight, and style of your fonts and components create a visual roadmap, guiding attention, signaling importance and waypoints, and shaping how people navigate your product.

Info-dense sites like the New York Times use hierarchy for orientation, organization, and way-finding. The title of the section, “Lifestyle,” is large, serif, and bold (seen first), the article title is smaller (seen second), and the article description text is regular and small (read next). Dates and writers names are even smaller and lighter (last). This design is not that different from a dashboard in a SaaS context, and the same principles apply.

On Uncrate, an ecommerce site, the product image is the hero. It commands the majority of the screen real estate and draws you in, which makes sense. Then the product name and price, the next 2 most important elements, are big and high-contrast with bold black font on a white background. The description is smaller, and details like SKU or fine print are subdued. The “Add to Cart” button is the single primary action on the page.

You control the flow of information consumption. Because every screen tells a story, and visual hierarchy decides the order in which it’s consumed.

Use this today

Before shipping any screen or page, ask: “What should users notice first?” Make that element bigger, bolder, or more contrasted than everything else.

If you’re working with dense content, like dashboards, documentation, or settings, ask instead: “How do users mentally organize this?” Match your visual hierarchy to that mental model. Group related items, use different sizing for different importance levels, and make section breaks obvious.

LLM Prompt

You are a world-class UX architect and information designer analyzing visual hierarchy.

Examine the attached screen and provide:

Scan path analysis: Describe what element draws your eye first, second, and third. What is the primary focal point?

Goal alignment: Based on what this screen appears to be (e.g., checkout flow, dashboard, marketing page), does the current hierarchy support its likely purpose? If the hierarchy seems misaligned, explain why.

Specific recommendations: Suggest concrete changes to improve hierarchy, such as:

“Increase the CTA button size and use a high-contrast color”

“Reduce header weight—it’s competing with the main content”

“Group related items closer together to create clear sections”

Focus on actionable adjustments to size, weight, color, contrast, spacing, and position.

Before you begin, ask me up to 5 clarifying questions, one by one, about the screen’s purpose or target user action until you have enough information. Then provide your full analysis.

Learn More

• https://www.interaction-design.org/literature/topics/visual-hierarchy

• https://www.figma.com/resource-library/what-is-visual-hierarchy/

Subscribe now

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

When people get closer to a goal, they work harder to finish it.

When a goal feels too distant, progress is abstract and motivation is weak. This is when most people drop off, because the payoff feels too far away.

The “Goal Gradient Effect” shows that as the finish line gets closer, momentum builds. The work feels worth it because completion feels reachable.

You see this pattern clearly in conversion data. That’s why it’s called a funnel, not a tube. Most abandonment happens early, before progress feels real.

🔜 If you need people to finish, show them they’re getting closer to the goal.

In other words, make progress visible.

Progress indicators work because they provide both orientation and motivation. They answer two critical questions at once:

• Where am I?

• How much is left?

That context matters. Without it, effort feels endless. With it, work feels finite and achievable.

🎯 Visible Progress Turns Effort Into Commitment

This concept shows up clearly in loyalty programs.

Loyalty cards turn repeat behavior into a visible journey. Each stamp or checkmark signals momentum. The reward at the end reframes effort as accumulation, not obligation.

The “free thing” isn’t just an incentive, it’s a psychological anchor. Once progress is visible, people don’t want to abandon it. The closer they get, the stronger the pull to finish.

This is the Goal-Gradient effect made physical: progress creates commitment, and commitment drives return behavior. People are more likely to visit the café as they get closer to a free coffee.

The same dynamic shows up in airline status programs, to the extent that some people book flights they don’t actually need just to preserve status.

The incentive isn’t the flight. It’s the goal, driven by the visibility of distance from it.

Simply making the goal and distance visible is often enough to change behavior. When people understand what they’re working toward, and how close they are, they’ll often act without additional incentives. The goal itself becomes the motivator.

Why should I care?

If you need people to move through a workflow, complete a sequence of steps, or make a purchase, their willingness to continue depends on whether progress feels real.

When the path is vague, people hesitate. When the goal is visible and distance is clear, effort increases. This is true whether you’re designing a checkout flow, an onboarding sequence, or a creative tool.

Design isn’t just about removing friction. It’s about creating momentum.

Use this today

Ask yourself:

• Can you reward people sooner, before motivation drops?

• Can you break large goals into smaller, more frequent wins?

• Can you make progress visible, not implied?

If people can see movement, they’ll keep moving. If the goal feels closer, effort feels justified. Design for momentum, not patience.

LLM Prompt

You are a senior UX designer and behavioral design expert.

Analyze the following website or flow with a focus on momentum, progress visibility, and goal completion.

Your task is to identify where users may lose motivation and where design could better leverage progress-based psychology (goal-gradient effect, early rewards, visible advancement).

Context

• Website type: [marketing site / SaaS app / ecommerce / onboarding flow / newsletter / other]

• Primary user goal: [what users are trying to complete]

• Key conversion action: [signup, purchase, submit, finish, etc.]

Ask any questions, one at a time, that will help clarify this ask.

Respond with:

• A short executive summary

• Key friction points

• Concrete, testable design suggestions

Learn More

• http://home.uchicago.edu/ourminsky/Goal-Gradient_Illusionary_Goal_Progress.pdf

• https://www.researchgate.net/publication/234791131_The_importance_of_percent-done_progress_indicators_for_computer-human_interfaces

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Friction slows people down. You may or may not want that.

Friction is the resistance users feel when an interface slows, confuses, or interrupts their flow. It can be physical (more clicks), cognitive (hard to understand), or emotional (annoying).

Friction isn’t inherently good or bad on its own. Used correctly, it’s an effective tool to improve your product’s experience. Used poorly, it causes frustration, mistakes, and drop-off.

Good friction vs. bad friction

😇 Good friction slows users on purpose:

• A moment of pause with ability to undo before sending money

• A confirmation dialog or typing “DELETE” before deleting critical data

All of these slow the flow towards the user goal for a reason, like ensuring safety and confirming user intent. If there are parts of your experience where mistakes are costly, you want to ensure the user moves mindfully. Used this way, friction is a form of error prevention.

See examples in our companion Guide

😤 Bad friction slows users unnecessarily, worsening the experience and impeding key actions

• Long, mandatory form fields that aren’t necessary

• A disabled button with no explanation

• A five-step checkout when one would do

Bad friction results in pissed off users. They wonder “wtf why is this so hard!?” and you’ll lose them. If the user doesn’t understand the interface or why the system is slowing them down, you are eroding trust with each step.

For example, you would not sign up for whatever this is:

See example in our companion Guide

Why should I care?

Removing unnecessary friction improves speed, confidence, and user trust.

Adding intentional friction in the right moments reduces mistakes, increases safety, and gives users time to think before acting.

It’s not about having no friction in the experience. It’s about the right amount, in the right place, for the right reason.

How to use this today

When reviewing a screen or flow, ask:

• Are there any extra steps or unclear moments that don’t serve a purpose?

• Is there friction that should exist (e.g. to prevent a destructive action) but doesn’t?

Designing with AI: Test Your Product for Friction

Take a screenshot of your interface and paste it into ChatGPT or Claude with this prompt:

“Act as a senior UX strategist. Evaluate this interface for potential negative user friction. Identify where the experience slows users down, creates confusion, breaks flow, or adds cognitive load. Distinguish between intentional friction (helpful, protective, clarifying) and unintentional friction (accidental, distracting, redundant). Recommend precise adjustments that increase clarity, speed, and ease of use. If anything is ambiguous or missing, ask targeted questions before drawing conclusions.”

Subscribe now

Dive in Deeper

• NNG: Designing for Friction and Flow in Customer Journeys

• The Best Interface is No Interface by Golden Krishna

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.

Subscribe now

Make it hard to fuck up.

Errors in your product create a frustrating experience, and frustrated users ultimately become your problem. They will blow up your support channels or just stop trusting your product and leave all together.

Design your product so that the wrong action is the hardest one to take.

3 strategies to prevent user error

1. Prevention - Stop people from making a mistake in the first place.

For example, disable Buttons until they are able to be used, only giving the user the ability to use it when they can take an action with it.

Or ask users to type a specific word, like “delete,” to confirm destructive and irreversible actions. It’s a simple, proven way to stop accidents before they happen.

2. Real time guidance - Highlight errors while users are in the flow, not after.

The ubiquitous red line spell check is a great example of this in action - you know right away that something is wrong, and can fix it before moving on.

If your product experience uses forms, make the input forgiving. Accept numbers and phone formats however users type them. However, when only one input format is valid, guide users or format it automatically. Phone Numbers are a common example, where international differences in format make clarity essential.

Slack uses confirmation popups mid-workflow. For example, when using the “@channel” command, it a warning pop-up is delivered to ensure you intend to notify everyone in every timezone.

3. Recovery - Help people easily diagnose and fix problems when they do occur.

Even with all these guardrails, people still fuck up. When they do, tell people how to fix the problem, in plain language, with actionable error messages.

And if they still make it all the way to the disaster we’ve been trying to protect them from? Your ultimate fail-safe is this: let them undo. Make reversal easy, obvious, and fast.

Match error prevention to the severity of the consequences.

While you want to prevent errors, not all errors are created equal. Making a typo is different than deleting a critical record. Error preventions can add friction, so make sure the tradeoff is worth it. Potential big mistakes should have big interventions. Little mistakes need little interventions.

Why should I care?

If someone makes enough mistakes, your experience becomes frustrating or useless. This becomes your problem, in the form of support tickets and churn. An error free experience creates trust, and if they can’t trust your product, they won’t use it.

How to Use Today

Move through the key workflows or user journeys of your product and ask:

• Is it too easy to make a mistake, or accidentally delete something important?

• Do we balance the error prevention method with the size of the possible error?

• Is my product experience forgiving, allowing users to easily engage and recover?

LLM Prompt for Evaluation

Copy/paste this into your model with associated screens or workflows:

Review the following feature, screen, or workflow and evaluate it purely through the lens of error prevention. Identify any places where a user could accidentally make a mistake, misinterpret an action, or submit incorrect information. For each issue you find, suggest one or more improvements that would make the error impossible or much harder to commit.

Focus on:

• preventing errors before they can happen

• validating inputs in real time, not after submission

• limiting destructive actions or making them clearly intentional

• giving users clear constraints, defaults, or guided paths

• matching confirmation or safeguards to the severity of the consequence

Return your response in three parts:

1. Where a user might mess up

2. How to prevent it

3. Suggested improvements to the interaction that makes it harder to mess up

Learn More:

• https://www.nngroup.com/videos/usability-heuristic-error-prevention/

• https://usabilitygeek.com/error-prevention-in-ux-design-how-facebook-and-gmail-get-it-right/

About Us

Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.

Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.

David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.