Build-It-Yourself — Prineeth Ramachandra

Build-It-Yourself — building with what you already have — 01
Building with what you already have

02
Context — cardboard in and around the school

Research documentation to be added

Research and framing

04
Material categorisation for algorithmic matching

Design principles visual to be added

Four design principles

Prototyping in the classroom — 09
Prototyping — 8 teacher–student pairs

Materials, troubleshooting, offline and privacy — 12
Materials, troubleshooting, offline, privacy

Reflections visual to be added

Thoughts and reflections

Project

Making and DIY culture has arrived in education, and it mostly arrives in a box you have to buy. BIY removes the kit. It is a phygital platform that generates building instructions from the materials a child already has — at home or in the classroom — using AR on the phones most families already own. The starting observation was mundane and local: .

The design problem is a matching problem. If the system is going to adapt to whatever is on hand, materials have to be categorised by what they can do — strength, flexibility, whether they can be cut, folded, joined, coloured — rather than by what they are. Most of the early work was building frameworks for that categorisation and testing whether they survived contact with a real pile of rubbish. Contextual inquiry with 15 children and 6 teachers confirmed that children were most engaged when using familiar objects in unfamiliar ways — the "wait, you can make that from this?" moment.

Four principles governed the design: resource adaptability, so the system offers alternatives when something is missing; phygital integration that does not dilute the hands-on part; learning-centred interaction that prioritises discovery over instruction-following; and a dual-user experience — simple enough for a child of eight, deep enough for the teacher standing behind them. Each one posed its own computational problem, which is a polite way of saying each one was harder to implement than to write down.

From there: flows, screens, and the awkward question of how much to put in front of a ten-year-old at once. The emotional journey we mapped went from excitement at the start, to frustration on encountering missing materials, to either abandonment or pride depending on whether a substitution was found. The interface had to catch people at the frustration point — which is a narrow window when you are eight.

We began with the least digital experiment available — . That told us what guidance is actually valuable mid-build, where frustration shows up, and how children respond to being asked to repurpose things. Two forms got explored, a T-Rex and a helicopter; by popular demand the T-Rex won. Testing with eight teacher–student pairs showed we needed visual confirmation of material substitutions and a much simpler categorisation scheme than the one I was attached to.

The revised architecture covers exploring materials, troubleshooting a build that will not stand up, working offline, and a parent-permission and privacy flow — because a system that learns what a child makes is collecting data about a child, which is a sentence that should make any designer pause.

The moment that settled it: a student explaining, proudly, how she had used a cardboard box from outside her house instead of chart paper. Her pride was not diminished by the substitution — it was larger, because she had solved it herself. What began as designing for resource-limited environments became the strength of the thing. The unsolved part is still the algorithm: suggesting viable alternatives without overwhelming a young user. I suspect it needs more technically strong eyes than mine.

Faces of minors obscured in the source documentation.