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.

Slow experiences feel shitty and broken. There’s a science to why.

The “Doherty Threshold” says that when systems respond in under 400 ms (4/10ths of a second), users stay in a flow state and feel in control. The system feels fast and responsive. Anything slower breaks momentum and feels broken.

Now obviously not all actions can happen that quickly. We’re talking 4/10ths of a second! So when users tap a button, open a menu, or trigger a workflow, the system should acknowledge the action within the threshold, even if the full process continues in the background. That quick “I heard you” signal preserves rhythm and reduces frustration.

Take a look at the difference:

Try this for yourself in the Design Language Companion Guide →

Even small delays feels big

When feedback lands within 400 ms (4/10th of a second), users don’t consciously register the pause. They stay focused on the task, not the system. When feedback lags beyond that point, they start wondering if something is broken.

You should use loading animations and confirmations for those longer tasks.

Why should I care?

Products that stay under the threshold feel responsive, trustworthy, and efficient. Products that don’t cause drop-offs, uncertainty, or unnecessary retries. The threshold gives teams a concrete target: respond fast enough to keep people in motion. That single shift can improve engagement, reduce support requests, and increase the likelihood users complete tasks.

How to use this today

Pick one core interaction in your product - something used daily - and ask:

• Does the interface acknowledge the action within 400 ms?

• If the action takes longer, is there immediate visual feedback so the user knows something is happening?

• If not, could a lightweight pattern (optimistic update, inline loader, skeleton screen) keep momentum instead of forcing a hard wait?

Designing with AI: Test Your Product’s Speed with LLMs

Paste URL or connect LLM to your web app:

“You are the world’s foremost expert in UX responsiveness. Analyze this interface for adherence to the Doherty Threshold (400 ms interaction feedback). Identify each user action, estimate perceived response time, and flag any steps where acknowledgement appears delayed or unclear. Suggest specific UI patterns that would maintain user momentum if backend processing takes longer than 400 ms. If anything is unclear, ask questions one by one until you understand the intended behavior.”

Dive in Deeper

• Laws of UX - Doherty Threshold

• PC Mag Encyclopedia - Doherty Threshold

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 runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders. 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.

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 Principle of Common Region

The principle of Common Region says that elements inside a defined boundary are perceived as belonging together.

By defining clear regions, users quickly understand structure, relationships, and context within an interface, reducing cognitive load and improving scan-ability.

In other words, people will think the stuff in the box is all related.

Ever noticed how a card UI makes separate bits of content feel connected? A photo, a title, and a button framed inside one box read as a single unified object.

Proximity, similarity, and region all guide how we make sense of visual information. Our brains assume: “If it’s inside the same box, it probably belongs together.”

Grouping supports cognition.

When related elements are not visually grouped, users must interpret relationships and expend mental effort to determine what belongs together. When elements are clearly grouped, the interface communicates structure for them. Effective use of common regions reduces cognitive burden, which is especially critical in high-density interfaces, making information easier to scan, digest, and act on.

Clear boundaries and consistent use of grouping make your product feel ordered, intentional, and easy to parse at a glance.

Why should I care?

Applying the common region principle makes complex interfaces easier to parse and reduces cognitive load. By making relationships visually explicit, users grasp structure instantly, move through tasks with less effort, make fewer mistakes, and operate with greater confidence and speed.

How to use this today

When reviewing your product or screen, ask:

• Are related elements visually grouped in a shared region?

• Are unrelated elements ever grouped by mistake?

• Does every “card,” “panel,” or “section” have a clear reason to exist, or are some arbitrary boxes just adding noise?
  

Designing with AI: Test Your Product’s Grouping with LLMs

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

“You are the world’s foremost UX design expert. Please analyze this design for use of the “Common Region” principle. Identify all distinct visual regions or groups. For each region, explain what the grouping communicates to users and whether it accurately reflects related functionality or content. Flag any regions where unrelated elements are enclosed together or related elements are visually separated. Recommend layout or boundary adjustments to make the grouping clearer and more aligned with user understanding. If you are unclear about anything, ask me questions, one by one, until you have the information you need.”

Dive in Deeper

• Gestalt Principles of Perception | Interaction Design Foundation

• Universal Principles of Design by Lidwell, Holden, & Butler

• Nielsen Norman Group: Visual Grouping and the Gestalt Laws

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.

Use the right button for the right action

Different button styles have different purposes, and using them incorrectly will confuse users and decrease engagement.

There are 4 basic button types a system should have, which have specific purposes.

• Primary

• Secondary

• Confirmation

• Danger

Button Types

Primary

The primary is exactly what is sounds like - the most important action on a screen. There should be only one primary button on any given screen. Your primary button design should stand out as one of the most attention seeking elements on the page.

Secondary

Use these for all other actions that require a button. They should have a more conservative design and not stand out as dramatically as the primary buttons. You often see them with white backgrounds and dark text.

Confirmation

This button tells the user they are about to accomplish or confirm something. It’s usually a change to the system in a positive direction. This button is often Green. Good for actions like Save, Buy, Add, etc.

Danger

This tells the user they are about to take an action that takes something away, like deleting content or removing records. This button should be Red - and feel like an alert. Good for actions like delete, trash, remove, etc.

Even on Amazon, with it’s characteristically cluttered interface, the most important action is Buy Now, and your eye is drawn immediately to the button.

Why Should I care?

Buttons should lead your users through the experience to your desired outcome. If users take the wrong actions, don’t know what they should be doing, or where they should be going, this will lead to a bounce, churn, or cancellation.

How to Use Today

Pick one primary screen or workflow in your product and ask these 3 questions:

1. Is the primary button on the page used for the primary action?

2. Does the styling of this button make it stand out?

3. Do I only use this style to highlight the most important action, and not anywhere else?

LLM Prompt for Evaluation

Paste a screenshot of your screen or Figma frame into an image-capable LLM and ask:

“You are the world’s foremost expert in usability and UX design. Identify the primary action on this screen. Is it visually distinct, clearly labeled with a verb phrase, and positioned near the content it affects? Suggest improvements if not. If you are unsure, ask me questions, one by one, until you have the information you need to most accurately answer this question.”

Deeper Dives

• Apple HIG: Buttons

• Material Design: Buttons

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.

Affordances are the signals that make or break your UX

An affordance is a design element’s built-in suggestion about how it should be used. A design element, object, or interface should signal what actions you can take with it.

Ever tried to tap something in a mobile experience that seemed “tappable,” and nothing happened? Or tried to find a link on a page, but there was nowhere obvious to click?

Ever tried to push a door that was pull only (side note, fuck these doors).

Affordances are the visual cues that suggest use.

A clearly designed button invites a tap; underlined text suggests a link. When these cues are clear, people act instinctively without thinking about it.

That underline on the link? That’s the affordance. It instantly communicates “this will take you somewhere else.” It’s one of the internet’s earliest design patterns, and is now so ingrained that you don’t even think about it.

And it’s jarring and weird when underlined text is NOT a link. It messes with your expectations and learned behavior. It feels broken.

Affordances can be shapes, text, color, etc., and there is no right or wrong approach - as long as the outcome is clarity. Decades of digital design has taught us all to understand common design patterns as affordances, like the link example above. Take advantage of all that work.

Why should I care?

Affordances can be the difference between a product that feels intuitive vs. one that feels broken. Users will quietly bounce or churn if poorly designed affordances make the product feel hard to use, and never return.

How to use this today

When reviewing a new design or existing product, ask:

• Is it clearly understood what actions can be taken?

• Are there any interactive elements that are hard to recognize?

• Are any expectations subverted or broken about how something should work?

Designing with AI: Test Your Product’s Affordances with LLMs

Take a screenshot of your UI and drop it into ChatGPT/Claude with this prompt:

"You are the world’s foremost UX design expert. Please analyze this design for use of affordances. Identify all interactive elements on the page and present them in a list. Then flag any interactive elements that don’t look interactive enough, or any non-interactive items that appear clickable (false affordances). Highlight any cases where a user’s expectations might be subverted. For each issue, explain why it could confuse users and suggest how to improve the design so it’s clear what can be clicked or tapped. Ask me any questions, one by one, about the intentions of on-screen design elements if they are unclear."

Dive in Deeper

• What are Affordances? | IXDF

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.