Key Stage 4 computing · Computational thinking

GCSE computing design skills: a guide for parents

Design is the planning stage that happens between understanding a problem and building the answer. At Key Stage 4 pupils learn to apply design skills to computing problems: deciding what a system must do, what data it needs, how people will use it and how they will know it works. Strong design makes the programming that follows quicker, and it is a skill pupils are expected to explain as well as do.

Design skills in computing, explained

The National Curriculum lists design alongside analytic, problem-solving and computational thinking skills, and says pupils should be able to evaluate and apply information technology, including new or unfamiliar technologies, analytically to solve problems. Design is where those ideas meet. Before building anything, pupils are expected to work out who the users are, what the system needs to achieve and how they will judge success. Teachers usually call these the requirements or success criteria, and they are written down at the start so they can be checked at the end. Part of the design is choosing the right technology for the job, such as a spreadsheet, a database, an online form or a program written from scratch, and justifying that choice against the requirements, even when the tool is one your child has not used before.

A design has several layers. The first is the structure of the task: what goes in (inputs), what the system does with it (processes) and what comes out (outputs). Flowcharts and pseudocode describe the logic of a program, showing decisions and loops before any code is written. The second layer is data: what facts must be stored, what each one is called and what type it is, such as a whole number, text, a date or true or false. A well-designed set of fields makes later searching and sorting far easier.

The third layer is the part the user sees. Pupils sketch screens, sometimes called wireframes, and think about how a user will move through them, what instructions they need and how errors will be explained. They plan checks that stop bad data getting in, called validation, and think about people who need extra support, so text must be readable and nothing should rely on colour alone. Pupils also consider security and privacy: who should be able to see and change what, and what should never be stored.

Finally, a design includes a test plan and an evaluation. The test plan lists what will be tried, with what data and what result is expected. The evaluation compares the finished system with the original requirements, using real feedback from users, and suggests improvements. Designs are meant to change: a good project loops back, adjusting the plan when a test or a user shows something was missed. Teachers value that honest cycle of design, build, test and improve more than a perfect first draft.

Words your child will hear

Requirements: A clear list of what a system must do, agreed before building it.
Success criteria: Specific, checkable statements used to decide whether the solution works.
Flowchart: A diagram using standard shapes and arrows to show the steps and decisions in an algorithm.
Data type: The kind of value a piece of data holds, such as integer, string, date or Boolean.
Wireframe: A simple sketch of a screen showing where items will go, drawn before any building starts.
Validation: An automatic check that data entered is sensible, such as being in a permitted range.
Iterative development: Improving a solution in repeated cycles of design, build, test and review.

What the National Curriculum says

The programme of study for Key Stage 4 says:

All pupils should be taught to develop and apply their analytic, problem-solving, design, and computational thinking skills
Aim: pupils can evaluate and apply information technology, including new or unfamiliar technologies, analytically to solve problems.

Objectives from the National Curriculum in England, © Crown copyright, used under the Open Government Licence v3.0.

Try it: designing a lost property tracker for school

The school office wants a simple system to log lost property, so that staff can record an item and pupils can find it. Show how your teenager might design it before building anything.

Find the users and write requirements. The users are office staff, who add and remove items, and pupils, who search. Success criteria: an item can be logged in under 30 seconds; a search by colour or type shows matching items; an item is marked returned once collected.
Describe inputs, processes and outputs. Inputs: item type, colour, where found, date found. Processes: store the record, search records, mark as returned. Outputs: a list of matching items and a confirmation message.

Design the data. Each item is one record with these fields and data types.

ItemID     integer (automatic)
ItemType   string
Colour     string
Place      string
DateFound  date
Returned   Boolean (true/false)

Plan validation. The date cannot be in the future. The item type must be chosen from a list so that “jumper” and “jumpers” are not stored separately. The colour cannot be left empty.
Sketch the interface and the logic. Draw an “add item” screen and a “search” screen, with clear buttons and a message such as “No items found”. Draw a flowchart for the search: input colour, loop through the records, show the ones that match and are not returned.
Write a test plan using three kinds of data: normal (a blue coat found last week, which should be saved), boundary (found today, which should be accepted, and found tomorrow, which should be rejected) and erroneous (letters typed into the date box, which should be rejected with a clear message). State the expected result for each before testing, then evaluate with real office staff and revise.

A complete design has requirements with measurable success criteria, inputs, processes and outputs, a table of fields with data types, validation rules, interface sketches, a flowchart, a test plan with expected results, and a plan to gather user feedback and improve it.

Common mistakes and how to help

“Design is just drawing a nice screen”

Visual design is the part that looks like design, so the data, logic and testing are skipped or left until later.

What helps: Ask your child to point to the inputs, processes and outputs in their plan, and to show where data is stored. A design should answer how the system works as well as how it looks.

Writing vague success criteria such as “it should be easy to use”

These statements feel sensible, but they cannot be checked, so nobody can say whether the finished product succeeded.

What helps: Ask “how would we measure that?” A better criterion is “a new user can add an item without help in under a minute”.

Storing everything as text

Text is the easiest thing to type, and children do not yet see why data types matter.

What helps: Show that dates stored as text sort alphabetically rather than in time order, and numbers stored as text cannot be added up properly. Choosing the right type avoids that.

Treating the first design as final

Planning takes effort, so changing it later feels like failure.

What helps: Reassure your child that revising a design after testing is the normal process and shows good judgement. Ask what the test taught them.

How to help at home

Design something before building it. Choose a simple everyday system, such as a rota for jobs at home or a way to track who has borrowed what. Ask your teenager to list the users, the information needed and what a good result looks like.
Sketch it on paper. Pencil and paper are enough for screens and flowcharts. A quick sketch you can both point at often reveals a missing step or button that would have cost far more time to fix in code.
Be the user. Offer to test their prototype without any help from them. Notice where you hesitate, and tell them honestly. Feedback from a real person is the core of the evaluation stage.
Spot good and poor design around you. A confusing self-service machine or form is a design problem. Ask what the designer should have known about the user and what rule or message would have prevented the mistake.
Talk about the choices. Ask why they chose a particular field, button or check. Being able to justify design decisions in writing is what teachers look for, and it shows real understanding.

Builds on

Key Stage 3: Abstraction and modelling