The design process for QCE Digital Solutions Unit 3
“Apply a structured design process of exploring, generating, producing and evaluating to develop a digital solution from a real-world problem”
The design process moves through exploring the problem and its requirements, generating and evaluating ideas, producing the solution by prototyping and building, and evaluating it against the requirements; it is iterative, so you cycle back to refine earlier stages as you learn, and each stage produces artefacts that justify the next.
Jump to a section
What this dot point is asking
QCAA frames the whole subject around a structured approach to solving problems, often described as exploring, generating, producing and evaluating. This dot point is about the process itself: how a developer moves from a real-world problem to a justified, tested solution. The process is iterative, not linear, and it is the spine of both IA1 and IA2. Understanding it lets you organise your project work and explains why design artefacts (requirements, algorithms, prototypes, tests) appear in the order they do.
Exploring the problem
The first stage is understanding the problem before solving it. You investigate the real-world context, identify the users and their needs, and specify the requirements and constraints (see the solution requirements dot point). You gather and analyse information, including how existing solutions work and what data is involved. The output is a clear problem definition and a set of requirements that every later decision is judged against. Rushing this stage is the root cause of most weak projects.
Generating ideas
With the problem understood, you generate possible solutions and evaluate them against the requirements and constraints. This includes sketching interface ideas, considering data models, choosing structures and technologies, and weighing alternatives. The point is to make and justify design decisions deliberately rather than building the first idea. You document the options you considered and why you chose one, because that reasoning is exactly what IA1 rewards.
The design process is iterative. You do not finish exploring, then never return; testing a prototype often reveals a missed requirement, sending you back to refine the design. Showing this cycling, where evaluation feeds back into earlier stages, demonstrates a genuine design process rather than a one-pass build, and it is what separates high responses from mid ones.
Producing the solution
Producing is where design becomes a working artefact. For a digital solution this means prototyping interfaces, writing and testing algorithms, building the database, and integrating the components into a running solution. Prototyping is central: you build progressively more complete versions, testing as you go, rather than attempting the whole solution at once. Each prototype is evaluated and refined, which is the iterative loop in action. Version control of your work and incremental testing keep the build manageable.
- Explore: interview the client, define users (staff and customers), and specify requirements (make a booking, view availability) and constraints (web platform, two-week deadline).
- Generate: sketch two interface layouts, design a data model with a bookings table, choose a list-of-records structure, and justify the chosen design against the requirements.
- Produce: prototype the booking form, write and desk check the availability algorithm, build the database, and integrate, testing each part as it is added.
- Evaluate: test each requirement with normal, boundary and abnormal data, judge fitness for purpose, and recommend improvements.
Each stage feeds the next, and a defect found in evaluation sends you back to refine the produce or generate stage.
Evaluating the solution
The final stage judges the solution against the requirements using test evidence (see testing and evaluation strategies). Evaluation is reasoned: it states which requirements are met, which are not, what the limitations are, and what would improve the solution. A genuine evaluation acknowledges weaknesses rather than claiming perfection, and it feeds back into the next iteration. In a finished project, evaluation closes the loop opened by exploring, answering whether the original problem was solved.
Why a process matters
A structured process makes the work traceable: each artefact justifies the next, and the finished solution can be traced back to the original requirements. It also makes the project manageable within a deadline by breaking it into stages with clear outputs. QCAA assesses your reasoning across the process, not just the final product, so documenting decisions at each stage is as important as the code.
How this appears in assessment
IA1 (the technical proposal) is largely the explore and generate stages: investigating the problem, specifying requirements, and designing and justifying a solution. IA2 (the digital solution) is the produce and evaluate stages: building, testing and evaluating a working solution. IA3 applies the same process to a data exchange. The external exam can ask you to identify a stage or describe what happens in it. Use the process to structure your project documentation end to end.
- Skipping exploration. Building before the problem and requirements are clear produces a solution that solves the wrong thing.
- Treating the process as linear. Strong responses iterate, cycling back from evaluation to refine earlier stages.
- No justification. Markers assess your reasoning at each stage; an undocumented decision earns nothing.
- Building everything at once. Prototype and test incrementally rather than attempting the whole solution in one pass.
- Evaluation that claims perfection. A real evaluation names limitations and improvements, supported by test evidence.
Exam-style questions
Questions in the style of QCAA exam questions on this dot point, each with a worked answer. They are written by ExamExplained unless tagged "Past paper"; the year shows the paper a question is modelled on.
Practice8 marksAnalyse how the four stages of the design process (explore, generate, produce and evaluate) apply when developing a digital solution for a small business, and justify why the process is iterative rather than strictly linear.Show worked answer →
An 8 mark analyse-and-justify answer rewards mapping each stage to digital work and defending iteration.
Analyse: explore investigates the problem and requirements; generate designs solutions (algorithms, data and interface designs) and evaluates options; produce implements and refines a working solution; evaluate tests it against the requirements and judges its success. Each stage produces evidence the next stage uses.
Justify iteration: testing in evaluate often reveals a requirement that was missed or an algorithm that fails an edge case, so the developer loops back to generate or produce; prototyping deliberately cycles to refine. A strictly linear process would lock in early mistakes. Markers reward correct stage roles and a clear reason that feedback loops improve the solution.
Practice4 marksExplain the purpose of the evaluate stage of the design process and how it differs from testing during the produce stage.Show worked answer →
A 4 mark explain answer needs the role of evaluate and the contrast with produce-stage testing.
Testing during produce checks that the code works as built (does this function return the right value). The evaluate stage steps back to judge the whole solution against the original requirements and criteria, asking whether it actually solves the user's problem and how well, often recommending improvements.
Markers reward distinguishing low-level correctness testing in produce from holistic, criteria-based judgement in evaluate.