처음부터 슬랙과 함께 | (새 탭에서 열림)

Figma는 협업형 인터페이스 디자인 도구의 핵심 협업 경험을 자체 메시징 기능이 아니라 Slack 위에 구축하기로 했다. 디자이너들이 Slack을 일상적으로 사용하고, Slack 사용자가 디자인 과정을 더 개방적으로 공유하는 경향이 있었기 때문이다. 따라서 Figma 팀을 Slack 팀과 연결하고 파일 알림도 Figma가 아닌 Slack으로 전달하는 전략이 통합과 사용자 경험 측면에서 효과적이었다.

Slack 사용자를 관찰한 배경

• Figma는 제품을 개발하며 디자이너들이 파일 저장, 사양 작성, 제품 의사결정 등을 어떻게 협업하는지 조사했다.
• 인터뷰한 디자이너 중 절반 이상이 Slack을 하루 종일 사용한다고 답했다.
• Slack 사용 여부는 다른 협업 방식과도 연관되어 있었다.
  • Slack을 사용하는 디자이너일수록 디자인 과정을 팀에 더 개방적이고 투명하게 공유하는 경향이 있었다.
• 이를 통해 Slack이 단순한 채팅 도구가 아니라 디자인 협업의 중심 채널이 될 수 있다고 판단했다.

중복 기능을 만들지 않은 이유

• Figma는 디자인에 대한 커뮤니케이션을 지원하는 제품이므로, 자체적으로 메시지·알림 기능을 구현하고 싶은 유혹이 있었다.
• 하지만 Slack과 비슷한 기능을 다시 만들면 다음과 같은 문제가 생긴다.
  • 사용자가 메시지를 확인할 장소를 하나 더 관리해야 한다.
  • 팀을 Figma와 Slack 양쪽에서 별도로 설정해야 한다.
  • 이미 익숙한 협업 흐름이 여러 서비스로 분산된다.
• Figma는 사용자가 또 다른 메시지함을 확인하도록 만들기보다, 기존에 사용 중인 Slack을 협업 기반으로 활용하기로 했다.

Figma와 Slack의 긴밀한 통합

• Figma의 협업 모델에서 “Figma 팀”은 “Slack 팀”과 연결된다.
• Figma 파일에서 발생하는 알림은 Figma 내부가 아니라 Slack을 통해 전달된다.
• 사용자는 Slack에서 디자인 관련 소식을 확인하고 팀원과 논의할 수 있다.
• 이는 Slack을 단순한 외부 연동 대상이 아니라 Figma 협업 경험의 기반 플랫폼으로 활용한 결정이다.

플랫폼 전략과 사업적 판단

• Figma는 Slack 플랫폼이 공식적으로 출시되기 전부터 Slack을 플랫폼으로 바라보고 통합을 준비했다.
• Slack 중심의 협업 구조는 당시로서는 큰 전략적 선택이었지만, 초기 성과를 통해 그 판단이 효과를 내고 있다고 평가했다.
• 글은 앞으로 다른 기업들도 자체 기능을 무작정 복제하기보다, 사용자가 이미 익숙한 플랫폼 위에 제품 경험을 구축할 가능성이 커질 것이라고 전망한다.

실용적으로는 새로운 협업 기능을 개발할 때 자체 메시징·알림 시스템을 추가하기 전에, 사용자가 이미 매일 사용하는 도구와 자연스럽게 연결하는 방식을 우선 검토할 필요가 있다.