Pilot · L01 · 50 minutes
Designing a useful program
Compare two club-finder briefs, separate the user need from features and internal details, describe a program by purpose, inputs and outputs, and justify a revision with evidence from users.
Topics: 1.1 Collaboration · 1.2 Program Function and Purpose · 1.3 Program Design and Development
Goals and vocabulary
By the end you can:
- Distinguish a user need from a feature or implementation detail.
- Describe a program’s purpose, input events and outputs, and tell outputs apart from internal values.
- Explain how a division of work with shared review produces a better program.
- Choose a revision that is supported by evidence from a user test.
- User need
- What a specific user is trying to achieve, independent of how the program does it.
- Feature
- A visible part of a program, such as a screen or button, that is one way to meet a need.
- Input
- Data a program receives from outside, such as a tap, typed text or a file.
- Event
- An action, such as a tap or key press, that causes part of a program to run.
- Output
- Data a program sends out, such as text on screen, sound or a saved file.
- Iterative development
- Building in small cycles of design, test and revision.
- Program documentation
- Written explanation of how a program or part of it works and why, for other programmers.
Start from a need, not a feature
A program is useful when it helps a particular person do something they could not easily do before. That “something” is the user need. A feature — a screen, a button, a search box — is one possible way to meet it. Designers who start with features often build things nobody asked for.
Our running example is a club finder for a school. Ninth graders say: “I want to find a club that still has room and meets on a day I’m free.” That sentence names the user (ninth graders), the need (find a club with room, on a free day) and a constraint (they are free on some days, not others).
| Statement | Need or feature? | Why |
|---|---|---|
| Students want to know which clubs still have places. | Need | It describes what the user is trying to achieve. |
| Add a dropdown listing every weekday. | Feature | It is one way to collect the user’s free day; a checkbox list would also work. |
| Store each club’s places as a number. | Implementation detail | Users never see it; it is how the program keeps track internally. |
Inputs, outputs and purpose
Every program can be described by three parts. The purpose is the reason it exists. Inputs are data the program receives from outside — a tap, typed text, a sensor reading, a file. Outputs are what the program sends back out — text on screen, a sound, a saved file, a message.
Values the program works out along the way are not outputs unless they leave the program. In the club finder, the count of matching clubs is an internal value until the program displays it.
- Purpose: help a ninth grader find a club with places on a day they are free.
- Input event: the student taps “Find clubs” after choosing a day. (Choosing the day is also input; the tap is the event that starts the search.)
- Internal value: the list of matching clubs while it is being built.
- Output: the matching clubs shown on screen, or a message saying none match.
Worked example: comparing two design briefs
Worked example
Two teams wrote a brief for the same club finder. Read both, then follow the comparison.
The two briefs and their test counts below are fictional, invented for this lesson.
| Row | Brief 1 | Brief 2 |
|---|---|---|
| Opening line | “Students will love our animated club cards.” | “Ninth graders need clubs that have places on a day they are free.” |
| Screens | Welcome animation, club gallery, profile page | Day picker, results list, club detail |
| Input | Swipe through cards | Choose a day, tap Find clubs |
| Output | Cards with photos | Clubs with places on that day, or “No clubs match — try another day” |
| Evidence | None | 6 of 8 students we asked could not tell which clubs were full |
- Find the user need. Brief 1 never states one; it starts from a feature (animated cards). Brief 2 states it in the first line.
- Check that each screen serves the need. Brief 2’s three screens map to choose → see → decide. Brief 1’s profile page is not connected to finding a club with room.
- Check the output covers the empty case. Only Brief 2 says what happens when nothing matches.
- Check the evidence. In this fictional scenario, Brief 2 cites what its team observed when asking students; Brief 1 cites nothing and is a guess.
- Conclusion: Brief 2 is the stronger starting point. Brief 1’s cards might still be a good idea later, as a way to present Brief 2’s results.
Collaboration that improves the program
Teams produce better programs when they combine different perspectives and review each other’s work. Splitting work is useful only if the pieces are checked together: two students who each build half a program and never test the halves together usually find the problems on the last day.
- Agree the need and the inputs and outputs before anyone builds.
- Divide work by part (for example day picker and results list) and agree how the parts connect.
- Review each other’s part against the brief, not against personal taste.
- Invite people who are like the users — and people who are not like the team — to try it.
Revising with evidence
Design is iterative: build a small version, test it with users, and change it based on what you observe. A revision is justified when you can point to evidence — what a user did or said — that the change addresses.
| Observation | Justified revision | Not justified by this observation |
|---|---|---|
| 3 of 5 testers chose a day, then did not notice the Find clubs button below the fold. | Move the button next to the day picker, or search automatically when a day is chosen. | Change the colour scheme because the team prefers blue. |
| Testers asked “is this club full?” on the results screen. | Show places left next to each club. | Add a login screen. |
Documentation is part of revision too. A short comment that explains why the results list hides full clubs helps the next programmer avoid “fixing” a deliberate choice.
Explore each concept
Choose a concept, change its inputs and follow the explanation. Each example models the stated rule or scenario; completing it is practice rather than evidence of mastery.
- Diverse perspectives
- Driver and navigator
- Shared tools and conflict resolution
Change it · step through · explain
Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.
Ready · Make a prediction
- Team approachpaired-reviewWaiting
- User evidencecolour-vision-barrierWaiting
Ready to explore: Pair programming and shared review
Why: Change an input, predict the first effect, then advance one step.
Try this: Change one input or choose another listed case. Predict the effect, reset and compare the states and governing rule.
Step through and experiment
Change it · step through · explain
Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.
Ready · Make a prediction
- Input 1visible-and-labelledWaiting
Ready to experiment
Why: Predict the first change, then advance one step.
Try this: Compare text-only with visible-and-labelled. Which barrier remains?
Step through and experiment
Change it · step through · explain
Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.
Ready · Make a prediction
- Input 1ArtWaiting
- Input 25Waiting
Ready to experiment
Why: Predict the first change, then advance one step.
Try this: Try 0, 007, an empty input and a letter. Does validation or display change?
Common misconceptions
The need is the feature list
The belief: A good brief lists the screens the team wants to build.
What is actually true: A brief starts with who the user is and what they need. Screens come later and are judged by whether they serve that need.
Check yourself: Can you rewrite your first sentence without naming any screen or button?
Every value is an output
The belief: The count of matching clubs is an output because the program calculates it.
What is actually true: A value is output only when it leaves the program — shown, played, saved or sent. Until then it is internal.
Check yourself: Where would a user see or hear this value?
Any change is an improvement
The belief: A revision is good if the team likes it better.
What is actually true: A revision is justified when it addresses something users actually did or said during testing.
Check yourself: Which observation does this change respond to?
Guided practice
Guided: pull apart a brief
Work with a partner on Brief 3 below. Fill a three-column table: need, feature, implementation detail.
- Underline the sentence that states the user need.
- List every feature mentioned and say which part of the need it serves.
- Find the implementation detail and explain why users never see it directly.
- Name the input event and the output of booking a room.
- Write one question you would ask real students before building.
Independent practice
Independent: revise from a test
Your team tested the club finder with five ninth graders. Use the notes to propose one revision and justify it.
- Tester 1 picked Tuesday, saw three clubs, joined one. No problems.
- Testers 2 and 4 picked a day, then scrolled looking for a button. Both asked “how do I search?”
- Tester 3 asked whether the Robotics club was full.
- Tester 5 said the purple header was “a bit much”.
- Choose the problem that affected the most testers or blocked the user need.
- Propose one revision and describe what will change on screen.
- Quote the observation that justifies it.
- Say how you would check the revision worked in the next test.
- Write a one-sentence comment another programmer would need to understand your change.
Exit check
- A classmate says “the app’s purpose is to have a results screen.” Rewrite the purpose as a user need.
- Name one input and one output of the club finder, and one value that is internal.
Check yourself
Practice only: answers are checked in your browser and nothing is saved or sent to your teacher. Each explanation links back to the section it practises.
Lesson practice
Your practice so far
Check an answer to see its rationale.
Apply it somewhere new
Your practice so far
Check an answer to see its rationale.