Week 06 · lesson
Testing a Team-Building Choice
Your group made a routine.
It looks clean. The slide is nice. Everyone agrees it should work.
Good.
Now try to break it.
A design is not proven by how good it looks. It has to survive use.
Testing finds assumptions
Every design contains hidden assumptions.
Maybe your routine assumes:
- everybody arrives on time
- everybody understands the vocabulary
- the captain is always present
- people remember the order
- nobody is upset
- equipment works
Testing exposes those assumptions.
Ask better questions
Do not only ask:
Did everyone like it?
That can be useful, but it is not enough.
Ask:
Did people know what to do?
Did the routine finish?
Where did people hesitate?
What step was misunderstood?
What did people skip?
What required help?
How long did it take?
What broke?
Now you have evidence.
The observer
Your group needs one person who does not run the routine.
Their job is to watch and record evidence:
00:20
Player asks what step comes next.
00:45
Two people begin different tasks.
01:10
New participant misses verbal instruction.
01:40
Captain repeats Step 3.
02:20
Routine complete.
Notice: no judgment. Just evidence.
Observation versus interpretation
Compare:
Jordan was not paying attention.
with:
Jordan asked for Step 2 to be repeated twice.
One is interpretation. One is observation.
You can discuss reasons later. First capture what happened.
Test Round 1: Normal mode
Run the routine exactly as designed.
Assign:
- participants
- owner
- observer
Record:
- completion time
- confusion points
- missed steps
- questions asked
- moments requiring teacher or coach help
- whether everyone completed their responsibility
Do not fix things immediately. If the designer keeps jumping in to explain, the routine did not explain itself. That is evidence.
Round 2: Stress test
Choose a failure card.
Failure Card A: Owner absent
The person who normally leads the routine is not there.
Failure Card B: New player
One participant knows nothing about the routine. Everyone else has used it before.
Failure Card C: Time pressure
You have half the normal time.
Failure Card D: Equipment problem
One player cannot complete the normal equipment step.
Failure Card E: Communication failure
Nobody may explain the routine verbally.
Failure Card F: Frustrated team
The team just lost badly. People want to skip the debrief or reset routine.
Failure is information
Failure does not mean the project is bad.
Failure means you found information.
If a pre-match routine collapses when the captain is absent, now you know the captain is a single point of failure. The fix might be a backup owner.
That is improvement.
Compare Version 1 with reality
Create a table:
| Design assumption | What actually happened | Revision |
|---|---|---|
| Everyone understands roles | New player asked who makes final call | Add visible role board |
| Captain leads routine | Captain absence stopped process | Assign backup |
| 3 minutes is enough | Test took 5:20 | Reduce steps |
| Verbal directions work | Two steps were missed | Add checklist |
Your revisions need evidence, not just preference.
Test for inclusion
Ask specifically:
- Did the routine require prior knowledge?
- Did it use unexplained vocabulary?
- Could someone recover after missing a step?
- Did one person dominate the process?
- Was important information available visually?
- Could a new participant understand what success looked like?
Efficiency versus access
A routine could be extremely fast because the captain gives every instruction and everyone follows immediately.
Efficient? Maybe.
Inclusive? Maybe not.
Another routine could include so many supports that a three-minute check becomes fifteen minutes.
Accessible? Maybe.
Efficient? No.
Design involves tradeoffs. Your job is to find something that works.
Evidence challenge
Your group must collect at least:
1 timing measurement
3 observable behaviors
1 confusion point
1 successful part
1 stress-test failure
1 revision
That is a small amount of evidence, but enough to make a design decision.
Revision question
Do not only ask:
What should we add?
Always adding creates bloated systems.
Also ask:
What should we remove?
Maybe a step duplicates another step, does not solve the original problem, takes too long, creates confusion, or belongs somewhere else.
Simpler can be better.
Before you leave, complete:
Our biggest incorrect assumption was __________.
Then:
We know because during testing __________.
Then:
Version 2 changes __________.
Source note
This lesson extends Learn with League's teamwork and productive communication concepts into an original team-process testing activity.
The observer protocol, stress-test cards, inclusion audit, evidence requirements, assumption testing, and iterative revision framework are original Robotnix Academy material.