ID · Instructional Designer
S.P.A.R.K. Content Presenter
Raw content to learning experience. Hours, not days.
No rebuilding. No review cycles. Just scale.
The system reads learning content as prose, decides how each moment should be presented, and outputs a production-ready activity — no manual authoring required.
Logos are properties of their respective companies.
TL;DR
I architected a scalable content processing system: a custom component grammar and an assembly pipeline that converts raw learning prose into production-ready activities.
Raw learning proseCustom component grammarAssembly pipeline
Center systemS.P.A.R.K. Content Presenter
Converts raw learning prose into production-ready activities.
Production-ready activitiesOutput consistencyUpdates in minutes
A custom component grammar and an assembly pipeline turned raw learning prose into production-ready activities.
The shift was immediate: one file in three days becomes 100 files in two hours, output consistency was built into the system, and updates that once required full rebuilds now took minutes.
0 files in ~2 hours
Batch conversion?Previously, one activity could take around 3 full days to convert, review, revise, export, and upload through the manual workflow.The metric refers to batch conversion speed for a representative production run.
Batch conversion moved from activity-by-activity authoring to scaled production.
45%+ automated accuracy
Translation reliability?Reliability came from codifying SME intent, design judgment, component rules, schema expectations, and quality checks into the workflow.The remaining edge cases were handled through validator and corrector stages.
Translation reliability was supported by validation and correction checks.
MIN to update
Update cycle?Maintenance shifted from regenerate-and-reupload to update-source-and-render.The final activity became a render of structured content instead of a static third-party package.
Content changes could move from source correction to rendered activity without rebuilding a full package.
Problem
AI made content creation fast. Converting that content into a presentable, review-ready activity still took days — and it still depended entirely on a third-party tool that wasn’t built for this.
I opened every file, read and understood the complete lesson, and interpreted it to build manually in Articulate Rise. One file. Three days.
SM · Course Architect
Intent lived in separate rooms
RV · Course Architect
Review became production
OP · Operations
Every update was a rebuild
PE · Product & Engineering
Tracking was locked out
The bottleneck wasn't content. It was that every presentation decision was made by hand. That needed to become a system.
My approach
How I approached the problem
Once the problem was clear, I asked:
if every presentation decision is already being made by hand,
what would it take to make those decisions automatic?
We mapped the manual workflow step by step. For each step, we wrote three things: the intent behind it, the success criteria, and the thinking that drove it. Then we turned those three into system intelligence.
01
The SME lens
What should the learner understand here?This machine had to preserve instructional intent — what matters, what comes first, what needs emphasis. The content already carried this intelligence. The system needed to read it.
02
The designer's eye
How should this moment be presented?This machine had to decide: is this an explanation, an example, a takeaway, a practice problem? The same call a designer makes manually — made automatically.
03
The engineer's spine
How does this become stable product input?This machine had to turn presentation decisions into structured, valid, renderable data — something the backend could store and the frontend could reliably render.
We didn't need another design tool. We needed an assembly line with the intelligence of an SME, the judgment of a designer, and the thinking of an engineer.
With the assembly-line lens on,
01
We built a modular system, not a single monolith.
The choice
We built a modular system, not a single monolith.
Situation
Every lesson had to move from raw prose to a structured output format the rendering engine could read — reliably, at scale, without manual oversight at every step.
Reasoning
A single monolith is simpler: one input, one output, fewer parts to build. But when it fails, you can't tell where.
A modular system has more stages. Each depends on the previous — more to build, more to test. But each stage does exactly one thing. When it fails, you know which stage to fix. And when the system needs to grow, you add a stage without touching the ones that already work.
Result
We started with three stages: extract, store, render. Stages two and three worked. Stage one didn't — so we debugged it in isolation, split it into two, and added a Validator and Corrector around it. Three stages became six. None of the working stages changed.
That's the proof.
02
A fixed component vocabulary, not open-ended interpretation.
The choice
A fixed component vocabulary, not open-ended interpretation.
Situation
The system needed to decide how to present every moment in a lesson — whether a piece of content was an explanation, an example, a practice problem, a takeaway. Until now, a designer made that call manually for every lesson.
Reasoning
If the system could invent any presentation approach, output would be unpredictable and impossible to test comprehensively. A fixed vocabulary means the system works within a defined set. Every lesson speaks the same visual language. Testing becomes finite.
We closed the vocabulary.
Result
The first version had 25 components — too many. Reviewing the output as learners, the switching felt overwhelming. We simplified the library. Because the vocabulary was fixed, removing a component was plug-and-play.
The fixed vocabulary became a lever: update one component, and every lesson that uses it updates with it. Automatically.
03
JSON as the contract between the pipeline and the backend — not HTML.
The choice
JSON as the contract between the pipeline and the backend — not HTML.
Situation
The pipeline needed to hand its output to the backend for storage, and the backend to the renderer for display. HTML was the path of least resistance — it would have worked.
Reasoning
HTML is a single chunk — no named parts, nothing addressable, nothing trackable. Store it, display it, and that's all you get.
JSON names everything. Every component, every field — addressable and trackable. And when both the pipeline and backend share the same expected format, the handoff becomes a contract.
We chose JSON.
Result
The backend stored structured data, not an HTML export. Every component was named, every learner interaction trackable — and the pipeline and backend held the same contract at every conversion.
HTML would have stored the lesson. JSON stored every moment inside it.
04
Structured fields where the component decides the sequence. Free-flow HTML where the learning content does.
The choice
Structured fields where the component decides the sequence. Free-flow HTML where the learning content does.
Situation
For most components, the component's own structure defined the layout — a heading, a body, a visual. But some learning blocks contained mixed content where the author's sequence was the layout: text, then image, then more text — not because of component design, but because that was the order the learning demanded.
Reasoning
Structured fields organise content by type — the component decides what goes where. When the learning sequence is more specific than the component's structure, typed fields break it. Images land in the image field, text in the text field — regardless of the order the author intended.
Free-flow HTML lets content define its own order. The trade-off: it can't be addressed field by field. For components where the author's sequence is the layout, that's the right trade.
The schema became a hybrid.
Result
Learning blocks that mixed text and images now rendered in the order the content was written, not the order the data model preferred.
The schema served the learning sequence, not data convenience.
Build Process
The build process produced
a system, not just a screen.
The work was less about designing a single learning activity and more about building a reliable production path. Each stage produced an output that made the next stage possible.
Map the manual workflow
Every step of the existing process documented — who did it, why, and what a good outcome looked like. That map defined exactly what the system had to replicate.
Before
Every step is manual
3 days · 1 file
Deploy
Tracking added, activity linked by operations
Correct
Fixes implemented back in Rise
Validate
Learning intent reviewed by SME
Extract
Content built manually in Articulate RiseWrite
Prose content authored by SMEThe S.P.A.R.K. assembly line
All the manual effort automated
2 hours · 100 files
Renderer
JSON stored, rendered natively
Corrector
Resolves errors in the JSON
Validator
Checks output. Flags errors.
Extractor
Reads prose, maps to learning blocks
Write
Prose content authored by SMENot just built.
Iterated, tested, and hardened at scale.
5 filesused for Proof of concept
20 filesused for Component lexicon
100+ filesFinal testing
4 completeiterations done for the renderer
Shipped Output
S.P.A.R.K.'s backend and translation logic stay invisible to the learner. What students experience is the final rendered activity: a cleaner learning flow that feels like part of the same e-GMAT ecosystem, not a third-party activity stitched onto the side.
Shipped Output
Try the live learning experience
Click through a few S.P.A.R.K.-rendered learning activities to see how structured learning content becomes a cohesive product experience.
The converter is internal; this is the rendered student-facing output.
Outcome
Scalability at pace without manual cost.
The shift was immediate: one file in three days becomes 100 files in two hours, output consistency was built into the system, and updates that once required full rebuilds now took minutes.
100 files in ~2 hours
Batch conversion?Previously, one activity could take around 3 full days to convert, review, revise, export, and upload through the manual workflow.The metric refers to batch conversion speed for a representative production run.
Batch conversion moved from activity-by-activity authoring to scaled production.
95%+ automated accuracy
Translation reliability?Reliability came from codifying SME intent, design judgment, component rules, schema expectations, and quality checks into the workflow.The remaining edge cases were handled through validator and corrector stages.
Translation reliability was supported by validation and correction checks.
MIN to update
Update cycle?Maintenance shifted from regenerate-and-reupload to update-source-and-render.The final activity became a render of structured content instead of a static third-party package.
Content changes could move from source correction to rendered activity without rebuilding a full package.
That is how I built this one.
