EdKit

EdKit began as a side effect of the Intuitive ML course — a Google-internal machine learning curriculum I was helping design. We kept running into the same problem: static slide decks and long-form documents were the only tools available to content creators, and they were terrible at teaching people things. They couldn't adapt. They couldn't respond. They couldn't tell us what was working.

The question was whether we could build something better — not just for our team, but for every content creator at Google. The answer became EdKit.

The Problem with Static Content

Google produced enormous volumes of internal educational content — onboarding programs, technical courses, policy training, skill development. Most of it was consumed passively. A learner read a document or watched a video. There was no feedback loop. Authors couldn't tell whether their content worked. Learners couldn't signal where they were confused. The system optimized for production, not learning.

Building interactive learning experiences required developer involvement. A PM or program manager who wanted to create a quiz, a branching scenario, or a drag-and-drop exercise had to file a ticket and wait. Most didn't bother.

What We Built

EdKit was a toolkit for building embeddable, interactive learning experiences — with no engineering dependency. Content creators could build quizzes, flip cards, drag-and-drop exercises, branching scenarios, and choose-your-own-path learning flows through a visual interface, then embed the result anywhere Google hosted content.

The core components:

• Activity Creator — a visual builder for interactive learning modules. Drag and configure; no code required. Supported a growing library of activity types that content creators could chain together.
• Learning Path Engine — a sequencing system that let authors chain multiple activities into choose-your-own-adventure style paths. Learners could be routed to different content based on their responses, prior knowledge, or stated preferences.
• Analytics Layer — every interaction was tracked and surfaced back to the author. Which questions stumped people. Where learners dropped off. Which paths were chosen most often. Authors could iterate on content informed by actual behavior, not assumptions.
• Skills Stack Integration — EdKit activities could be tagged to Google's internal skills graph, connecting learning completions to organizational capability tracking.

Zero Mandates

EdKit spread entirely through organic adoption. We never mandated its use. We never sent a company-wide announcement. We built something that solved a real problem better than the existing alternative, made it easy to find and use, and then stayed close to early adopters to improve it quickly.

The result: hundreds of content creators across every major Product Area at Google, thousands of deployed instances, embedded in internal sites across the organization. Product teams used it for feature rollout training. HR used it for onboarding. Legal used it for compliance training. None of them were our intended audience — they found EdKit because it worked.

The most powerful design lever isn't mandate or marketing — it's making the right thing the easy thing. When we did that, adoption followed on its own.

What It Required

Co-founding EdKit meant doing design work that most UX roles don't ask for. Product strategy. Infrastructure decisions. Author support. Community building. I was designing the tool, the system around the tool, and the conditions for the tool's survival simultaneously.

The component architecture decisions we made in 2019 were still holding up in 2023. The analytics model we designed early became the basis for how EngEDU measured learning effectiveness across all of its programs. EdKit was never a feature — it was infrastructure.

The Thread to Act 3

EdKit was the first time I designed a system that was explicitly about embedding expertise into a tool so that the tool could do the expert's job without the expert being present. A content creator building an EdKit learning path wasn't just building content — they were encoding their pedagogical knowledge into a system that would apply it consistently across thousands of learner interactions.

That's the same problem as LemonADE, where AI agents encode engineering documentation expertise and apply it continuously across the SDLC. The same problem as Prompt City, where prompt anatomy frameworks encode prompt engineering expertise and surface it to users who don't have it. The domain is different. The design challenge is identical.