Every course is different. The editor didn't know that yet.

Most curriculum tools make a quiet assumption: that all courses are shaped the same way. Pupilfirst made that assumption too. Fixing it meant questioning something much deeper than the interface.

01 — CONTEXT

The assumption baked into every curriculum tool

Think about how you learned something. Maybe it was a linear sequence: lesson one, lesson two, lesson three. Maybe it was organised by levels, each containing a set of topics. Maybe it was something looser, where you moved between concepts based on what you needed next.

Now think about the person who built that course. They had a mental model of how their content was structured. A shape. And they had to force that shape into whatever tool they were using.

At Pupilfirst, the existing editor enforced one structure: levels, each containing topics. It worked for many courses. But it silently failed every teacher whose content didn't fit that mould. They weren't doing it wrong. The tool was just thinking too narrowly.

Pupilfirst was building tools for learners of today, across subjects, contexts, and teaching styles. The question we started asking was a simple one: is it fair to force every teacher into the same structure, just because it was the structure we had always used?

The answer was obviously no. Figuring out what to do about it took us somewhere we didn't expect.

02 — the flaw in the foundation

It wasn't a UI problem. It was a structural assumption.

The more we explored, the clearer it became. The issue wasn't the editor's interface. It was the data model underneath it. An editor that forces levels and topics forces every teacher to think in levels and topics, no matter what their course actually looks like.

The old model

Course contains levels. Levels contain topics. Topics contain content. Every course, the same shape. Teachers built what they could, not what they wanted.

What we needed

A structure that could be whatever the teacher needed. Linear for some, nested for others, branching for a few. The tool had to follow the teacher's thinking, not the other way around.

Our CTO pushed for us to explore a pages model. A page could contain content, but it could also contain other pages, creating a hierarchy as deep or as shallow as the course required. A teacher wanting two levels of nesting could have that. A teacher wanting a flat list could have that too.

It felt like the right direction. And then we hit a wall.

03 — the wall we didn't see coming

Pages solved structure. But courses need more than structure.

A curriculum isn't just content organised in a hierarchy. It has tests. Assignments. Milestones. Ways of knowing whether a student has actually finished something, understood it, demonstrated it.

The pages model handled content beautifully. But when we asked "how do we add an assignment here?" or "how does the system know a student has completed this section?", we had no clean answer.

We had been thinking of content as blocks and everything else as something separate. A different layer, a different system. That is when it clicked: what if everything was a block? Not just text, images and documents. Assignments, quizzes, milestones too. If every piece of a curriculum lived in the same block system, the structure problem and the assessment problem had the same solution.

This wasn't a planned decision. It emerged from hitting the wall. But once it surfaced, it was obviously right. I quickly built prototypes around it, we stress-tested it together, and it became the foundation of everything that followed.

04 — the flexible structure

A flexible structure is only useful if teachers can see it

The model gave teachers freedom. Freedom is only valuable when you know how to use it. And that meant the editor had one job above all others: make the structure of the course visible, readable, and obvious at every moment.

A teacher building a course shouldn't have to hold the structure in their head. They should be able to see it. If they couldn't glance at the editor and immediately understand the shape of what they were building, the flexibility we'd given them would become confusion instead of power.

The tree was the source of truth

The sidebar showed the full course as a navigable tree at all times. Indentation communicated depth. Labels communicated type. A teacher could see their entire course structure at a glance, understand where they were inside it, and move anywhere with one click. The tree never hid or collapsed by default.

Block types were visually distinct, not just labelled

A text block, a quiz block and a milestone block looked different in the tree and in the editor. Not through colour alone, not through labels alone, but through a combination of icon, shape, and position. Teachers learned to read the structure visually, the way a musician reads notation.

Every action communicated its consequence before you took it

Adding a page inside another page showed a preview of where it would appear in the tree before it was created. Moving a block showed the destination highlighted. Nothing happened silently. The editor narrated its own structure in real time.

Depth had a visual cost

Deeply nested pages became visually heavier in the tree: tighter spacing, lighter text. It wasn't a hard limit, but it was a gentle signal. Teachers naturally kept their structures shallow because the UI made depth feel like a decision, not a default.

The principle behind all four

Structure should be something a teacher sees, not something they have to remember. Every visual decision in the editor was in service of that. When the structure is visible, the teacher is free to think about the course. When it isn't, they spend their energy thinking about the tool.

05 — OUTCOMES

What changed for teachers

Anystructure now possible

Blocksfor every need

Task completion rates in the editor went up 15 to 20 percent. That number represents teachers getting further through building their courses without getting stuck or giving up. The editor stopped being a source of friction and became something they moved through without thinking about it.

The system also preserved backwards compatibility. Courses built in the old level and topic structure continued to work, now expressed as pages and blocks. The migration was seamless because the new model was a superset of the old one. That was a deliberate constraint: whatever we built, it couldn't break what teachers had already made.

The best sign that an editor is working: teachers stop thinking about the tool and start thinking about their course.

06 — NEXT STEPS

What to do differently

Involve teachers in the structural decisions earlier

We made the pages model decision largely from first principles and internal discussion. Testing the concept with actual teachers at the whiteboard stage would have surfaced the assessment problem a full cycle earlier.

Define student completion as a first-class constraint

The milestone and completion logic came late. It shaped several block types in ways that needed rework. That thinking needed to sit alongside the structural model from the very beginning, not follow it.

The lasting lesson: when a tool isn't working, the problem is rarely the interface. It's usually the assumption underneath it. The level and topic model wasn't a bad UI. It was a confident answer to the wrong question. Asking the right question, and keeping the team focused on it, changed everything else.