Context

Raspberry Pi had been relying on Trinket, an open-source code platform integrated across multiple products. It worked, but it was borrowed infrastructure with real limitations: no control over the experience, no ability to adapt it for our specific users, and no way to serve the breadth of contexts the Foundation needed. We decided to build our own. I was the designer at the conception.

‍

Problem

The brief was technical. The real problem was human. A code editor for children learning to code for the first time needs to optimise for something most editors ignore: the feeling that you can do this. The moment a child hits an error and doesn't understand it is the moment they close the tab. The interface either prevents that moment or causes it. There's no neutral ground.

‍

Goal

Build a code editor that feels simple and un-intimidating for the widest possible audience, from a seven-year-old in a classroom to a student writing code that would go to space on the Astro Pi Mission Zero programme. It had to adapt across contexts: embedded within the Projects site, standalone for Astro Pi, and responsive across every device a teacher might use in a classroom, and safe for school environments where safeguarding is a non-negotiable constraint.

The decision that shaped everything: design for the moment before someone gives up

I started by mapping the user journey, not what users do, but what they feel. Specifically, what happens in the moment when code doesn't work and a young user doesn't understand why?

That question changed every subsequent decision. Error messages became as important as the interface itself. The difference between "SyntaxError: unexpected token" and "Something's off on line 4 — here's what might help" is the difference between a child who keeps going and one who closes the tab. I rewrote every system error message with the same care as the UI — which meant working directly with engineering on implementation, not just handing off a design file.

‍

The constraint: one editor, multiple contexts

This product wouldn't live in one place. It had to work as an embedded code display within the Projects site, as a standalone editor for Astro Pi, and as a classroom tool displayed by teachers on devices ranging from tablets to projectors.

That meant building versatility into the system from the start, responsive layouts, flexible type sizing, and an accessibility-first approach to contrast and hierarchy so that a child reading the screen from the back of a room had the same experience as one sitting in front of it.

‍

Six wireframe stages before a single design decision

The wireframing process was extensive because the constraints were genuinely competing: keep features minimal, keep hierarchy clear, keep the layout buildable quickly, and make sure it could scale as features were added later. After six stages of wireframing and stakeholder feedback, we landed on something that held all of those constraints without sacrificing any of them.

‍

Style: harmony with the ecosystem, identity of its own

The visual design had to feel coherent within the Raspberry Pi product family while being distinct enough to function as its own tool. Dark mode wasn't an aesthetic option. It was a deliberate personalisation mechanism, when someone customises the environment they're working in, they feel ownership over it, and ownership increases the likelihood they come back.

Strategic considerations

‍

One filter for every decision

‍Is this safe for a school environment, and does it serve the learning without distracting from it?‍

‍Image uploads were removed entirely

‍An open upload function in a tool used by children creates safeguarding risks that no design solution fully resolves. Removing it was the right call, not a compromise.‍‍

Remix is the hardest debate

‍Letting students copy and build on each other's projects, as Scratch allows, had a real motivational case. The safeguarding implications and distraction risk outweighed it. It's still a decision I think about.

Text size settings is one feature, two problems

‍Accessibility for students with visual needs, and practicality for classrooms where a teacher might be projecting onto a screen twenty feet away.

Dark mode for personalisation, not aesthetics‍

‍Ownership over your environment increases the likelihood you come back. Scoped to one toggle — full colour customisation was considered and cut. Too many choices in a tool designed to reduce cognitive load works against itself.

What I'd do differently

The remix decision is the one I'd revisit with more time and more research. We made the right call for the launch scope, but I don't think we fully stress-tested the motivational case. A controlled version, where students can view but not copy, or remix only within a teacher-managed classroom  might have threaded the needle between engagement and safeguarding. I'd want to design and test that properly.