Reviewing an Interaction Plan

Useful review is not praise and not insult.

It is evidence about what breaks when real users run the design.

Review the design, not the designers

Focus on mechanism quality.

Do not evaluate personality.

Alignment test

Problem
  -> Design
  -> Expected change

If these do not connect, the intervention is misaligned.

Stress tests

1. Clarity: can outsiders run it without explanation?
2. Reality: does it assume ideal behavior under pressure?
3. Inclusion: who is excluded or overloaded?
4. Privacy: does it expose unnecessary information?
5. Failure mode: what happens if owner is absent or conflict rises?
6. Unintended consequence: what new problem could it create even if executed as written?

Peer review rounds

Round 1: silent read-through and comprehension notes.

Round 2: choose three failure cards and simulate breakpoints.

Round 3: ethics and digital-citizenship check.

Feedback format

We understood...
We observed...
This may break when...
Evidence...
Possible revision...

Designer response format

For each key suggestion:

Feedback
Evidence
Accept, reject, or modify
Why

Teams may reject suggestions with defensible reasoning.

Prioritize revisions

Classify as:

• high priority: breaks system
• medium priority: meaningful improvement
• low priority: preference

Exit ticket

Complete:

1. Most useful feedback was... because...
2. Suggestion not fully accepted was... because...

Source note

This lesson extends Learn with League and Cybersmile principles into formal prototype review.

The alignment test, failure-card stress test, unintended-consequence mapping, and revision-decision protocol are original Robotnix Academy components.