Building a design-to-code process that freed an estimated $10,000 of engineering time

All eight redesigned activities in a grid, on desktop and phone

Year

2026

Timeline

Jul to Aug

Industry

Edtech

Company

Everyday Speech

Team

1 Product Designer, 1 Engineer, Content Team

Tools

Claude Code

Figma

Summary

Everyday Speech gives teachers and speech-language pathologists ready-to-use lessons and interactive activities. With no product manager, I led an experiment to test whether AI could speed up how we make those activities. I set the rules, rebuilt 8 activities in Claude Code, and turned the results into a process we can scale.

Impact

Everyday Speech now has a proven process to scale content production

Build time

1 week

8 activities designed and built, versus an estimated 3 months before.

Engineering cost

~$10,000

Estimated engineering time freed up for other work.

Scalable process

Ready to scale

A tested way to make more activities and games, faster.

The Problem

Producing a new activity took too long to keep teachers supplied

The content team produced illustrations, the product designer wrote specs, and then engineers built each activity from scratch. Refreshing 8 activities this way was budgeted at about 3 months.

Old process flow: content specs, design specs, engineering build — budgeted at 3 months

Context

Teachers who use more of our content stay subscribed longer

In a May 2026 survey of 195 elementary educators, 80% said our content powered most or all of their sessions. Teachers who used our content most, and rated it highly, also stayed subscribed longer. The content team wanted more activities, faster, without lowering the bar, so they asked me to lead an AI experiment.

Design Principles

The rules I set before writing any code

Use AI where it helps most

I pointed AI at the slow, detailed work: motion, making sure accessibility standards are met, and testing every possible edge case.

Design using real content

Live lesson content showed exactly where layouts broke, so testing reflected what teachers would see.

Build accessibility in from day 1

None of the 8 activities were accessible or worked well on phones, so this became a priority.

Solution

I mapped which parts of the code I could change before building

I used Claude Code to study how the Matching activity loads content and reports answers. Layout, motion and interactions were open to change, while the data and answer logic stayed locked. I wrote these limits into a rules file that Claude Code followed on every change.

Scope: what I can change vs what stays locked, with rules file excerpt

A pilot activity proved my prototypes were ready for engineers

I rebuilt Matching first with real lesson content, which exposed long text and odd image sizes early. AI helped me test rare situations and add motion, keyboard support, read-aloud and phone layouts from the start. Engineering approved the code, so I used the same approach for the other 7 activities.

Stakeholders played the real activities and became my testers

An engineer and I built a live sandbox with all 8 activities for the team to review, replacing our old ways of sharing static Figma screens and video walkthroughs. Stakeholders played them on their devices and sent screen recordings as feedback in Asana.

Live sandbox on desktop and mobile with Asana feedback

Key Decisions

I logged every discovery to prove production could scale

I documented every step and finding that week. I turned the notes into a retrospective that showed leadership we could make activities and games at scale. The same notes became a guide and video tutorial for the content team.

Retrospective document and content team video tutorial

Building layouts before final art saved time but caused rework

The 1 week covered layouts and code for all 8 activities, with final art added afterward. The art took about a week per activity, and fitting it in took me a day each. Next time, I'd lock the art first and use AI to make simpler pieces like patterns.

Activity before and after final art — layouts first, art later

Retrospective

The experiment changed how design hands work to engineering

We set out to test whether AI could speed up production. It did, and it showed a designer can hand engineers code they can build on.

Designers can hand off working code

This was the first time a product designer at Everyday Speech handed engineers working code. As this process matures, I'm excited to take on bigger projects and keep learning from our engineers.

Live prototypes get better feedback

Playing the real activities turned stakeholders into testers. Their feedback became specific and easy to act on. Sharing live prototypes became a valuable change to our process.