Teaching developers a new language

Google • 2019

Created Flutter's first interactive coding tutorials by applying learning science research, repurposing survey software for rapid prototyping, and testing with 15 developers. Result: reduced bounce rates and published frameworks adopted by Google's developer relations team.

Problem

Flutter is Google's cross-platform UI framework. But it requires Dart, a programming language new to many developers.

Learning Dart was the #3 reason developers didn't adopt Flutter. Mature languages like JavaScript or C# had rich interactive resources; Dart only had static docs.

Bar chart showing top responses to 'What made you lean against adopting Flutter?' Learning a new language (Dart) ranked third among the listed concerns. — Top barriers to Flutter adoption — Learning Dart ranked #3

We needed to remove the barrier. Not just write more documentation, but design for how people actually learn.

My role: Learning science research → prototyping → user testing → post-launch measurement. Solo researcher working with PMs, engineers, and technical writers across three offices. 2-3 weeks per cycle, from research to launch.

Research

I reviewed learning science literature. I analyzed 18 coding tutorials—from Codecademy, Kubernetes to freeCodeCamp. Two common approaches:

Two tutorial screenshots side by side. Passive static tutorials: 'How to do it myself?'. Pure freeform discovery: 'Why this isn't working?'

Passive tutorials: Watch, read, memorize. You think you learned, but can't apply.
Discovery learning: Blank canvas sounds empowering. Leads to frustration.

The middle ground is guided discovery learning. Give learners a clear problem, just enough structure, room to struggle productively.

I distilled this into three principles:

Scaffold, don't overwhelm
Facilitate reflection between steps
Teach transfer, not memorization

Each principle required design decisions: When to show hints? How much help? When to pause versus let them continue?

Alignment: 3 hours instead of 5 days

PMs, engineers, and technical writers across three cities. Packed Google I/O schedules. Nobody knew where to start.

Engineers: What should we build first?

Writer: How do we create effective tutorials?

PMs: What works in competitor tutorials?

I compressed a 5-day Design Sprint into three 1-hour sessions over two weeks.

Diagram comparing traditional 5-day Design Sprint to modified 3-session format

Output: Demo → exercise → quiz. Everyone knew what we were building and why.

Prototyping

I needed to test the interaction components before the infrastructure was ready. I repurposed Qualtrics—a survey tool—into an interactive learning environment.

Multi-fidelity approach:

High-fidelity: Embedded a working code editor so it felt real
Mid-fidelity: Built interactions with JavaScript, HTML, CSS
Low-fidelity: Tested variations quickly with slides

High-fidelity prototype showing embedded code editor via iframe alongside Qualtrics-powered real-time feedback display

Interactive prototype demonstrating hover-to-highlight feature where hovering over key points highlights corresponding code sections

Google Slides mockups showing different variations of tutorial guidance: when to provide help, what information to show, and how to present it

User testing: 15 developers, 2 rounds

I tested with Java developers learning Dart for the first time. Spent an hour with each. Measured completion rate, error types, usefulness, usability.

Recruiting challenge

I needed Dart beginners with async experience in other languages—a rare profile. I recruited Java developers and gave them a Dart syntax cheat sheet.

Dart syntax cheat sheet showing common programming constructs

Key insight: Participants wanted the challenge of solving independently, yet hiding solutions hurt discoverability. Half wanted solutions even after passing—to check their approach.

Final design: solution button always visible, but two clicks to reveal. First click encourages using hints. Learners can override if needed.

Two solution reveal designs tested. Two-click reveal won—encourages trying hints before showing code — Two-click reveal balanced challenge with access

Results

Shipped the tutorial with embedded survey and Google Analytics tracking.

Final tutorial interface showing code editor, exercise instructions, and interactive feedback components

Impact

Reduced bounce rate, increased time on page
45+ content changes from user testing
Created Dart and Flutter's first interactive tutorials
Published open-source framework guide—adopted by team and community
Co-authored academic poster on tutorial design
Featured in keynote release
Cited in org all-hands (120+ people)
Delivered 3 lightning talks

Open-source tutorial framework guide showing design principles, implementation patterns, and best practices for creating interactive coding tutorials — Best practices guide for the team and community

Academic poster presenting tutorial design principles, user testing methodology, and learning outcomes from the interactive Dart tutorial research — Academic poster on tutorial design

I've never worked with user research with this level of granularity.

— Product Manager, 10+ years at Apple, Amazon, Microsoft

Reflections

Repurposing Qualtrics wasn't elegant, but it worked. Sometimes the tools you have matter less than moving fast and learning.

The two-click solution: sometimes good UX means keeping the friction, just putting it in the right place.