Behavioral Design Wireframes: My Octalysis Step 5 Method

Behavioral design wireframes are where every gamification project actually wins or loses. In short: behavioral design wireframes are wireframes where every element is annotated with the Core Drive it activates and the Desired Action it pushes the user toward. The Strategy Dashboard is beautiful, the brainstorm is bursting with ideas, the Power/Ease list has been argued over for weeks, the Battle Plan looks crisp. Then someone opens Figma, drops in some rectangles, labels one of them “Checkout,” and ships the file to a graphic designer who quietly turns Step 5 into wallpaper.

Step 5 of the Octalysis Design Process is where months of strategic thinking finally meets a human being. Everything upstream is invisible to the user. The wireframe is what they feel. And the part most teams get wrong is that they treat the wireframe like layout work when it is actually behavioral work — every button, transition, zero state, and bottom-nav decision is a vote for or against the behavior you said you wanted.

This is the method I have been refining for over two decades across client work at LEGO, Microsoft, Porsche, and a few governments that prefer not to be named in headlines. Wireframes are not boxes. They are blueprints for how a real person will feel inside your system the first time they show up, the hundredth time, and the time they almost rage-quit.

Speed Run Notes

• Step 5 of the Octalysis Design Process is the translation layer between hidden strategy and what the user actually feels. If it breaks here, everything upstream goes with it.
• Wireframes have two jobs, not one. Most teams nail the documentation job for developers and skip the simulation job for themselves, which is where motivational flaws hide.
• Build every screen around the Desired Action first. Layout, balance, and information hierarchy are supporting cast. If an element does not push the user toward a Desired Action or activate a Core Drive, it is clutter.
• Design the zero state, the normal state, and the max state for every screen. Most engagement deaths happen on screens new users see and screens whales hit at the ceiling.
• Placeholder steps like “Register” or “Checkout” lie about pacing. If a real step burns five minutes of attention, wireframe it screen by screen so you feel the cost the user is paying.
• Fidelity is a tool, not a status symbol. A PowerPoint wireframe you have walked through as a user beats a polished Figma file you have only built to impress a stakeholder.

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.

TEDxLausanne · Gamification to Improve Our World17 min

The Two Goals of a Wireframe (and Why Most Designers Pick One)

Wireframes serve two distinct purposes, and the failure mode of most teams is that they only consciously serve one.

The first goal is to communicate your vision to other people: developers who need to build it, stakeholders who need to approve it, investors who need to fund it, clients who need to feel the future. This goal requires completeness. Every button, every state, every edge case has to be specified in enough detail that the developer does not have to guess what tapping “Checkout” means. A well-spec’d wireframe in this mode reads like a contract.

The second goal — the one I see skipped over and over — is to let you live through the user journey before the user does. This is the empathy pass. You walk through the screens in order, as if you had never seen the product before, and ask: how do I feel when I land on the first screen? What is my emotional state by the third? Does the motivation hold across the full sequence, or does it leak out somewhere in the middle?

Goal one creates a developer-ready document. Goal two creates an experience that actually works.

Here is a real example of what skipping goal two costs you. A team I worked with had wireframed onboarding step by step, perfectly. They had not bothered to draw the bottom navigation bar yet because “we will add that later.” When we finally dropped the nav bar into the full sequence, three of the five tabs directly competed with the onboarding Desired Action. The user would land on “complete your profile” and see four glowing escape routes at the bottom of the screen pulling them somewhere else. That single oversight had been invisible in twenty-eight individual screen reviews. It only became obvious when someone walked the journey end to end.

Another example. You label a step “Registration” on the wireframe. On the deck it takes up three millimeters of vertical real estate. In reality it is a five-minute form with ten fields.

By the time the user reaches your beautifully designed post-conversion win state, they have already burned through most of the motivation energy they brought with them. The wireframe lied about pacing, so the celebration screen feels flat instead of triumphant.

The discipline is simple to state and hard to practice: if a user will see a screen, you need a wireframe for it. Not because the developer needs the spec, but because you need to feel the pacing. Include the edge cases, the zero states, the max states, the errors, and the failures. All of them shape the emotional journey.

Start With the Desired Action, Not the Layout

The most common Step 5 mistake is opening Figma and starting to arrange shapes. Designers trained in graphic design think about balance, symmetry, negative space, information hierarchy. They are thinking like visual artists. Their output looks beautiful. It also frequently has nothing to do with the behavior you wanted.

The behavioral design move is to put the Desired Action in the center of the screen and build everything else around it. The Desired Action is the main character. Navigation, copy, social proof, progress bars, secondary buttons — these are all supporting cast.

The process I run my own teams through:

1. Name the Desired Action. “Join a challenge,” “share a workout,” “claim a badge,” “invite three friends.” A verb plus a specific object. “Click here” is not a Desired Action.
2. Place it prominently. Usually center, or wherever the eye naturally lands first. Use visual weight, color, and motion to make it unmissable.
3. Add supporting context. What does the user need to know to feel ready to take that action? Proof? Social validation? A progress bar showing they are already 60% there? Each element should map to a specific Core Drive in the Octalysis Framework.
4. Add navigation, but subordinate it. Users need to be able to move around. They should not be able to easily escape the action you actually want. Intentional friction is a design choice. Accidental friction is a defect.
5. Design the feedback. What happens the instant after they act? That feedback is the reward signal. If it is delayed, generic, or disconnected from the action, the loop weakens.

I annotate every wireframe with which Core Drive each element targets. If an element cannot be traced to a Desired Action or a Core Drive, it is noise. Remove it. This single discipline cleans up more wireframes than any visual polish ever has.

Eight Behavioral Blueprint Principles for Step 5

These are the rules I check every wireframe against before it leaves my desk.

1. Every Element Traces Back to a Core Drive

The headline that celebrates the user’s streak? Core Drive 2 (Accomplishment & Feedback). The “your three friends already joined” pill? Core Drive 5 (Social Influence & Relatedness). The countdown timer above the offer? Core Drive 6 (Scarcity & Impatience).

Annotate the wireframe with these mappings. If you cannot annotate it, it does not belong.

2. Navigation Architecture Either Enables or Sabotages the Desired Action

Users should reach their destination as fast as possible, or the path should at least feel logically inevitable. Confusion in navigation equals drop-off. But sometimes you want to slow the user down — if the action requires a real decision (choosing a difficulty level, picking which friends to invite), the interface should make space for thought. Intentional friction is design. Accidental friction is failure.

3. Placeholder Steps Are Where Real Friction Hides

When you collapse “Register,” “Payment,” or “Checkout” into a single placeholder, you erase the real motivational cost of the experience. What looks like a three-second tap on the wireframe deck might be five exhausting minutes for the user. Teams routinely ship with weak post-conversion screens because they never felt how fatigued the user actually is by the time they arrive.

Practical rule: if a step takes more than thirty seconds in reality, wireframe it screen by screen. Show every form field, every validation moment, every progress indicator. Let yourself feel the weight of the minutes the user is spending.

4. Empathy Beats Functionality at the Wireframe Stage

A wireframe should not just reflect what the company wants to collect or control. It should reflect empathy for what the user is feeling at this moment of their life.

There was a government COVID app that asked users in onboarding: “Do you have anyone close to you who died of COVID recently? Who? When?” One quarter-second of empathy reveals the user is grieving. They are in pain. Yet the app proceeded mechanically with clinical questions, as if filling a tax form. Nobody on the design team paused to feel what the user would experience.

When you review a wireframe, ask: how does the user probably feel on this screen? What small shift would reduce the emotional friction? A technically complete interface can still fail if it makes users feel confused, dismissed, or unseen.

5. Realistic Placeholders Over Pretty Ones

If your wireframe is populated with unusually attractive avatars, polished stock photography, and idealized social content, the team will overestimate the strength of the design. The team falls in love with the assets, not the product. Ship the same wireframe filled with ordinary photos, average user-generated content, and inconsistent engagement and the emotional promise breaks.

Rule of thumb: use attractive placeholders when the goal is to sell the concept to stakeholders. Use realistic placeholders when the goal is to judge whether the lived experience actually works.

6. Wireframes Are Journeys, Not Isolated Screens

A wireframe can look correct on individual screens and still feel wrong as an experience. Teams say “we have the social buttons, the form fields, the call to action, the data” and still produce something cold, tone-deaf, or exhausting. They were reviewing screens in isolation instead of as a sequence.

Every design review I run is a journey review. We walk the screens in order, in real time. How does the user feel entering the first screen? What is their emotional state after the second? Does the pacing sustain through the middle of the flow, or does motivation leak out around screen seven?

7. Outline Before You Draw

Before you create any visual wireframe, write a simple outline of every element that belongs on the screen. Content elements (quotes, metadata, images). Primary and secondary Desired Actions. Feature states (active or inactive, locked or unlocked). Edge cases (what if the user hits a cap, what if they have three boosts active). Navigation cues and feedback moments. Any overlays.

Once everything is listed, the visual arrangement is the easy part. You already know what has to exist. Skipping this step is how teams end up with wireframes that miss states, confuse developers, and require rounds of rework.

8. When Metrics Conflict, Business Metrics Break Ties

Wireframes get crowded. Eventually something has to be cut or demoted. Most teams do this on taste or symmetry. The Octalysis move is to use business metrics: identify which Desired Actions each element supports, identify which business metrics those Desired Actions drive, preserve the elements tied to your top metrics, and cut the ones with weaker strategic contribution, even when the visual rhythm of the screen takes a hit from the rebalancing.

Zero, Normal, Max: Design All Three States

Most teams design only the “happy path” — the normal state where the user has average data and average activity. Real users do not stay on the happy path. Half of them are brand new, with empty dashboards and zero progress. A smaller but disproportionately important group has hit your ceiling: 99 friends, level 999, daily challenge already complete.

For every important screen, wireframe three versions.

Zero state. The user is new. No friends, no activity, no data. This is where motivation is most fragile. A wireframe that shows “0 friends, 0 challenges, 0 points” makes the user feel like nobody on a stage. Replace zero counts with the next meaningful action: “Join your first challenge,” “Invite a friend to start a streak,” “Complete your first lesson and unlock the dashboard.” Emptiness becomes momentum.

Normal state. Average activity, typical data. This is your baseline. It is also the state most teams design.

Max state. The user has hit your ceiling — 99 friends, level 999, daily challenge already done. At that point the interface either degrades gracefully or it breaks. Yahoo Answers is the canonical horror story: they shipped seven levels expecting maybe a five-year run. The product lasted fifteen years. Hardcore users hit level seven and discovered that every desired action they had previously been rewarded for now produced nothing. Their response was to create new accounts and start over from level one. If your power users would rather restart from zero than stay at max, your endgame economy has failed.

Exponentially scaling progression curves solve this. Day one delivers three levels. Month six delivers one. Year three delivers a fraction. By the time the hardcore player is approaching the ceiling, the habit has carried them for so long that the system is part of their life.

The Fidelity Spectrum: When PowerPoint Beats Figma

Wireframes exist to communicate behavioral design intent. They do not exist to look beautiful. Fidelity should match the job, not the trend.

Pen and paper. Best for solo ideation and rapid iteration. Cheap, fast, disposable. Good for the first pass through a sequence when you do not yet know what shape the flow takes.

PowerPoint or Keynote. Best for internal communication and rapid prototyping. The original Octalysis Prime island concept was sketched in Keynote. A basic octagon shape, labels like “fishing here” and “futuristic city,” vague game design notes. The final designers took that rough concept and executed it cleanly. The wireframe communicated intent without polish, and intent was what mattered.

Figma or similar. Best for client presentations and developer handoff. The current standard for professional teams. Refined enough to guide implementation, expressive enough to show intention. Most of my client work lives at this fidelity.

Pixel-perfect mockups. Best for final stakeholder approval and usability testing. Carries a risk: stakeholders sometimes confuse “this is decided” with “this is final,” and feedback dries up. Save this tier for after the behavior has already been validated.

The principle that matters more than the tool: a low-fidelity wireframe you have actually walked through as a user beats a polished wireframe you built only to check a box.

Offline Wireframes: When the Interface Is a Classroom

Wireframing is not limited to apps and websites. Any experience that unfolds in sequence can be wireframed. Physical classroom flows, workshop agendas, retail journeys, even hospital intake — all of them benefit from the same storyboarding discipline digital teams use for screens.

Food Heroes is a good example from my own work. The team did not stop at abstract strategy. They built minute-by-minute classroom storyboards covering video triggers, activity flow, transitions, reinforcement moments, and homework cycles across forty-minute sessions. That is wireframing for an offline experience, and the outcome is the same: you simulate the journey before the user walks it.

For a live experience, wireframe what happens minute by minute, who speaks when, what object or media appears next, what emotional state the participant is likely in at each moment, and what fallback you run if the activity fails. A live experience is still an interface that unfolds across time rather than pixels, and the same walk-the-journey-as-the-user discipline is what separates a workshop that holds attention from one that loses the room by minute fifteen.

The deeper insight, which I only got after running the Food Heroes storyboards: once you accept that any sequence is an interface, wireframing stops being a software-design skill and becomes a behavioral-design skill that happens to use software most of the time. The behavior is the unit of work. The medium — pixels, classroom minutes, retail aisle steps, hospital triage stations — is the wrapping. Step 5 generalizes. Teams that learn this run better digital wireframes too, because they stop confusing the tool with the discipline.

Handoff: Make the Feeling Survive the Translation

Early concept wireframes should act like storyboards, not like boxes. They need to show not just where modules go, but what the user is supposed to feel at each moment. A sterile wireframe can preserve function while losing emotional intent. When developers and graphic designers inherit boxes and labels with no feeling annotated, the motivational architecture gets flattened in implementation. The strategy survives on paper and dies in the build.

What I require on every handoff wireframe:

• Annotated tone, copy direction, and imagery intent on each screen
• Notes on the emotional moment (“this is the trust handshake,” “this is the celebration peak”)
• Storyboard-style sequence views for any behavior-heavy flow
• Explicit notes on which Core Drives each section targets

The designer who creates the wireframe understands the behavioral intent. The developer who reads it later usually does not. Annotate the feeling so the intent survives the handoff. Visual designers then add color, typography, imagery, and polish on top of a structure that is already sound. Behavior before beauty. Blueprint before polish. That is the order. The reverse, where teams build beautiful interfaces first and try to bolt behavior on later, is how Step 5 quietly kills good Octalysis work. (For a longer treatment of how that failure plays out, see my breakdown of how most wireframes quietly kill engagement.)

Where Step 5 Sits in the Full Octalysis Design Process

Wireframes do not appear from nowhere. They are the output of every prior step in the five-step pipeline.

1. Strategy Dashboard. Business metrics, player types, Desired Actions, Core Drives.
2. Octalysis Brainstorming. Mechanics generated across four experience phases and eight Core Drives.
3. Power-Ease Feature List. Ideas scored by impact and effort to filter the brainstorm.
4. Battle Plan Spreadsheet. Triggers, feedback, reward mappings, progression rules, edge cases mapped per feature.
5. Wireframes. The system rendered as a concrete lived experience.

By the time you reach Step 5, you should already have a clear Desired Action per screen (from Strategy), the mechanics that support each action (from Brainstorming), the prioritized feature set (from Power-Ease), and the detailed rules and edge cases (from Battle Plan). Wireframes visualize decisions; they should not be where you discover them. If you find yourself making new system-level decisions inside Figma, your Battle Plan is incomplete and your interface work will be unstable.

Step 5 is where backstage strategy becomes user reality. Get the upstream work right and Step 5 becomes a translation job. Skip the upstream work and Step 5 becomes a guessing game. The reason so many gamification projects feel “off” despite obvious effort is almost always that the team tried to compress Steps 1 through 4 into the wireframe itself.

FAQs

What are behavioral design wireframes?

Behavioral design wireframes are Step 5 of the Octalysis Design Process — the moment where strategic decisions about Desired Actions, Core Drives, and game loops get translated into the specific screens, buttons, and flows a real user will experience. Unlike standard UX wireframes, every element on a behavioral wireframe is mapped to a Core Drive or a Desired Action. If an element cannot be traced to one of those, it is noise and gets removed.

Where does the wireframe fit in the Octalysis Design Process?

It is Step 5, the final step. Steps 1 through 4 build the system from the inside: Strategy Dashboard, Octalysis Brainstorming, Power-Ease Feature List, and Battle Plan. Step 5 is where that internal architecture becomes a lived experience for the user. Skipping any of the upstream steps makes Step 5 unstable, because you end up making system-level decisions inside Figma instead of expressing them.

What is the most common Step 5 mistake?

Starting with layout instead of the Desired Action. Designers trained in graphic design tend to think first about balance, symmetry, and information hierarchy. The behavioral move is to put the Desired Action at the center of the screen first and build everything else around it. Layout serves behavior, not the other way around.

Do I really need to wireframe edge cases and zero states?

Yes. The zero state is where new users decide whether to invest. The max state is where your power users decide whether to keep playing or quit. Both states test your motivational architecture in ways the normal state does not. Skipping them is how teams ship interfaces that feel great in the demo and break for half the user base in production.

How is this different from regular UX wireframing?

Regular UX wireframing optimizes for usability — can the user complete the task without confusion. Behavioral design wireframing optimizes for motivation — will the user want to complete the task, return tomorrow, and tell their friends. Usability is the floor. Motivation is the ceiling. Behavioral wireframes design for the ceiling without losing the floor.

Related Reading

• The Octalysis Design Process: 5 Steps to Better Gamification Strategy
• The Octalysis Brainstorming Engine: How to Generate 100+ Engagement Ideas in One Session
• Desired Actions: An S-Tier Behavioral Designer’s Guide
• Why Do Most Wireframes Quietly Kill Engagement?
• The Octalysis Framework: Complete Gamification Guide

Take Step 5 Seriously

If you only remember one thing from this guide: Step 5 is the difference between a strategy your team is proud of and an experience the user actually feels. Wireframe every state, every edge case, every minute of every flow. Annotate the feeling. Walk the journey as the user before you ask the user to walk it for the first time. The strategy you spent months on lives or dies inside a few hundred pixels of decision.

If you want to go deeper on the framework behind every step, start with the full Octalysis Framework guide, or pick up Actionable Gamification for the long-form version.

If you want a senior Octalysis team to run Step 5 with you on a live project, talk to the Octalysis Group. We run the full five-step process for clients across gaming, finance, health, and government.

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