ROBOTICS AND CODING MODULE

Project Workshop

Turning a vague idea into a chain of problem, user, criteria, constraints, prototypes, tests and evidence.

Last updated: 27 July 2026
MODULE IDENTITY

The distinctive work of this module

Turning a vague idea into a chain of problem, user, criteria, constraints, prototypes, tests and evidence.

Completion evidence: Project canvas, version log, test table, safety note and presentable output.

Choose a small real problem; state success as a number or behaviour, then test a paper prototype and a working version separately.

Core production

Project canvas, version log, test table, safety note and presentable output

Laboratory

Choose a small real problem; state success as a number or behaviour, then test a paper prototype and a working version separately.

Safety / limit

Record power, wiring, data or user limits on hardware, and model limitations in simulation.

LESSON SEQUENCE

A 16-step learning pathway

The order is recommended. Before a project page, complete evidence from foundation, practice and debugging lessons.

01 · Doing Research

Learn to research similar solutions from reliable sources, take notes and cite where things came from.

Open lesson →

02 · Making a Demo Video

Learn to record a short demo video of your project working, safely and with respect for privacy.

Open lesson →

03 · The Requirements List

Learn to write what your project must do as clear, prioritised and measurable requirements.

Open lesson →

04 · The Bug Log

Learn to record the bugs you find with their date, symptom, cause and fix, and track them tidily.

Open lesson →

05 · Improving

Learn to improve your project in small steps from tests and feedback, and to know when it is good enough.

Open lesson →

06 · Using Sources and Licences

Learn to use other people's work responsibly, with permission, licences and proper attribution.

Open lesson →

07 · Understanding Users and Needs

Learn to figure out who your project is for and what they really need, using observation and questions.

Open lesson →

08 · Bill of Materials and Cost

Learn to list the parts your project needs and work out quantities and an estimated cost.

Open lesson →

09 · How to Choose a Problem

Learn to choose a small, doable and meaningful project problem that starts from a real need.

Open lesson →

10 · Post-Project Review

Learn to look back after a project at what went well, what you learned and what you would change next time.

Open lesson →

11 · Documenting a Project

Learn to document your project so others can understand and reproduce it, and write a README.

Open lesson →

12 · Prototyping

Discover the power of building a rough, quick first version and learning by trying early.

Open lesson →

13 · Preparing a Presentation

Learn to present your project as a short, clear problem–solution–result story that respects privacy.

Open lesson →

14 · Sketch and Flowchart

Learn to plan your idea with a sketch, block diagram and flowchart before you build.

Open lesson →

15 · Test Scenarios

Learn to test your project in a planned, repeatable way using 'input → expected output' scenarios.

Open lesson →

16 · Solution Alternatives

Learn to come up with several solutions to the same problem and pick the best by weighing pros and cons.

Open lesson →
EVIDENCE MATRIX

Four checks before saying it works

Four checks before saying it works table
CheckQuestionEvidence to keep
InputWhich value, event or user request enters the system?Sample inputs and edge cases
ProcessWhich rule, algorithm or physical relationship is applied?Code, calculation, diagram or state table
OutputWhat should be observed in correct and incorrect states?Expected–actual comparison
SafetyUnder which condition should the system stop or request help?Safe-stop and recovery behaviour
MODULE-SPECIFIC DEPTH

Project Workshop: from one example to a system

Turning a vague idea into a chain of problem, user, criteria, constraints, prototypes, tests and evidence. A correct example alone is therefore insufficient. Completion evidence should be project canvas, version log, test table, safety note and presentable output, tested with normal, boundary and invalid inputs.

In the first cycle, pair foundation and application among Doing Research, Solution Alternatives, Making a Demo Video, The Requirements List, The Bug Log. Predict the result, run or measure it, then explain any difference. Even when prediction and reality match, state which changed condition would break the result.

In the second cycle, complete this laboratory: Choose a small real problem; state success as a number or behaviour, then test a paper prototype and a working version separately. Do not close with one successful screenshot. Keep the input table, expected behaviour, actual behaviour, error or measurement and the correction in one file.

In the final cycle, connect Documenting a Project, Prototyping, Preparing a Presentation, Sketch and Flowchart, Test Scenarios. Let one lesson's output become another lesson's input; show where safe stopping is needed when data type, unit, wiring, timing or user expectation changes.

Repeat the same task one month later with less source support. Compare not only speed or appearance but test coverage, explainability, safety and whether another person can rebuild the work.

CROSS-LESSON BRIDGE

How do Doing Research and Test Scenarios connect?

Use the foundation produced in Doing Research as an input to Bill of Materials and Cost. Then show in Test Scenarios how the same idea changes under the limits of a larger system. This bridge carries the goal of turning a vague idea into a chain of problem, user, criteria, constraints, prototypes, tests and evidence. beyond one isolated example.

Add three columns to the project canvas, version log, test table, safety note and presentable output file: knowledge carried from the previous lesson, condition changed in the new lesson and result observed in testing. Sharing a word does not establish a connection; one lesson’s output should genuinely become the next process’s input.

Test the connection through this laboratory: Choose a small real problem; state success as a number or behaviour, then test a paper prototype and a working version separately. After the first attempt, add an edge condition such as empty data, wrong type, disconnected input, extreme value or user error. Record whether the system remains understandable and safe beyond the normal example.

  • Name the previous lesson output
  • State the one changed condition
  • Separate expected and actual result
  • Define safe stopping or error feedback
  • Make one change in the second version
MICRO QUIZ

Test the reasoning behind the module

1. What is the module completion evidence?

Project canvas, version log, test table, safety note and presentable output

2. Does a simulator replace hardware testing?

No. A simulator tests logic; physical power, wiring and sensor conditions require separate tests.

3. Which four fields belong in an error log?

Condition, expected result, actual result and change made.

4. When should the project page be opened?

After completing foundation concepts and at least one practice artefact.

5. What is the module mini laboratory?

Choose a small real problem; state success as a number or behaviour, then test a paper prototype and a working version separately.

PRIMARY SOURCES

Verify versions and tool behaviour

NASA Engineering Design Process

Primary source for current technical behaviour and limits.

Open source →

W3C Accessibility Principles

Primary source for current technical behaviour and limits.

Open source →