Desired Actions: An S-Tier Behavioral Designer’s Guide

I’ve sat in maybe two hundred gamification briefings over the last fifteen years, and roughly one hundred and ninety of them started in the wrong place. The team had a leaderboard concept. They had badge mockups. Someone had drawn a streak counter. What they did not have was an answer to the only question that matters: what desired actions are you trying to motivate?

This sounds like a small bookkeeping issue. It is the most expensive blind spot in the field. Without a clean list of desired actions, every mechanic you ship is decoration. The points float on top of behavior nobody asked for. Your leaderboard ranks players on activities that don’t produce real value. The badge celebrates a moment your business doesn’t care about. You can sense the wrongness when you use the product, but you can’t name it, because the missing piece is upstream of everything you’re looking at.

In the Octalysis Framework, desired actions are the foundation. They sit before the eight Core Drives, before the four phases of the player journey, before any mechanic you might dream up. Get them right and the rest of the design becomes precise. Skip them and you’re decorating air.

This is the long-form pillar I’ve wanted to write for a while: what a desired action actually is, why teams misidentify it, how it scales across the player journey, and the design moves that turn a list of actions into a behavioral engine.

⚡ Speed Run Notes

• A desired action is a specific, observable behavior, concrete enough that a robot could execute it. “Engage the platform” doesn’t qualify. “Click the green button” does.
• Every screen needs ONE visually dominant desired action. When two compete, attention splits and neither gets full commitment. Pinterest’s onboarding is the cleanest live example: pick eight interests, that’s it.
• Granularity is non-negotiable. Sign-up isn’t one desired action; it’s seven. Every micro-step where motivation is required gets its own line on the map, or you’ll never see the drop-off.
• Desired actions change across the four phases of the player journey (Discovery, Onboarding, Scaffolding, Endgame). The same user, same product, same week, but different actions matter at each stage. Mismatching phase to action is the most common diagnostic finding.
• Every desired action produces a Win State the moment it completes. Your only design choice is whether that Win State feels rewarding, neutral, or punishing. Anti-climactic Win States quietly bleed motivation across the whole product.
• Feedback that does not trigger a desired action belongs hidden in account settings. Surfaced feedback should ask for a next behavior, not present a static fact.
• Drop-off in any sequence of desired actions tells you which Core Drive is missing at that step. The map is the diagnosis tool, not just a planning document.

Author Credibility: Yu-kai Chou

Yu-kai Chou is the creator of the Octalysis Framework, the behavioral design system now applied to products and experiences reaching over 1.5 billion users. His book Actionable Gamification is one of the most-cited works in the field, and he has been ranked the #1 Gamification Guru in the World.

Desired actions are the part of Octalysis I get asked about most often when I consult, and the part teams most reliably skip. Every Level 1 Octalysis Certification student spends their first weekend on desired actions before they’re allowed to draw a single mechanic. The reason that sequence is non-negotiable is the same reason this post exists: you cannot motivate a behavior you have not named.

Verify: Wikipedia · Google Scholar · Wikidata · LinkedIn

What a Desired Action Actually Is (And What It Isn’t)

A desired action is a specific, observable behavior you want a user to take. The test I run with every team is the same: could a robot do this action? If a machine could mechanically execute it, you’ve found a real desired action. If the action requires human interpretation to even know whether it happened, you’ve written a goal, not an action.

Goals masquerading as desired actions ruin briefs. “Engage with our platform.” “Build community.” “Love our brand.” “Have a great session.” Lovely sentences. Useless for design. There is no green button on the screen labeled “Engage.” A user does not click “Build Community.” They click Send Reply. They click Invite. They click Post. Those are the actions. Engagement is the lagging metric you hope will move once the actions accumulate.

Real desired actions sound like this. Click the sign-up button. Input your email. Upload a profile photo. Complete the first lesson. Invite three friends. Make a purchase. Return on day three. Post a review. Each one is observable, trackable, and small enough that you can apply motivational pressure at exactly the moment the user is asked to take it.

The reason this distinction matters so much: business outcomes do not move on their own. Revenue moves because users buy. Retention moves because users return. Virality moves because users invite. If a metric matters to you, the only path forward is to trace it back to the observable action that produces it. Skip that step and your gamification is wishful thinking dressed in confetti.

The One-Per-Screen Rule

The most violated principle in product design is also the simplest: every screen should have one clear, visually dominant desired action. Even if a stranger doesn’t speak your language and has never opened your product, the screen should say this is what to do next.

I know this sounds restrictive when you have a feature-rich product. Trust me on this one. I’ve watched the alternative fail hundreds of times. When a screen offers four near-equal calls to action, the user’s attention splits four ways. Each option gets a quarter of their commitment, and confusion creeps in around the edges. Confusion isn’t a feeling people sit with; it’s a feeling people exit from.

The cleanest live example is Pinterest’s first-time onboarding. You don’t see the home feed. The search bar is gone. There is no sidebar of categories. What you see is eight interests on a clean grid and one instruction: pick what you like. That’s the entire screen. Users breeze through it because there is nothing else for them to think about, and that scarcity of options is what makes the action feel light.

When a screen needs to support more than one action, and many do, there are two ways out. Either strip the screen to one action and reveal the others later, or use a guided onboarding spotlight that darkens the rest of the interface and points the user at the one action they should take right now. Both approaches preserve the rule. The user is still only being asked to do one thing.

This was one of the six core findings in the wireframe audit I published last week — and the principle I see violated more than any other. A wireframe that lays out a beautiful dashboard of widgets, with no clue what the user should click first, is the visual equivalent of a host who hands you a menu in a language you don’t read.

Granularity: Why No Step Is “Too Trivial”

Here’s the trap I see senior teams fall into: they list desired actions at the wrong altitude. “Sign up.” “Make a purchase.” “Complete onboarding.” Those are not desired actions; they are mountains. A desired action is a single step a user takes, and most of what teams call “one action” is actually a chain of seven.

Sign-up, broken honestly, looks like this. Click the sign-up button. Type your email. Type a password. Confirm the password. Upload a profile photo. Click submit. Find the verification email. Click the link. Land back in the product. Each one is a place where a human being decides whether to keep going. Each step needs motivation, or the chain breaks.

This is where most gamification quietly fails. The team rewards the end of the sequence — “Welcome aboard! You earned 100 points!” — but applies no motivational pressure to steps two through nine. Users abandon halfway through, and the team blames “low intent” or “the funnel,” when the real problem is that nobody designed for the middle.

The discipline I want you to take from this section: list every step at the granularity of a single click or a single decision. If the step requires user motivation, it earns a line on the map. The reward is that drop-off becomes legible. You can finally see which step is bleeding users, and that’s the entire prerequisite for fixing it.

Phase-Aware Actions: Discovery, Onboarding, Scaffolding, Endgame

The same user, in the same product, has different desired actions at different points in their journey. Octalysis divides that journey into four phases. The actions that matter inside each phase are different from the actions that mattered yesterday and different from the actions that will matter next month. Mismatch phase and action, and the design feels off in a way users can’t articulate but they sense it anyway.

Discovery

The user hasn’t committed yet. They’re asking, does this even apply to me? The desired actions in this phase are about lowering activation energy. Click to learn more. Watch the explainer. Read the testimonial. Start a free trial. Download the lite version. None of these ask for serious commitment. All of them give the user a reason to look closer.

Onboarding

The user has decided to try. Now they need to feel one full loop of value before they leave. The desired actions in onboarding are about completion. Set up your profile. Make your first choice. Create your first item. Earn your first micro-win. Invite your first friend so the loop is social, not solo. The whole point of onboarding is to drag the user across the finish line of one full reward cycle, because once they’ve felt that loop close, they have evidence the system works.

Scaffolding

The basic loop is understood. Now you’re expanding the surface area without overwhelming. Unlock the next tier. Try a new feature. Take on a harder challenge. Collaborate with another player. Customize your setup. Scaffolding actions feel like you’re growing into a bigger version of the same game, not switching games.

Endgame

The user has mastered the basics. They’re playing for mastery, status, contribution, or self-expression. The desired actions look different in shape and altitude. Mentor a new player. Compete at the highest tier. Create content for the community. Customize aggressively. Defend a record. Endgame players are bored by what onboarding asked of them and offended when the product treats them like a beginner.

The diagnostic implication: when veteran users complain that the product “got worse,” nine times out of ten the product didn’t change — they did. The actions that motivated them in onboarding stopped applying when they reached endgame, and the design never offered them new ones. This pattern is the same logic that explains why so many onboarding flows quietly leak users: the next desired action stops being visible the moment the user finishes the first one.

Win States: The Reward Layer Sitting On Every Action

Every desired action produces a Win State the moment the user completes it. The Win State exists by definition: the door opened, the form submitted, the photo uploaded. The only design question is what the user feels in that moment. There are three flavors, and most teams accidentally ship the wrong one.

Rewarding. The user takes the action and the product responds with progress, recognition, or momentum. Password accepted, green checkmark, “welcome back.” Form submitted, your application is being reviewed. Photo uploaded, your friends loved it. The user feels their action mattered. Rewarding Win States carry the user into the next action without a fresh push.

Neutral. The user takes the action and nothing happens. Page refreshes silently. The next form appears. No acknowledgment that the previous step counted for anything. The Win State exists but feels hollow, and over enough hollow moments, the user learns that their actions don’t register. That’s the slow corrosion that produces the dreaded “I’m not sure what I’m getting out of this product anymore.”

Punishing. The user does exactly what was asked and feels worse afterward. Password rules revealed only after submission. Verification emails that yank the user out of the product into an inbox full of distractions. Confirmation pages that say “Confirmed.” in twelve-point sans-serif on white space and nothing else. I wrote a longer post on this exact failure mode (the three Win State traps that kill sign-up flows), and the punishing Win State is the one that does the most damage per occurrence.

The reason “Win State” is the right word: the framing makes the design question concrete and testable. Instead of asking “is this experience good?” (which nobody can answer with confidence), you ask “when the user finishes this action, do they feel rewarded, neutral, or punished?” That second question has an answer a hallway test with five users can deliver in an afternoon, and once the diagnosis lands, the fix tends to design itself.

The Feedback Mechanic Test: Surface or Hide

Most products surface the wrong feedback. The dashboard shows you how much you’ve spent this month, your current score, your last achievement. Useful information, none of it asking for a next move. The user reads it, processes it, and is left standing in the middle of the room with no instruction about what to do next.

The test I want you to run on every feedback element on your screen: does this trigger a desired action? If yes, surface it prominently. If no, hide it in account settings.

Feedback that triggers action looks like this. A progress bar showing three of eight lessons done triggers do the next lesson. The fifty-day streak counter triggers return tomorrow. Show a badge bar at 70%, and the trigger is finish what’s missing. Surface that fifteen friends are playing, and the trigger becomes see who’s playing. Every one of these turns information into a forward push.

Feedback that doesn’t trigger action looks like this. “You’ve spent $247 on this platform this month.” Technically a feedback display. Triggers what, exactly? Probably regret. Probably churn. That data belongs in account history, where users can find it if they need it, never in the main flow where it competes with the actions you actually want.

The principle compresses to a single rule: surfaced feedback must ask for a next behavior. If it can’t, it should not be on the main screen. This sounds obvious in the abstract and gets violated on every dashboard I’ve ever audited.

Sequencing Actions: Chronology, Not Importance

Once you have a granular list of desired actions, the next question is what order to place them in. Most teams sort by business importance: revenue actions first, retention actions second, viral actions third. That feels rational and produces a worse design every time.

The right ordering is chronological. List the desired actions in the order the user will encounter them, not the order your CFO cares about. The reason chronology wins: a chronological map reveals exactly where motivation drops off. If 70% of users start step one but only 20% reach step five, the gap between four and five is your problem, and now you know where to apply intervention.

Importance ordering is for your business metrics dashboard, which is a separate tool with a separate audience (you and your team, not the user). Conflating the two produces designs that try to monetize at the wrong moment, ask for retention behavior before the user has tasted value, or push virality on someone who hasn’t yet completed onboarding. Each of those is the same root error: importance ranking applied to user-facing sequence.

One more move I want to flag: stitch the actions into a single experience, not a sequence of mini-loops. The temptation is to design “the loop for action one,” “the loop for action two,” and so on, dropping the user back to neutral between each. A better design carries momentum across boundaries, where completing action one increases readiness for action two, which then warms the user up for action three. The user feels like they’re on a single arc instead of grinding through a checklist.

Mapping Desired Actions to Core Drives

Once your action map is clean and chronologically ordered, the next layer is asking which Core Drives apply to each action. The answer is usually two to four. Never all eight. Forcing more Core Drives into a single action produces noise, not motivation.

An example I use in workshops. A beginner uploading their first photo. The Core Drives that fit: Development & Accomplishment (“you uploaded your first photo!”), Social Influence (“share this with your friends”), and Empowerment of Creativity (“now you can customize your profile”). That’s three drives, each pulling in the same direction without competing. Each one is authentic to the moment.

The same user three months later, perfecting their craft, has different drives doing the work. Development & Accomplishment shifts to mastery recognition. Loss & Avoidance shows up as “don’t break your streak.” Ownership emerges through the unique collection of work they’ve built up. Same product, same user, same action, but different Core Drive interventions because the user is in a different phase.

One more move from the diagnostic side. When you can’t get a desired action to fire, the question to ask is which Core Drive’s anti-drive is blocking it. A confused user is trapped in the anti-drive of Development & Accomplishment. The helpless user is trapped in the anti-drive of Empowerment. A bored user is trapped in the anti-drive of Unpredictability. Anti-drives don’t show up on positive heat maps, but they’re the reason actions fail to launch.

The Diagnostic Power: Finding Where Motivation Leaks

The most underused application of desired actions is diagnostic. Once your map exists and is chronological, you can lay funnel data over the top and the leak shows up the way a heat signature shows up under thermal imaging.

Here is the exercise I run with consulting clients on day one. Take the sign-up flow we broke apart earlier — the seven-step chain from click sign-up to land back in the product. Now lay a real funnel on top:

• Step 1, click sign-up: 100% (this is the population)
• Step 2, type email: 92%
• Step 3, type password: 88%
• Step 4, confirm password: 71%
• Step 5, upload profile photo: 38%
• Step 6, click submit: 36%
• Step 7, verify email and return: 22%

The leak is obvious now in a way it never was when you only saw “23% sign-up completion.” The drop between step 4 and step 5 is enormous, and the drop between step 6 and step 7 is the second-largest. Two separate leaks, two separate diagnoses, two separate fixes.

Now apply the Core Drive overlay. Step 5 fails because the profile-photo upload is the first moment the product asks the user for visible commitment, and Core Drive 4 (Ownership & Possession) hasn’t been built up yet. There is nothing yet for the user to feel ownership of. The fix is not better copy on the upload screen. It’s giving the user something to own (name your space, pick your color, claim a username) before you ever ask for a photo.

Step 7 fails because the verify-email loop ejects the user out of the product, into an inbox, where Core Drive 7 (Unpredictability & Curiosity) is hijacked by every unread message they haven’t opened yet. The fix is not a more aggressive reminder email. It’s removing the email roundtrip entirely — verify by magic link inline, or defer verification until after the first reward loop closes.

Neither of those interventions would have been obvious looking at the aggregate metric. Both become unmissable the second you have the granular map plus the Core Drive overlay.

This is why I tell teams that desired actions are not preparation for the design. They are the design’s diagnostic substrate. You don’t draft them, file them, and forget them. You return to them every time the product underperforms, because the answer is almost always sitting in the gap between two steps you’d already mapped but stopped looking at.

The Five Questions Before You Touch a Mechanic

If you take one practical artifact away from this post, take this. Before you draw a single mechanic for a gamified experience, write the answer to these five questions. If you can’t answer them in one or two sentences each, you don’t have a brief. You have a wish.

1. Who is the player? Be specific. “Customers” is not specific. “First-time visitors who arrived from a TikTok ad and haven’t seen the product before” is.
2. What is the desired action you want them to take? One sentence, observable, robot-passable. Not “engage.” A specific action.
3. Which phase of the journey are they in when you ask for it? Discovery, Onboarding, Scaffolding, or Endgame. Each phase has different rules about what’s appropriate to ask.
4. Which two to four Core Drives are doing the motivational work? Name them. Map them to the action. If you can’t, the action isn’t well-defined yet, or the Core Drives aren’t authentic to the moment.
5. What is the Win State, and how will the user feel when it fires? Rewarding, neutral, or punishing. If you can’t predict the answer, prototype the moment and find out before you scale.

I’ve watched teams who could only answer two of these confidently produce a year of mechanics that made no impact on the metric they cared about. I’ve watched teams who could answer all five precisely produce designs that moved retention double digits within a release cycle. The math is consistent. Mechanics built on top of clean desired-action thinking outperform mechanics built on vibes by a margin that doesn’t show up on a single screen but compounds across the product over months.

If you want the deeper version of this thinking — the full architecture of how Octalysis ties desired actions to Core Drives to player phases to Win States — that’s what Actionable Gamification is for. The book treats desired actions the way I do in consulting engagements: not as prelude, but as the spine the rest of the design hangs on.

Frequently Asked Questions

What’s the difference between a desired action and a goal?

A desired action is observable and specific: a click, a form submission, a return visit. A goal is the lagging outcome those actions are meant to produce: engagement, retention, revenue. You design for actions because actions are what users take in real life. Goals move only when the underlying actions accumulate.

How granular should my desired actions list be?

Granular enough that each step represents one human decision to keep going. Sign-up isn’t one action; it’s typically seven to ten. If a step requires motivation to complete, it earns its own line. The reward for granularity is being able to see exactly which step is bleeding users in your funnel data.

How many desired actions should be on a single screen?

One, visually dominant. If a screen needs to carry more, either strip it back and reveal additional actions later, or use a guided onboarding spotlight that visually quiets everything except the action being asked for. Two competing actions of equal weight is the failure mode to avoid.

Do desired actions change as a user matures in the product?

Yes, and this is one of the most overlooked design facts. The actions that matter in onboarding (complete the tutorial, make your first choice) are not the actions that matter in endgame (mentor a newer player, compete at the highest tier). Same user, same product, different phases of their journey, different actions worth motivating.

Where should I start if my product is already shipped and I’ve never done this exercise?

Map the desired actions retroactively, in chronological order, for the first thirty minutes of new-user experience. Lay your funnel data over the top. The largest drop-off is your highest-leverage intervention point. Fix that one before you touch anything else, then repeat the exercise for week-two retention behavior, then for power-user retention.

Where to Take This Next

Desired actions sit at the foundation of every behavioral design that works. Mechanics applied without them are decoration. Mechanics applied on top of a clean desired-action map become precision tools. The first move, the move I’d ask you to take this week, is to write down the desired actions in your product the way I described — granular, chronological, phase-aware — and lay your funnel data on top.

The leak you find will surprise you. It almost always does. And once you can name it, you can fix it.

The next read most people get the most out of is the Octalysis Framework overview — that’s where the rest of the architecture lives (the eight Core Drives, the four phases, the Game Techniques), and it’s the natural sequel to this post. If you want the long-form treatment with case studies for every Core Drive, that’s what Actionable Gamification is for. If you’re applying this to a specific product right now and want a direct review, consulting engagements are the fastest path.

WOULD YOU LIKE YU-KAI CHOU TO WORK WITH YOUR ORGANIZATION?