Worked example · Computer Science · Year 8
DCF: Producing → Sourcing, searching and planning digital content
A complete Year 8 plan for the Clybiau app: the audience table, the content plan, the three wireframes drawn as grey-box plans, and the notes that justify them. Show it after pupils have drawn their own, or you will get thirty copies of this layout. The point to make is that it is deliberately ugly — that is what a wireframe is for.
| Question | Answer |
|---|---|
| Who exactly will use this app? | Pupils in Years 7 to 11 who are not already in a club and do not know what exists. The second audience is the club leader, who needs to see who has joined — but they are not in version 1. |
| What is the one job they most need it to do? | Answer "what can I join, and where do I go?" in under thirty seconds, then let them join without speaking to anybody. |
| Where and when will they be using it? | On a phone, on the bus or in a corridor, one-handed, in a hurry, sometimes on a cracked screen. So: big tap targets, no tiny text, no wide tables, and the important information at the top where a cracked corner will not hide it. |
| Two things the brief asks for that are easy to forget | (1) Places remaining — the brief says "how many places are left", so that number has to be on the detail screen, not buried. (2) Welsh and English, which means every label needs room for a longer Welsh version. |
| One thing left out of version 1, and why | Notifications about cancelled clubs. The brief never asks for them, they need someone to keep the data up to date every day, and adding them would delay the thing pupils actually asked for. |
Names a specific audience and a single primary job, both traced back to the brief — first success criterion. The "left out" row shows the pupil scoping the work rather than promising everything.
| Screen | What has to be on it | Where the information comes from |
|---|---|---|
| 1. Home | Search box; heading "This week"; a card per club showing name, day and time, and year groups; navigation bar. | The club list the school council already keeps in a spreadsheet. One member of staff updates it; the app only reads it. |
| 2. Search results | The search term or the filter that was tapped; three category filters (Chwaraeon, Celf, Cymraeg); a count of results; one row per matching club; navigation bar. | Same club list, filtered by the category field. The count is calculated by the app, not typed in. |
| 3. Club details | Club photo; club name; day, time and room; year groups allowed; places left; two or three sentences of description; Join button; add-to-calendar button; back arrow. | Club list for the fixed details. Places left is worked out from the room capacity minus the number who have joined, so it changes on its own. The photo is supplied by the club leader. |
Content listed before any drawing, with a source for every field — second success criterion. Note the distinction between data that is typed in and data the app calculates.
Placeholders throughout: grey blocks where photos go, ruled bars where descriptions go, real words only on headings and buttons. A plan you can redraw in two minutes when the client changes their mind — third success criterion.
| No. | What it is | Why it is there |
|---|---|---|
| 1 | Search box, full width, at the top of the home screen | The brief's first complaint is "nobody knows what clubs exist". Search is the fastest route to an answer, so it goes above everything else and is wide enough to hit one-handed. |
| 2 | Club cards under the heading "Yr wythnos hon / This week" | A pupil who does not know what to search for still needs something to tap. Showing this week's clubs first answers "what is on?" without any typing. |
| 3 | Three category filter chips | The brief asks to "search by the sort of thing you like". Three fixed categories are quicker than free typing and cannot be misspelled. |
| 4 | One-line result rows with a chevron on the right | Rows are 42 pixels tall so five fit on a small screen without scrolling. The chevron tells the user the row is tappable, which an underline would not. |
| 5 | Photo placeholder at the top of the detail screen | It is a placeholder, not a picture, because the club leaders have not sent photos yet. The layout must not fall apart when one is missing, so the box has a fixed height. |
| 6 | Filled "Ymuno / Join club" button, with "Add to my calendar" below it as an outline | The brief says pupils should join "without having to find the teacher", so joining is the one filled button on the screen. The calendar action is useful but secondary, so it is outlined rather than filled — the user can tell them apart at a glance. |
Every note points at a line in the brief or at a constraint of the device, not at personal taste — fifth success criterion.
Every screen has a documented route in and a route out, including the short cut from home straight to a club — fourth success criterion.
The two questions my partner could not answer from my wireframe alone:
1. "What happens after you tap Join?" There is no confirmation screen in my plan. I would add a short message on screen 3 saying "You have joined — see you Tuesday" and change the button to "Leave club", rather than a whole new screen.
2. "How do I switch the app to Welsh?" There is nowhere to do it. It belongs on the "Fi" tab in the navigation bar, which I have drawn but not designed, so I would note that on the plan instead of pretending the question is answered.
Takes the review seriously and records the gap honestly instead of quietly redrawing over it.