$npx -y skills add human-avatar/skills-for-humanity --skill s4h-design-iterationStructures the feedback loop between making and learning — prototyping, testing, and convergence toward fit. Triggers: 'prototype and test', 'iterate on the design', 'how do we test this', 'get feedback on the design', 'what should we prototype', 'design feedback loop', 'test and
| 1 | # Design: Iteration |
| 2 | |
| 3 | No design survives first contact with the real world intact. The best designers know this and plan for it: they make something quickly, put it in front of reality, learn what's wrong, and make something better. The iteration cycle is not a failure mode — it is the mechanism by which design improves. The question is not whether to iterate, but how to structure each cycle so it produces the most learning for the least effort. |
| 4 | |
| 5 | Dieter Rams designed and redesigned Braun products over decades of close observation — not because the first version was wrong but because fit is discovered, not planned. Don Norman's fundamental insight in *The Design of Everyday Things* is that designers are wrong about users — systematically, predictably, and in ways they can't detect by reasoning alone. The only cure is observation: put the thing in front of people and watch what happens without explaining it. |
| 6 | |
| 7 | This skill structures the iteration cycle. It distinguishes what kind of test is needed at each stage (divergent versus convergent), specifies the right prototype fidelity for the question being asked, and defines the decision criteria that determine when to narrow, when to pivot, and when enough learning has accumulated to commit. |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## Your Process |
| 12 | |
| 13 | **Step 1: State the Current Hypothesis** |
| 14 | Every prototype is a test of a hypothesis. State it explicitly: "We believe [specific design choice] will [produce this outcome] for [this user doing this job]." If the hypothesis is vague, the test will be uninformative. Specificity is not premature commitment — it is what makes learning possible. |
| 15 | |
| 16 | **Framing check:** Confirm the design stage and the hypothesis being tested before continuing. State what you've identified — the design being iterated and the key question it needs to answer — in one sentence, then use `AskUserQuestion`: |
| 17 | - **Question:** "I'm reading this as: [your one-sentence framing of the hypothesis and stage]. Is that right?" |
| 18 | - **Header:** "Framing" |
| 19 | - **Options:** |
| 20 | - **Yes — proceed** — framing is correct |
| 21 | - **Adjust** — one element is off; user will correct it before you continue |
| 22 | - **Reframe** — different situation than read; incorporate the correction before proceeding |
| 23 | |
| 24 | **Step 2: Identify the Iteration Type** |
| 25 | Two distinct types of test require different setups: |
| 26 | |
| 27 | - **Divergent test:** "Which direction is most promising?" Used when there are multiple competing design directions and you need to narrow. Set up multiple options. Vary one thing at a time. Measure preference, comprehension, or engagement. |
| 28 | - **Convergent test:** "Does this work?" Used when a direction has been chosen and you're refining fit. Test the specific design against real use. Measure success on the actual task. |
| 29 | |
| 30 | Identify which type is needed. Mixing them produces muddled learning. |
| 31 | |
| 32 | **Step 3: Specify the Prototype** |
| 33 | Match prototype fidelity to the question being asked: |
| 34 | |
| 35 | - **Sketch/paper:** for testing whether an interaction model makes sense, before any investment in appearance |
| 36 | - **Wireframe/low-fi:** for testing structure, navigation, and information hierarchy |
| 37 | - **Mid-fi prototype:** for testing comprehension, flow, and whether the sequence works |
| 38 | - **High-fi prototype:** for testing response to the complete experience — aesthetics, tone, emotional reaction |
| 39 | - **Live/functional:** for testing real behaviour under real conditions |
| 40 | |
| 41 | The most common error is over-building the prototype for the stage. A high-fidelity prototype for a question that could be answered by a sketch wastes time and creates attachment that biases the test. |
| 42 | |
| 43 | Specify: what to make, at what fidelity, and what it should and should not include. |
| 44 | |
| 45 | **Step 4: Design the Test** |
| 46 | A test that doesn't answer the hypothesis isn't a test. Define: |
| 47 | |
| 48 | - **The question:** What specific thing are you trying to learn? |
| 49 | - **The method:** Observation, task completion, interview, A/B, diary study — each is suited to different questions. Observation reveals what people do; interviews reveal what they believe; task completion reveals where design fails. |
| 50 | - **Who:** Which users, how many, which context. The smaller and more specific the group, the cleaner the signal. |
| 51 | - **What counts as a result:** Define in advance what a positive result looks like, and what would indicate a need to pivot. |
| 52 | |
| 53 | **Step 5: Read the Signal** |
| 54 | After testing, separate observation from interpretation. What did people actually do, say, or fail to do? Where did they hesitate, ask questions, or deviate from the intended path? Those moments are the data. Interpretations follow from data — not the reverse. |
| 55 | |
| 56 | Classify findings: |
| 57 | - **Confirms hypothesis:** evidence the |