When Design and Engineering Skip the Handoff
The clean, linear handoff—design finishes, engineering builds—is more myth than reality for product teams working on genuinely new territory. Duolingo’s Math team is a case in point. Operating like a startup within the larger company, the group is responsible for defining what math education looks like in the app. With no existing blueprint for the lessons and games they are creating, the team relies on a fluid, prototype-driven process that keeps designers and engineers working together from the first sketch to the final ship.
Product Designer Colleen MacDonald and Software Engineer Sammi Siegel explain how the team builds through co-creation and constant iteration rather than discrete handoffs.
From Shared Brainstorming to Shared Ownership
Because the Math team is building interaction-heavy modules and games from scratch, there is no template to fall back on. This changes the pace and scope of the work. Instead of a designer working in isolation before passing work along, team members—designers, engineers, and product managers—start new projects by brainstorming together in a shared FigJam file. Only after agreeing on a direction does a designer begin mocking up the product in Figma and mapping out details like motion.
Engineers remain active during this phase. They review complex interactions and animations in Figma before implementation, calling out potential difficulties in comments. To reduce friction, the team connects Jira directly to Figma, which limits context switching and keeps momentum going while moving from design to code.
Learning Through Rapid Prototypes
Once a design mockup is aligned, engineers build an initial prototype using components from Duolingo’s design system. The designer-engineer pair then brings that prototype to a broader team meeting for testing and feedback. Slack channels keep the loop tight: designers share Figma files, engineers share working prototypes, and both sides trade questions and suggestions.
This cycle—prototype, test, tweak—repeats for each feature until the team reaches a final version. The process is intentionally back-and-forth. “It’s not a clear-cut ‘design handed this off, engineering go forth,’” Siegel says. “It’s a lot more collaborative.”
That collaborative spirit is anchored in Duolingo’s “show don’t tell” principle: building an idea is more effective than merely debating it. For a product still finding its identity, prototypes make abstract decisions concrete. The goal is not to perfect a design before building, but to move fast and make key decisions based on how an experience actually feels.
Shipping Faster by Cutting Scope, Not Quality
When the team was chasing product-market fit for educational games, this pace was critical. Rather than building two fully featured games, they opted for a first wave of simpler designs without extra mechanics. This let them see what resonated with users quickly. After testing seven prototypes, the tight design-engineering loop helped them narrow to the four strongest ideas to ship.
Stripping a feature down often means simplifying details like animation, but never at the expense of polish or fun. “We’ll cut corners on the scope of a feature, but never the polish or the fun,” MacDonald says. Extra time is built into the review process from the start to ensure that baseline level of quality, which the team looks for when dogfooding new features.
Defining "Done" and Building Trust
Moving at this velocity requires a shared definition of when a product is ready. Duolingo’s philosophy of “v1 vs. MVP” frames a first release as a foundation to be refined, not a final form. The team knows there are future iterations that are simply out of scope for launch.
Alongside a baseline of polish, every new feature must fit cohesively within the Duolingo suite. Since the Math course exists alongside language courses, design system components and shared engineering code keep the experience consistent with the rest of the app. Part of that cohesion also comes from what Duolingo calls the “trust battery”: trust earned through contributions, which reinforces collaboration over time. Through transparency and shared ownership, the team has built the mutual reliability that lets them make decisions together and ship with confidence.
