MYP Design User Personas and Scenarios Notes

A Persona Is a Pattern With a Face

1. Personas are introduced earlier in this subject through ergonomics, so the job here is turning one into something a digital product can be built from.
2. Build the persona out of research you actually ran: twenty survey responses, four interviews, two sessions watching someone use the current system.
3. Sort the findings into patterns before anyone gets a name, because the pattern is the useful part and the name is just a handle.
4. A class sized sample normally shows two or three patterns, which means two or three personas rather than eight.
5. If you cannot point at the survey answer or interview line behind a detail on the card, delete the detail.

What a Digital Persona Card Has to Carry

1. Start with the basics that make her memorable: name, age, a sketch or photo, and one sentence about an ordinary day.
2. A digital persona then needs fields a workshop project would not bother with: which device, screen size, how good the connection is, and how confident she is with new apps.
3. Two headings do the heavy lifting: goals, what she is trying to get done, and frustrations, what stops her doing it now.
4. One quote lifted straight from an interview transcript does more work than a paragraph you wrote yourself.
5. Finish with a context of use: on a bus, one handed, bright sunlight, 4% battery, thirty seconds to spare.

User Stories Turn a Persona Into a Build List

1. A user story is one line written to a fixed shape, which stops you drifting into describing screens before you know the need.
2. Maya's main story reads: "As a year 9 student, I want to see whether a book is on loan, so that I do not walk to the library for nothing."
3. The "so that" half is the filter, because a feature with no believable benefit sentence has nowhere to hide.
4. Keep each story small enough to build and test on its own, so "I want to search by title" is a story and "I want a library app" is not.
5. Ten to fifteen stories is plenty for a six week project, and marking three of them as must have decides what gets built first.
6. Every story should trace backwards to a persona and forwards to a screen, which makes it easy to spot screens nobody asked for.

Scenarios: the Persona Doing Something at a Real Moment

1. A scenario is a short paragraph of plain sentences putting one persona, one situation and one goal together.
2. It fixes the when and where: "Maya has four minutes before registration and the library shuts at 4pm, so she checks the app in the corridor."
3. Awkward conditions belong in the scenario, since low battery, no signal and a misspelled title are where most designs fall over.
4. Write one scenario where everything goes right and one where something breaks, or your error screens will never get designed.
5. Scenarios feed straight into testing, because a test task is usually a scenario with the answer taken out.

Task Flows Show Every Step and Every Decision

1. A task flow is a diagram of the steps between where the user starts and where the goal is reached, with a diamond drawn at each decision.
2. Count the boxes, because nine steps for a job the user wants done in twenty seconds is a finding in itself.
3. Mark the points where the user can fail, then write next to each one what the product does about it.
4. Ask two people in your group to draw the same flow separately and the differences will show you what your team has not actually agreed.
5. Task flows lead directly into how content gets organised, which is the next article in this unit.

A Persona Ends Arguments That Taste Cannot

1. Group design arguments stall when both sides run on preference: "I think it should be a hamburger menu" against "I think a tab bar looks better".
2. A persona swaps "I think" for evidence: Maya holds her phone one handed on a moving bus, so the three main sections belong within thumb reach at the bottom.
3. It also kills features quickly, because a feature that matches no persona goal is work you have just saved yourself.
4. When two personas want opposite things, write down which one this version serves first and why, rather than trying to please both and pleasing neither.
5. Record the argument and the decision in your folder, since criterion B asks you to justify choices against your specification rather than just present them.