듀오링고 메소드: (새 탭에서 열림)

Duolingo Math 팀은 디자인과 엔지니어링을 분리해 순차적으로 넘기는 전통적인 핸드오프 대신, 처음부터 함께 아이디어를 만들고 프로토타입을 반복 검증하는 방식을 택한다. 디자이너·엔지니어·PM이 실시간으로 협업하며 실제 작동하는 경험을 바탕으로 결정하기 때문에, 새로운 제품에서도 빠르게 방향을 찾고 완성도를 높일 수 있다. 핵심은 완벽한 설계를 먼저 확정하는 것이 아니라, 만들고 보여주고 수정하는 과정을 팀 전체의 공동 작업으로 만드는 데 있다.

선형적인 핸드오프의 한계

• 디자인에서 엔지니어링으로 작업을 한 번에 넘기는 방식은 제품 개발이 실제로 진행되는 방식과 맞지 않는다.
• 특히 Duolingo Math처럼 새로운 학습 모듈과 게임을 처음부터 만들어야 하는 팀은 기존 템플릿이나 검증된 청사진을 활용하기 어렵다.
• 상호작용과 애니메이션이 많은 기능은 문서나 정적인 화면만으로 구현 난이도와 사용자 경험을 정확히 판단하기 어렵다.
• 따라서 디자인과 엔지니어링이 초기 단계부터 지속적으로 연결되어야 한다.

초기 단계부터 함께 아이디어 구상

• 디자이너가 혼자 작업을 시작하지 않고, 디자이너·엔지니어·제품 관리자가 공유된 FigJam 파일에서 함께 아이디어를 낸다.
• 방향이 정해지면 디자이너가 Figma에서 화면과 동작, 모션을 구체화한다.
• 엔지니어도 이 단계에 적극 참여해 복잡한 상호작용과 애니메이션을 미리 검토한다.
• 구현하기 어려운 부분은 Figma 댓글 등으로 조기에 지적해 불필요한 설계 수정을 줄인다.
• Jira를 Figma와 직접 연결해 도구 간 맥락 전환을 줄이고, 디자인과 개발 작업의 흐름을 유지한다.

빠른 프로토타이핑과 반복 실험

• 디자인 시안에 합의한 뒤 엔지니어가 Duolingo 디자인 시스템의 컴포넌트를 활용해 초기 프로토타입을 빠르게 만든다.
• 디자이너와 엔지니어가 작동하는 프로토타입을 만든 후 팀 회의에서 직접 테스트하고 피드백을 받는다.
• Slack 채널에서 디자이너는 Figma 파일을, 엔지니어는 구현된 프로토타입을 공유하며 질문과 의견을 주고받는다.
• 각 기능마다 다음 순환을 반복한다.
  • 프로토타입 제작
  • 팀 테스트
  • 피드백 수집
  • 수정 및 재검증
• Duolingo의 “말로 설명하기보다 직접 보여준다(show don’t tell)”는 원칙에 따라, 아이디어의 타당성을 논의만 하지 않고 실제 경험으로 확인한다.
• 프로토타입은 설계를 미리 완성하기 위한 결과물이 아니라, 제품이 실제로 어떻게 느껴지는지 확인하고 핵심 결정을 내리기 위한 도구다.

함께 다듬고 출시하기

• 지속적인 협업을 통해 개발 중에도 빠르게 의사결정을 내리고 기능을 다듬을 수 있다.
• 속도가 중요할 때는 애니메이션을 단순화하는 등 기능을 핵심 경험 위주로 축소한다.
• 교육용 게임의 시장 적합성을 확인할 때도 처음부터 완성도 높은 게임 두 개를 만드는 대신, 단순한 디자인과 최소한의 메커니즘을 가진 게임부터 빠르게 제작했다.
• 어떤 기능을 우선할지 미리 정한 뒤, 일곱 가지 프로토타입을 반복적으로 제작하며 사용자에게 어떤 경험이 반응을 얻는지 확인했다.
• 이 방식은 대규모 기능을 장기간 개발한 뒤 실패하는 위험을 낮추고, 초기 학습을 제품 방향에 빠르게 반영하게 한다.

실무에 적용할 때의 시사점

• 디자인 완료 후 개발을 시작하기보다, 초기 기획부터 디자이너와 엔지니어를 함께 참여시킨다.
• 정적 시안보다 작동하는 작은 프로토타입을 우선 제작한다.
• 기능별로 짧은 제작·테스트·수정 주기를 운영한다.
• 속도와 학습이 중요한 초기 단계에서는 부가 기능보다 핵심 사용자 경험에 집중한다.
• 협업 도구를 연결하고 공유 채널을 마련해 작업 맥락과 피드백을 실시간으로 유지한다.