C05 · Topic 1.3 · 40 minutes · CRD-2.E, CRD-2.F, CRD-2.G, CRD-2.H
Designing for a user
By the end you can:
- Translate needs into testable requirements.
- Compare designs using relevant criteria.
- Describe a development process without assuming it is linear.
Before this lesson: topics 1.2.
- Requirement
- A condition the solution should satisfy for its intended users.
- Iteration
- Revising a design through repeated development and evaluation.
Understand
Start design from a user need, then describe behaviour that would satisfy it. A useful requirement can be checked: “a user can identify a free room without distinguishing red from green” is more informative than “the app is good”. Consider input, processing, output and how users interact with the result.
Development can include investigation, design, prototyping, implementation, testing and refinement in different orders. Teams often return to an earlier step after discovering an assumption. A prototype can answer a design question without implementing every final feature.
Worked example
A booking prototype uses only red/green icons to indicate room status.
- Need: identify availability, including users who cannot distinguish those colours.
- Requirement: provide readable status text or a non-colour cue for every room.
- Prototype two alternatives and ask users to identify a free room; compare errors and completion, not just appearance.
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.
- Requirements and prototypes
- Incremental versus iterative work
- Comments, documentation and acknowledgement
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
- Development approachiterateWaiting
- Documentation audienceuserWaiting
Ready to explore: Iterative development and documentation
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?
Check a misconception
Claim: Requirements should name the exact code before understanding the need.
Specify the intended behaviour and constraints first; implementation choices should serve them.
Guided practice
Write a testable requirement for finding the booking action.
Work with a partner. Make a prediction, compare your reasoning, then identify the rule that supports your answer.
Independent transfer
A team can build either a full animation or a text-status prototype. Which better investigates the stated access question?
Exit check
Why may testing lead back to design?
Write your reasoning before comparing with a classmate. If your teacher assigned this task, submit it through My classes to save your work and receive feedback.
Check yourself
Your practice so far
Check an answer to see its rationale.