intro
This is the course-building workspace for teaching and operations teams in a new AI education product—a backend that breaks textbooks into the smallest units and recombines them into structured learning content.
Over four months, I led the planning, design, launch, and iteration of the product, taking it from a working demo to a fully integrated 0–1 release.
It reshaped part of the content production workflow by making AI easier to integrate into complex projects while keeping the process clear and manageable. It also established a scalable content foundation for future product growth.
Services
UI/UX Design, Data Visualization, Research, Coding
Year
2025

CONCEPT
For an AI education product, the goal is not simply to build a digital textbook. What learners need is a system that can genuinely improve learning outcomes—one that adapts to each student’s current level, rather than moving everyone through the same pages at the same pace.
But this requires a fundamental shift: if AI is to dynamically adjust learning paths, content cannot remain locked inside full chapters. It must be broken into smaller “knowledge nodes” and mapped to each learner’s knowledge graph. Only then can the system understand how concepts relate, skip what a student already knows, and replan around what they have yet to master.
This leads to a conclusion that sounds obvious, yet is slightly counterintuitive: in AI products, personalized learning is closely tied to the front-end experience—but more fundamentally, it can only happen when the backend can produce atomic, structured, and recomposable content at scale.
So the hardest problem was never the student-facing app. It was the tool used by teachers. That tool had become the project’s Achilles’ heel—and the reason I chose to design and build the backend system.
PROBLEM

In the old version, courses could only be generated through a fixed workflow. Teachers could upload content, manage versions, and correct details, but they could not change the course structure or generation logic. This made it difficult to support different regional curricula or enable personalized learning based on each student’s knowledge graph. In essence, it was little more than asking AI to write another textbook.
So instead of building another “upload-and-generate” tool, I reframed the new backend as a content production and orchestration system. Teachers can create textbooks, organize structures, assemble courses, edit pages, and configure components and events for different learning contexts.
STRUCTURE

Decouple content so courses can be recomposed.
The system is structured around Books → Catalogs → Courses → Pages → Learning Events. Books map to regional curricula, catalogs define the learning sequence, courses and pages deliver instruction, while learning events provide targeted practice and feedback based on each student’s progress.
Because these layers are decoupled, teachers can build a local curriculum structure first, then fill it with reusable courses. The same knowledge point does not need to be produced repeatedly—it can simply be recombined for different regions, languages, and difficulty levels.
DESIGN principle

Complex capabilities need to stay within the user’s cognitive limits. Workflows, variable references, and input/output logic are intuitive to engineers, but unfamiliar to teachers. Research showed that even a simple node-based prompt workflow was already near the limit most teachers and operators could comfortably understand. Abstracting it further into Skills or configuration files would reduce both clarity and editability.
Content atomization creates a similar tension. Learning depends on context, and over-fragmentation can break continuity. I worked closely with teachers to define the minimum information each page should contain, balancing flexibility, engineering efficiency, and learning flow. The goal of design is not to remove complexity, but to keep it where users can still control it.

From single-page editing to generating an entire textbook through node-based workflows.
Teachers can define prompts, inputs, and outputs within the workflow. When adding text, image, audio, or question components to a course page, they can bind each content field to a workflow output and save the page as a reusable template.
Once the structure is set, teachers only need to provide batch inputs through Excel to run all page workflows at once, generating the first draft of a lesson—or even a full textbook. AI handles production at scale, while teachers retain control over structure, review, and final publishing.
DESIGN SYSTEM

To keep AI-generated pages consistent, I packaged design principles, tokens, component rules, and examples into a single reference page that both designers and Codex could use to understand and build the system.
All components are displayed together, linked, and kept visible and adjustable. This makes the design system explicit while also defining clear execution boundaries for AI.
In practice, I define goals, shape the structure, and refine key experiences; AI turns those inputs into PRDs, then generates interfaces and code based on the design system.
The designer’s role shifts from drawing every screen to defining rules, controlling quality, and focusing on decisions that truly require design judgment.
Repetition & Consistency

Repetition makes the system learnable. Backend pages follow the same core structure: left navigation, a top toolbar, and a main canvas for different tasks. The canvas may contain a table, content tree, node editor, or course page, but navigation, action placement, and feedback patterns stay consistent.
This repetition is not simple duplication. It reduces the learning cost of moving between modules, while also giving Codex stable components and page patterns to reuse. In AI-native products, repetition is also a way to control generated outcomes and system complexity.
Feedback & Iteration

The earlier it runs, the earlier real problems surface.
Codex brought the product into a working state very early. Design was no longer limited to static screens—it could be clicked, tested, and connected directly to backend services. Many issues around hierarchy, batch actions, and edge cases only emerged with real data and complete workflows.
In this project, backend iterations typically took 2–3 days. Feedback often arrived the same day a version went live, and updates followed the next day.
As a result, prototyping, implementation, and validation became one continuous loop: define rules, generate interfaces, connect data, uncover problems, and feed those learnings back into the system.
成果




