Design Language

The static design deliverable is dying

Design Language — Sun, 17 May 2026 22:02:01 GMT

The “Figma is dead” takes started the moment Claude Design shipped - a few shorts weeks ago. They’re wrong. But something is dying, and it’s worth calling it out.

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.

User Flows as AI Context

Design Language — Mon, 11 May 2026 16:45:34 GMT

You’re building a new product, workflow, or feature and your coding agent is helpful, but unmoored. It’s making strange decisions because it doesn’t know what comes before or after at each step of the process.

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

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

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.
Create a directory in your main project directory called User Flows and save all these files there.
Convert the flow to a markdown (.md) file by dropping those files into Claude or ChatGPT along with this prompt:

The image(s) attached show a user flow diagram for [PRODUCT OR FEATURE NAME]. If there are multiple images, treat them as sequential sections of a single larger flow, ordered as numbered.

Convert this into a machine-readable markdown document to be used as persistent LLM context for a product being actively built. Structure the output as follows:

Overview — One short paragraph describing what this flow represents: the user’s goal, where the flow begins, and what a successful end state looks like.

Flow Diagram — A Mermaid flowchart capturing the complete flow: every step, decision point, branch, and termination state visible in the image(s).

Step-by-Step Breakdown — A numbered list of every step in the flow. For each step, describe what is happening on screen, what the user is doing or deciding, and what comes next. Call out branches explicitly.

Edge Cases and Error States — Any alternative paths, error conditions, empty states, or failure modes visible in the diagram. If none are shown, note that.

Context Notes — Observations useful to someone building or extending this product: assumptions the flow makes about the user, handoff points between user and system, steps that seem underspecified, or anything that would affect implementation decisions.

Output the entire document as a single markdown file. Write it as documentation for a technical collaborator, not a design review. Be specific and structural — the goal is machine-readability, not narrative description.

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.

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

The Issue Tracker Is the New IDE

Design Language — Tue, 05 May 2026 15:18:49 GMT

For years the Jira versus Linear conversation has been about taste. Linear is prettier, Jira is more powerful, and the running joke has been that Jira feels like an HR portal that learned to write tickets. That framing made sense when these tools were just project management software. But it doesn’t make sense anymore.

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.

Why your product feels broken

Design Language — Mon, 27 Apr 2026 18:19:17 GMT

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:

Does every action get immediate acknowledgment?
For waits over 3 seconds, does the user know how much longer?

LLM Prompt

You are a UX designer reviewing a product for loading state quality. I’m going to share a product experience — as a screenshot, URL, or codebase.

First, identify every moment where the system is processing, loading, or waiting for a response.

For each moment, use the following decision logic to recommend the right loading pattern. If you can determine the answer from what I’ve shared, make the recommendation directly. If you can’t, ask me one clarifying question at a time before proceeding.

1. Is content loading into a layout (a feed, dashboard, or set of cards)?

→ If yes: use a skeleton screen.

2. If not — is this a high-confidence, fast action (a like, a save, a send)?

→ If yes: use an optimistic update. Assume success and correct only on failure.

3. If not — do you know roughly how long the wait will take?

→ If yes: use a progress bar.

→ If no: use a spinner — but always set a timeout so it can’t run forever.

For each moment, also describe what the error or failure state should look like if the action doesn’t resolve cleanly.

Finally, flag any moments where no loading state currently exists and one is needed.

If anything is unclear from what I’ve shared, ask one clarifying question at a time before proceeding.

Subscribe now

About Us

Your Notes App Is Failing You

Design Language — Sun, 19 Apr 2026 16:04:38 GMT

Your Notes App Has No Idea What It Is Anymore

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

Keyboard Shortcuts - Your mouse is a tourist. Your keyboard is a local.

David Issa — Mon, 13 Apr 2026 19:23:29 GMT

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.

Linear’s Level 3 “Command-K” menu

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

You are an expert UX designer and accessibility auditor specializing in keyboard interaction. Audit the attached screenshot(s) of my product against four areas:

1. ACCESSIBILITY BASELINE — Can every interactive element be reached and triggered by keyboard alone? Are there focus traps? Is the focus state always visible?

2. PLATFORM CONVENTIONS — Are Cmd/Ctrl+S, Z, C, V, F, A, Enter, Esc, and Tab mapped correctly? Flag any standard slot used for a non-standard action.

3. POWER USER EFFICIENCY — Identify the 3–5 highest-frequency actions. Does each have a shortcut? Is there a command palette (Cmd+K)?

4. DISCOVERABILITY — How would a user learn shortcuts exist? Is there a `?` reference, tooltip hints, or a self-documenting palette?

For each area, flag specific gaps and recommend concrete fixes. Rank the top 3 fixes by impact on accessibility compliance, task completion, or power-user retention.

End with a one-paragraph verdict: could a keyboard-only user complete the core workflow today? Would a power user feel rewarded for learning your product, or punished?

Ask me up to 3 clarifying questions before starting.

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

File storage is fucked. AI is making it worse. And Dropbox Isn't Helping : Acquired Taste

Design Language — Sun, 05 Apr 2026 16:15:42 GMT

This is the companion piece to Acquired Taste, Episode 2. Watch the video above, or read on.

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

Jakob's law - Don’t reinvent the wheel; just make it roll.

Design Language — Mon, 30 Mar 2026 19:13:04 GMT

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.

Everyone knows what this means, no need to get cute

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.

The '“hamburger” icon is a well established pattern to indicate a menu

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

Breadcrumbs orient users

Getting adoption is hard enough.

Leverage existing patterns to make it easier.

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.

Ecommerce has well-established patterns

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

Introducing "Acquired Taste" - a product design teardown. Ep. 1 - Slack

Design Language — Sun, 22 Mar 2026 14:02:45 GMT

This is the companion piece to our first Design Language video, a live teardown of Slack through the lens of product design. Watch it above, or read on.

---

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

Available for iOS and Android

Japandi - where calm is a competitive advantage

David Issa — Mon, 16 Mar 2026 18:47:36 GMT

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

avelacreative.com

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.

source: avelacreative.com

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

Indicators: WTF is happening rn?

David Issa — Mon, 02 Mar 2026 19:03:17 GMT

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

Subscribe now

About Us

Interface-Off: What LLM designs the best marketing site?

Design Language — Mon, 16 Feb 2026 18:22:21 GMT

AI coding tools are legitimately amazing, but their default designs are not.

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:

Claude code built a skeleton of the page with no styling, only content and layout based on a PRD it also wrote.
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
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.”
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).
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

Size does matter: how to use Hierarchy to direct attention

Mon, 02 Feb 2026 19:18:15 GMT

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

Subscribe now

About Us

Progress is a hell of a drug

Design Language — Tue, 20 Jan 2026 17:00:46 GMT

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.

This is why it’s called a funnel, not a tube.

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.

When people clearly understand a goal—and how close they are to it—they’ll often act without additional incentives. The goal itself becomes the motivator.

🎯 Visible Progress Turns Effort Into Commitment

This concept shows up clearly in loyalty programs.

People are more likely to visit the cafe as they get closer to the free coffee.

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.

This is why I’m in Zone 8

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

About Us

F: Friction can be a feature or a bug

Design Language — Mon, 05 Jan 2026 19:31:50 GMT

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:

Confirming you are sending money to the right person is a solid example of “Good Friction”

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:

Nobody’s filling this out. There is a reason a vast majority of people use SSO. It’s easier.

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

Subscribe now

E: Error Prevention - Stop people from messing up.

Design Language — Mon, 22 Dec 2025 17:15:32 GMT

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.

Credit: Toonhole.com

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.

The button only becomes active when the field is filled out

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.

It’s like 2FA for destruction

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.

The red line that saved a zillion emails. Also I can’t spell ubiquitous.

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.

You can’t enter the phone number incorrectly.

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.

Slack’s internal comms call this “don’t be a cock.”

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.

For readers of a certain age…

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.

Undo that nasty late night email to your boss

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:

Where a user might mess up
How to prevent it
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

D: Doherty Threshold — Designing for Instant Response

Design Language — Mon, 08 Dec 2025 17:05:46 GMT

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

About Us

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.

C: Common Region - Grouping Related Elements Clearly

Design Language — Mon, 24 Nov 2025 17:30:38 GMT

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

B : Buttons - Button Types and when to use them

Design Language — Mon, 10 Nov 2025 22:42:30 GMT

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.

Substack’s “Danger Zone”

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:

Is the primary button on the page used for the primary action?
Does the styling of this button make it stand out?
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

Subscribe now

About Us

A: Affordances - Making UI Actions Obvious

Design Language — Mon, 03 Nov 2025 14:00:16 GMT

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).

We miss “The Far Side” too

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.

The underline of a link is the affordance.

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