Week 16: Design Your Decision Protocol
Build Your System
A protocol is a plan that tells you what to do before you have to think about it. The best decisions are made in advance, calmly and rationally — not in the moment when you're tired, stressed, or tempted.
This week we take the Problem Map from Week 15 and build a Decision Protocol — a simple system designed to override the problematic default behavior at the key decision points.
- The protocol should be simple enough to actually follow. If it has more than 3-4 steps, it's too complex.
- Help the student be realistic. A protocol that requires superhuman willpower will fail.
- The "stress test" in Session 2 is where partners poke holes in the plan. This is valuable, not discouraging.
- The protocol is a hypothesis, NOT a final answer. It will be tested in Week 17 and improved in Week 18.
Week at a Glance
| Prep time | ~5 minutes |
| Materials | Problem Map from Week 15, index cards or sticky notes, pencil |
| Key vocabulary | protocol, trigger, default action, pre-mortem |
| Difficulty | Advanced |
Facilitator Preparation
- Have the student's Problem Map from Week 15 ready
- Prepare the Protocol Template (below)
- Think about protocols you use in your own life (even unconsciously) to share as examples
- Prepare "stress test" scenarios based on the student's specific friction point
The best protocols feel almost too simple. That's the point. A protocol needs to work when you're tired, rushed, or not thinking clearly. Complexity is the enemy of follow-through.
For Younger Learners (Ages 8–9)
Simplest version of the concept: "You're making a plan for your friction point — like a recipe that tells you exactly what to do when the problem shows up."
What to shorten or skip:
- Focus on the Protocol Template with just 2 parts: "When ___ happens, I will ___." Skip the formal "check" component.
- Skip the pre-mortem and stress-test formalities. Just ask: "What could go wrong with this plan?"
- Keep the protocol to 1–2 steps maximum. Simpler = more likely to stick.
- Keep sessions to 20 minutes.
Adapting the activities:
- Use an index card to write the protocol. One card = one protocol. Tape it somewhere visible (bathroom mirror, inside of backpack flap, on the fridge).
- Model with a real example: "My friction point is losing my keys. My protocol: When I walk in the door, I put my keys in the bowl. That's it!"
- Let the learner pick their trigger and action with guidance. The facilitator can suggest options: "When you feel like arguing with your sister over the TV, you could: (a) flip a coin, (b) set a timer to take turns, (c) ask a parent. Which would YOU actually do?"
Journal alternative: "My protocol: When ___ happens, I will ___." Draw a picture of yourself doing it. Spoken is fine.
What success looks like: The learner has ONE clear "When ___, I will ___" plan written down and posted somewhere they'll see it.
- Full protocol with trigger, default action, and check/review built in.
- Run the stress-test: brainstorm 3–5 scenarios where the protocol might fail and design fallbacks.
- Conduct a pre-mortem: "Imagine it's next week and your protocol failed. What went wrong?"
- Write Protocol v1.0 as a formal document they'll test in Week 17.
Guided Session 1
Protocol Design Workshop
Learning Goal
By the end of this session, the student can:
- explain the three components of a decision protocol (trigger, default action, check)
- design a first draft protocol for their friction point
- give an example of a protocol they already use (even if they didn't know it was one)
Activities
1. Protocols You Already Use
Start by recognizing that protocols are everywhere:
"A protocol is just a pre-planned response to a situation. You already have tons of them:"
| Trigger | Default Action | Check |
|---|---|---|
| Alarm goes off | Get out of bed | Am I actually up? |
| See a red light | Stop the car | Look both ways |
| Feel hungry at lunch | Open lunchbox and eat | Did I eat enough? |
| Someone says "hello" | Say "hello" back | (Automatic) |
| Fire alarm sounds | Walk to exit | Is everyone together? |
Remember the walk-away point from Week 7? That was a protocol! Trigger: reaching your limit. Default action: stop. Check: did I follow through? Today we're building a fuller version of that same idea.
"Most of these are automatic — you don't even think about them. We're going to BUILD one on purpose for your friction point."
2. The Protocol Template
A Decision Protocol has three parts:
📝 DECISION PROTOCOL v1.0
Friction Point: ________________________
TRIGGER:
When does this decision/situation happen?
What's the cue that tells me "this is the moment"?
DEFAULT ACTION:
What will I do automatically when the trigger fires?
(This should be the "good" behavior I want to build.)
CHECK:
How will I know if the protocol is working?
What will I measure or observe?
When will I check? (Daily? Weekly?)
3. Build the Protocol
Work through each section together using the student's friction point.
Example — "I run out of allowance too fast":
TRIGGER: Whenever I want to buy something that costs more than $3
DEFAULT ACTION:
1. Wait 24 hours before buying
2. During the wait, check: Do I still want it tomorrow?
3. If yes, check: Do I have enough money left for the rest of the week?
4. If yes to both, buy it. If no to either, skip it.
CHECK:
Track spending in Decision Journal every Sunday.
Goal: Have at least $2 left at the end of each week.
Example — "I'm always late for school":
TRIGGER: Every night at 8pm (the evening BEFORE)
DEFAULT ACTION:
1. Pack backpack completely (check every pocket)
2. Set out tomorrow's clothes
3. Put shoes by the front door
4. Set alarm with 10 extra minutes of buffer
CHECK:
Morning checklist on my bedroom door.
Goal: Walk out the door by 7:15 (currently leaving at 7:25).
Example — "I procrastinate on homework":
TRIGGER: Getting home from school (walk in the door)
DEFAULT ACTION:
1. Put backpack on desk (not on the floor)
2. Set a 25-minute timer
3. Work on homework until the timer goes off
4. Take a 5-minute break, then decide if I need another round
CHECK:
Rate my stress level before bed (1-10).
Goal: Average stress below 4 (currently around 7).
Now the student writes their own.
4. The Simplicity Test
Review the protocol with this question:
"Imagine it's the worst possible moment — you're tired, rushed, and not thinking clearly. Would you still be able to follow this protocol?"
If the answer is "probably not," simplify. Cut steps. Reduce decisions. Make the default action as automatic as possible.
"The best protocol is the one you'll actually use, not the one that looks impressive on paper."
Guided Session 2
Stress-Test Your Protocol
Learning Goal
By the end of this session, the student can:
- identify potential failure points in their protocol
- explain what "edge cases" are and why they matter
- iterate on their protocol based on feedback
Activities
1. The Stress Test
The caregiver (or a sibling/friend) plays the role of "stress tester." Their job is to find holes:
"I'm going to throw scenarios at you. For each one, tell me: does your protocol still work?"
Generic stress tests:
- "What if you're really tired that day?"
- "What if someone interrupts you in the middle of the protocol?"
- "What if you completely forget about the trigger?"
- "What if it works for 3 days and then you slip on day 4?"
- "What if the situation is slightly different than usual?"
Specific stress tests (based on the student's problem):
- For the allowance protocol: "What if a friend invites you to buy something together right now?"
- For the lateness protocol: "What if you can't find your packed bag because someone moved it?"
- For the homework protocol: "What if you have a really fun playdate right after school?"
2. The Edge Case Fix
For each failure scenario, discuss:
- How likely is this? (If very unlikely, maybe we don't worry about it.)
- If it happens, what's the backup plan?
- Do we need to add an "if/then" to the protocol?
Add edge cases to the protocol:
EDGE CASES:
If [situation], then [backup action].
If [situation], then [backup action].
But limit to 2-3 edge cases max. More than that = too complex.
3. The Pre-Mortem
Introduce a powerful professional tool:
"A pre-mortem is when you imagine it's 3 weeks from now and your protocol FAILED completely. Now you look backwards and ask: why did it fail?"
Have the student write:
"It's Week 18. My protocol didn't work. The most likely reason is: ________________________"
Now: Can you add a safeguard against that failure? If so, add it to the protocol.
If the most likely failure is "I just forgot" or "I stopped caring," the solution might be:
- A daily reminder (alarm, sticky note, parent prompt)
- Accountability (tell someone about the protocol and ask them to check in)
- Reward (if the protocol works for one full week, some small reward)
4. Protocol v1.0 — Final Draft
Write the final version of the protocol neatly. This is version 1.0 — it WILL be updated in Weeks 17-18.
Independent Practice
Goal
Finalize the protocol and prepare for the testing phase.
Activities
1. Write the Protocol Card
Create a physical card (index card or sticky note) with the protocol that can be placed where the trigger happens:
- Allowance protocol: in your wallet or piggy bank
- Lateness protocol: on your bedroom door
- Homework protocol: on your desk
The card should be simple enough to read in 5 seconds.
2. Set Up the Tracking System
Design how you'll collect data next week:
- What exactly will you measure?
- How will you record it? (Tally marks? A daily rating? A simple tracker?)
- How often will you check in?
Minimum viable version (younger learners): Write your protocol on an index card: "When ___, I will ___." Put it where you'll see it every day. Try to follow it for 3 days. Each night, mark a check (✓) if you followed it or an X if you didn't. No judgement — just honest tracking.
Decision Journal
Write the full protocol in your journal (trigger, default action, check, edge cases). Then make a prediction: On a scale of 1-10, how confident are you that this protocol will work? What probability do you give it? What's the most likely thing to go wrong?
Reflection Questions
- Why is a protocol more powerful than just "trying harder"?
- What's the difference between a protocol and a rule someone else gives you?
- If you could install one automatic protocol in your brain right now (like an app update), what would it be?
Quick Mastery Check
After this week, check whether the learner can:
- Name the three parts: "What are the parts of your protocol?" (Looking for: a trigger, an action, and ideally a check — or at minimum "When ___ happens, I will ___.")
- Explain why it helps: "Why is a pre-made plan better than just trying harder?" (Looking for: "Because in the moment I won't be thinking clearly" or "Because I already decided what to do.")
- Anticipate failure: "What could go wrong with your protocol?" (Looking for: at least one realistic scenario — "I might forget" or "I might be too tired to follow it.")
If the learner has a protocol with a clear trigger and action, and can identify at least one way it might fail, they're ready to test it in Week 17.
Pause and Notice
After the protocol design session, ask:
"How does it feel to have a PLAN for your friction point? Does it feel empowering — or does it feel like another rule you have to follow?"
"A protocol you design for yourself is different from a rule someone else gives you. YOU chose it. YOU know why it matters. That ownership is what makes it work. If it doesn't feel right, change it — it's YOUR protocol."
This week's takeaway: The best protocol is one simple enough to follow on your worst day. Don't aim for perfect — aim for doable.
Spiral Review
- From Week 7: "The walk-away point from Week 7 was your first protocol! 'When I've spent $X, I stop.' Now you're building a more complete version for a different problem."
- From Week 11: "Is your protocol for a two-way or one-way door? Two-way door protocols can be more experimental — try it, and if it doesn't work, change it easily."
- From Week 5: "Your protocol should guard against the biases you've learned about. If your friction point involves impulsive decisions, build in a delay: 'Wait 5 minutes before deciding.'"
- From Week 15: "The root cause you found last week is the TARGET. Your protocol is the TOOL. Make sure the protocol actually addresses the root cause, not just the surface symptom."