Section 315 of 440
Complete canonical tutorial. This reader section contains the same teaching body as PWR-133 · Design thinking. Open the Power dossier.
PWR-133 · SELF GUIDED full tutorial
Turn supplied evidence into three reversible prototypes without inventing empathy
Design thinking here means understanding a bounded context, separating observations from assumptions, framing a testable problem, generating alternatives, making small reversible prototypes and learning from task-specific feedback. The exercise uses a fictional community-room name-card return problem. The learner does not invent a demographic persona, claim to know another person’s feelings or implement a real service change.
1 · Permission and limits
Know exactly what you may do
2 · Get ready
Gather what you need and check the starting conditions
What you need
- Exact fictional evidence packet: after each of three events, 9–12 of 30 reusable name cards remain on tables; the current return box sits behind the open exit door and is not visible from the final table; the cleaner moves remaining cards to the office; one supplied note says ‘I looked for the return place while leaving and did not see it.’ These are fixture facts, not real participant data.
- Observation–assumption sheet, role map, problem-frame card and three paper-prototype kits.
- Walkthrough rubric for visibility, reach, clarity, burden, reversibility and rights, plus three hidden challenge cards: A says the exit path must remain clear; B sets the fixture’s reachable opening at 70–100 cm; C limits organiser setup to five minutes.
Before you start
- Write FICTIONAL FIXTURE and list the supplied evidence only.
- Name the fictional owner, affected roles and who could stop a test.
- Set paper-only scope with no real participant recruitment or installation.
3 · The method
Follow these steps in order
- Extract observations
Copy only directly supplied actions and conditions, such as cards left on tables after events. Put explanations in a separate assumption column.
Why: Design starts from evidence rather than judgement about people.
Check: Every statement is labelled observation or assumption.
- Map roles and authority
List participant, organiser, cleaner and room manager, then mark who experiences, operates, approves and can stop the change.
Why: Affected roles and decision rights are different.
Check: The map names proposer, owner, affected roles and stop authority.
- Frame a bounded question
Write one how-might-we question tied to the observed moment and avoid labels such as careless or unmotivated.
Why: A neutral frame keeps multiple causes and solutions open.
Check: The question names task, moment and desired function without diagnosing people.
- Generate alternatives
Create at least six mechanisms before selecting: return box at exit, table rack, lanyard cue and structurally different options.
Why: Divergence prevents the first familiar solution from defining the problem.
Check: At least three mechanisms differ in where or when they act.
- Build three smallest prototypes
Make paper representations of three mechanisms, each answering one named uncertainty.
Why: A prototype should buy information, not imitate a finished service.
Check: Each prototype has one question and can be discarded cheaply.
- Run the fictional walkthrough
Apply the same supplied scenarios and rubric to all three. Record failures, access barriers and assumptions needing real participant evidence.
Why: Comparable tests expose trade-offs while preserving the boundary.
Check: Every score cites a walkthrough observation.
- Test the riskiest assumption
For each prototype, select the assumption most likely to reverse its result and use a supplied fictional evidence card to challenge it. Do not invent a participant response.
Why: A prototype can look successful only because an unsupported belief stayed hidden.
Check: Each concept has one named assumption, one challenge card and a keep, revise or unresolved response tied to that evidence.
- Revise and state the gate
Change one feature in the strongest learning candidate, preserve prior versions and list approvals and participation needed before any real test.
Why: Iteration and implementation authority must remain visible.
Check: The final record has version change, evidence and an explicit no-implementation gate.
4 · Worked example
See the whole method used once
Scenario
Fictional evidence shows reusable name cards often remain on tables because the return point is not visible when people leave.
Walkthrough
- Rae copies that observation and separates the assumption “people do not care.”
- She maps participant, organiser, cleaner and manager and names the manager as fictional owner.
- She frames “How might the return action become obvious at the exit?”
- She builds an exit box, table rack and lanyard prompt in paper.
- Challenge card B rejects the high rack because its opening is above the fixture’s 70–100 cm reach band; she lowers the paper exit-box opening in version two and notes that real users must test it before implementation.
Result
Rae traces a design revision to supplied evidence and a fictional access test without claiming lived experience. Nothing is installed or approved for real use.
5 · Right and wrong
Compare correct or safer execution with the common wrong version
| Moment | Right / safer | Wrong / riskier | Why it matters |
|---|---|---|---|
| Evidence | Separate observed behaviour from explanations. | Write “users are careless” as a fact. | A judgement can misframe the problem and blame people. |
| Empathy | Use supplied notes and let consenting people correct records. | Invent a persona for a real marginalised group. | Imagination cannot replace participation or authority. |
| Prototype | Build the smallest reversible test of one uncertainty. | Polish one favourite solution before comparison. | Premature finish hides alternatives and wastes learning. |
| Decision | List who must approve and who can stop. | Assume the design team may implement because it has an idea. | Proposal does not grant legitimate authority. |
6 · Common mistakes
Spot the error and apply the correction
| Mistake | Fix |
|---|---|
| Assumptions are mixed into interview notes. | Use separate columns and never rewrite supplied participant words. |
| Three prototypes are cosmetic variants. | Require different mechanisms, moments or locations. |
| The walkthrough changes by prototype. | Use the same scenarios and rubric for all three. |
| Access appears only after selection. | Make access and burden criteria part of framing and every walkthrough. |
7 · Practice
Turn the steps into a usable skill
First session
- Copy the 9–12 cards-left observation, hidden-box location and supplied participant sentence; put ‘people do not care’ in assumptions, not evidence.
- Map participant, organiser, cleaner and room manager as experiencer, operator, fictional owner and stop authority.
- Frame the exit-moment return question without adding a demographic persona or motive.
- Generate six mechanisms, then build paper exit-box, table-rack and lanyard-cue prototypes with one uncertainty each.
- Apply challenge cards A, B and C plus the same six-part walkthrough, revise one feature and record the no-installation gate.
Repeat plan
Use one new fictional service fixture weekly for four weeks. Rotate which uncertainty is tested and have a second reviewer audit evidence traceability and invented assumptions after a 48-hour delay.
Progress when
- Every problem claim traces to supplied evidence or is marked assumption.
- Three prototypes test distinct mechanisms.
- Access failures and authority gates survive revision.
Do not progress when
- The project involves real people or implementation without consent and authority.
- Identity, trauma, disability or culture is used as decoration.
- A prototype creates physical, digital or privacy risk.
8 · Check the result
Measure what changed
Evidence traceability and learning value across three fictional prototypes.
How: Score observation trace, assumption labels, role/authority map, mechanism diversity, common rubric, access findings, versioned revision and implementation gate.
Good result: All eight audit features are present, and a delayed reviewer can trace every sampled design choice to supplied evidence or an explicitly labelled assumption. Any untraceable choice is corrected or removed rather than hidden behind a percentage score.
This does not prove: It does not establish user desirability, implementation impact, representation authority or a general design-thinking training effect.
Self-check
- Is ‘9–12 of 30 cards remained’ an observation while ‘people do not care’ stays explicitly marked assumption?
- Can you distinguish the participant and cleaner from the fictional room-manager owner and stop authority?
- Do exit box, table rack and lanyard cue test different moments or mechanisms under the same visibility–reach–burden rubric?
- Which concept fails the 70–100 cm reach card, and what consent, accessibility evidence and organisational approval remain missing before any real installation?
9 · Stop, adapt or get help
Keep the safety boundary practical
Stop and get help
- Stop if a real person, service or sensitive record enters without consent and authority.
- Stop if a prototype could cause physical, privacy, security or exclusion harm.
- Seek affected-person, accessibility, domain, rights and organisational review before a real test.
Accessibility and adaptations
- Use tactile paper prototypes, narrated storyboards or accessible digital mock-ups.
- Provide easy-read evidence cards and one role per page.
- Include disabled participants through legitimate participation in real work, never through invented personas.
10 · Evidence and limits
Why these instructions are here
- primary research
Cross-sectional design-training evidence found stronger divergent but not convergent performance with more design exposure and did not establish causality.
Design Training and Creativity: Students Develop Stronger Divergent but Not Convergent Thinking - official guidance
US Copyright Office guidance on copyright and AI supports keeping authorship, source status and permissions visible in creative work.
Copyright and Artificial Intelligence
Limits
- The fixture is fictional and paper-only.
- A prototype produces information, not implementation proof.
- Human-centred claims require actual legitimate participation rather than imagined empathy.
Open the complete canonical research register
- Primary empirical supportLimiting / contraryDesign Training and Creativity: Students Develop Stronger Divergent but Not Convergent Thinking
Xia T; Kang M; Chen M; Ouyang J; Hu F · 2021 · Primary research
- Limiting / contraryOfficial boundary contextCopyright and Artificial Intelligence
United States Copyright Office · 2025 · Official guidance
- Limiting / contraryOfficial boundary contextTraditional Cultural Expressions
World Intellectual Property Organization · 2026 · Official governance
Read the complete evidence interpretation on the Power dossier.
Tutorial delivery controls
Learn, adapt, troubleshoot and resume
Progress is saved only in this browser on this device.
Step-by-step learner mode
Each activity includes its success check, a nearby accessible alternative and an “I’m stuck” correction path. Alternatives preserve the target where possible; when they change the task, Titan labels them as related rather than equivalent.
Extract observations
Copy only directly supplied actions and conditions, such as cards left on tables after events. Put explanations in a separate assumption column.
Design starts from evidence rather than judgement about people.
Every statement is labelled observation or assumption.
I’m stuck on this step
Reset: Re-read this authored instruction — “Copy only directly supplied actions and conditions, such as cards left on tables after events. Put explanations in a separate assumption column.” — and its success check, then attempt only this step.
Possible snag: Access appears only after selection.
Correction: Make access and burden criteria part of framing and every walkthrough.
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Map roles and authority
List participant, organiser, cleaner and room manager, then mark who experiences, operates, approves and can stop the change.
Affected roles and decision rights are different.
The map names proposer, owner, affected roles and stop authority.
I’m stuck on this step
Reset: Re-read this authored instruction — “List participant, organiser, cleaner and room manager, then mark who experiences, operates, approves and can stop the change.” — and its success check, then attempt only this step.
Possible snag: The result from “List participant, organiser, cleaner and room manager, then mark who experiences, operates, approves and can stop the change.” does not yet meet this declared check: The map names proposer, owner, affected roles and stop authority.
Correction: Return to the start of “Map roles and authority”, reduce complexity or pace, and repeat only the part needed to satisfy: “The map names proposer, owner, affected roles and stop authority.”
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Frame a bounded question
Write one how-might-we question tied to the observed moment and avoid labels such as careless or unmotivated.
A neutral frame keeps multiple causes and solutions open.
The question names task, moment and desired function without diagnosing people.
I’m stuck on this step
Reset: Re-read this authored instruction — “Write one how-might-we question tied to the observed moment and avoid labels such as careless or unmotivated.” — and its success check, then attempt only this step.
Possible snag: The result from “Write one how-might-we question tied to the observed moment and avoid labels such as careless or unmotivated.” does not yet meet this declared check: The question names task, moment and desired function without diagnosing people.
Correction: Return to the start of “Frame a bounded question”, reduce complexity or pace, and repeat only the part needed to satisfy: “The question names task, moment and desired function without diagnosing people.”
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Generate alternatives
Create at least six mechanisms before selecting: return box at exit, table rack, lanyard cue and structurally different options.
Divergence prevents the first familiar solution from defining the problem.
At least three mechanisms differ in where or when they act.
I’m stuck on this step
Reset: Re-read this authored instruction — “Create at least six mechanisms before selecting: return box at exit, table rack, lanyard cue and structurally different options.” — and its success check, then attempt only this step.
Possible snag: The result from “Create at least six mechanisms before selecting: return box at exit, table rack, lanyard cue and structurally different options.” does not yet meet this declared check: At least three mechanisms differ in where or when they act.
Correction: Return to the start of “Generate alternatives”, reduce complexity or pace, and repeat only the part needed to satisfy: “At least three mechanisms differ in where or when they act.”
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Build three smallest prototypes
Make paper representations of three mechanisms, each answering one named uncertainty.
A prototype should buy information, not imitate a finished service.
Each prototype has one question and can be discarded cheaply.
I’m stuck on this step
Reset: Re-read this authored instruction — “Make paper representations of three mechanisms, each answering one named uncertainty.” — and its success check, then attempt only this step.
Possible snag: Three prototypes are cosmetic variants.
Correction: Require different mechanisms, moments or locations.
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Run the fictional walkthrough
Apply the same supplied scenarios and rubric to all three. Record failures, access barriers and assumptions needing real participant evidence.
Comparable tests expose trade-offs while preserving the boundary.
Every score cites a walkthrough observation.
I’m stuck on this step
Reset: Re-read this authored instruction — “Apply the same supplied scenarios and rubric to all three. Record failures, access barriers and assumptions needing real participant evidence.” — and its success check, then attempt only this step.
Possible snag: Assumptions are mixed into interview notes.
Correction: Use separate columns and never rewrite supplied participant words.
Possible snag: The walkthrough changes by prototype.
Correction: Use the same scenarios and rubric for all three.
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Test the riskiest assumption
For each prototype, select the assumption most likely to reverse its result and use a supplied fictional evidence card to challenge it. Do not invent a participant response.
A prototype can look successful only because an unsupported belief stayed hidden.
Each concept has one named assumption, one challenge card and a keep, revise or unresolved response tied to that evidence.
I’m stuck on this step
Reset: Re-read this authored instruction — “For each prototype, select the assumption most likely to reverse its result and use a supplied fictional evidence card to challenge it. Do not invent a participant response.” — and its success check, then attempt only this step.
Possible snag: The result from “For each prototype, select the assumption most likely to reverse its result and use a supplied fictional evidence card to challenge it. Do not invent a participant response.” does not yet meet this declared check: Each concept has one named assumption, one challenge card and a keep, revise or unresolved response tied to that evidence.
Correction: Return to the start of “Test the riskiest assumption”, reduce complexity or pace, and repeat only the part needed to satisfy: “Each concept has one named assumption, one challenge card and a keep, revise or unresolved response tied to that evidence.”
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Revise and state the gate
Change one feature in the strongest learning candidate, preserve prior versions and list approvals and participation needed before any real test.
Iteration and implementation authority must remain visible.
The final record has version change, evidence and an explicit no-implementation gate.
I’m stuck on this step
Reset: Re-read this authored instruction — “Change one feature in the strongest learning candidate, preserve prior versions and list approvals and participation needed before any real test.” — and its success check, then attempt only this step.
Possible snag: The result from “Change one feature in the strongest learning candidate, preserve prior versions and list approvals and participation needed before any real test.” does not yet meet this declared check: The final record has version change, evidence and an explicit no-implementation gate.
Correction: Return to the start of “Revise and state the gate”, reduce complexity or pace, and repeat only the part needed to satisfy: “The final record has version change, evidence and an explicit no-implementation gate.”
Stop / get help: Stop if a real person, service or sensitive record enters without consent and authority.
Correct versus incorrect execution
These accessible process diagrams are built from the tutorial’s own right/wrong teaching. They are not anatomical illustrations and do not add technique beyond the canonical tutorial.
Separate observed behaviour from explanations.
Write “users are careless” as a fact.
Use supplied notes and let consenting people correct records.
Invent a persona for a real marginalised group.
Build the smallest reversible test of one uncertainty.
Polish one favourite solution before comparison.
List who must approve and who can stop.
Assume the design team may implement because it has an idea.
Method-structure checklist
10 of 10 structural checks present
- Ordered, Power-specific instructions — present
- Every activity has a success check — present
- Materials or supplied records are declared — present
- Measurement or assessment rule is present — present
- Tutorial-specific troubleshooting is present — present
- Stopping or escalation boundary is present — present
- Every activity has an adjacent alternative — present
- Correct-versus-incorrect comparison is present — present
- Evidence context is bound to the Power record — present
- Planning metadata is present — present
The method-readiness band and presence checklist assess tutorial presentation and are separate from evidence quality for the underlying Power. They are automated editorial aids, not human approval.
Manual editorial sign-off: Pending. This tutorial must not display a human-approved state until an identified editor signs the exact content hash.