MYP Design Evaluating a Solution Against the Specification Notes

The Specification Is the Mark Scheme You Wrote Yourself

1. Back in criterion B you wrote a design specification, a numbered list of what the solution must do, and criterion D is where you are held to it.
2. Every point gets its own judgement, so a nine point specification produces nine verdicts rather than one paragraph of general praise.
3. The verdict comes from your test data and your feedback, not from how you feel about the thing you made.
4. A point you never tested cannot be marked as met, and writing "not tested, no evidence" is better than bluffing.
5. If a point changed while you were making the solution, say when and why, then judge the final product against the point as it now stands.

One Verdict Per Point, With the Evidence Attached

1. Give each point a clear label, met, partly met or not met, then the evidence, then one sentence of explanation.
2. The evidence line quotes the actual result, such as "Test 2: lid stayed shut in 8 of 10 drops from 75 cm".
3. The explanation says why the result came out that way, for example that both failures landed on the hinge corner.
4. Keep the same order as the specification, so point 4 in the specification is point 4 in the evaluation.
5. A table is the clearest shape for this, and it stops you writing three paragraphs about your favourite point and one line about the rest.
6. Write each verdict as though the reader has never seen your product, because a moderator has not.

Partly Met Is the Most Common Honest Verdict

1. Partial success fills most honest evaluations, because most solutions do part of what they promised.
2. Say which part worked and which did not, so the stand held the tablet at 60 degrees on wood but slid on glass.
3. Give the size of the gap, since "2.3 seconds over the 6 second target" is far more useful than "a bit slow".
4. A point met in one condition but not another is partly met, and you name the condition that broke it.
5. Resist upgrading a partly met point because you ran out of time, since that gap is exactly what your improvements section needs.

Evidence Beats Adjectives Every Time

1. Each verdict needs a pointer to something real: a table row, a photograph, a timing, or a quotation from the client.
2. Number your evidence so the evaluation can say "see Table 3" instead of retelling the whole test.
3. Client and user comments count as evidence when they are quoted and attributed, not blurred into a general claim.
4. Say which test produced the evidence and when, because a result from the first prototype does not evaluate the final solution.
5. Where the evidence is thin, say so, since one user trying the app once supports a hint rather than a conclusion.

Write a Conclusion That Judges the Whole Solution

1. After the point by point table, write a short conclusion saying how far the solution meets the need overall.
2. Count the verdicts honestly, for example six points met, two partly met and one not met.
3. Name the strongest and the weakest part, and be specific about what made each one so.
4. Connect back to the client and the original problem, saying whether the person you designed for is actually better off.
5. An accurate account of a flawed product is a strong evaluation, so there is nothing to apologise for.

Laying the Evaluation Out in Your Design Folder

1. Order it the way the work happened: the tests, then the point by point judgement, then the conclusion.
2. Place images next to the verdicts they support, so nobody has to scroll between the two.
3. Keep the writing tight, because a moderator is reading for the verdict and the evidence behind it.
4. Leave the gaps clearly stated, since your improvements and impact sections are built on them.