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 assumptionWhat actually happenedRevision
Everyone understands rolesNew player asked who makes final callAdd visible role board
Captain leads routineCaptain absence stopped processAssign backup
3 minutes is enoughTest took 5:20Reduce steps
Verbal directions workTwo steps were missedAdd 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.