product-analytics

3 개의 포스트

figma

피그마 오픈 베타 출시의 (새 탭에서 열림)

Figma의 Dev Mode 오픈 베타 사례는 출시일을 끝이 아니라 제품 생애의 첫날로 보고, 이후 2주를 집중적인 사용자 조사 기간으로 활용해야 한다고 주장합니다. 제품·마케팅·지원팀이 역할을 나누되 긴밀히 협업하면서 사용 데이터, 여론, 버그 및 개선 요청을 종합해야 합니다. 성공 여부는 사전에 정의한 핵심 지표와 기준선으로 판단하고, 얻은 피드백을 우선순위와 제품 개선으로 연결하는 것이 결론입니다. ## 출시 후 2주는 집중적인 사용자 조사 기간 - Dev Mode는 Figma 안에서 개발자를 위해 설계된 별도 작업 공간입니다. - 브라우저 인스펙터처럼 캔버스 위 요소를 확인하며 치수, 스펙, 에셋 등의 정보를 얻을 수 있습니다. - 오픈 베타 기간에는 2023년 말까지 모든 Figma 사용자가 무료로 이용할 수 있도록 해 대규모 사용 데이터를 확보했습니다. - 출시 후 2주 동안 다음을 확인하는 것이 목표였습니다. - 사용자가 실제로 Dev Mode를 사용하는가 - 어떤 기능이 유용하게 받아들여지는가 - 어떤 버그와 불편이 즉시 해결되어야 하는가 - 제품이 개발자 커뮤니티의 요구를 충족하는가 ## 제품·마케팅·지원팀의 역할 분담 - **제품팀** - 기능별 사용량과 사용자 행동을 추적했습니다. - 어떤 기능이 실제 워크플로에 사용되는지 분석했습니다. - **마케팅팀** - 소셜 미디어와 공개 반응을 통해 제품에 대한 전반적인 여론을 파악했습니다. - **지원팀** - 버그 신고, 개선 요청, 고객 문의를 집중적으로 수집했습니다. - 각 팀은 담당 영역을 나누었지만, 중요한 트윗이나 반복적으로 발생하는 문제를 공유하며 지속적으로 소통했습니다. - 제품 관리자는 여러 출처의 정보를 종합하고, 실행 항목의 우선순위를 정하며, 후속 조치를 조율하는 역할을 맡았습니다. ## 사전에 정의한 성공 지표 - Dev Mode의 **북극성 지표(north star metric)** 는 개발자 역할을 가진 주간 활성 사용자 중 Dev Mode를 사용하는 비율이었습니다. - 출시 전에 측정 기준과 대시보드를 준비해, 출시 전후의 변화를 비교할 수 있도록 했습니다. - 기준선이 없으면 수치가 좋은지 나쁜지 판단하기 어렵기 때문에, 베타 결과를 해석하려면 사전 벤치마크가 중요합니다. ## 기능 채택과 사용자 반응 측정 - **기능 채택** - Inspect 패널 - 변경 사항 비교(Compare changes) - 관련 링크(Related links) - 그 밖의 Dev Mode 기능별 사용률 - 기능별 사용량을 비교해 사용자가 가장 매력적으로 느끼는 기능과 활용도가 낮은 기능을 구분했습니다. - **도달률과 반응** - 소셜 미디어 게시물 노출 수 - 이메일 오픈율 - 제품 내부 메시지 노출 수 - 소셜 미디어의 긍정·부정 분위기 - Config 행사 중 실시간 청중 반응 - 단순히 사용자에게 도달했는지뿐 아니라, 어떤 기능이 관심과 기대를 유발했는지도 함께 살폈습니다. ## 버그와 개선 요청 수집 - 사용자가 겪는 문제를 파악하기 위해 다양한 접점을 활용했습니다. - Help Center 문서 조회 수 - 제품 내 피드백 버튼 제출 내용 - 고객 지원 티켓 - 여러 채널에서 들어오는 요청을 한곳에 모아 반복되는 문제와 우선적으로 해결해야 할 개선 사항을 파악했습니다. - 비공개 베타 기간에 개발자와 디자이너의 워크플로 및 고충을 인터뷰한 결과도 출시 후 분석의 기반으로 활용했습니다. - 이러한 사전 학습을 통해 핵심 기능을 수정하고, 협업 방식에 맞게 기능을 조정하며, 처음에는 예상하지 못했던 요구도 반영할 수 있었습니다. 출시를 성공시키려면 발표 당일의 화제성보다 이후 데이터를 어떻게 측정하고 피드백을 어떻게 실행으로 전환하는지가 중요합니다. 오픈 베타를 진행할 때는 담당 팀과 지표를 미리 정하고, 출시 전 기준선을 확보한 뒤, 사용량·여론·지원 요청을 통합해 빠르게 우선순위를 결정하는 것이 좋습니다.

figma

데이터를 활용하는 방법 | 피그 (새 탭에서 열림)

Figma는 서비스를 제공하는 데 필요한 **기능 데이터**와 제품 개선에 활용하는 **분석 데이터**를 구분해 수집·활용한다. 분석 데이터는 기능 개발, 성능 개선, 커뮤니티 보호를 위한 의사결정을 지원하며, A/B 테스트와 데이터 분석을 통해 사용자 경험을 정량적으로 검증한다. 글은 데이터 활용이 제품을 발전시키는 동시에 고객에게 수집 목적과 책임을 투명하게 설명해야 한다고 강조한다. ## 기능 데이터: 서비스 제공에 필요한 최소 정보 - 이메일 주소는 사용자 이름 부여와 비밀번호 재설정 등 중요한 안내에 사용된다. - 가입 시 이름과 역할을 추가로 수집하며, 이 정도의 기본 정보만으로 파일 생성과 협업을 시작할 수 있다. - 다른 클라우드 서비스와 달리 신원 확인 서류나 문서 등 민감한 정보를 일반적으로 요구하지 않는다. - 유료 플랜의 결제 정보는 Figma가 직접 처리하지 않고 결제 인프라 제공업체인 Stripe가 수집·처리한다. ## 분석 데이터: 제품 개선을 위한 사용 정보 - 사용자가 어떤 기능을 사용하는지, 사용하지 않는지, 이용 과정에서 어려움을 겪는지를 파악한다. - 플랫폼에 접근하는 방식과 같은 메타데이터도 분석 대상에 포함된다. - 사용자 의견이나 소셜미디어 반응만으로는 전체 사용 패턴을 파악하기 어렵기 때문에 정량적 데이터가 필요하다. - 데이터 과학팀이 수집된 정보를 처리·분석해 제품 개발 방향을 세운다. - 주요 활용 목적은 기능 개선, 애플리케이션 성능 최적화, Figma 커뮤니티 보호다. ## A/B 테스트를 통한 기능 개선 - Figma는 UX 리서치, 데이터 분석, 제품 직관에서 세운 가설을 실험으로 검증한다. - 새로운 기능이나 UI 변경이 사용자 행동에 미치는 영향을 정량적으로 비교해 출시 여부를 판단한다. - 공유 모달 개선 사례에서는 가입 후 첫 달에 공유 모달을 여는 사용자가 20%에 불과했고, 그중 실제 파일 공유에 성공하는 비율도 절반이었다. - Figma는 UI를 단순화하고 부차적인 기능을 별도 탭으로 옮겨 공유 과정을 쉽게 만들었다. - 실험 결과: - 초대장을 보내는 사용자 비율이 2% 증가했다. - 파일마다 초대되는 사용자 수가 2% 증가했다. - Figma Community에 작업물을 게시하려는 성향에는 부정적인 변화가 없었다. - 이 결과는 이후 공유 경험을 개선하는 작업의 방향을 설정하는 근거가 됐다. ## 성능 문제와 장애 원인 분석 - Figma의 여러 팀은 플랫폼별 애플리케이션 성능 데이터를 지속적으로 분석한다. - 분석 결과는 성능 개선 과제와 전반적인 사용자 경험 향상에 활용된다. - iOS 앱 베타 출시 후에는 충돌 발생 빈도, 충돌 상황, 영향을 받는 플랫폼을 조사했다. - 분석 결과 프로토타입이 iOS 충돌의 주요 원인 중 하나였으며, 프로토타입 관련 충돌의 25%가 로딩 시작 후 10초 이내에 발생했다. - 이처럼 단순히 충돌 횟수만 보는 것이 아니라, 특정 기능·플랫폼·사용 시점과 연결해 문제의 우선순위를 정한다. Figma의 사례는 필요한 기능 데이터는 최소한으로 수집하고, 분석 데이터는 구체적인 제품 문제를 해결하는 데 사용해야 한다는 점을 보여준다. 데이터 기반 의사결정은 사용자 행동을 더 정확히 이해하게 하지만, 실험 결과를 사용자 경험과 개인정보 보호라는 관점에서 함께 검토하는 것이 중요하다.

figma

Draft 3 (Standard blog style): (새 탭에서 열림)

Figma는 댓글이 팀 협업과 사용자 유지에 중요한 기능이라는 데이터를 확인했지만, 실제 사용률이 낮은 원인을 실험으로 검증했다. 댓글 진입점을 더 쉽게 노출하자 댓글 작성이 45% 증가했지만, 위치를 단순히 왼쪽에서 오른쪽으로 옮긴 실험은 발견 가능성을 20% 낮췄다. 이 과정은 제품 가설을 직관이 아니라 데이터로 검증하고, 작은 실험을 반복해 전면적인 댓글 경험 개편으로 발전시킨 사례다. ## 댓글과 팀 성장의 관계 - 첫 달에 협업한 팀은 그렇지 않은 팀보다: - 유지될 가능성이 1.75배 높았다. - 유료 고객이 될 가능성이 6.5배 높았다. - Figma는 편집자뿐 아니라 보기 전용 사용자도 디자인 과정에 참여해야 팀 전체의 협업이 성장한다고 판단했다. - 댓글은 파일에 대한 피드백을 주고받는 기능이므로, 팀 협업을 시작하게 하는 ‘마법 같은 순간’이 될 수 있다고 가설을 세웠다. - 그러나 댓글이 팀 성장과 참여도의 강한 지표임에도 실제 사용률은 높지 않아, 데이터와 사용자 행동 사이의 차이를 실험으로 조사했다. ## 댓글 발견 가능성 가설 - 기존에는 Figma 편집기 왼쪽 상단의 아이콘을 눌러 댓글 모드에 진입해야 했다. - 사용자 조사에서 댓글의 가치는 인정했지만, 기능 자체를 찾기 어렵다는 문제가 확인됐다. - 첫 번째 실험은 보기 전용 개발자를 대상으로 진행했다. - 이 사용자들은 디자이너와 긴밀히 협업하지만, 기존에는 댓글을 가장 적게 사용하는 집단이었다. - 실험군과 대조군을 50 대 50으로 나누고 2주간 관찰했다. - 댓글 작성을 유도해 기능을 노출한 결과: - 실험군의 댓글 작성이 45% 증가했다. - 다음 주 댓글로 다시 돌아오는 비율에는 부정적인 영향이 없었다. - 즉, 댓글 자체의 가치가 부족한 것이 아니라 사용자가 기능을 발견하지 못한 것이 주요 장벽이었다. ## 댓글 진입점 이동 실험의 반전 - 두 번째 실험에서는 댓글 진입점을 메뉴 바 왼쪽에서 오른쪽으로 옮겼다. - 왼쪽은 디자인 도구와 캔버스 기능이 모여 있고, 오른쪽에는 협업·보기 기능이 많으므로 댓글도 오른쪽이 더 적합할 것이라고 예상했다. - 신규 가입자를 대상으로 50 대 50 실험을 진행하고, 가입 후 7일 안에 댓글을 발견한 비율을 측정했다. - 예상과 달리 댓글 발견 가능성이 전체적으로 20% 감소했다. - 기능의 의미와 무관하게 위치, 주변 UI, 사용자의 기존 탐색 습관 같은 작은 변화가 발견성과 사용률에 큰 영향을 줄 수 있음을 보여줬다. ## 데이터 기반 제품 개발의 교훈 - 제품 가설은 대부분 맞지 않을 수 있으므로, 직관만으로 전면 출시하지 않고 실험으로 검증해야 한다. - 첫 번째 실험은 ‘노출을 높이면 사용이 늘어난다’는 가설을 입증했다. - 두 번째 실험은 ‘오른쪽이 협업 기능에 적합하므로 댓글도 더 잘 발견될 것’이라는 가설을 반박했다. - 실패한 실험도 사용자의 행동 패턴과 제품 구조를 이해하는 데 중요한 정보를 제공한다. - 여러 차례의 작은 실험과 사용자 조사 결과가 쌓이면서 댓글 기능의 재설계와 전체 사용자 대상 출시로 이어졌다. 댓글 같은 협업 기능은 기능을 추가하는 것보다 사용자가 자연스럽게 발견하고 진입하도록 만드는 일이 중요하다. 따라서 UI 위치를 변경할 때는 직관에 의존하지 말고, 대상 사용자와 명확한 지표를 정한 뒤 통제 실험으로 효과와 부작용을 함께 측정하는 것이 바람직하다.