Health Decision-Making and Goal-Setting

Summary

This chapter applies a structured decision-making process to weigh how health decisions affect personal and community wellbeing from multiple perspectives, evaluate options and consequences, and choose and justify the healthiest option. Students then use that same structured approach to evaluate focus areas and set personal health goals individually, with support, or collaboratively.

Concepts Covered

1. Health Decisions And Personal Wellbeing
2. Health Decisions And Community Wellbeing
3. Multiple Perspectives On Health Decisions
4. Evaluating Options In Health Decisions
5. Evaluating Consequences In Health Decisions
6. Choosing The Healthiest Option
7. Justifying Health Choices
8. Evaluating Health Decision Outcomes
9. Health Goal Focus Area Evaluation
10. Individual Goal-Setting Process
11. Supported Goal-Setting Process
12. Collaborative Goal-Setting Process
13. Formulating Goal Strategies
14. Evaluating Goal Strategy Outcomes

Prerequisites

Builds on individual and interpersonal factors in health practices and community/societal/environmental factors from Chapter 13: Influences on Health Behavior.

---

From understanding influences to making the call

Chapter 13 showed you why a health behavior happens — the whole stack of individual, interpersonal, community, and policy forces pressing on every choice. This chapter hands you the tool for what to do with that understanding: a repeatable process for actually making a hard health decision, and then a matching process for setting a goal and following through on it. Both skills use the same underlying logic, so once you learn it, you have it for the rest of your life.

A Structured Model for Health Decisions

Most people make health decisions by instinct, mood, or whoever spoke last. That approach works fine for low-stakes choices, but it breaks down under pressure, ambiguity, or when a decision affects more than one person. This chapter uses a six-step framework — DECIDE — that turns a vague "what should I do?" into a process you can walk through under stress and defend afterward:

1. Define the decision that needs to be made
2. Explore the realistic options
3. Consider the consequences of each option
4. Identify the healthiest option
5. Decide and act
6. Evaluate the outcome

Every remaining concept in this chapter's first section is one step of this model, applied to a single running example so you can see the whole process work end to end: Maya, a junior, was just offered a ride home from a party by a friend who has been drinking.

Diagram: The DECIDE Framework Walkthrough

The DECIDE Framework Walkthrough

Type: workflow

sim-id: decide-framework-walkthrough
Library: Mermaid
Status: Specified

Bloom Taxonomy: Apply
Bloom Taxonomy Verb: use, demonstrate

Learning objective: Apply the six-step DECIDE decision-making model (Define, Explore, Consider, Identify, Decide, Evaluate) to a realistic health scenario, tracing how each step builds on the last.

Purpose: Give learners a persistent visual anchor for the model referenced throughout the chapter, using Maya's ride-home scenario as the worked example at every step.

Visual style: Mermaid flowchart, six sequential nodes in a loop shape (the final "Evaluate" node loops back to "Define," showing decisions feed future decisions); every node has a click handler.

Steps: 1. "Define" — click: "Maya defines the real decision: how do I get home safely tonight, given that my planned ride has been drinking?" 2. "Explore" — click: "Maya lists real options: ride with her friend, call a parent, use a rideshare app, ask another sober friend, stay over." 3. "Consider" — click: "For each option, Maya considers consequences — physical safety, relationships, cost, curfew, honesty with parents." 4. "Identify" — click: "Maya compares consequences against her values and identifies which option best protects health and safety." 5. "Decide" — click: "Maya acts: she calls her mother for a ride and texts her friend that she is not getting in the car." 6. "Evaluate" — click: "Afterward, Maya reflects: did this decision keep me safe? What would I do differently next time?" Loops back to Define for the next decision.

Color coding: Each step a distinct color (blue, teal, gold, orange, red, purple) in a circular flow to emphasize decision-making as a repeating cycle, not a one-time event.

Implementation: Mermaid flowchart with click directives opening an infobox reusing the text above for each node.

Health Decisions And Personal Wellbeing

Every health decision starts with recognizing its effect on personal wellbeing — physical safety, mental and emotional health, and long-term goals. Defining the decision clearly is step one of DECIDE, and it is easy to skip: people often act before they have actually named what they are deciding. Maya's real decision is not "should I be rude to my friend?" — a frame that would make refusing feel unkind — it is "how do I get home safely tonight?" Naming the decision accurately changes which options even occur to you.

A precise definition also separates a decision from the emotions surrounding it. Feeling anxious about disappointing a friend is real, but it is a feeling about the decision, not the decision itself. Personal wellbeing includes both the immediate outcome (arriving home unhurt) and the longer arc (staying someone who can be trusted to make sound calls under pressure).

Health Decisions And Community Wellbeing

A choice framed only around personal wellbeing misses half the picture, because most health decisions ripple outward to family, peers, and the wider community. If Maya's friend drives while impaired, the risk is not contained to the driver: passengers, other drivers, pedestrians, and anyone who later has to respond to a crash (first responders, hospital staff, grieving families) all bear some part of the consequence. A personal decision to get in — or stay out of — that car is simultaneously a community-safety decision.

This ripple effect runs in both directions. A community's norms and resources shape what a personal decision even costs: a community with reliable free late-night rideshare vouchers for teens makes the "call for a ride" option cheap and fast; a community without one makes it slower, costlier, or unavailable, which is exactly the kind of community-level factor Chapter 13 taught you to notice. Health decisions and community wellbeing are linked in both directions — individual choices affect the community, and community conditions affect which individual choices are realistic.

Decision	Personal wellbeing effect	Community wellbeing effect
Riding with an impaired driver	Injury or death risk to self	Risk to other road users; strain on emergency services
Skipping a recommended vaccination	Personal disease risk	Reduced herd immunity affecting immunocompromised community members
Vaping at a friend's house	Personal respiratory/addiction risk	Normalizes use for younger siblings or peers present
Reporting a peer's suicidal statement to a trusted adult	Emotional discomfort, fear of breaking trust	Potentially saves a life; strengthens a school's help-seeking culture

Notice the pattern in that table

In every row, the "personal" and "community" columns are not separate stories — they're the same decision viewed at two zoom levels. Skilled decision-makers habitually check both columns before acting, because a choice that looks purely personal almost never actually is.

Multiple Perspectives On Health Decisions

Because health decisions affect more than the person making them, the same decision can look completely different depending on whose perspective you take. Maya's driving friend might see the ride offer as a normal favor between friends and feel hurt by a refusal. Maya's parents might see the decision through a safety-first lens and want to be called regardless of the hour. A school administrator might view the same night through a policy lens — was there an underage drinking issue that needs a broader response? None of these perspectives is simply "wrong"; they are different lenses shaped by different roles, values, and stakes in the outcome.

Taking multiple perspectives seriously does not mean a decision has to satisfy everyone. It means checking your reasoning against viewpoints you might otherwise ignore, which often reveals blind spots. A decision that looks perfectly safe from one angle (a friend's feelings) can look dangerous from another (a parent's safety concerns) — and in health decisions, safety concerns generally outweigh social comfort.

Diagram: Multiple Perspectives Stakeholder Map

Multiple Perspectives Stakeholder Map

Type: diagram

sim-id: multiple-perspectives-stakeholder-map
Library: vis-network
Status: Specified

Bloom Taxonomy: Analyze
Bloom Taxonomy Verb: differentiate, examine

Learning objective: Analyze how a single health decision affects and is viewed differently by multiple stakeholders (self, peer, family, community), distinguishing each stakeholder's primary concern.

Components to show: Central node "Health Decision" with a dropdown to select a scenario (impaired-driver ride, vaping at a gathering, skipping a vaccine, reporting a peer crisis). Four surrounding stakeholder nodes: Self, Peer/Friend, Family, Community/School.

Connections: Edges from the central decision to each stakeholder node, labeled with that stakeholder's primary concern for the selected scenario (e.g., Self: "physical safety"; Peer: "feeling excluded or judged"; Family: "wants to be contacted, prioritizes safety"; Community: "broader norm or policy implications").

Interactive features: Clicking a stakeholder node opens an infobox showing a one-paragraph explanation of that stakeholder's perspective and why it differs from Self's perspective. Learner can drag nodes; a "Compare perspectives" toggle highlights any two selected nodes' concerns side by side to show where they align or conflict.

Visual style: Radial/star layout, Self at center.

Color scheme: Self (gold), Peer (blue), Family (teal), Community (navy).

Working Through a Health Decision: Options, Consequences, and Justification

The next four concepts are the working core of DECIDE — Explore, Consider, Identify, and the justification that follows Identify — applied step-by-step to Maya's scenario.

Evaluating Options In Health Decisions

The Explore step means generating a realistic range of options before judging any of them. A common decision-making failure is narrowing to just two choices too early ("get in the car or ruin the friendship") when more options usually exist. For Maya's situation, a fuller option set might include:

• Ride with the friend who has been drinking
• Call a parent or guardian for a ride
• Use a rideshare app
• Ask another sober friend or attendee for a ride
• Stay at the location until someone sober can drive, or overnight if safe
• Walk, if the distance and route are genuinely safe

Generating this list before evaluating any option matters because premature judgment ("Mom will be mad") can quietly delete a genuinely good option before it is fairly considered. Evaluating options well means listing them all first, then judging.

Evaluating Consequences In Health Decisions

The Consider step weighs each option's likely consequences across several dimensions at once: physical safety, emotional/relational impact, financial cost, and alignment with personal values. A consequence table makes the comparison concrete instead of abstract:

Option	Physical safety	Relationship impact	Other consequences
Ride with impaired friend	High risk of crash/injury	Avoids awkwardness now	Legal risk if stopped; guilt if something happens
Call a parent	No safety risk	Possible short-term tension or curfew conversation	Builds trust over time; costs nothing
Rideshare app	Low safety risk	Neutral	Costs money; requires phone/payment access
Ask a sober friend	Low safety risk	Depends on friend's availability/mood	May feel like "asking a favor"
Stay overnight	No travel risk	Requires host's/parents' permission	May need to coordinate logistics

A trap to watch for when weighing consequences

People tend to overweight the consequence that will happen in the next ten minutes (an awkward conversation) and underweight the consequence that might happen later but matters more (a crash). When comparing options, deliberately ask "what's the worst realistic outcome, and how likely is it?" for each one — not just "what's uncomfortable right now?"

MicroSim: Consequence Weighing Calculator

Consequence Weighing Calculator

Type: microsim

sim-id: consequence-weighing-calculator
Library: p5.js
Status: Specified

Bloom Taxonomy: Apply
Bloom Taxonomy Verb: calculate, apply

Learning objective: Apply a weighted-consequence comparison to rank decision options by combining likelihood and severity scores for physical safety, relationship, and other consequences.

Canvas layout: Left (450px): a table of 5 options (matching the ride-home scenario) with sliders per option for "likelihood of a bad outcome" (1-5) and "severity if it happens" (1-5). Right (250px): computed risk score (likelihood x severity) per option displayed as a sorted bar list, updating live.

Interactive controls: Slider pair per option (likelihood, severity); dropdown to switch the whole scenario to two additional preset examples (deciding whether to report a peer's substance use to an adult; deciding whether to attend a gathering with no adult supervision); "Reset to defaults" button.

Default parameters: Preloaded plausible starting values for the ride-home scenario (e.g., Ride with impaired friend: likelihood 3, severity 5; Call parent: likelihood 1, severity 1).

Behavior: As sliders move, the right-side bar chart re-sorts in real time from lowest to highest computed risk score, so the learner sees which option becomes "safest" as they adjust their own risk estimates.

Instructional Rationale: This is an Apply-level objective requiring learners to use a calculation (likelihood x severity) on realistic option sets, not merely recall that consequences exist — a live-updating calculator lets them test how sensitive the "best" choice is to their own risk estimates.

Implementation notes: p5.js sliders and a live-redrawing horizontal bar chart; store scenario data as a JS array of objects.

Choosing The Healthiest Option

The Identify step compares the consequence analysis against a clear standard: which option best protects physical safety, mental/emotional health, and long-term wellbeing — for both the person deciding and others affected? In Maya's case, calling a parent or using a rideshare both score far better than riding with an impaired driver on every safety dimension, even though they carry minor social cost. Identifying the healthiest option is not the same as identifying the easiest or most popular one — those two answers only sometimes match.

Choosing the healthiest option can also mean rejecting a false binary. Maya doesn't have to choose between "loyal friend" and "safe passenger" — she can decline the ride and still show care by texting the friend later, or by encouraging the friend to also avoid driving. The healthiest option often includes ways to reduce harm for others in the situation, not just protect yourself.

Justifying Health Choices

Choosing well is only half the skill; being able to justify the choice — to yourself, to a friend who feels rejected, to a parent who asks "why didn't you just come home with your friend?" — is what makes a decision durable under social pressure. A strong justification names the specific evidence and values behind the choice, rather than just asserting a conclusion:

"I called my mom instead of riding with you because impaired driving is one of the leading causes of teen death, and that risk was higher than any awkwardness from asking for a ride. I still value our friendship — that's actually why I texted you not to drive either."

Notice the structure: it states the reasoning (safety risk outweighs social cost), cites the relevant fact, and separates the decision from the relationship, which prevents the refusal from being misread as rejection. Justifying a choice well often reduces the very social friction people fear when they imagine making the harder, healthier choice.

Justifying a choice out loud can feel harder than making it

It's normal for explaining a healthy decision to friends or family to feel more uncomfortable than making the decision itself. That discomfort fades with practice — and a clear, values-based justification like the one above usually earns more respect over time than it costs in the moment.

Evaluating Health Decision Outcomes

DECIDE's final step loops back on itself: after acting, evaluate the outcome. Evaluation asks several distinct questions, and they don't always point the same direction:

• Did the decision achieve its immediate goal (Maya got home safely)?
• Was the process sound, regardless of outcome (would this same reasoning have been the right call even in a version of that night where nothing went wrong)?
• What would you do differently next time, and what worked well enough to repeat?

That second question matters because outcomes and process quality can diverge: a well-reasoned decision can still turn out badly by chance (a rideshare gets in its own unrelated accident), and a poorly-reasoned decision can still turn out fine by luck (riding with the impaired friend and arriving home unharmed). Evaluating the process, not just the result, is what actually improves future decisions — judging only by outcome can teach the wrong lesson ("it worked out, so it must have been fine").

Quick check: process vs. outcome — Click to expand

A student decides not to wear a helmet while biking to save time, and nothing bad happens. Was this a good decision?

Answer: No — evaluate the process, not just the outcome. The decision carried real risk regardless of that day's result. A good outcome from a risky process is luck, not evidence the process was sound.

Applying the Same Process to Goal-Setting

Here is the connecting idea for the rest of this chapter: setting and achieving a health goal is a structured decision-making process extended over time. Instead of one decision made once, goal-setting is a series of linked decisions — what to focus on, how to pursue it, what strategy to use, and how to judge progress — each of which can use the same DECIDE logic you just practiced.

Diagram: Decision-Making to Goal-Setting Bridge

Decision-Making to Goal-Setting Bridge

Type: graph-model

sim-id: decision-to-goal-bridge
Library: vis-network
Status: Specified

Bloom Taxonomy: Understand
Bloom Taxonomy Verb: compare, exemplify

Learning objective: Explain how each step of the DECIDE decision-making model maps onto an equivalent step of the goal-setting process, showing goal-setting as decision-making applied repeatedly over time.

Node types: Two parallel chains of six nodes each — top chain "Decision- Making Steps" (Define, Explore, Consider, Identify, Decide, Evaluate); bottom chain "Goal-Setting Steps" (Evaluate Focus Area, Explore Process Type, Formulate Strategies, Choose Strategy, Act on Plan, Evaluate Outcomes).

Edge types: A horizontal "maps to" edge connecting each top node to its corresponding bottom node (e.g., "Define" maps to "Evaluate Focus Area"; "Explore" maps to "Explore Process Type"; "Consider" and "Identify" map to "Formulate Strategies" and "Choose Strategy"; "Decide" maps to "Act on Plan"; "Evaluate" maps to "Evaluate Outcomes").

Sample data: Clicking any "maps to" edge opens an infobox explaining the parallel in one sentence, e.g., "Just as you first Define a decision, you first must Evaluate which health focus area actually deserves a goal."

Layout: Two horizontal rows, decision-making on top, goal-setting on bottom, aligned in columns.

Interactive features: Hover a node for its definition; click a connecting edge for the mapping explanation; zoom and pan enabled.

Visual styling: Top row in the six DECIDE colors from the earlier diagram; bottom row in matching shades one tone lighter, visually pairing each step.

Legend: "Decision-making step" vs. "Goal-setting step," with the mapping edges explained as "same underlying skill, applied over time."

Implementation: vis-network with a fixed two-row hierarchical layout.

Health Goal Focus Area Evaluation

Just as DECIDE starts by defining the decision, goal-setting starts by evaluating which focus area actually deserves a goal — this is the Define step applied to your own life as a whole rather than to a single moment. A useful evaluation looks across multiple wellbeing domains (physical activity, nutrition, sleep, mental/emotional health, relationships, substance-free choices) and asks which area currently has the largest gap between where you are and where you want to be, and which gap actually matters most to you.

Focus-area evaluation resists two common mistakes: picking a goal because it's trendy or because someone else assigned it (that's not evaluation, it's imitation), and picking a goal so vague ("be healthier") that no specific action follows from it. A well-evaluated focus area is specific enough to point toward action: not "sleep," but "I fall asleep past midnight most weeknights and it's affecting my mood and grades."

Diagram: Health Goal Focus Area Self-Assessment

Health Goal Focus Area Self-Assessment

Type: infographic

sim-id: health-goal-focus-area-assessment
Library: Chart.js
Status: Specified

Bloom Taxonomy: Evaluate
Bloom Taxonomy Verb: judge, prioritize

Learning objective: Evaluate personal wellbeing across six focus-area domains (physical activity, nutrition, sleep, mental/emotional health, relationships, substance-free choices) to justify prioritizing one area for goal-setting.

Chart type: Radar/spider chart, six axes, one per wellbeing domain.

Purpose: Let learners self-rate their current standing (1-5) on each of six domains, then visually identify the domain with the lowest score and/or the domain they mark as "matters most to me" via a separate priority-weight slider per axis, producing a combined "priority score" (gap size x personal importance).

X-axis/Y-axis: Not applicable (radar chart); six labeled axes around the perimeter.

Data series: One series per learner (self-rating), one overlay series for "where I want to be" (target rating), so the gap between current and target is visually the shaded area between the two polygons.

Interactive elements: Slider per axis for current rating and target rating; hovering any axis point shows the numeric gap; a ranked list below the chart auto-sorts domains by gap x importance to suggest a top-priority focus area, with a text box for the learner to write why they agree or disagree with the suggestion.

Title: "Where Should My Health Goal Focus?" Legend: Current rating (blue polygon) vs. target rating (gold polygon).

Implementation: Chart.js radar chart plugin with linked sliders.

Individual Goal-Setting Process

Once a focus area is chosen, the Explore step of goal-setting becomes choosing a process type. The simplest is the individual process: you set the goal, plan the approach, and monitor progress mostly on your own, without formal outside involvement. This process fits goals that are private, low-risk, and within a person's existing skills and resources — for example, a goal to walk 20 minutes daily or reduce late-night screen time before bed.

An individual process still benefits from structure. A goal stated as "specific, measurable, achievable, relevant, and time-bound" (SMART) is far easier to evaluate later than a vague intention:

Vague: "I want to sleep better." SMART: "I will be in bed with lights off by 11:00 p.m. on school nights, checked by my own phone's screen-time log, for the next four weeks."

Supported Goal-Setting Process

Some goals are better pursued with support — a process where you keep ownership of the goal but deliberately involve someone with more knowledge, authority, or resources: a coach for a fitness goal, a school counselor for a stress-management goal, a doctor for a nutrition or sleep-disorder goal, or a parent for a goal involving a household change (like reducing screen time, which needs someone else's cooperation with Wi-Fi routines).

The supported process differs from doing it entirely alone in one key way: you are borrowing expertise or accountability you don't have yourself, while still driving the decision. It differs from full collaboration (next concept) because the goal still belongs primarily to you — the support person advises or assists, but does not co-own the goal's success or failure.

Collaborative Goal-Setting Process

A collaborative process goes a step further: two or more people set and pursue a shared goal together, with joint ownership of both the plan and the outcome. Examples include two friends training for a 5K together, a family jointly committing to more device-free dinners, or a school club setting a shared goal to reduce stigma around mental health resources on campus (directly echoing Standard 9.3.1.7 from Chapter 13).

Choosing collaborative over individual or supported is itself a decision worth running through DECIDE: collaboration adds accountability and shared motivation, but it also requires coordinating schedules, resolving disagreements about the plan (using the negotiation and conflict-resolution skills from Chapter 13), and tolerating that the group may move at a different pace than any one person would alone.

Process type	Who owns the goal	Best fit	Example
Individual	You alone	Private, low-risk, within your own skill/resources	Reducing screen time before bed
Supported	You, with an advisor's input	Needs outside expertise or accountability you lack	Training plan designed with a coach
Collaborative	Shared, jointly	Goal is inherently social or needs group buy-in	Friends training for a 5K together

Choosing a process type is itself a DECIDE decision

Notice you just used Explore and Consider again — listing the three process types and weighing their fit for your specific goal. The DECIDE model isn't just for one-time choices like Maya's ride home; it is the same reasoning you now apply to a much longer-running decision: how you will pursue a goal over weeks or months.

Formulating Goal Strategies

With a focus area and a process type chosen, the Consider/Identify work of goal-setting is formulating a strategy — the specific actions, supports, and checkpoints that will move you from current state to target state. A strong strategy usually includes:

• A concrete first action (not just an intention)
• Specific supports enlisted (a person, an app, a schedule change)
• Anticipated barriers and a plan to work around them
• Checkpoints for reviewing progress before the final goal date

For a sleep-goal example: "First action: charge my phone in the kitchen, not my room, starting tonight. Support: ask my sibling to remind me at 10:45. Anticipated barrier: weekend schedule is different, so I'll set a looser 12:30 a.m. weekend target. Checkpoint: review my screen-time log every Sunday for four weeks."

MicroSim: Goal Strategy Builder

Goal Strategy Builder

Type: microsim

sim-id: goal-strategy-builder
Library: p5.js
Status: Specified

Bloom Taxonomy: Create
Bloom Taxonomy Verb: formulate, construct

Learning objective: Formulate a complete strategy to support a personal health goal, assembling a first action, a support, a barrier plan, and a checkpoint schedule into one coherent plan.

Canvas layout: Left (400px): four labeled drop zones — "First Action," "Support Enlisted," "Barrier + Workaround," "Checkpoint Schedule." Right (300px): a bank of draggable example strategy-component cards plus a blank custom-card option (text input) so learners can write their own.

Interactive controls: Drag-and-drop cards into the four zones; a "Focus area" dropdown (sleep, physical activity, nutrition, stress management) that swaps the example card bank to match; button "Generate my plan summary" that compiles the four filled zones into a single readable paragraph.

Default parameters: Focus area = sleep; drop zones start empty, prompting the learner to build rather than view a finished example.

Behavior: When all four zones are filled, the "Generate my plan summary" button becomes active and produces a plain-language paragraph combining the four choices, modeling how a real SMART goal strategy reads as connected prose rather than a checklist.

Instructional Rationale: This is a Create-level objective (formulate a strategy), so the pattern is a builder/model-editor with draggable components rather than a passive example — learners must assemble an original plan from parts, which is what distinguishes formulating a strategy from merely recognizing one.

Implementation notes: p5.js drag-and-drop with defined drop-zone hit regions; text input DOM element for custom cards; string concatenation for the summary.

Evaluating Goal Strategy Outcomes

Just as DECIDE ends by evaluating a decision's outcome, goal-setting ends by evaluating the strategy and the outcome together — and, as with decisions, these can diverge. A goal can be fully achieved through a weak process (reaching a step count only by obsessively overtraining in a way that risks injury) or only partially achieved through an excellent process (a sleep goal that improved bedtime by 45 minutes instead of the full hour, but revealed exactly which barrier — weekend schedule — needs a better strategy next time).

Evaluation should examine three separate questions: Was the checkpoint data actually tracked, or is the "outcome" just a guess? Did the specific strategy components (support, barrier plan) function as intended? And does the plan need revision, or does the goal itself need to change based on what was learned? This loops the whole model back to Define/Focus Area Evaluation — exactly the same cyclical structure you saw in Maya's decision, now operating on a longer timescale.

Diagram: Goal Strategy Outcome Evaluation Rubric

Goal Strategy Outcome Evaluation Rubric

Type: infographic

sim-id: goal-strategy-outcome-rubric
Library: p5.js
Status: Specified

Bloom Taxonomy: Evaluate
Bloom Taxonomy Verb: assess, critique, justify

Learning objective: Evaluate a completed goal-setting scenario's process and outcome against a four-criterion rubric (data tracked, strategy components functioned, goal partially/fully achieved, plan revision needed), producing a written evaluation.

Purpose: Give learners practice judging goal outcomes on process quality, not just success/failure, echoing the process-vs-outcome distinction from the decision-making evaluation earlier in the chapter.

Layout: Left panel: one of three preset four-week goal scenarios (sleep, physical activity, stress management) presented as a short checkpoint log (weekly entries with notes). Right panel: four-criterion rubric with a 1-4 rating slider per criterion and a text box for justification.

Interactive elements: Selecting a scenario loads its checkpoint log; rating each criterion unlocks a "Compare to model evaluation" button that reveals expert reasoning per criterion, similar in structure to the conflict-resolution rubric rater from Chapter 13 but applied to goal outcomes.

Data to display: Three four-week checkpoint logs with realistic mixed results (partial success, one failed checkpoint, one component that didn't work as planned) so learners must weigh genuine trade-offs rather than rate a uniformly successful example.

Color scheme: Neutral gray log panel; gold slider handles; green/red comparison highlight after reveal.

Implementation: p5.js with DOM text panels and a custom slider-rubric widget.

Diagram: Health Goal Feedback Loop

Health Goal Feedback Loop Interactive Poster

Type: infographic

poster-id: health-goal-feedback-loop
Library: p5.js
Status: Published

Nine circular stations show health goals as a flexible feedback process rather than a pass-or-fail test.

Use Explore mode to select a marker or section and learn more. Use Quiz mode to practice finding each idea.

Bringing It Together

Every concept in this chapter is one step of a single repeatable process, used at two different time scales. At the scale of a single moment, DECIDE takes you from a vague dilemma to a justified, healthy choice you can evaluate afterward. At the scale of weeks or months, the same six moves — defining a focus area, exploring a process type, considering and formulating a strategy, acting, and evaluating outcomes — turn a wish ("be healthier") into a goal you can actually track and adjust. Neither skill works well as pure instinct; both work well as a structure you can return to, refine, and eventually run almost automatically.

You now own a repeatable process, not just a one-time answer

You can now define a real health decision, explore genuine options, weigh consequences from your own and others' perspectives, choose and justify the healthiest path, and evaluate how it went — and you can run that exact same structured thinking across weeks or months to set and achieve a health goal, individually, with support, or as part of a team. That is the DECIDE model, and it is yours to reuse for the rest of this course and far beyond it.