K12 Story Studio

K12 Story Studio is an AI storytelling product that lets K-4 students create and read stories while building literacy through quizzes and an interactive reader. The technology was ambitious, but the everyday experience got in its own way: kids stalled inside quizzes, parents couldn’t tell whether reading was actually improving, and the reader was a chore to move through. The question wasn’t “add more.” It was “why isn’t the learning loop landing?”

So I made a deliberate bet: fix the core loop (read, quiz, see progress) before anything else, and treat the quiz, dashboard, and reader as one connected system, not three separate screens. Every change had to earn its place against comprehension and engagement, not polish. I worked inside Stride’s Unified Design System on purpose, so the work would ship on existing components and scale across the product instead of forking it.

Story Studio could generate a story, quiz a student on it, and report progress to a parent. On paper the learning loop was complete. In practice every step leaked, and I kept hitting the same three failures, each one quietly costing the product the engagement it was built for.

This was a blended role, and I treated it that way. I owned the product and design decisions on my surfaces and kept a cross-functional team pointed at the same outcome:

Before changing anything, I wanted the brief to be measurable. I audited the existing quiz questions, dashboard, and reader for where they broke down, and benchmarked comparable learning products to see what the category had already taught students and parents to expect. That turned a broad “improve engagement” goal into a short list of problems I could design and measure against.

The most important call here was to treat the quiz as part of learning, not a graded checkpoint. For a seven-year-old, a wrong answer with no path forward is exactly where engagement dies, so I put feedback at the center of the design: an incorrect answer now nudges the student toward understanding instead of just marking them wrong. I sequenced questions into a clearer, guided path and added progress cues so kids always knew how much they had left.

Because the users are five to ten years old, the words carried as much weight as the flow. I rewrote prompts, error messages, and success feedback to be developmentally appropriate and encouraging, and cut instructional tooltips down to what a young reader could actually follow. This is where design and content strategy did the product work: for this age group, the copy is the interface.

Parents didn’t need more data, they needed a verdict: is my kid improving? So I connected quiz results to overall performance and rebuilt the dashboard around that one question, pulling the signal to the top and pushing detail beneath it. Tying those numbers together on the shared design system also meant the same progress model could carry into other parts of the product instead of living as a one-off screen.

The reader has one job, keep a kid inside the story, so every decision aimed at removing friction and widening who could use it. I gave it clear page navigation, added font-size and dark-mode controls so the experience worked for more kids rather than an average one, and strengthened audio so the story could carry students still building fluency. Accessibility here wasn’t a compliance box to tick; it directly expanded the product’s reachable audience.

The payoff was a learning loop that finally held together. Clearer quiz feedback gave students a way to recover from a wrong answer, the reader stayed out of the way of the story, and the dashboard pulled reading, quizzes, and progress into one view a parent could actually read. Because it all shipped on Stride’s Unified Design System, the improvements stayed consistent across the product rather than living in one corner of it.

The clearest opportunity I found wasn’t a fix, it was a whole user we were underserving. Teachers were managing student progress inside a dashboard built for parents, so I led new research into how they actually track reading engagement and run a classroom day to day.

What I heard pointed to a distinct product, not a tweak:

That work defined the case for a dedicated educator experience and set up the next phase of the product.

The lesson I took into product work: for a learning tool, the win is closing the loop, not adding to it. Make the feedback land, make progress legible, and get the interface out of the way, and the product does the one thing it was built to do.