Everything a person feels and does while using a product, from finding it and learning it to finishing a task and coming back later.
MYP design runs one design cycle whatever you are making, and the four criteria name its stages: Inquiring and analysing, Developing ideas, Creating the solution and Evaluating.
For a digital product those stages usually get called discovery, define, wireframe, prototype, test, build and iterate, which are the same moves wearing different names.
The real difference is the cost of changing your mind: moving a button in a design file takes ten seconds, moving a hole in a laser cut acrylic panel means cutting a new panel.
Because change is that cheap, digital designers go round the loop four or five times in one project instead of marching through it once.
What you are actually designing is the user experience, which includes finding the app, understanding the first screen, finishing the job and deciding whether to open it again.
Your design folder has to show that loop happening, so plan for each stage to leave something behind you can screenshot or scan.
Discovery: Find the Problem Before You Draw a Screen
Discovery is criterion A work: who has the problem, what do they do now, and what exactly is annoying about it.
Three methods carry most of the weight: a short survey of 20 to 30 people, four interviews of about fifteen minutes each, and watching one person do the task while you write down where they stall.
A competitor analysis means opening two or three products that already do a similar job and recording, with annotated screenshots, what works and what fails.
Record what people did, not what they said they would do, because the two disagree more often than students expect.
Evidence for the folder: raw survey results as a chart, interview notes with at least one direct quote each, and the annotated competitor screenshots.
Example
A year 4 class was told to design a digital product for the school library.
Discovery found that 18 of 24 students could not tell whether a book was already on loan without queuing at the desk.
That one number turned a vague idea about a library app into a sharp problem about showing loan status.
Define: Turn Findings Into Something You Can Check
Define is where research gets squeezed into a design brief and a numbered list of design specifications.
A specification only earns its place if it can be tested: "a new user finds a book's loan status in under 20 seconds" beats "the app is easy to use".
Write the test next to the specification, so criterion D already has a ruler to measure the finished product against.
Cut ruthlessly, because one job done properly in six weeks beats nine features half built.
Evidence: the brief, the specification list, and one line under each specification naming the research finding it came from.
Wireframe and Prototype: Fail While Failing Is Free
A wireframe is a grey box layout of one screen drawn before anything looks finished, and a prototype is those screens linked so a person can tap through them.
A tester getting lost on paper costs you one sheet of A4, while the same mistake found after three weeks of coding costs three weeks.
Draw three different layouts of your hardest screen rather than polishing the first one, because criterion B wants a range of ideas judged against your specification.
Fidelity climbs in steps: pencil sketch, then grey boxes with real labels, then a clickable version.
The full method for wireframes and storyboards comes later in this unit, so at this stage just know where they sit in the loop.
Evidence: dated sketches, a screenshot of each prototype version, and a sentence on why one layout was taken forward.
Common Mistake
A prototype that looks finished pulls comments about colour instead of comments about whether the thing works.
Testers also hold back criticism when a screen looks polished, because they assume you already spent weeks on it.
Keep early prototypes grey and rough on purpose.
Testing: Watch a Stranger, Not a Friend
Testing in the digital cycle means handing a real person a task and watching in silence, not asking a friend whether they like it.
Test the prototype before you build, because that is the last moment when changing your mind is still free.
Five testers running the same three tasks will surface most of the obvious problems, and a later article in this unit sets out how to run and score those sessions.
Write down what you changed because of each session, since the change is the evidence, not the session.
A test that finds nothing usually means the task was too easy or you talked the tester through it.
Exam technique
A moderator can only credit what is in the ePortfolio, so a decision you made in your head counts for nothing.
Screenshot every prototype version with a date and one line saying what changed.
Name the finding that caused each change so the trail from evidence to decision is visible on the page.
Build and Iterate: Version 1 Is a Draft
Build is criterion C, and it opens with a plan listing steps, dates and the tools or files each step needs.
Work one screen at a time and get it running end to end before starting the next, so a broken piece never hides behind three other broken pieces.
Dated screenshots are how a digital project proves it was made, because there are no offcuts or tool marks to photograph.
Iterating means going back round the loop with a reason attached, such as "four of five testers missed the search bar, so it moved to the top and gained a label".
The loop stops when the deadline arrives rather than when the product is perfect, so finish by recording the next change you would make and why.
Active recall
Name the four MYP design criteria in order.
Why is testing a prototype cheaper than testing a built product?
What makes a design specification testable?
What three pieces of evidence should discovery leave in your design folder?
What turns a change into an iteration rather than a random tweak?