Curriculum Intelligence Infrastructure
Turning fragmented curriculum data into a connected system for mapping, coverage, planning and AI-assisted learning journeys.
Contents · 12 chapters
The information existed. The relationships didn’t.
- ROLE
- Product Designer
- TIMELINE
- 2025
- CLIENT
- Confidential / NDA
- DISCIPLINES
- Product design · Systems design · AI UX
The whole tool, rebuilt on invented data. Click through it.
Client work under NDA. Every screen shown is from an anonymised rebuild.
The curriculum team was managing frameworks, competencies, learning resources and content across multiple spreadsheets. The sheets contained the information they needed, but answering questions across them required significant manual work.
- Does this competency match?
- What needs to be learned before this?
- Have we already covered it?
- Do we have a resource for it?
- What should we create next?
Every question required someone to manually reconstruct relationships across different sources. The challenge wasn’t simply organising more information. It was making those relationships visible and usable.
A curriculum isn’t a list. It’s a network.
Initially, the problem could have been approached as a better interface for managing curriculum data. But mapping the existing workflows revealed that the spreadsheet rows weren’t the most important part. The relationships between them were.
- A competency could belong to a framework.
- It could depend on other competencies.
- It could correspond with competencies from another framework.
- Multiple resources could address it to different degrees.
- And its coverage could ultimately influence what content should be created next.
That led to the central design question:
How might we turn fragmented curriculum data into a connected system that helps teams understand what exists, what’s missing and what should happen next?
Before designing the workflows, I designed the relationships.
Rather than treating Crosswalk, Coverage, Resources and Learning Journeys as separate products, I modelled the common infrastructure underneath them.
This became the backbone of the product. Once these relationships existed, the same system could begin answering several previously disconnected questions.
| Question | Relationship |
|---|---|
| What does this content teach? | Content → Competency |
| What should learners know first? | Competency → Dependency |
| How does this map to another curriculum? | Competency ↔ Competency |
| What haven’t we covered? | Competency → Coverage |
| Do we have something for it? | Competency → Resource |
| What should come next? | Gaps + Dependencies + Resources |
How might we compare curricula without manually comparing rows?
Different frameworks could describe overlapping learning outcomes using different language and structures. Previously, experts had to manually inspect competencies across different sources to identify those relationships.
I designed Crosswalk to bring the comparison into one workspace.
The design shift
- Search
- Compare rows
- Interpret
- Document manually
- Select frameworks
- Review relationships
- Identify gaps
Instead of simply telling users whether two competencies matched, the experience surfaced different levels of alignment: Covered · Partially covered · Missing. This turned framework comparison into something more useful: gap analysis.
A missing relationship could now become the beginning of another workflow.
Knowing what to teach wasn’t enough. We needed to understand what came before it.
Learning outcomes don’t exist independently. A learner may need competency A before they can meaningfully understand competency B. But many of these prerequisite relationships weren’t explicitly represented in the existing system.
I designed the dependency experience so experts could inspect:
- ExistingAlready connected prerequisites.
- MissingPotential gaps in the learning sequence.
- SuggestedAdditional relationships worth considering.
- Needs reviewRelationships that may not belong.
This made prerequisite knowledge inspectable rather than leaving it implicit in spreadsheets or people’s heads. And once dependencies became structured, they could power something much more valuable.
From finding competencies to sequencing learning.
A curriculum expert could start with a learning intent — Framework · Learning level · Domain. Instead of manually finding and sequencing competencies, the system could use the underlying curriculum model to help construct a learning journey.
- 01Comp. A✓ Resource
- 02Comp. B✓ Resource
- 03Comp. C! Content gap
- 04Comp. D✓ Resource
But the important design decision was what happened underneath.
The AI wasn’t generating from the prompt alone.
The AI could use structured curriculum context to consider what belonged in the journey, what prerequisite knowledge came first and what supporting resources already existed.
AI became a reasoning layer over the curriculum infrastructure — not a replacement for it.
Having a lot of content doesn’t mean the curriculum is covered.
Once content and competencies were connected, the team could answer a question that had previously been difficult to see at a glance: how much of this curriculum can our existing content actually support?
| Numbers | Shapes | Measure | Patterns | |
|---|---|---|---|---|
| Level 01 | ||||
| Level 02 | ||||
| Level 03 | ||||
| Level 04 |
This shifted the conversation from “How much content do we have?” to “Where is the curriculum actually underserved?”
Coverage became more than reporting. It became an input into planning.
A curriculum gap doesn’t automatically mean new content.
Once a gap was identified, the next question was: do we already have something that could address it?
The Resource Map connected competencies with available learning resources and the extent to which those resources addressed them. This created a clearer decision path:
- Identify gap
- Inspect resources
- Evaluate coverage
- Reuse / Adapt / Create
Curriculum planning and content inventory were no longer separate activities.
Closing the loop.
By this point, the system could understand:
- 01What the curriculum expects
- 02How frameworks relate
- 03What learners need beforehand
- 04What has already been covered
- 05What resources already exist
- 06Where gaps remain
The final step was connecting those signals with content planning.
back to curriculum
Instead of planning content independently from curriculum needs, teams could use the same infrastructure to understand what had been covered, what was in progress and what still required attention.
The system moved from documenting work to informing what should happen next.
Then I made the entire system conversational.
By now, the product could answer increasingly sophisticated questions. But users still shouldn’t have to remember which tool contained each answer. That’s where the Companion came in.
- Crosswalk
- Dependencies
- Coverage
- Resource Map
- Journeys
A user could ask:
- “Which competencies in this domain still need content?”
- “What prerequisites are missing here?”
- “Help me build a learning journey for this domain.”
The Companion could use the same curriculum infrastructure underneath those workflows to retrieve context and help the user move toward an action.
The AI wasn’t the intelligence.The system underneath it was.
What looked like several features was actually one connected system.
- A gap discovered in Crosswalk could surface in Coverage.
- Coverage could lead to Resource Map.
- Resource Map could reveal that suitable content didn’t exist.
- Dependencies could show what learners needed first.
- Those signals could inform a Learning Journey.
- And ultimately, the same information could inform what content needed to be created next.
Each workflow made the others more useful.
From storing curriculum information to understanding its relationships.
The project wasn’t ultimately about replacing spreadsheets with screens. It was about transforming disconnected curriculum information into a system where relationships could be seen, questioned and acted on.
I designed the infrastructure connecting curriculum, content and planning — and the experiences that made that infrastructure useful.
- My role
- Product Designer
- Timeline
- 2025
- Client
- Confidential / NDA
- Disciplines
- Systems Thinking · Information Architecture · Product Design · Data Visualization · AI Experience Design
MyGooru Companion
An AI companion that understands where you are, where you're going, and what might help you get there.