How to Outline a Wireframe Before You Draw (4-Step Method)

I used to draw wireframes the way most people do. No wireframe outlining method. No plan. Just stare at the blank Figma canvas, start placing rectangles, move them around, realize the navigation does not work, delete everything, start over. By the third or fourth restart I would usually figure out what I actually wanted to build, but the screens that came out were patched together from those false starts, which meant some of them were load-bearing and some of them were just where I had given up rearranging.

The screens went to a graphic designer. The graphic designer made them beautiful. The product launched. Engagement was mediocre, and nobody could tell you why, because the wireframe was not a plan — it was a record of a person making decisions in real time while pretending those decisions were design.

So I changed my process. I stopped drawing wireframes until I had outlined them first. Outlining a wireframe means doing the planning work on a sheet of paper before any rectangle hits the canvas: which screens exist, how they relate, what lives on each one, and which one carries the business. Done well, the outline takes thirty minutes. Done well, the wireframe afterward takes one deliberate pass instead of four patching rounds.

This post is the four-step wireframe outlining method I use on every Octalysis Group client project before I open Keynote or Figma. The steps are not exotic. The order is what makes them work, and the order is what makes the wireframe defensible when it lands on the graphic designer’s screen and the developer’s ticket queue and, eventually, the user’s phone.

Speed Run Notes

• Wireframing without an outline produces the “draw, scrap, redraw” loop most designers do not notice they are stuck in; thirty minutes of structured outlining upstream breaks the cycle entirely.
• Step 1 lists the minimum set of unique screens (containers of experience) the product actually needs, derived from the desired-action list and the game loop.
• Step 2 arranges the containers into a hierarchy diagram so depth-to-desired-action is visible at a glance, which lets you cut or promote before you draw.
• Step 3 pulls every element on every container from three planning artifacts simultaneously (PE Feature List, Game Loop, Battle Plan) and forces you to name the ONE desired action per screen.
• Step 4 sets your bottom-nav order by business-metric priority — whichever container drives your top metric earns the center tab, with everything else arranged around that anchor.

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

Why I Outline Before I Draw

The trap with wireframing is that the tool wants you to draw. Figma opens to a blank artboard. Keynote opens to a blank slide. The medium is pre-disposed toward production, not planning, and most designers oblige the medium.

But a wireframe is supposed to communicate experience design: the WHAT the user does, the WHY each element exists, the FLOW from one screen to the next. The drawing is the OUTPUT of those decisions. When you draw before you decide, you are inverting the order of operations. The screens fill up with elements you have not justified yet, the navigation drifts toward whatever happened to feel symmetric, and the desired actions get added at the end as labels on buttons that were placed for layout reasons.

If you have ever stared at a finished wireframe and thought “okay, but what is this app actually FOR,” that is a wireframe drawn without an outline.

Outlining is the cheap part. It is done with a list, a hierarchy diagram, and a one-line answer to “what is the desired action on this screen.” It costs you thirty minutes of structured thinking. What it buys you is a wireframe you can defend, line by line, on the principle that every element on a screen drives a desired action, every screen drives a metric, and every metric ties back to the business goal. That is the wireframe that survives the graphic designer pass without losing its meaning along the way.

I will walk through the four steps using the same example I use in the Octalysis Design Process course, ChangeRoots, a civic engagement app where the central business metric is donations to political campaigns. The pattern itself transfers cleanly to any product where you have already done the upstream behavioral-design work and now need to translate it into screens a user will actually touch.

Step 1 — Identify Your Containers of Experience

A “container of experience” is my term for a unique screen, one with its own interaction mode that cannot be folded into another screen without losing what it does. The login page is one container. The home feed is one container. The settings page is one container. A modal that pops over the feed is usually NOT its own container; it is a sub-experience that lives inside the feed container.

The first move is to list every container the product needs. The rule I use is minimum unique containers, not maximum. Every container the user has to learn is a tax on their cognitive load, and most of the apps I audit have three or four containers that exist for organizational reasons rather than user reasons. Those should be merged.

Where do the containers come from? Two sources you should already have if you have worked through the first four Octalysis Design Process steps: the list of desired actions and the game loop diagram.

Walk the desired actions one at a time and ask: does this action need its own container? Some do. “Compare politicians side by side” is a database experience. It cannot be a row on the feed. It needs a container. “Donate five dollars” is a desired action, but it does not need its own screen. It can live as a button row on a politician card inside the feed. Same goes for “view context on a quote.” That is a subscreen that opens from the feed, not a top-level container.

Then walk the game loop and ask the same question of every node: does this loop or trigger imply a dedicated interface? The “daily chest opens at 9am” mechanic might need a dedicated daily-chest screen, or it might live as a celebratory overlay on the feed. The “earn 100 EXP to unlock the next archetype” loop might need a progress screen, or might tuck inside the profile.

By the end of Step 1 you should have a list that fits on an index card. ChangeRoots, for example, came out to Feed, Politidex, Store, Learn, and Profile. Five containers, with everything else (Daily Chest, Context, Donate, Submit Content) demoted to a subscreen of one of those five rather than promoted to its own top-level interface.

Step 2 — Organize the Hierarchy

Take the container list and arrange it as a tree. Top-level containers are the ones the user can navigate to directly from the bottom nav or main menu. Subscreens hang under their parent, reachable only from inside that parent’s flow.

For ChangeRoots, the hierarchy looked like this. Feed (top-level) had three subscreens: Daily Chest (triggered by tapping the chest icon), Context (links out from a quote on the feed), and Donate (either inline or as a subscreen depending on the interaction). Politidex (top-level) had Politician Detail as a subscreen. Store (top-level) had Item Detail. Learn (top-level) had Individual Quiz. Profile (top-level) had Submit Content as a subscreen.

The hierarchy is doing two jobs at once. It is telling you what the bottom nav will look like. Five top-level containers means a five-tab nav, four means a four-tab nav, and anything over five usually means you need to cut something. And it is telling you the depth a user has to traverse to reach any given desired action, which is a hidden engagement cost most teams do not measure.

When you sketch the hierarchy and a desired action sits four levels deep, the diagram itself makes the call for you. Either the action at the bottom of that chain is not important enough to justify the depth and you cut it, or it is so important that you need to promote it up to a top-level container and let it claim its own tab on the nav bar.

Step 3 — Pull Components from Three Sources

For each container in the hierarchy, you now answer: what elements live on this screen?

The mistake here is brainstorming components from scratch. You already have three sources that tell you what belongs:

The PE Feature List is your prioritized feature inventory from earlier in the Octalysis Design Process. Walk it container by container. For each V1 feature, ask which container it lives on: “Daily quote display” → Feed. “Politician scorecard” → Politidex. “Donation button” → Feed (inline on politician card) and Politidex. By the end you have mapped every V1 feature to a container.

The Game Loop tells you which trigger/action/reward sequences run through each container. The Feed in ChangeRoots is where the “see today’s content → react → earn points → see streak” loop happens, which means the Feed container needs UI for today’s content card, reaction buttons, points feedback, and streak indicator. Those four elements are non-optional. Without them the loop breaks and the engagement plan collapses.

The Battle Plan is your sequencing document: what gets unlocked when, what feedback fires when, which rewards appear at which stage of the player journey. The Battle Plan tells you that on a Day 1 user’s Feed, the daily chest icon is grayed out with a “comes back tomorrow” tooltip. On a Day 7 user’s Feed, the chest icon shows a “5-day streak bonus” badge. Same container, different states. The Battle Plan is the schedule of state changes the wireframe needs to depict.

Pull from all three. Then, for the container, write one line: the ONE desired action this screen exists to drive. Not three. Not five. One. Every other element on the screen is a trigger pointing toward that desired action, or a piece of context that helps the user perform it, or it is a distraction that needs to be cut.

The Feed in ChangeRoots: desired action = donate to a politician based on what they said or did today. Everything else on the Feed earns its place by either surfacing the trigger (today’s quote or action), providing the context (politician scorecard inline), or capturing the conversion (donation button). The points system, the streak indicator, the daily chest icon: all of those exist to bring the user back to the Feed so they can encounter the donation trigger again, which makes them scaffolding for the desired action rather than competing surfaces that fragment the user’s attention.

Step 4 — Let Business Metrics Decide Your Navigation

The last step is the one most teams skip, and it is the one that costs them most.

The order of your bottom-nav tabs is a business decision, not a design decision. The tab in the center position gets the most thumb-reach, the most accidental taps, the most discovery, and the most muscle-memory taps from returning users. Whichever container hosts the desired action that drives your number-one business metric belongs in the center position.

For ChangeRoots, the number-one metric is donations. Donations happen on the Feed. Therefore the Feed sits in the center tab. Not the home tab on the left, not the discovery tab on the right, but center, where the user’s thumb already lives.

When you have to cut a container (and you usually do, because five tabs is already a lot to ask), do not cut by gut. Walk back up the chain: which desired actions does this container drive, and which business metrics do those desired actions drive? The container least connected to the top business metrics is the one that gets cut, or demoted into a subscreen of a more important container, not arbitrarily but through the business-metric lens.

This is also where a lot of teams discover that their navigation order is wrong. They had Profile in the center tab “because the user is the center of the experience” or some similar phrase that sounds nice and is not a business reason. The business-metric lens cuts through the rhetoric. Profile is a settings container. Settings is not a metric, so it gets moved to the edge of the nav bar where settings-tier features belong, freeing the center for the container that actually drives revenue.

The ChangeRoots Walkthrough, End to End

Here is how the four steps came together on ChangeRoots, written as a single chain so you can see the logic running end-to-end:

Step 1 — Containers. From the desired-action list and the game loop, the unique containers were Feed, Politidex, Store, Learn, and Profile. Daily Chest, Context, and Donate were considered as containers and demoted to subscreens of Feed. Submit Content was demoted to a subscreen of Profile. Five top-level containers, four major subscreens.

Step 2 — Hierarchy. Feed at the top with three subscreens (Daily Chest, Context, Donate). Politidex with Politician Detail underneath. Store with Item Detail. Learn with Individual Quiz. Profile with Submit Content. The depth analysis showed donation could happen at depth-1 (inline button on Feed) or depth-2 (Feed → Donate subscreen). We made it depth-1 because the business metric demanded zero friction on the conversion path.

Step 3 — Components per container. The Feed got today’s quote card, politician scorecard inline, reaction buttons (from the game loop), donation button (the conversion surface), points indicator (game loop feedback), streak counter (game loop feedback), and daily chest icon (game loop hook). Desired action for the Feed: donate based on today’s content. Politidex got a searchable politician database, a comparison view, and detailed scorecards. Desired action: discover politicians worth donating to. Store, Learn, and Profile each got the same treatment: three planning sources walked, one desired action named.

Step 4 — Navigation order. Donations drive revenue. Donations happen on the Feed. The Feed sits center. Politidex (discovery of who to donate to) sits one to the left. Store (using accumulated points as a hook back into the loop) sits one to the right. Learn and Profile take the outer positions because they support engagement but do not directly drive the revenue metric.

By the end of this outline (maybe two hours including discussion with the founders) the team had a one-page document that any of us could hand to a wireframer, and the wireframes that came back from a single round of drawing were defensible against any question a stakeholder might ask. We drew once.

You Do Not Need Figma (And Why That Is the Point)

Nearly every person who joins the Octalysis Group arrives without Figma or Photoshop skills. Engineers, diplomats, authors, executives, a few academics. They all learn wireframing inside the course, and by the end of their first client project they are handing high-fidelity wireframes to teams that did not know their advisor was a few weeks ago a complete beginner with the tools.

The reason is that wireframing is not a graphic-design skill. It is an experience-design skill expressed through whatever drawing tool you happen to have at hand.

I build most of my own wireframes in Apple Keynote. Pretty ugly, communicates everything I need. When I built the original concept for Octalysis Prime, the first version was a rough Keynote drawing: a hand-drawn octagon, random icons pulled from Google Image search, an arrangement of shapes. I gave that ugly file to a graphic designer who turned it into the island experience members know today. The shape of the experience was already correct because the outline behind it was correct.

If you can sketch on paper, you can wireframe. If you can drag boxes in Keynote or PowerPoint, you can wireframe to a level a client will accept. The fidelity is the last five percent of the work, and the last five percent is where graphic designers earn their keep. The first ninety-five percent (the experience design, the desired actions, the hierarchy, the navigation order) is yours to do, and the outlining method is how you do it without needing a graphic-design background to validate your decisions. For a deeper read on the design-skill question, see “Octalysis Level 2 Requirements: The Wireframing Test.”

The Diagnostic Questions to Ask at Each Step

The outline gets you a structurally correct wireframe. The diagnostic questions get you an emotionally correct one. After each step, run the appropriate question against your output:

After Step 1 (containers): “Could I cut one of these and merge it into another?” If yes, do it. The fewer containers, the lower the cognitive tax on the user. Tim Ferriss has a principle from his startup advisory work. When he visits a product team, he tells them to remove buttons and navigation items, and their engagement metrics go up afterwards. The reason: twenty options paralyze users, and two options get fully engaged with. Cut until cutting hurts.

After Step 2 (hierarchy): “Standing in the user’s shoes, does this hierarchy make them feel smart, or does it make the product feel smart at their expense?” There is a difference. A clever information architecture that organizes the product elegantly for the team is not the same thing as an architecture that lets a first-time user predict where things are without instruction. Photoshop is sophisticated software; using Photoshop makes most people feel stupid for the first six months. Build for the user feeling competent, not for the product feeling clever.

After Step 3 (components per container): “What is the ONE desired action on this screen, and would a foreign-language user know where to click without reading a single word?” This is the Foreign Language Test. Imagine you land on a page in a language you cannot read (Polish, Mandarin, Welsh, whatever you do not speak). If the desired action button is visually dominant and obviously the right click, you have passed. If the screen has two equally weighted buttons and you would have to guess, you have failed. Most agree-to-terms pages on airport wi-fi fail this test, which is why people accidentally click the wrong button and end up paying for a daypass they did not want.

After Step 4 (navigation): “Is the center tab driving my number-one business metric, or did it land there because someone on the team thought it felt right?” Tab-order intuitions are almost always wrong, especially when the team has been staring at the same prototype for weeks and has lost the ability to see it the way a first-time user does. The business-metric lens corrects the intuition by forcing a measurable answer instead of an aesthetic preference, which is why this question is the last one you ask before the outline becomes the wireframe and the wireframe becomes the build spec.

Frequently Asked Questions

What is wireframe outlining?

Wireframe outlining is the planning work you do BEFORE you start drawing any screens. You list your containers of experience, organize them into a hierarchy, map which elements live on each container, and order the navigation by business metric. The outline answers WHAT the wireframe will show before you commit to HOW it will look. Done well, the outline takes thirty minutes and saves you three rounds of throwaway drawing.

Why outline a wireframe instead of just drawing it?

Because drawing tools push you toward production before you have a plan. Figma opens to a blank artboard, you start placing rectangles, and you end up with a screen layout you then justify after the fact. Outlining inverts that order — you decide what the wireframe will say first, then you draw what you have already decided. The drawing becomes a single deliberate pass instead of three rounds of patching.

What are the four steps of the outlining method?

Step 1: identify your containers of experience — the unique screens, in their minimum set. Step 2: organize them into a hierarchy, distinguishing top-level containers from subscreens. Step 3: pull the elements that live on each container from three sources at once (the PE Feature List, the Game Loop, the Battle Plan) and name the ONE desired action that container exists to drive. Step 4: order your navigation so the container hosting your number-one business metric sits in the center tab where the user’s thumb naturally lives.

Do I need Figma or Photoshop to wireframe?

No. The Octalysis Group trains engineers, diplomats, authors, and executives, and most arrive with no graphic-design tools at all. They build wireframes in Apple Keynote or on paper, and they deliver client-ready work by the end of their first project. Wireframing is an experience-design skill expressed through whatever drawing tool you happen to have. The first ninety-five percent of the work is the outline; the last five percent is the graphic polish, which is where graphic designers earn their keep.

What is a container of experience?

A container of experience is a unique screen with its own interaction mode — one that cannot be folded into another screen without losing what it does. The Feed is one container. A modal that pops over the Feed usually is not — it is a sub-experience inside the Feed container. The first job of outlining is listing the minimum set of containers your product actually needs, not the maximum set your team can imagine.

Related Reading

• Behavioral Design Wireframes: My Octalysis Step 5 Method — the broader Step 5 methodology that this outlining method fits inside.
• Why Do Most Wireframes Quietly Kill Engagement? — the six behavioral-design principles that should be alive in every wireframe you produce.
• The Octalysis Design Process: 5 Steps to Better Gamification Strategy — the full five-step process; outlining is the planning layer of Step 5.
• Desired Actions: An S-Tier Behavioral Designer’s Guide — the foundation desired-actions concept this method depends on.
• Octalysis Level 2 Requirements: The Wireframing Test — what level-2 Octalysis certification requires from your wireframes.

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