The Duolingo method: Collaboration as a core practice
Duolingo’s Math team ditches traditional handoff in favor of co-creation, scrappy prototypes, and constant experimentation.
Share The Duolingo method: Collaboration as a core practice
Illustrations by Jon Han
The myth of handoff is that it’s a clean baton pass from design to engineering, but in practice, product development is rarely so linear. This is especially true in fast-moving, exploratory environments like the Duolingo Math team, which operates like a startup within the larger company. Tasked with defining what math learning looks like inside one of the world’s most recognizable education apps, the team takes an iterative and collaborative approach to handoff, ensuring that design and engineering stay tightly connected and are able to riff in real time—from first sketch to final build.
In the fourth installment of our series on foundational team principles, we sit down with Product Designer Colleen MacDonald and Software Engineer Sammi Siegel on Duolingo’s Math team to learn how they build through a fluid, prototype-driven process defined by co-creation, constant communication, and ongoing experimentation.
Ideating together
The Duolingo Math team is building brand new learning modules and games from the ground up, so there’s no blueprint to follow. These lessons and games, designed to improve fluency, speed, and recall of math skills, are interaction-heavy and often take a lot of tweaking and iterating to get right. “Where other teams can use a template for similar features, we haven't gotten quite into that groove yet,” Sammi says. “We're still building a lot of really new things, and so that makes the process a little different, a little larger.”
Rather than designers starting the product development process in a silo, members of the Math team—including designers, engineers, and product managers—kick off projects by ideating together in a shared FigJam file. Once they collectively land on a clear direction, designers start mocking up the product in Figma, mapping out how they envision certain aspects like motion coming to life.
Duolingo engineers connect Jira directly to Figma, allowing them to reduce context switching and maintain momentum as they implement designs in code.
Duolingo’s engineers are active participants in this part of the process; they are empowered to assess complex interactions and motion in Figma before building them, and flag what might be difficult to implement in the comments.
Experimenting through rapid prototyping
Once there’s alignment on the design mockup, engineers will get to work on spinning up an initial prototype, leaning on components from Duolingo's design system. When the designer-engineer duo has a working prototype, they'll bring it to a team meeting to test it and get input from the broader group. In a group Slack channel, designers share Figma files, engineers share prototypes, and both teams exchange feedback and questions.
The team repeats this process for each individual product feature until reaching a final version. This quick loop—prototype, test, tweak—is at the heart of how the team builds. “There’s quite a bit of back and forth,” Sammi says. “It’s not a clear-cut ‘design handed this off, engineering go forth.’ It’s a lot more collaborative.”
It’s not a clear-cut ‘design handed this off, engineering go forth.’ It’s a lot more collaborative.
The team anchors on Duolingo’s principle, “show don’t tell”—the idea that talking about ideas is rarely as effective as building them.
This prototype-first approach helps bring clarity to an entirely new product. They use these prototypes to test assumptions and make decisions based on how a product feels when in their hands—what the Duolingo Handbook calls “show don’t tell.” The goal isn’t to perfect the design before building, it’s to move quickly and figure things out together. “There’s a lot of rapid iteration,” Colleen says. “A lot of times you have to really see or feel the experience to make key decisions on it.”
Polishing and shipping together
This ongoing collaboration allows the team to make fast decisions and polish as they go. It also sometimes means stripping a feature down to its essentials, like simplifying an animation, in favor of speedy creation.
That speed was especially important when the team was first tasked with finding product market fit for educational games. Instead of building out two robust games, they decided that starting with a first batch of simpler games—with minimalist designs and without any extra mechanics—would be a better way to see what resonated with users. They spun these up quickly and decided up front which features to prioritize. After iterating on seven different prototypes, they relied on their tight feedback loop between design and engineering to zero in on what worked and confidently choose the four strongest ideas to ship. Despite the stripped-down nature of the games, they were still able to ensure they met their bar for quality, fun, and intuitiveness. “We’ll cut corners on the scope of a feature, but never the polish or the fun or any of those elements,” Colleen says.
Adopting a shared language and beliefs
Designing and launching products at this velocity means the team has to be on the same page about when it’s time to ship a product. At Duolingo, product builders follow a philosophy of “v1 vs. MVP”—the idea that a feature’s first release isn’t its final form, but a starting point to be refined through ongoing iteration. Rather than aiming for perfection out of the gate, they focus on shipping a solid foundation and improving it over time. “We often know that there are iterations we want to do later but are just out of scope in the moment,” Sammi says.
There are a few pieces of criteria the Duolingo Math team has aligned on meeting before going live with their “v1.” For one, they aim to achieve a baseline level of polish on a feature. To do this, they make sure to build extra time into the review process from day one. “Out of everything we ship, that bar for polish is expected. So that’s what we look for when we dogfood a new feature,” says Colleen.
Aligning incentives across design and engineer teams, and agreeing on a shared idea of “done,” can be a tricky endeavor. Our design leader’s guide to handoff breaks down how to do it well.
They also ensure each product fits seamlessly within the Duolingo suite. This means designers and engineers build each feature with design system components to ensure it feels cohesive with the broader experience. “Our course exists alongside all of the language courses that everyone knows. So it’s important that we share the design language of the app and share engineering components,” Colleen says.
Our course exists alongside all of the language courses that everyone knows, so it’s important that we share the design language of the app.
Finally, they implement the idea of what Duolingo calls “the trust battery”—the notion that trust is earned through meaningful contributions. Those contributions add to a reserve of trust that strengthens collaboration over time. Through open communication, shared ownership, and transparency, the Duolingo Math team has built a strong foundation of mutual respect and reliability. Ultimately, it’s this trust that allows them to move quickly, make decisions together, and ship with confidence.
Read more about Duolingo's method here. Stay tuned for the next installment in our series about how teams build products and the principles and processes that guide their work.
Emma Webster is a writer and editor on Figma’s Story Studio team. Previously, she’s worked as a writer at Faire and Audley Travel.
