Technological Practice
Technological Practice is the domain that tests how you move from an issue or opportunity to a fit-for-purpose outcome. At Level 2, the exam rewards justified decisions: why you consulted particular stakeholders, why your specifications are testable, and how evidence from development shaped the final outcome. It is not a description of steps.
Brief development
An issue is the problem or opportunity; the context is the place, people, and practice in which it sits. A brief is a living document. It starts with stakeholder consultation, then a conceptual statement of the intended outcome, specifications (measurable attributes the outcome must have), and constraints (non-negotiable limits such as budget, deadline, regulations, or available tools). Specifications must be testable: “holds 30 bikes” beats “strong”.
Planning and development
Planning tools - action plans, Gantt charts, flowcharts, CAD, physical mock-ups - are used to manage time, resources, and dependencies. Conceptual design explores alternatives before commitment. Development is iterative: make, test, evaluate, modify. A prototype is trialled against specifications and constraints, and evidence (test data, photographs, stakeholder feedback, annotations) is used to justify changes. Fitness for purpose means the outcome meets specifications within its context.
Worked example
A school needs secure, dry bike parking. Context: 800 students, a concrete courtyard, limited covered space. Stakeholders: students, property manager, board. Brief: “Develop a secure, weather-protected bike parking system for 30 bikes that fits the existing courtyard and can be maintained by school staff.” Specifications: holds 30 bikes; keeps bags dry in moderate rain; lockable frame; no trip hazards; fits 6 m × 3 m; under $8,000. Constraint: no digging into concrete; installation by end of Term 2. Reasoning: each specification is measurable, so the prototype can be trialled and judged.
Traps
- Calling the context the issue, or writing vague specifications such as “cheap” and “strong”.
- Using planning tools as decoration rather than to make and record decisions.
- Ignoring stakeholder conflict, or failing to link feedback to a design change.
- Treating a prototype as the final outcome, or claiming it works without test evidence.