Year 8 · Summer 2 · Raid: App Forge

Writing a design brief from user needs

What this lesson covers

Topic 14 Programming further

KS3 Computing · Real programs keep data in lists, take text apart as strings, split work into subroutines, check their input, save to files, and get tested on purpose.

Topic 11 Algorithms

KS3 Computing · An algorithm is a precise, step-by-step plan to solve a problem. Computational thinking turns a messy problem into one. Every algorithm is built from just three things: sequence, selection and iteration.

Computational ThinkingCambridge Lower Secondary Computing 0860

You will learn to

Explain what a design brief is, and why it comes before any code.
Use open interview questions to find out a partner's real problem.
Write a brief with a user, a problem, three features and a success list.
Identify which features the app must have and which can wait.

Success criteria

I can ask open questions and write down what my partner says.
I can write a brief that names one user and one problem.
I can write a success list where every line can be checked with yes or no.

Key words

Say each word, then read what it means. Every one is in the glossary too.

List: One name holding many values in order. Also called an array.
Index: An item's position in a list, counting from 0.
Subroutine: A named block of code you can call when needed.
Function: A subroutine that returns a value.
Parameter: A placeholder in a subroutine for a value passed in.
Validation: Checking input is reasonable before using it.
Boundary data: Test data at the very edge of what's allowed.
Algorithm: Precise, ordered, finite steps to solve a problem.
Decomposition: Breaking a problem into smaller ones.
Abstraction: Ignoring detail that doesn't matter for the problem.
Sequence · selection · iteration: Steps one after another. First this, then this.
Pseudocode: Code-like writing for algorithms, without strict rules.
Trace table: Records variable values step by step to check logic.
Variable: A named place in memory that holds a value.

The explanation

Read it here, or open the study page below to go one step at a time with things to try.

Start with the user, not the app

A user is the person who will use your app.

A design brief is a short plan. It says who the app is for, what problem it solves and what it must do.

Write the brief before any code. It stops you building something nobody needs.

e.g.Example

'I want to make a cool app' is an idea. 'New Year 7 pupils keep forgetting which room their lesson is in' is a problem. Start with the problem.

?Why?

Why not just start building?

Changing a plan takes a minute. Changing a finished app can take days.

Interview your user

An interview is a short chat. You ask questions and write down the answers.

Question type	What it is	Example
Open	Needs a full answer	'Tell me about the last time you lost your timetable.'
Closed	Needs only yes or no	'Do you lose your timetable?'

Ask mostly open questions.
Ask about what really happened, not what they might want.
Write down their words, not yours.
Do not pitch your app idea yet. Just listen.

★Remember

Start with 'Tell me about the last time…'. Real stories show the real problem.

Write the brief

Part	The question it answers	Example: the timetable app
User	Who is it for?	Year 7 pupils who are new to the school
Problem	What goes wrong for them now?	They forget which room each lesson is in, so they arrive late
Features	What will the app do? Three things at most.	Show today's lessons and rooms. Choose another day. Show a PE kit reminder.
Success list	How will we know it works?	See the list below

The success list says what 'finished' looks like. Each line can be checked: yes or no.

A pupil can see today's lessons in under 10 seconds.
Each lesson shows its room.
The pupil can change the day.
Three Year 7 testers find their next room without help.

!Watch out

Three features is plenty. A small app that works beats a big app that does not.

Must have or nice to have

You will have more ideas than time. Sort every idea into two groups.

Must have: the app is useless without it.
Nice to have: build it only if there is time left.

e.g.Example

Timetable app. Must have: show the lessons and rooms. Nice to have: a dark mode, sounds, a map of the school.

★Remember

Build every must-have first. Only then start a nice-to-have.

e.g.Worked example

Your partner says: 'I always forget my homework. I write it in my planner, then I never look at it.' Turn this into a brief.

User: a Year 8 pupil who writes homework in a planner but forgets to check it.
Problem: the homework is written down but missed, because nothing reminds them.
Features: add a homework task; see all tasks in a list; tick a task off when it is done.
Success list: adding a task takes under 30 seconds. A tester can add and tick off a task without help.
Nice to have: a reminder the day before. Build it only if there is time.

Study it

Open the study page and go one step at a time.

Topic 14 · Year 9

Programming further

Real programs keep data in lists, take text apart as strings, split work into subroutines, and get tested on purpose.

Topic 11 · Year 7

Algorithms

An algorithm is a precise, step-by-step plan to solve a problem. Computational thinking turns a messy problem into one.

Check yourself

One question at a time. The reason shows after each answer.

Saved on this device.