I’ve sat with hundreds of product teams over the years. They show me their app, excited to walk through every feature they’ve built. I see a home screen packed with 50 options. Beautiful design. Tons of work. And I watch their users stare at it, frozen.
That moment of paralysis is when I know they’re missing a critical component. Not about design systems or best practices. About human choice architecture.
Here’s the uncomfortable truth: every screen you design should have exactly one clear desired action. One thing you actually want people to do. Everything else exists to support that action or, honestly, shouldn’t be there at all.
I call this the Desired Action Audit, and it’s where product discipline separates winners from “why is my app being uninstalled?”
⚡ Speed Run Notes
- Every screen needs one clear Desired Action. If you can’t point to the single most important thing a user should do on each screen, your UX has no discipline.
- The Desired Action Audit means walking through every screen and asking what the user should do here, then checking whether the design makes that next step obvious. In many audits I’ve run, a large minority of screens fail that test.
- Anti-Desired Actions matter too. If closing the app is easier than completing the next step, your screen is fighting itself.
- Every Desired Action should map to a Core Drive. If the answer is only “because we need them to,” that’s not motivation design. That’s wishful thinking.
- Screen-by-screen UX mastery means no orphan screens and no conflicting screens asking users to do two primary things at once.
Table of Contents
Author Credibility: Yu-kai Chou
Yu-kai Chou created the Octalysis Framework after studying gamification since 2003 — years before the term entered mainstream vocabulary. As a Human-Systems Architect & Behavioral Designer, his framework has been applied by LEGO, Microsoft, Porsche, Coca-Cola, Salesforce, and MrBeast, impacting over 1.5 Billion Users.
Chou has taught the Octalysis methodology at Harvard, Stanford, Yale, Tesla, Google, BCG, and IDEO.
His work has been cited by Harvard, Stanford, MIT, Forbes, Wall Street Journal, Wired, US Department of Energy, NIST, NSF, NCBI, US Department of Education, ClinicalTrials.gov, and Google Scholar — with 3,700+ more academic publications. Explore his books here.
The One Thing Rule
When I pitch this to teams, someone always pushes back. “But our users have different goals. We need options.”
Sure. But not on every screen.
The principle is simple: if a user sees your screen and can’t immediately identify what you want them to do next, their brain defaults to “I’ll figure it out later” or, more commonly, “I’ll figure it out somewhere else.”
The desired action should be so clear that even if it’s in a foreign language, people just want to click on it. Not because they read the label, but because the visual hierarchy, the placement, the contrast scream “this is what matters right now.”
I tested this idea with an automotive app once. The home tab was beautiful. It had navigation, stats, service history, and a prominent call-to-action. Except the “Home” label was competing visually with the actual button we wanted people to click. Not in terms of text, but in hierarchy. Two equal weights fighting for attention. Users looked confused.
We killed one of them. Removed the redundancy. Suddenly, people knew what to do.
The flip side is just as important. For every desired action, there’s an anti-desired action — the thing the user does instead when your screen fails. Closing the app. Tapping back. Walking away to a competitor. If those moves are easier than completing your desired action, your screen isn’t neutral. It’s actively losing. The audit isn’t just “what should the user do here?” It’s also “what will they do if I don’t pull them in?” Designing for the second question is what separates teams that ship to ship from teams that ship to win.
The Feature Pride Trap
This is where founders stumble. You’ve built 50 features. You’re proud. So you show them all on the first screen.
That’s not impressive. That’s overwhelming.
The better approach sounds almost counterintuitive: show one or two really cool things. Let users interact with one of them. Feel good about it. Then reveal the next tier. “Hey, you just unlocked the third thing.”
I worked with a food ordering app where the first screen had five competing actions: browse categories, view your profile, check the leaderboard, create a custom burger, and see what’s trending. The founder saw this as showing off. I saw five different desired actions fighting each other.
In reality, users only wanted to do two things: either order an existing burger or build their own. Everything else was secondary. We reorganized the hierarchy, and suddenly the funnel converted better. People weren’t lost. They knew what mattered first.
Feature pride isn’t just ego. It’s misunderstanding that showing everything is the opposite of respect for user attention.
Confusion Kills Motivation
Let me connect this to something deeper in behavioral design: my Octalysis Framework and Core Drive 2, which is about accomplishment and progress.
When a user feels confused, they don’t feel accomplished. They feel stupid. And confusion is the fastest path to closing your app and never coming back.
Confusion is anti-Core Drive 2. It strips the scaffolding of progress and replaces it with shame. “I don’t understand how to do this” becomes “this product doesn’t respect my intelligence.”
That’s the stakes. Not productivity. Not features per screen. Psychological safety and the confidence to move forward.
There’s a second Core Drive at stake here too: Core Drive 3 (CD3): Empowerment of Creativity and Feedback. Empowerment requires that the user knows what action to take and trusts that the action will have a consequence. A confused screen breaks both halves of that contract. The user can’t pick an action confidently, and even if they did, they wouldn’t trust the system to respond meaningfully. So confusion doesn’t just block Core Drive 2 (the accomplishment drive). It also blocks Core Drive 3 (the agency drive). When you fix screen clarity, you don’t just restore one Core Drive. You restore two at the same time.
The Five Rules of Desired Action Design
Rule 1: One Desired Action Per Screen
I keep coming back to this. Test it. Show your screen to someone who doesn’t speak your language. Don’t tell them what to do. Can they figure out the primary action just from visual signals? If the answer is no, you’ve got work to do.
I audited a mobile app where the primary action (booking a ride) was equally weighted with secondary navigation, settings, and promotions. All on one screen. All claiming to be important.
We reorganized. One button. Everything else supported it or lived elsewhere. Conversion improved because people finally knew where to focus.
Rule 2: Break Complexity Into Single Choices
This is the TurboTax pattern. It turns a complex process into a sequence of small steps, almost like good quest design. TurboTax doesn’t show you all tax forms on one screen. It asks you one question. You answer. Next question. One decision per screen, and you’re building momentum.
Compare this to an e-commerce checkout that throws shipping, payment, gift options, insurance, warranty, and loyalty signup all on the same page. Your user’s cognitive load explodes.
Single choice per screen. One desired action. Then the next page presents the next single choice. That’s how you maintain both clarity and momentum.
Rule 3: No Dead Ends
Here’s where I see a lot of products fail silently: they obsess over the happy path and ignore everything else.
Your About Us page. That’s a dead end if there’s no next action after someone reads it. Your post-purchase confirmation page. If it just says “thanks!” with no path forward, you’ve wasted a moment of engagement.
Error pages, profile pages, and empty states all need a next action. They’re not destinations. They’re stepping stones.
I audited an eco-friendly e-commerce site. After someone made a purchase, they saw a beautiful confirmation popup. Then it routed them back to the homepage instead of to their profile, where they could see their order, track it, or share it. The purchase felt isolated, not integrated.
We added a clear path: “View Your Order” button that took them somewhere with meaning. Suddenly, more people continued into the post-purchase journey. The desired action wasn’t just completing the transaction: it was starting the relationship after the purchase.
Rule 4: Design for Empty State
Empty states reveal truth about your product design. If your empty state is a beautiful placeholder image of a model happily using your product, you’re not designing for reality. You’re designing for aspirational bias, what I call Core Drive 4 thinking.
Real empty states are powerful because they’re honest. And honesty builds trust.
I looked at a social feed app once. The founder had seeded it with “purchases” from the past 7, 40, and 80 hours. Looks active, right? Except users knew something was off. These weren’t real people they followed. It created negative social proof: “this app is either fake or I’m doing this wrong.”
We redesigned the empty state to acknowledge what it was: “No purchases yet. When your friends buy something, you’ll see it here.” Suddenly, it felt real. Users didn’t feel stupid. They understood the mechanics and knew what success looked like.
Rule 5: Meaning Before Metrics
Your user just earned 1,247 points. Congratulations! Except… what does that mean?
Raw numbers isolate people from real accomplishment. They’re meaningless without context. I’ve seen engagement collapse when products show points without explaining why they matter.
The better approach: achievement symbols. Certificates. Icons. Proof that something real happened. An ocean cleanup app I advised showed users digital certificates for every ocean cleanup contribution. Not arbitrary points, but proof they’d actually removed real plastic from real oceans. The engagement was different. The meaning was different.
The deeper Octalysis read on this: meaningful symbols pull on Core Drive 4 (CD4): Ownership and Possession. A digital certificate for an ocean cleanup is something the user feels is theirs. They earned it. They’d feel a small loss if it disappeared. A meaningless point total has no such weight. Worse, it can trigger Core Drive 8 (CD8): Loss and Avoidance in its anti-form: “I spent twenty minutes earning these points. Was that time wasted?” That’s how engagement collapses. Not because the user disliked the action. Because they couldn’t convince themselves the reward meant anything. Symbols solve this by being unambiguous. Numbers without context invite the doubt.
Metrics should tell a story about progress. Not just counting.
Friction Is Contextual
Here’s where people misunderstand efficiency. They think removing friction is always good. Fewer clicks equals better product.
That’s wrong.
There are two ways to think about product design. Function-focused design removes friction and assumes motivation already exists. You want a drink, you tap a button, you get it delivered. Ten seconds. Maximum efficiency.
Human-focused design accepts friction as a tool for building motivation. Instead of tapping a button, you walk through a virtual bar, you see drinks being made, you chat with the bartender. Five minutes instead of ten seconds. But the experience itself becomes part of the appeal.
Compare Discord to Roblox. On Discord, you tap a voice channel and you’re in. Instant. Function-focused. On Roblox, you walk your avatar across a hangout space, wave at someone, sit on a couch, then start the conversation. More friction. But that walk builds anticipation, presence, and the feeling that you arrived somewhere. Different design philosophy. Different outcome.
The question isn’t “how do we remove friction?” It’s “where does friction serve motivation, and where does it just create abandonment?”
For your desired action (the one thing per screen), friction should be minimal. Users should feel like geniuses clicking forward. But secondary actions can live in friction. They’re optional. They can cost a few extra steps.
Anti-Friction Flow State
The best product experiences create a feeling I call anti-friction flow state. User clicks the obvious thing. Gets immediate feedback. Sees the next obvious thing. Clicks again. And again. By the end, they feel like they’ve uncovered the secret to your product without reading a manual.
There’s no cognitive friction. No confusion. No second-guessing. Just momentum.
This happens when every screen has one clear desired action. When that action is preceded by context that explains why they should care. When completion gives them feedback and shows them the next step.
It’s the opposite of most product experiences, which feel like solving a puzzle designed by someone who actively doesn’t want you to win.
The desired action audit forces you to design flow state. Not as an afterthought, but as your core design constraint.
Beyond Apps
Now consider this: this isn’t just about apps. I’ve applied the Desired Action Audit to emails, classroom designs, website flows, and even meeting agendas.
Every email you send should have one clear desired action. Not three calls-to-action competing for clicks. One. Everything else supports it.
A classroom lesson should have one primary learning objective per session. Not seven learning objectives plus a project plus a quiz. One thing students should leave understanding.
A website landing page? One desired action. Everything else, such as testimonials, features, and pricing, should support that single conversion goal.
Even a meeting agenda should have one desired outcome. The rest of the time supports that outcome.
Why does this work across such different domains? Because as long as we’re dealing with human beings, the psychology is the same. Clarity beats complexity. One choice beats many. Momentum beats decision paralysis.
This isn’t a feature. It’s a discipline.
FAQ
How do I run a Desired Action Audit on my product?
Screenshot every screen in your user flow. For each, write down: (1) what should the user do here? (2) is that action visually obvious? (3) what Core Drive motivates it? (4) what’s the anti-desired action? If you can’t answer all four for every screen, that screen needs redesign.
What if a screen genuinely needs multiple actions?
Prioritize ruthlessly. One action should be primary (large, colored, prominent). Others are secondary (smaller, muted). If two actions compete for priority, you probably need two separate screens.
How often should I audit?
After every major feature launch and quarterly for stable products. User behavior patterns change, new features introduce new screens, and old assumptions become stale. A quarterly audit catches drift before it impacts retention.
Can I automate the Desired Action Audit?
Analytics tools can identify where users drop off (indicating unclear desired actions) and heat maps show where users click versus where you want them to click. But the strategic question — “what SHOULD the user do here?” — requires human judgment.
What’s the most common finding in a Desired Action Audit?
Orphan screens are screens where the user completes an action and has no obvious next step. These are engagement dead-ends. The second most common: competing actions where two buttons of equal prominence ask for different things.
Doesn’t limiting actions per screen reduce functionality?
No. It redistributes functionality across multiple screens, each with purpose. You’re not removing features. You’re creating a path that doesn’t overwhelm. Think of TurboTax: it has complexity, but it’s sequenced. Each screen is simple. The product isn’t less functional. It’s more usable.
What if my users legitimately have different needs?
Then personalization or segmentation happens before your screen, not on it. If User A wants to check status and User B wants to place an order, they should land on different screens. Or your app has multiple entry points that funnel to different desired actions. But once they’re on a screen, clarity rules.
How do I know what the desired action should be?
Ask: “What would break our business model if no one did this?” Or: “What’s the one thing that increases our north star metric the most?” That’s usually your desired action. Everything else supports it or gets removed.
Can I have a secondary action on the screen?
Yes, but it shouldn’t compete visually. Secondary actions can exist: back buttons, settings, links to documentation. But they should be lower in visual hierarchy, smaller, different color. When someone looks at your screen, they see one thing first.
What about power users who want speed and complexity?
Give them settings. Advanced modes. Keyboard shortcuts. But don’t make your default experience complex to serve power users. Optimize for your median user, then provide depth for people who want it. The desired action audit applies to the default path, not to hidden options.
Isn’t this just common sense?
If it were, I wouldn’t spend so much time fixing products that violate it. Common sense and common practice are two different things. Most teams build features independently, then throw them all on a screen. This discipline requires saying no and sequencing experiences. That’s harder than it sounds.
Master the Desired Action Audit
If you’re ready to apply this discipline to your product, start with a simple exercise: pick your three highest-traffic screens. For each one, write down the one desired action you actually want users to take. Then audit everything else on that screen against that action. Does it support the desired action, or does it compete with it?
In my experience, most teams find there is more clutter to remove, hide, or move into a secondary flow than they expected. That clarity is where better conversion usually starts.
If you want a senior pair of eyes on your product’s screens — the same lens applied across products reaching over 1.5 billion users — book a Desired Action Audit with the Octalysis Group.
Related Reading
- The Octalysis Framework: Eight Core Drives of Human Motivation
- Onboarding Design: The First 5 Minutes That Matter
- Real-World Gamification Case Studies
- Behavioral Design: How to Build Products People Love