Master the strategic decision of selecting the right site map element for your project. You will learn to identify when to use static pages, page stacks, or decision points to align your design with user goals and project risks. This lesson empowers you to visualize complex logic and resolve stakeholder disagreements effectively.

Learning Objective: By the end of this lesson, learners will be able to select the appropriate site map element (static pages, page stacks, or decision points) based on project constraints and user flow complexity.

The strategic choice between static pages, page stacks, and decision points defines how users navigate and how stakeholders understand the product's logic. This isn't merely structural; it's a move that balances clarity against the complexity of user flows.

Experienced practitioners use a specific heuristic: map the risk, not just the content. This forces you to look beyond the inventory of pages and ask what the user is actually doing.

When the goal is exploration, static pages work best for informational sites. But if the user must follow a set path to succeed, page stacks are optimal for task-based flows.

Decision points become essential when user paths diverge based on choices. This is critical when usability issues carry severe consequences, like safety risks or lost sales.

Teams often default to static pages, rationalizing that they can add the logic later. This leads to a disconnect where critical decision points remain invisible until development is complete.

By identifying these three core site map elements, you can select the appropriate representation. You'll describe the specific project conditions that favor each structure.

Then, you'll apply the 'Map the Risk' heuristic to determine the optimal map structure. This prevents stakeholder gridlock and ensures your testing covers the paths where users actually get stuck.

Key Points:

The sequence begins by reading specific signals in your project environment. You need to identify the conditions that favor each site map representation. This moves you away from guessing and toward evidence-based structure.

Stakeholder disagreement is a powerful signal. When teams argue about design direction, friction blocks progress. Switching to a decision-point model resolves this because seeing is believing. Visualizing the logic turns opinion into evidence. This breaks the gridlock and aligns the team.

Task complexity points directly to page stacks. If users must complete a series of steps, linear progression works best. Think of a corporate training course or a checkout flow. The goal is task completion, not browsing. Page stacks help you pace content for comprehension. This ensures users don't get overwhelmed by information.

High-stakes consequences demand rigorous mapping of decision points. Consider a healthcare app calculating medication dosage. A wrong input here isn't just bad UX; it's dangerous. You must map every branch to catch safety risks. The cost of a missed path is too high to ignore.

Data availability changes how you validate your choices. If you can test options against real user behavior, do it. This prevents decisions based on the Highest Paid Person's Opinion. You rely on facts, not hunches. This keeps your map grounded in reality.

Apply the Map the Risk heuristic to determine the optimal structure. Ask three questions. Is the outcome binary or linear? Use page stacks. Are there critical branching points with risk? Use decision points. Is the goal exploration? Use static pages. This heuristic forces you to look beyond content inventory. You focus on what the user is actually doing. This prevents rationalizing the wrong choice for simplicity.

Key Points:

Let's say you are building a medication dosage calculator where a wrong input could lead to dangerous outcomes. You don't just list the screens; you explicitly map out where a user might make a critical error. This is the moment you choose Decision Points because a user choice leads to significantly different risks.

Now, imagine you are designing an online learning module where new employees must follow a set path to succeed. The outcome is binary or linear, so you use Page Stacks to represent that specific flow. This approach breaks the content into manageable chunks that are paced for comprehension without overwhelming the user.

Consider a corporate website where the primary goal is exploration rather than task completion. If the user is browsing for information without a specific task, you use Static Pages to establish a basic inventory. This method works best when your project timeline is short and you need clarity without modeling complex interactions.

The core principle here is to look beyond the inventory of pages and ask what the user is doing. You must also ask what happens if they make the wrong choice to truly map the risk. Visualizing this logic moves the conversation from opinion to evidence and prevents the "we can add the logic later" trap.

When stakeholders disagree on the design direction, seeing the branching logic often resolves disputes because seeing is believing. You avoid the cost of the Highest Paid Person's Opinion by using data to validate the chosen map structure. This heuristic forces you to identify critical branching points before development begins.

By applying the "Map the Risk" heuristic, you select the appropriate site map element based on project constraints. You now know how to apply this decision framework to determine the optimal map structure for any scenario. This ensures your map serves as a dynamic model of user behavior, not just a static list.

Key Points:

Pause and think about your last project where a simple page map failed to capture the real user risk. Did you default to static pages because they were easy, or did you actually map the logic? This is where you apply the heuristic to map the risk, not just the content.

Consider a healthcare app building a medication dosage calculator. If you treat this as static pages, you bury critical safety warnings deep in the code until a fatal error occurs. Instead, you must use decision points to visualize exactly where a user might skip a warning and cause harm. Seeing this branching logic moves the conversation from opinion to hard evidence.

Now contrast that with a corporate training course for new employees. Here, the goal is a linear progression through lessons, so you need page stacks to define that specific task flow. If you miss this distinction, you risk stakeholder gridlock or ineffective testing that never uncovers where users get stuck. Ask yourself: is the outcome binary, or is it a linear path?

Key Points:

A frequent error is defaulting to static pages because they are easier to draw, rationalizing that logic can be added later. This leads to a disconnect between your map and the actual user experience, leaving critical decision points invisible until development is complete. You might avoid the immediate friction of mapping complex flows, but you will face much higher costs when safety warnings or revenue logic are buried in code.

Watch out for stakeholder gridlock when you skip mapping decision points in high-stakes environments. Without visualizing the branching logic, teams remain stuck in political debates because the facts of the user flow are not visible. Seeing the consequences of different paths is often the only way to move from opinion to evidence.

To prevent this, review your current project's user flows and apply the Map the Risk heuristic to validate your structure. Ask yourself if the outcome is linear, if there are critical branching points, or if the goal is simple exploration. This forces you to look beyond the inventory of pages and determine what the user is actually doing when they make a wrong choice.

That brings us full circle: your site map must reflect the logic of the product, not just the list of its parts. By mapping the risk, you ensure your design serves the user's needs while protecting your team from costly oversights.

Key Points: