Loading...
A useful design explains how the planned parts work together to meet the analysed need. Justify data, algorithms, usability and tests instead of presenting disconnected diagrams.
What you'll be able to do
Break the problem into manageable responsibilities and explain why the boundaries are useful. A diagram can show the structure, but each component also needs a purpose, inputs, outputs and relevant interactions. A design should let another informed reader understand how the core behaviour will be achieved.
Describe algorithms at an appropriate level of precision, using pseudocode, flowcharts or other clear representations. An unlabelled box saying “calculate result” does not explain a central difficult algorithm. Identify preconditions, decisions, loops and important boundary cases, and show how the parts combine into the overall solution. Iterative refinement is compatible with design; record significant changes and their reasons.
Choose key variables, data structures and classes from the requirements. Explain the operations each representation supports and the trade-offs involved. A graph can represent route connectivity, but its edge meaning, direction, weight and constraints still need definition. A database diagram should connect entities through justified identifiers rather than repeat a picture of a screen.
Validation rules should follow the domain and be enforced at relevant boundaries. Interface design should include usability features that serve identifiable tasks, such as meaningful feedback, clear navigation and accessible input. Explain why a feature matters to the user and how its effectiveness can later be assessed. Attractive colours alone do not demonstrate a complete usability design.
Specify test data for iterative development and further post-development tests, with expected outcomes and a reason for each case. Normal, boundary and invalid cases should be derived from the actual rule. A minimum allowed value suggests tests just below, at and just above it; an empty data collection can expose a different class of fault.
Use independent expected results for core calculations rather than copying the program’s output into an expected column. Plan integration tests across component boundaries and final robustness/usability checks. A test plan can evolve when requirements or risks change, but retain enough traceability to explain the change. The objective is a justified verification strategy for the learner’s own design, not a generic table repeated without connection to it.
| Design question | Evidence to develop |
|---|---|
| Why these components? | Responsibilities and dependency explanation |
| How does the core method work? | Precise algorithm with important cases |
| Why this representation? | Required operations and trade-offs |
| What must be rejected? | Domain validation rules and responses |
| How will it be assessed? | Test cases, independent expectations and reasons |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.