user-research

25 개의 포스트

line4분 읽기큐레이션 요약

도쿄에서 후쿠오카까지, 현장에서 답을 찾다 - CS InquiryChat 도입기

타사 채팅 솔루션의 종료를 계기로 데마에칸은 자체 메시징 플랫폼인 InquiryChat으로 전환했다. 이 프로젝트는 연간 라이선스 비용을 0원으로 줄였을 뿐 아니라, 상담 재활성화 비율을 약 20% 낮추고 보안·운영 유연성·사용자 경험을 개선했다. 성공적인 전환의 핵심은 단순한 기능 복제가 아니라, 현장 관찰과 사용자 테스트를 통해 실제 업무 맥락을 파악하고 이해관계자 간 합의를 이끌어낸 데 있었다. ## 자체 솔루션 전환의 배경과 목표 - 기존 타사 채팅 서비스의 종료가 예정되면서 후속 솔루션 도입과 자체 개발을 비교 검토했다. - InquiryChat을 선택한 이유는 다음과 같다. - 라이선스 비용을 제거할 수 있음 - 데마에칸의 운영 프로세스에 맞춘 유연한 커스터마이징 가능 - 내부 담당자를 통한 실시간 연동과 운영 지원 가능 - 고객 정보를 보안 문제 없이 활용 가능 - 실시간 분석·리포팅 제공 - 기존 서비스에는 다음과 같은 개선 과제가 있었다. - 상담원이 사용자가 전송하지 않은 메시지를 미리 볼 수 있는 보안 취약점 - 사용자가 이탈하면 세션이 유지되지 않아 상담을 처음부터 반복해야 하는 문제 - 다른 플랫폼과의 통합 및 사용자 정의가 제한적임 - 안정적으로 사용하던 도구를 교체하는 만큼, 상담원 교육과 업무 프로세스 변화, 서비스 중단 없는 전환이 필요했다. ## 문서 중심 요구 사항의 한계 - 초기 요구 사항은 기존 기능을 단순히 나열한 목록에 가까웠다. - 기능이 실제로 사용되는지, 현장 업무에 필요한지, InquiryChat에서 그대로 제공할 수 있는지 판단하기 어려웠다. - 요구 사항이 협업 부서를 거쳐 전달되면서 실제 상담원과 매니저의 업무 맥락이 희석됐다. - 기능을 다음 세 가지로 재분류해 우선순위를 정리했다. - 기본 제공 기능 - 커스터마이징 또는 추가 검토가 필요한 기능 - 신규 개발이 필요한 기능 ## 후쿠오카 콜센터 현장 조사 - 실제 사용자인 상담원과 매니저를 이해하기 위해 후쿠오카의 두 콜센터를 직접 방문했다. - 피크 시간대 업무를 모니터링한 뒤 여러 상담원과 매니저를 인터뷰해 공통 요구 사항을 도출했다. - 현장 조사로 불필요한 기능과 필수 기능을 구분할 수 있었다. - 매니저에게 지원을 요청하는 메시지 기능은 실제로 손짓이 더 빨라 거의 사용되지 않음 - 사무실에서 소리를 켤 수 없어 채팅 단절 음성 경고 기능은 실효성이 낮음 - 상담 내용을 CS 솔루션에 연동하는 기능은 상담 기록과 공유에 필수적이므로 우선순위를 높여 구현 - 직접 관찰한 근거를 바탕으로 협업 부서와 기능 우선순위를 설득할 수 있었다. ## 복잡한 협업 구조를 관리한 PM 전략 - 한국과 일본의 여러 부서, 외주 콜센터가 참여하는 구조에서 공통된 목표와 기준을 만드는 데 집중했다. - Jira 대시보드를 설계해 개발 진행 상황을 실시간으로 시각화하고 지표 기반 의사 결정을 가능하게 했다. - 파편화된 요구 사항을 하나의 마스터 사양서로 통합해 단일 기준을 마련했다. - 기획 의도가 실제 구현에 반영됐는지 확인하기 위해 기획·개발 단계의 내부 QA를 주도했다. - 출시 직후 현장에서 활용할 수 있도록 상세 운영 가이드도 제작했다. ## FGT를 통한 실제 사용자 경험 검증 - 화상 회의와 문서만으로는 세밀한 사용 경험을 검증하기 어렵다고 판단해 FGT를 진행했다. - 사용자와 상담원 역할을 나누고, 고객 문의 시작부터 문제 해결까지의 전체 시나리오를 직접 수행했다. - FGT 과정은 배경 설명, 수행 과제, 실습, 설문, Q&A 등으로 구성됐다. - 백엔드 연동에 집중하던 개발자도 실제 앱 사용 흐름을 경험하면서 문제를 QA 전에 발견하고 수정할 수 있었다. - 주요 피드백과 개선 사항은 다음과 같다. - 역할과 현재 상태를 더 직관적으로 표시할 필요 - 링크에 날짜뿐 아니라 시간도 표시 - Android 푸시 안정화 - 키패드와 채팅 입력창이 겹치는 문제 개선 - 푸시 알림 제목 변경 - 일부 대화 로그가 CS 솔루션에 누락되는 문제 해결 ## 보안과 상담 효율 사이의 균형 - 기존 상담원이 선호하던 ‘입력 중 메시지 미리보기’는 고객이 전송하지 않은 데이터까지 상담원이 볼 수 있다는 보안·정보 주권 문제를 안고 있었다. - 상담원에게는 고객 답변을 미리 파악해 평균 처리 시간(AHT)을 줄이는 유용한 기능이었다. - 단순히 기능을 삭제하면 상담 효율이 떨어질 수 있어, 대안으로 ‘입력 중 표시기’를 제안했다. - 상담원은 고객이 메시지를 작성 중인지 알 수 있지만, 실제 입력 내용은 볼 수 없도록 설계해 편의성과 개인정보 보호를 절충했다. - 이 과정은 기술 내재화가 기존 기능을 그대로 복제하는 것이 아니라, 운영 효율과 보안 원칙을 재검토하는 과정임을 보여준다. ## 실용적인 시사점 자체 솔루션 전환에서는 요구 사항 문서보다 실제 사용 현장 관찰이 우선되어야 한다. 또한 기능을 그대로 옮기기보다 보안, 업무 효율, 사용자 경험을 함께 평가하고, FGT 같은 실사용 검증을 통해 출시 전에 문제를 발견하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
toss원문

외국인 유저 리서치: 캐나다인 "B"씨는 왜 토스 인증에 실패했을까 (새 탭에서 열림)

토스는 '모두를 위한 금융'이라는 비전을 실현하기 위해 외국인 사용자가 국내 금융 앱 가입 과정에서 겪는 본인 인증 실패 원인을 심층 분석했습니다. 산업단지와 다문화 센터를 직접 찾아가 진행한 리서치를 통해 이름 입력 포맷의 불일치와 주소 검색의 어려움이 핵심 이탈 요인임을 확인했습니다. 이를 바탕으로 인증 로직과 UI를 개선한 결과, 외국인 사용자의 인증 통과율을 약 15% 끌어올리며 내국인 수준의 서비스 접근성을 확보했습니다. ### 현장 리서치를 통한 사용자 페인 포인트 발굴 * 정보 접근성이 상대적으로 낮은 블루칼라 외국인 노동자들의 금융 생활을 파헤치기 위해 시화공단과 포천 다문화 센터 등에서 현장 인터뷰를 수행했습니다. * 외국인들이 모바일 앱 대신 오프라인 은행 창구를 선호하는 이유가 단순한 선호도가 아닌, 가입 단계부터 발생하는 기술적 허들 때문임을 파악했습니다. * 정형화된 설문조사 대신 친근한 방식의 길거리 인터뷰와 심층 인터뷰를 병행하여, 실제 사용자가 겪는 맥락적인 어려움을 수집했습니다. ### 본인 인증의 최대 걸림돌: 이름 입력 방식 * 외국인 등록증상의 이름과 통신사, 은행 등에 등록된 이름의 포맷(성·이름 순서, 띄어쓰기 등)이 서로 달라 본인 인증에 반복적으로 실패하는 문제가 가장 컸습니다. * 'BRAD PITT'를 'BR AD'로 띄어 써야 인증이 되는 등, 시스템마다 요구하는 형식이 달라 사용자가 스스로 성공 케이스를 학습해야 하는 불합리한 상황이 발생했습니다. * 인증 실패 시 구체적인 원인 안내가 부족하고, 5회 오류 시 시도가 차단되는 정책은 외국인 사용자들을 8년 넘게 온라인 인증에서 소외시키기도 했습니다. ### 한국어 주소 입력 및 검색의 난관 * 한국어 타이핑이 서툰 외국인들에게 주소 입력은 가입을 포기하게 만드는 주요 허들이었습니다. * 영문 주소나 우편번호로 검색하더라도 검색 결과 리스트가 너무 방대하여, 본인의 정확한 거주지를 스크롤 내에서 찾아내기가 매우 어려웠습니다. * 입력 방식의 반복된 시도에도 불구하고 원하는 결과를 얻지 못해 결국 서비스 이용 자체를 중도에 포기하는 이탈 구간이 발생했습니다. ### 리서치 기반의 개선 성과 * 유저리서치 결과를 바탕으로 담당 팀에서 이름 입력 구조를 유연하게 변경하고 인증 절차 전반을 고도화했습니다. * 개선 이후 외국인 사용자의 인증 퍼널 통과율이 15% 상승하는 가시적인 성과를 거두었습니다. * 현재는 외국인과 내국인 간의 인증 통과율 격차가 거의 해소되었으며, 디지털 금융 소외 계층을 위한 장벽을 낮추는 기술적 기틀을 마련했습니다. 디지털 금융 서비스에서 외국인 사용자의 접근성을 높이려면 단순한 번역을 넘어, 국내 인증 체계(통신사, 실명확인 기관)와 사용자 입력 데이터 간의 '포맷 불일치' 문제를 기술적으로 해결하는 것이 필수적입니다. 사용자가 직접 시스템에 맞추게 하는 것이 아니라, 시스템이 다양한 케이스를 수용할 수 있도록 설계를 개선하는 것이 진정한 금융 포용의 시작입니다.

toss원문

토스의 브랜드 심볼을 찾아서 (새 탭에서 열림)

토스가 오프라인 시장으로 확장하며 브랜드 인지도를 높이기 위해 사용자의 무의식 속에 자리 잡은 '진짜 얼굴'을 탐색한 과정을 다룹니다. UX 리서치를 통해 파란색 로고 자체보다 '흰 배경의 앱 아이콘' 형태와 '검정 영문 폰트'의 조합이 브랜드 정체성의 핵심임을 발견했습니다. 이를 통해 추상적인 브랜드 이미지를 구체적인 디자인 원칙으로 정립하여 오프라인 접점과 제품 디자인에 성공적으로 적용한 사례를 제시합니다. **오프라인 확장을 위한 브랜드 심볼의 재정의** * 온라인과 달리 맥락이 부족한 오프라인 환경(편의점 댕글러, POS 단말기 등)에서 사용자가 토스를 즉각적으로 인지할 수 있는 시각적 단서를 찾는 것이 과제였습니다. * 단순히 '어떤 로고가 예쁜가'를 넘어, 사용자가 낯선 환경에서도 토스를 토스로 인식하게 만드는 핵심 자산이 무엇인지 파악하기 위해 리서치를 시작했습니다. **심층 인터뷰를 통한 브랜드 이미지 탐색** * 브랜드에 대한 추상적인 인상을 명확한 언어로 표현할 수 있는 사용자를 선별하여 심층 인터뷰를 진행했습니다. * 사용자들이 느끼는 토스의 핵심은 시각적 요소가 아닌 '군더더기 없는 실용성'과 '편리한 경험'에 집중되어 있음을 확인했습니다. * 구체적인 시각적 심볼이 부족하다는 문제점을 발견하고, 이를 해결하기 위해 폰트, 컬러, 로고라는 세 가지 요소로 나누어 분석했습니다. **데이터로 찾아낸 세 가지 핵심 단서** * **폰트:** 사용자는 앱 내부의 국문 폰트보다 뉴스나 광고 등 외부 매체에서 자주 접한 '검정색 영문 toss'를 브랜드의 대표 폰트로 인지하고 있었습니다. * **컬러:** 사용자에게 각인된 토스의 컬러는 단일 '파란색'이 아니라, '흰 배경과 파란 로고'가 만나는 조합 그 자체였습니다. * **로고:** 로고를 직접 그려보게 한 결과, 사용자는 로고 단독 형태가 아니라 스마트폰 화면 속 '네모난 앱 아이콘(흰 바탕 + 파란 로고 + 사각 배경)' 구성을 브랜드의 얼굴로 기억하고 있었습니다. **리서치 인사이트의 실전 적용** * 리서치로 정의한 '진짜 심볼(앱 아이콘 형태 + 검정 영문 폰트 + 흰/파/검 조합)'을 실제 디자인에 반영했습니다. * **토스 10주년 캠페인:** 파란 배경 대신 사용자가 가장 토스답다고 느끼는 흰 바탕에 검정 글씨와 파란 로고 조합을 메인으로 사용했습니다. * **토스페이 결제 화면:** 전면 파란색 배경 시안을 걷어내고, 리서치로 검증된 시각적 공식을 적용하여 브랜드 인지도를 높였습니다. 브랜드 리서치는 추상적인 감각과 인식을 다루기에 결과물이 모호해질 위험이 있지만, 이를 구체적인 시각적 요소로 분해하여 분석함으로써 실질적인 프로덕트 개선과 일관된 브랜드 경험을 설계할 수 있습니다.

figma3분 읽기큐레이션 요약

제품 로드맵을 벗

제품 로드맵은 방향을 제시하는 도구이지, 반드시 지켜야 하는 계약서가 아니다. AI와 사용자 기대가 빠르게 변하는 환경에서는 사용자 피드백과 실험 결과에 따라 계획을 과감히 수정해야 하며, 이러한 우회와 전환이 오히려 좋은 제품을 만든다. Figma의 Dev Mode 사례는 초기 비전을 고집하기보다 실제 개발자의 문제를 해결하는 방향으로 피벗한 과정을 보여준다. ## 변화한 제품 개발 환경 - AI, 에이전트, 어시스턴트의 발전으로 제품 개발과 사용 방식이 빠르게 변하고 있다. - Claude, Cursor 같은 도구는 프롬프트만으로도 애플리케이션을 만들 수 있다는 기대를 높였다. - 기존의 6~12개월 단위 로드맵과 전통적인 개발 방식만으로는 변화 속도와 사용자 기대를 따라가기 어렵다. - 명확한 계획은 필요하지만, 로드맵을 지나치게 규범적으로 따르면 더 이상 유효하지 않은 방향을 계속 추진할 위험이 있다. ## 비전보다 중요한 유연성과 학습 - 신제품 개발은 계획대로 직선적으로 진행되지 않고, 실험과 실패, 재설계를 반복하는 비선형 과정이다. - 하나의 비전을 끝까지 고수해야 성공한다는 것은 기술 업계의 신화에 가깝다. - 사용자 조사, 내부 직원의 실제 사용(dogfooding), 베타 테스트를 통해 새로운 정보를 얻으면 기존 가정을 수정해야 한다. - 계획을 바꾸는 것은 실패가 아니라 더 나은 사용자 결과에 도달하기 위한 학습 과정이다. ## Dev Mode의 피벗 사례 - Figma는 처음에 Dev Mode를 디자인을 코드로 자동 변환하는 도구로 구상했다. - 초기 코드 생성 기능은 가능성을 보였지만, 개발자들은 생성된 코드가 실제 업무에 항상 유용하지 않다고 피드백했다. - 디자인 시스템을 사용하는 개발자들은 새 코드를 생성하기보다 이미 작성된 컴포넌트를 조합하는 데 더 많은 시간을 썼다. - Figma는 코드 생성에 계속 투자하는 대신 **Code Connect**를 개발했다. - 개발자가 디자인 시스템의 실제 코드 스니펫을 직접 연결할 수 있다. - Dev Mode에서 자동 생성 CSS가 아니라 팀이 사용하는 컴포넌트 코드를 보여준다. - 이 전환으로 출시가 늦어지고 기존 방향을 추진하던 팀원들이 좌절하는 비용이 발생했지만, 사용자에게 더 적합한 제품에 가까워질 수 있었다. ## 로드맵을 수정하는 데 따르는 비용 - 방향 전환은 이미 투입한 시간과 자원을 포기해야 하므로 조직적으로 쉽지 않다. - 기존 작업을 중단하면 출시 일정이 지연되고, 팀의 사기가 떨어질 수 있다. - 그러나 매몰비용 때문에 효과가 낮은 기능을 계속 개발하면 더 큰 손실로 이어진다. - Figma는 Dev Mode 베타 이후 로드맵보다 사용자 피드백을 우선했고, 한 달 동안 200개가 넘는 수정 사항과 신규 기능을 출시했다. ## 성공적인 제품은 전환을 통해 성장한다 - Loom은 기업에 제품 피드백을 제공하는 전문가 네트워크에서 출발했지만 여러 번 피벗한 끝에 현재의 비디오 녹화 플랫폼이 되었다. - Slack 역시 온라인 멀티플레이어 게임인 Glitch에서 시작해 협업 도구로 전환했다. - 이 사례들은 초기 아이디어를 끝까지 지키는 것보다, 새로운 학습을 바탕으로 사업과 제품의 방향을 바꾸는 것이 중요하다는 점을 보여준다. - 좋은 제품은 우여곡절 때문에 망가지는 것이 아니라, 그 우여곡절을 통해 정의된다. ## 실무에서의 적용 - 상세한 사양과 디자인을 확정하기 전에 빠른 프로토타입으로 가설을 검증한다. - 베타 사용자와 내부 사용자에게서 반복적으로 나타나는 문제를 로드맵보다 우선한다. - 제품이 시장이나 사용자에게 제대로 도달하지 못한다면 처음부터 다시 시작하는 결정을 고려한다. - 매몰비용이나 기존 방법론에 얽매이지 말고, 현재 환경에서도 유효한지 오래된 가정을 재검토한다. - 로드맵은 고정된 약속이 아니라, 언제 계획을 따르고 언제 방향을 바꿀지 판단하기 위한 기준으로 활용하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

파블로 산체스의 예기

Ableton Note의 디자이너 Pablo Sánchez는 예상 가능한 관행을 따르기보다 개인적 확신과 다양한 분야의 영감을 바탕으로 낯선 경험을 설계해야 한다고 주장한다. 좋은 디자인은 객관적 분석만으로 만들어지는 것이 아니라, 디자이너의 취향과 경험이 사용자에게 진정성 있게 전달될 때 힘을 얻는다. Note는 복잡한 음악 제작 도구 대신 손으로 소리를 만지고 즉시 실험하는 경험을 제공함으로써 이러한 철학을 구현했다. ## 1. 자신을 위해 디자인하라 - 디자이너가 실제로 가장 잘 아는 사용자는 자기 자신이므로, 개인적 확신에서 출발해야 한다. - 모든 사용자의 요구를 객관적으로 맞추려다 보면 제품의 독창성과 방향성이 약해질 수 있다. - Pablo는 Note에 기존 음악 앱에서 흔히 볼 수 있는 MIDI 편집기를 넣는 대신, 모바일의 즉각적이고 촉각적인 특성에 맞춘 악기 인터페이스를 제안했다. - 사용자 테스트를 통해 이 방향이 검증되었고, Note는 MIDI 편집기 없이 출시되었다. - 16개 패드로 리듬을 두드리고, 멜로디와 코드 진행을 연주하며, Session View에서 변주를 만들 수 있다. ## 2. 브레인스토밍 단계에서는 레퍼런스를 배제하라 - 처음부터 다른 제품이나 디자인 사례를 참고하면 이미 존재하는 해결책의 틀 안에서 사고하게 된다. - 외부 레퍼런스 없이 자신의 경험과 기억에서 출발하면 더 독특한 아이디어를 만들 수 있다. - 과거에 접한 여러 요소가 무의식적으로 결합되는 ‘집단적 의식(plural consciousness)’을 신뢰해야 한다. - Pablo는 Samplr와 Borderlands Granular 같은 음악 앱의 영향을 받았지만, 이를 직접 모방하지 않고 본질적인 감각만 Note에 녹였다. - 브레인스토밍 단계에서는 모호함을 허용하고, 구체적인 결과물을 너무 일찍 확정하지 않는 것이 중요하다. ## 3. 디자인 바깥에서 영감을 찾아라 - 디자인 사례만 보는 대신 문학, 춤, 자연, 과학, 동물, 개인적 기억 등 다양한 영역에서 영감을 얻어야 한다. - 다른 분야의 감정과 구조를 디자인 문제에 적용하면 예측하기 어려운 새로운 관점이 생긴다. - Note는 기타를 집어 들고 즉흥적으로 연주하는 듯한 즉각성을 모바일 UX의 목표로 삼았다. - 장식을 덜어내고 재료 자체를 강조하는 브루탈리즘 건축의 시각 언어도 참고했다. - 그 결과 Note는 복잡한 음악 제작 기능을 숨기고, 사용자가 소리를 직접 만지고 조작할 수 있는 단순한 인터페이스를 제공한다. - 휴대폰 마이크로 소리를 녹음하고 시각화하는 샘플러 역시 이러한 직접성과 탐구성을 강화한다. ## 4. 내일을 위해 디자인하라 - Anthony Dunne과 Fiona Raby는 디자인을 ‘긍정적 디자인(affirmative design)’과 ‘비판적 디자인(critical design)’으로 구분한다. - 긍정적 디자인: - 현재 세계의 문제를 해결한다. - 현실에 대한 답을 제시하고 소비를 촉진한다. - 비판적 디자인: - 아직 드러나지 않은 문제를 제기한다. - 현재와 다른 세계가 어떻게 가능할지 질문하게 만든다. - 예상 밖의 디자인은 두 접근법 사이에 위치한다. - 새로운 가능성을 상상하게 한다. - 사용자가 기존 현실을 당연하게 받아들이지 않고 탐구하도록 자극한다. - 현재의 조건을 반복하기보다, “세상이 달라질 수 있다면 무엇이 가능한가”를 질문해야 한다. - 글에서 소개한 제노페미니즘의 “자연이 부당하다면 자연을 바꿔라”라는 주장은 현재의 한계를 넘어 미래를 상상하는 태도를 상징한다. 제공된 글은 4번째 규칙의 중간에서 끝나 있어 나머지 5~7번째 규칙은 확인할 수 없다. 다만 실무적으로는 익숙한 레퍼런스를 모방하기 전에 자신의 경험에서 출발하고, 디자인 외부의 분야를 탐구하며, 현재의 문제 해결을 넘어 미래의 가능성까지 상상하는 접근이 유용하다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

디자인 시스템의 미래는

디자인 시스템은 좋은 컴포넌트와 문서를 만드는 것만으로 성공하지 않으며, 조직 구성원이 실제로 사용하도록 만드는 채택 전략이 필요하다. 따라서 디자인 시스템 팀은 자신들의 시스템을 하나의 제품처럼 보고, 사용자 이해·메시지 설계·조직 내 홍보·성과 측정을 마케팅 방식으로 수행해야 한다. 이를 통해 디자인 시스템을 선택 사항이 아닌 조직의 필수 기반으로 자리매김할 수 있다. ## 디자인 시스템도 제품처럼 시장 적합성을 찾아야 한다 - 디자인 시스템의 효과인 일관성, 효율성, 확장성은 구성원들이 널리 사용할 때 비로소 실현된다. - 단순히 Slack 메시지를 보내거나 교육 세션을 여는 것만으로는 채택을 이끌어내기 어렵다. - 디자인 시스템 팀은 내부 사용자를 대상으로 제품-시장 적합성(product-market fit)을 지속적으로 탐색해야 한다. - 디자이너, 개발자, 의사결정자 등 다양한 사용자의 다음 요소를 파악해야 한다. - 현재 업무 방식과 프로세스 - 반복되는 병목과 불편 - 새로운 도구에 대한 우려 - 시스템이 일상 업무에 제공할 수 있는 가치 - 아직 명확히 표현하지 못한 욕구와 불만 - 개별 실무자부터 리더십까지 Product Design and Engineering 조직 전반을 인터뷰하면 역할별 관점을 전략에 반영할 수 있다. - 인터뷰는 디자인 시스템 자체를 설명하는 것보다 현재의 업무 목표와 문제점을 먼저 묻는 방식으로 시작하는 것이 효과적이다. ## 대상별로 다른 메시지를 설계해야 한다 - 디자이너, 개발자, 프로젝트 관리자, 의사결정자는 같은 시스템을 사용하더라도 관심사와 판단 기준이 다르다. - 따라서 모두에게 동일한 홍보 문구를 전달하기보다 대상별로 설득 논리를 조정해야 한다. - **디자이너에게는** - 브랜드 일관성을 유지하면서도 창의성을 발휘할 수 있다는 점을 강조한다. - **개발자에게는** - 컴포넌트 재사용과 표준화 - 디자인과 코드 사이의 원활한 협업 - 반복 작업 감소와 효율 향상을 설명한다. - **의사결정자에게는** - 출시 속도 향상 - 기술 부채 감소 - 투자 대비 효과(ROI)를 중심으로 제안한다. - 유연성 부족, 기술적 한계, 도입 비용과 같은 반대 의견도 피하지 말고 구체적으로 다뤄야 한다. - 사용자의 회의적인 이유를 이해하고 이에 답하는 메시지를 제시하면 저항을 설득과 참여로 전환할 수 있다. ## 채택을 높이는 기능과 도구 - 글에서는 조직 전체의 채택을 지원하는 사례로 다음과 같은 기능을 언급한다. - 개발자를 위한 Code Connect - 타이포그래피 및 그라디언트 변수 - 디자인 시스템 사용 현황을 파악하는 Library Analytics API - 이런 기능은 디자인과 코드의 연결을 강화하고, 시스템이 실제로 어떻게 사용되는지 확인하게 해준다. - 특히 사용 데이터를 확보하면 어떤 팀이 시스템을 사용하고 있는지, 어느 부분에서 채택이 막히는지 파악해 후속 전략을 세울 수 있다. ## 조직 내부의 마케팅으로 접근하기 - 디자인 시스템 팀의 역할은 시스템을 구축하는 데서 끝나지 않고, 조직 안에서 그 가치를 지속적으로 알리고 확산시키는 데까지 확장되어야 한다. - 시스템을 성공시키려면 다음과 같은 제품 출시 전략이 필요하다. - 대상 사용자와 문제 정의 - 대상별 가치 제안 작성 - 도입 장벽과 반론에 대한 대응 - 내부 홍보와 지지자 확보 - 사용량과 성과 측정 - 이런 마케팅 관점은 디자인 시스템을 “있으면 좋은 도구”가 아니라 디지털 제품을 설계하고 개발하는 방식의 핵심 기반으로 바꾸는 데 목적이 있다. 실무적으로는 먼저 디자이너·개발자·리더를 인터뷰해 각자의 문제를 정리하고, 대상별 가치 제안과 도입 장벽을 문서화하는 것이 좋다. 이후 사용량과 반복 사용률 같은 데이터를 추적하면서 메시지와 지원 방식을 계속 개선해야 한다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

지금 바로 북마크해야 할

프로토타이핑은 제품 개발 막바지의 보조 수단이 아니라, 아이디어 검증·사용자 조사·이해관계자 피드백·프레젠테이션 등 전 과정에서 팀의 공통 비전을 만드는 핵심 도구다. 이 글은 Figma 프로토타이핑 학습을 위해 기초 강의부터 발표, 모션과 플로우, 변수, 오피스 아워까지 23개의 영상·커뮤니티 파일·콘텐츠를 단계별로 큐레이션한다. 학습자는 자신의 수준과 목적에 맞는 자료를 골라 인터랙션 구현 능력을 높이고 더 나은 제품을 설계할 수 있다. ## 프로토타이핑의 역할 - 프로토타입은 제품의 동작과 사용자 경험을 시각화해 팀이 아이디어를 공유하도록 돕는다. - 사용자 테스트와 이해관계자 피드백을 통해 문제를 조기에 발견하고 반복적으로 개선할 수 있다. - 발표 자료에도 인터랙션을 추가해 정적인 화면보다 설득력 있게 제품의 흐름과 기능을 전달할 수 있다. - Figma는 모바일·태블릿·워치 등 다양한 디바이스 화면을 고려한 프로토타이핑 기능을 강화하고 있다. ## 기초 기능 익히기 - **「Build prototypes」(8분)** - 인터랙티브 프로토타입 제작의 기본 흐름을 소개한다. - 애니메이션을 적용하고 테스트 사용자에게서 피드백을 반영하는 방법을 다룬다. - **「Prototyping playlist」(50분)** - easing curve, transition, Smart Animate, 스크롤, 디바이스 프레임 등 핵심 기능을 짧은 영상들로 학습할 수 있다. - **「Prototyping 101」(63분)** - 프레임 간 기본 내비게이션부터 인터랙티브 컴포넌트 같은 고급 기능까지 설명한다. - **제품 담당자를 위한 Figma 학습 시리즈** - 디자이너가 아닌 제품 담당자도 가벼운 프로토타입을 직접 만들 수 있도록 안내한다. - 두 번째 영상에서는 transition, Smart Animate, 스크롤 동작 등을 활용해 화면을 더 실제처럼 만드는 방법을 다룬다. - **접근 가능한 프로토타입 커뮤니티 파일** - Figma의 접근성 모드를 활용해 프로토타이핑 화면의 정보를 스크린 리더로 읽을 수 있다. - macOS의 VoiceOver와 Windows의 JAWS 같은 도구를 통한 접근성 테스트에 활용할 수 있다. ## 발표 자료를 인터랙티브하게 만들기 - **「Presenting with Figma」(70분)** - Figma 프로토타이핑 기능을 활용해 역동적인 슬라이드 프레젠테이션을 구성하는 방법을 소개한다. - **발표 팁 영상** - 슬라이드 안에 프로토타입을 중첩해 실제로 스크롤되는 모바일 화면 등 인터랙티브 요소를 넣을 수 있다. - 이 방식은 이사회 보고, 수업, 제품 소개처럼 메시지 전달이 중요한 상황에 유용하다. - **Figma 앱으로 발표하기** - 모바일 앱에서 슬라이드를 직접 클릭하며 발표하는 방법을 보여준다. ## 영상·모션·사용자 플로우 학습 - 프로토타입의 완성도를 높이려면 단순한 화면 연결뿐 아니라 전환 효과, 애니메이션, 스크롤 동작을 함께 설계해야 한다. - Smart Animate와 easing curve를 사용하면 화면 변화가 더 자연스럽고 제품의 실제 동작에 가까워진다. - 모션과 플로우를 활용하면 사용자가 어떤 순서로 기능을 경험하는지 명확하게 검증할 수 있다. ## 변수와 고급 프로토타이핑 - 변수 기능을 활용하면 하나의 프로토타입에서 상태, 값, 조건에 따른 다양한 동작을 관리할 수 있다. - 반복되는 상태나 화면을 개별 프레임으로 복제하는 대신 변수와 인터랙티브 컴포넌트로 구성해 유지보수성을 높일 수 있다. - 복잡한 사용자 플로우와 여러 상태를 표현할 때 변수 기반 설계가 특히 유용하다. ## 오피스 아워와 실습 자료 - Figma의 오피스 아워 콘텐츠는 프로토타이핑 기능과 실제 활용 사례를 보충 학습할 수 있는 자료로 제공된다. - 영상뿐 아니라 Figma 커뮤니티 파일을 직접 열어 결과물을 확인하고 따라 해볼 수 있다. - 학습 방식에 따라 짧은 영상, 장시간 강의, 실습 파일, 소셜 콘텐츠 중 적합한 자료를 선택할 수 있다. 처음 시작한다면 기초 프로토타입 제작과 프레임 간 내비게이션부터 익힌 뒤, Smart Animate·스크롤·인터랙티브 컴포넌트로 확장하는 순서가 좋다. 이후 접근성 테스트, 변수, 발표용 프로토타입을 적용하면 실무에서 검증과 커뮤니케이션을 동시에 강화할 수 있다.

원문 읽기(새 탭에서 열림)
figma2분 읽기큐레이션 요약

피터 양: 고객이 사랑

고객이 사랑하는 제품은 타고난 감각이 아니라 지속적으로 갈고닦은 제품 감각과 깊은 공감에서 출발한다. 고객 문제를 정확히 진단한 뒤 큰 방향과 전략을 세우고, 단기 일정이나 지표보다 장기적인 제품 품질을 우선할 때 의미 있는 결과를 만들 수 있다. 이를 위해 제품 관리자는 실행에만 매몰되지 않고 필요하면 방향을 바꾸거나 프로젝트를 중단할 수 있어야 한다. ### 제품 감각은 타고나는 것이 아니라 길러진다 - 제품 감각은 사용자가 의도한 효과를 얻도록 제품을 설계하고 개선하는 능력이다. - 단순한 직관이나 한 번 습득하면 유지되는 고정된 능력이 아니다. - 시장과 고객의 요구는 계속 변하므로 제품 감각도 지속해서 개선해야 한다. - 고객에 대한 공감, 창의성, 제품 제작 역량을 꾸준히 쌓는 태도가 중요하다. ### 공감으로 고객 문제를 진단하라 - 해결책이나 비전을 서둘러 정하기 전에 고객과 비즈니스가 실제로 겪는 문제를 명확히 파악해야 한다. - 고객을 팀원처럼 대하고, 직접 인터뷰하거나 제품을 고객의 입장에서 사용해 보면 공감 능력을 키울 수 있다. - 제품 관리자의 핵심 역량은 고객이 무엇을 필요로 하는지 깊이 이해하는 것이다. - 문제 진단이 부정확하면 이후의 전략과 기능 개발도 잘못된 방향으로 흘러갈 수 있다. ### 일상적인 실행보다 먼저 큰 방향을 세워라 - 문제를 파악한 직후 세부 실행에 뛰어들기보다 팀의 미션, 비전, 전략을 먼저 정해야 한다. - 팀과 함께 브레인스토밍하고, 여러 가능성 중 고객 문제를 가장 효과적으로 해결할 아이디어를 우선순위화한다. - 복잡한 해결책보다 고객에게 실질적인 가치를 주는 단순한 해결 과정을 설계하는 것이 좋다. - 고객에 대해 더 많이 알게 되면 우선순위와 트레이드오프를 다시 조정해야 한다. ### 품질을 위해 멈추고 방향을 바꿀 줄 알아야 한다 - 좋은 제품을 만들려면 출시 일정이나 단기 목표 지표를 놓치는 어려운 결정을 감수해야 할 때가 있다. - 고객 의견을 통해 꼭 필요한 기능을 발견했다면, 일정이 늦어지더라도 이를 포함하는 것이 장기적으로 더 나은 선택일 수 있다. - 제품의 완성도는 세부 사항에 대한 집착, 트레이드오프 판단, 버그 제거, 기대 이상의 개선에서 나온다. - 반대로 제품이 사용자에게 사랑받더라도 회사의 핵심 사업 목표에 기여하지 못한다면 프로젝트를 중단해야 할 수 있다. - Reddit의 Reddit Talk 사례처럼 사용자 만족도와 사업적 지속 가능성은 별개의 문제이므로, 제품 관리자는 제품 자체를 넘어 회사 전체의 방향을 고려해야 한다. ### 실용적인 적용 문제를 해결하기 전에 고객의 실제 사용 경험을 직접 확인하고, 팀과 함께 비전과 우선순위를 명확히 정하는 것이 좋다. 이후에는 일정과 지표를 절대적인 기준으로 삼기보다 고객 가치와 사업 목표를 함께 평가하며, 필요하면 출시 연기·방향 전환·프로젝트 중단까지 선택해야 한다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma의 데이터 사이언스 및

Figma의 데이터 과학팀과 사용자 조사팀은 알림 문제를 정량 데이터와 정성적 사용자 의견으로 함께 분석했다. 그 결과 알림 클릭률보다 앞선 단계인 “알림을 아예 받지 못하는 문제”가 가장 큰 개선 기회임을 발견했다. Figma는 이를 해결하기 위해 새로운 알림 유형을 추가하고, 누가 언제 알림을 받아야 하는지 재검토하는 실험을 시작했다. ## 정량 데이터와 정성 조사의 결합 - 데이터 과학은 대규모 사용자 행동을 통해 **무슨 일이 일어나는지(What)** 보여준다. - 사용자 조사는 사용자가 왜 그렇게 행동하는지 **이유(Why)** 를 파악하는 데 도움을 준다. - 수치만으로는 사용자의 동기와 맥락을 알기 어렵고, 인터뷰만으로는 전체 사용자에게 나타나는 패턴을 확인하기 어렵다. - 두 방법을 함께 사용하면 각 분석의 한계를 보완해 더 완전한 제품 이해가 가능하다. - 두 팀은 이를 날실과 씨실을 엮어 천을 만드는 과정에 비유했다. ## Figma 알림 퍼널과 문제 정의 - Figma 알림은 이메일, Slack, 모바일, 파일 브라우저·시스템 트레이·데스크톱 알림 등 여러 경로로 전달된다. - 알림 유형에는 댓글, 댓글 답글, 댓글 반응, 파일·팀·프로젝트 초대, 편집 초대, 멘션 등이 있다. - 사용자가 알림과 상호작용하려면 다음 단계를 통과해야 한다. - 알림 대상이 될 수 있음 - 알림을 받음 - 알림을 확인함 - 알림과 상호작용함 - 활동 팀은 어느 단계에서 사용자가 가장 많이 이탈하는지, 어떤 단계에 투자해야 하는지 알지 못했다. - 분석 결과 가장 큰 문제는 많은 사용자가 알림을 열지 않는 것이 아니라 **알림 자체를 받지 못하고 있다는 점**이었다. ## 협업형 분석 프로세스 구축 - Caitlin Hudon과 Jennifer Sanders는 FigJam에서 팀 전체 브레인스토밍을 진행했다. - 팀은 알림을 받은 사용자, 열어본 사용자, 클릭한 사용자의 비율과 현재 상태를 공유했다. - 이후 다음과 같은 질문을 함께 정리했다. - 분기별로 어떤 지표를 개선할 것인가? - 새로운 알림 유형이 필요한가? - 현재 데이터만으로 알 수 없는 것은 무엇인가? - 질문을 데이터 과학으로 답할지, 사용자 조사로 답할지 각자의 전문 영역에 따라 나누었다. - 두 연구자는 각자 프로젝트를 진행하면서도 지속적으로 소통하고, 공통된 질문과 발견을 맞춰 갔다. - 이런 지속적인 동기화와 결과 종합에 충분히 투자하는 것이 단순히 두 연구 결과를 나열하는 것보다 중요했다. ## 행동 데이터가 보여준 것과 사용자 조사가 밝혀야 한 것 - 데이터 분석은 알림 퍼널의 각 단계에서 사용자가 얼마나 줄어드는지 파악하는 데 적합했다. - 특히 알림 수신 여부와 실제 상호작용 사이의 차이를 수치로 확인할 수 있었다. - 사용자 조사는 사용자가 알림을 받지 못하거나 활용하지 않는 상황의 맥락과 기대를 이해하는 데 사용됐다. - 사용자는 자신의 행동 이유를 항상 정확히 설명하지 못할 수 있으므로, 인터뷰 결과를 행동 데이터와 함께 검증해야 했다. - 정량 결과와 정성적 설명을 결합해 팀은 단순한 클릭률 개선이 아닌 알림 전달 구조 자체를 개선해야 한다고 판단했다. ## 발견을 제품 개선으로 연결 - 활동 팀은 알림을 통해 팀원 간 연결과 협업을 강화하는 것을 목표로 했다. - 가장 큰 개선 영역은 기존 알림의 클릭을 유도하는 것보다 다음 문제를 해결하는 데 있었다. - 적절한 사용자가 알림을 받지 못하는 문제 - 필요한 상황을 포괄하지 못하는 알림 유형 - 알림을 받을 시점과 대상이 적절하지 않은 문제 - 이후 팀은 여러 알림 실험을 시작했다. - 사용자의 주요 불편을 해결하기 위한 새로운 알림 유형도 출시됐다. ## 실용적인 결론 제품 문제를 분석할 때 퍼널의 마지막 행동만 보지 말고, 사용자가 그 단계에 도달하기 전 어디에서 이탈하는지 확인해야 한다. 대규모 행동 데이터로 문제의 범위를 파악한 뒤, 사용자 조사로 원인과 맥락을 보완하고, 두 결과를 공동으로 종합하는 방식이 효과적이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

UX 디자인 커리어를 위해 출소

CROP는 출소자의 재사회화와 재범률 감소를 위해 UX 디자인 교육과 생활 지원을 결합한 비영리 프로그램이다. 1년 과정인 Ready 4 Life는 개인 성장, 직업 교육, 취업 지원, 안정적인 주거를 함께 제공하며, 참가자들이 기술 역량과 자신감을 갖고 새로운 삶을 설계하도록 돕는다. 이 프로그램은 출소자에게 필요한 것은 기회와 도구, 지속적인 지원이라는 점을 보여준다. ## 출소자의 재진입을 돕는 CROP의 탄생 - CROP의 공동 창립자들은 총 100년 이상의 수감 경험을 바탕으로 기존 재진입 지원 체계의 문제를 직접 경험했다. - 기존 서비스는 취업, 주거, 상담이 서로 분리되어 있어 참가자가 여러 기관을 오가야 하는 구조였다. - CROP는 이러한 단절을 해결하기 위해 개인의 삶을 전반적으로 지원하는 “통합적이고 포괄적인 지원” 모델을 구상했다. - 프로그램의 목표는 출소자가 사회와 노동시장에 안정적으로 복귀하고, 재범의 악순환에서 벗어나도록 돕는 것이다. ## Ready 4 Life의 네 가지 축 - **개인 성장** - 자기 이해, 회복, 목표 설정 등 새로운 삶을 준비하는 과정을 지원한다. - **직업 교육** - Figma를 활용한 UX 디자인을 포함해 실제 취업으로 이어질 수 있는 기술을 가르친다. - **취업 지원** - 직무 역량 개발뿐 아니라 취업 기회와 노동시장 진입을 돕는다. - **안정적인 주거** - 참가자들이 교육과 회복에 집중할 수 있도록 웨스트 오클랜드의 주거·교육 캠퍼스에서 아파트를 제공한다. - 12명의 펠로는 개인 코치와 월별 생활비 지원도 받는다. ## UX 디자인을 통한 새로운 진로 - CROP는 출소자들이 이미 갖고 있는 문제 해결 능력, 스토리텔링, 사람들과 연결하는 능력을 기술 교육과 결합하려 한다. - UX 디자인은 사용자의 경험과 문제를 이해하고 해결책을 설계하는 분야이므로, 참가자들의 삶의 경험과 관찰력이 강점으로 활용될 수 있다. - UX 트랙 강사 Alexis Bustos는 참가자들에게 부족한 것은 잠재력보다 기술적 교육과 도구에 대한 접근성이라고 설명한다. - Figma 워크숍을 통해 참가자들은 디자인 프로세스와 협업 도구를 익히며 테크 업계 진입을 준비한다. ## 사회적 낙인과 재사회화의 장벽 - 출소자는 형기를 마친 뒤에도 취업과 주거, 사회적 관계 형성에서 차별과 불신을 경험할 수 있다. - CROP는 단순히 직업 기술만 제공하지 않고 코칭, 주거, 생활비를 함께 지원해 재진입 과정에서 발생하는 현실적인 장벽을 줄인다. - 프로그램은 참가자를 과거의 범죄 기록으로만 판단하지 않고, 변화하고 성장할 수 있는 사람으로 대한다. - 참가자들이 자신의 경험을 새로운 관점에서 해석하고 미래를 직접 설계하도록 돕는 것이 중요한 요소다. ## 재활 투자와 비용 효율성 - 캘리포니아에서는 수감자 1인당 연간 약 10만 6천 달러가 소요되며, 그중 재활에 배정되는 비율은 약 3.4%에 그친다. - CROP는 참가자 1인당 프로그램 비용이 수감 비용의 대략 절반 수준이라고 설명한다. - 캘리포니아의 재범률이 약 50%에 이르는 상황에서, 주거·교육·취업을 결합한 장기 지원은 재범을 줄이기 위한 대안이 될 수 있다. - CROP는 캘리포니아 주정부와 3년간 2,850만 달러 규모의 파트너십을 맺고 프로그램을 확장하고 있다. ## 프로그램이 제시하는 가능성 - CROP의 사례는 사회적 약자를 위한 교육이 단순한 기술 훈련을 넘어 생활 기반과 심리적 안정까지 포함해야 효과적이라는 점을 보여준다. - 참가자들의 과거 경험은 약점만이 아니라 사용자 공감과 문제 해결에 활용할 수 있는 자산이 될 수 있다. - 취업 가능성을 높이려면 교육 과정, 실무 도구, 멘토링, 주거와 경제적 지원이 함께 제공되어야 한다. - 기술 업계 역시 다양한 삶의 경험을 가진 인재를 받아들일 때 더 폭넓은 사용자 관점을 얻을 수 있다. 출소자의 재사회화를 지원하는 프로그램을 설계할 때는 단기 교육보다 장기적이고 통합적인 접근이 효과적이다. 특히 실무 기술 교육을 안정적인 주거, 코칭, 취업 지원과 결합하면 개인의 역량뿐 아니라 실제 사회 복귀 가능성도 높일 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

피그마 오픈 베타 출시의

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 문서 조회 수 - 제품 내 피드백 버튼 제출 내용 - 고객 지원 티켓 - 여러 채널에서 들어오는 요청을 한곳에 모아 반복되는 문제와 우선적으로 해결해야 할 개선 사항을 파악했습니다. - 비공개 베타 기간에 개발자와 디자이너의 워크플로 및 고충을 인터뷰한 결과도 출시 후 분석의 기반으로 활용했습니다. - 이러한 사전 학습을 통해 핵심 기능을 수정하고, 협업 방식에 맞게 기능을 조정하며, 처음에는 예상하지 못했던 요구도 반영할 수 있었습니다. 출시를 성공시키려면 발표 당일의 화제성보다 이후 데이터를 어떻게 측정하고 피드백을 어떻게 실행으로 전환하는지가 중요합니다. 오픈 베타를 진행할 때는 담당 팀과 지표를 미리 정하고, 출시 전 기준선을 확보한 뒤, 사용량·여론·지원 요청을 통합해 빠르게 우선순위를 결정하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Draft 3 (Standard blog style):

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

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma PM 팀이

Figma의 PM 팀은 신뢰·투명성·성찰·포용을 바탕으로 제품 개발 과정을 여러 직군과 공유한다. 아이디어를 우선순위로 구체화하고, 정기 회의에서는 단순한 진행 상황을 넘어 개인적인 고민과 어려운 문제까지 나누며 협업의 질을 높인다. 핵심은 PM의 업무를 폐쇄적인 의사결정이 아니라 다양한 구성원이 참여하는 공동 창작 과정으로 만드는 것이다. ## 투명성과 신뢰를 중심으로 한 PM 문화 - PM은 제품 개발의 중심에서 디자인, 엔지니어링, 마케팅 등 여러 팀과 지속적으로 협업한다. - 회사마다 PM의 역할과 프로세스는 다르지만, 여러 직군과 효과적으로 소통하는 능력은 공통적으로 중요하다. - Figma는 다음 네 가지 가치를 PM 업무의 기반으로 삼는다. - 신뢰 - 성찰 - 포용 - 투명성 - FigJam을 활용해 아이디어 발상부터 회고까지 업무 과정을 공개하고 협업자들의 참여를 유도한다. ## 아이디어를 넓게 모으는 크로스펑셔널 브레인스토밍 - 좋은 아이디어는 한 팀에서만 나오는 것이 아니라 여러 팀과 구성원의 의견을 거치며 발전한다. - 브레인스토밍은 아이디어를 많이 내는 것만으로 끝나서는 안 된다. - 명확한 의사결정 - 실행 항목 - 담당자와 후속 조치 가 뒤따라야 실제 제품 방향으로 연결된다. - Figma PM 팀은 다양한 참여자의 의견을 정렬하고 우선순위를 정하기 위해 여러 협업 기법을 사용한다. ## `Buy a Feature`로 투자 우선순위 정하기 - 구성원에게 일정량의 가상 화폐를 나누어 주고, 제품 아이디어나 집중 영역에 투자하게 하는 우선순위 결정 방식이다. - PM은 각 아이디어에 투자할 수 있는 시간과 자원의 규모를 정한다. - 단순한 순위 투표와 달리, 사람들이 어떤 영역에 **얼마나 투자할 의향이 있는지**를 파악할 수 있다. - 사용자와 사내 여러 팀에서 들어오는 수많은 요청 중 무엇을 실행하고 무엇을 보류할지 논의하는 데 유용하다. - 아이디어의 선호도뿐 아니라 시간과 자원에 대한 인식까지 함께 드러난다. ## 얼라인먼트 스케일로 의견과 확신의 정도 확인하기 - 팀이 제품 방향이나 작업을 이끌어 갈 주장과 신념을 먼저 정한다. - 각 구성원은 FigJam의 프로필 스탬프를 척도 위에 배치해 자신의 동의 정도나 확신을 표시한다. - 구성원은 댓글로 배경과 우려를 설명하고, 의견 차이를 토론한다. - 이를 통해 찬반 여부만 확인하는 것이 아니라 다음을 파악할 수 있다. - 어떤 결정에 팀의 확신이 높은지 - 의견이 갈리는 지점은 무엇인지 - 추가 조사나 논의가 필요한 부분은 어디인지 ## 상태 보고를 넘어서는 주간 스탠드업 - PM 팀의 주간 스탠드업은 업무 진행 상황만 공유하는 자리가 아니다. - 임원진 업데이트와 PM들의 업무 공유 외에도 개인적인 상황과 심리적 상태를 나눈다. - 각 PM은 FigJam에서 다음 질문에 답한다. 1. 개인적으로 최근 어떤 생각을 하고 있는가? 2. 업무 또는 개인적으로 걱정되거나 기대되는 것은 무엇인가? 3. 고민 중인 어렵거나 흥미로운 문제는 무엇인가? - 이러한 방식은 단순한 태스크 추적을 넘어 팀원 간 공감과 신뢰를 만든다. - 동시에 다른 PM이 해결책을 제안하거나 도움을 줄 수 있는 문제를 조기에 발견하게 한다. ## 실무에 적용할 때의 시사점 - 브레인스토밍 후에는 반드시 결정 사항과 실행 항목을 문서화한다. - 우선순위 논의에서는 단순 투표 대신 제한된 예산이나 시간을 배분하게 하면 실제 투자 의향을 확인할 수 있다. - 의견 차이를 숨기지 말고 척도나 댓글로 시각화해 추가 논의가 필요한 부분을 찾는다. - 정기 회의에 업무 외 고민과 해결이 필요한 문제를 공유하는 시간을 포함하면 협업과 팀 신뢰를 함께 강화할 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

FigJam에서 협업

FigJam은 브레인스토밍 도구를 넘어 원격 환경에서 회의, 협업, 피드백 정리, 팀 문화 활동을 지원하는 가상 공간으로 활용될 수 있다. Figma는 스탠드업, 사용자 조사 결과 종합, 회고, 친목 활동에 FigJam을 사용하며, 스티키 노트와 템플릿, 타이머를 통해 구성원 모두의 참여와 진행 관리를 돕는다. 결론적으로 FigJam은 비동기적 기록과 실시간 소통을 결합해 팀의 맥락 공유와 연결감을 강화한다. ## 원격 협업을 위한 새로운 업무 공간 - Figma는 1년 넘게 원격 근무를 하면서 FigJam을 온라인 활동과 회의의 중심 공간으로 활용했다. - 초기에는 브레인스토밍과 아이디어 발상용으로 설계했지만, 이후 다음과 같은 용도로 확장했다. - 데일리 스탠드업 - 사용자 조사 및 결과 종합 - 회고 - 오프사이트 행사 - 팀 친목 및 놀이 - 최근 추가된 타이머는 팀 전체가 활동을 함께 시작·중지·일시 정지할 수 있게 해 회의의 흐름과 집중도를 높인다. ## 브라우저에서 진행하는 데일리 스탠드업 - Figma의 Editor Platform 팀은 매일 FigJam에서 스탠드업을 진행한다. - 팀원들은 스티키 노트에 다음 내용을 기록한다. - 현재 진행 중인 업무 - 최근 완료한 작업 - 해결이 필요한 장애물과 문제 - 매일 하나의 파일을 별도 기록으로 남기기 때문에 날짜별 진행 상황을 추적하기 쉽다. - 실시간으로 같은 파일에 모이면 팀원들이 서로의 업무 맥락을 빠르게 파악하고 필요한 문제 해결을 논의할 수 있다. ## 사용자 피드백을 시각적으로 종합하기 - 기존 Figma 연구팀은 스프레드시트로 사용자 피드백을 관리했다. - 스프레드시트 방식의 문제점은 다음과 같았다. - 피드백에 질문하려면 셀 댓글을 사용해야 했다. - 자료 관리와 검색이 어려웠다. - 실시간 회의 외에는 전체적인 그룹 인사이트를 도출하기 힘들었다. - 회의 시간이 길어지고 스프레드시트 검색에 많은 시간이 들었다. - FigJam에서는 사용자 의견을 기록하는 동시에 여러 직군의 구성원이 직접 댓글을 달고 질문하며 자료를 함께 해석할 수 있다. - 연구 보고서의 내용을 사용자 유형별 매트릭스에 배치하고, 디자인·엔지니어링·제품 리더들이 회의 전에 각자 자료를 읽고 의견을 작성하도록 했다. - 회의 전 개별적으로 생각을 정리하게 함으로써 회의에서는 단순한 정보 공유보다 집단적 해석과 논의에 집중할 수 있다. ## 회고에서 모든 구성원의 의견 반영 - Figma의 여러 팀은 다음 항목을 포함한 회고 템플릿을 사용한다. - 잘된 점 - 개선할 점 - 동료에 대한 칭찬 - 앞으로 만들고 싶은 것 - 스티키 노트는 말로 의견을 내는 데 익숙하지 않은 사람도 쉽게 참여하게 한다. - 각 의견이 화면에 자동으로 표시되므로, 다양한 참여 수준을 가진 구성원의 목소리를 한눈에 확인할 수 있다. - 엔지니어링·디자인·제품 관리자가 함께한 회고에서는 각 주제에 대해 15분씩 스티키 노트를 작성했다. - 타이머는 특정 논의가 지나치게 길어지는 것을 막고 회고를 일정한 속도로 진행하도록 돕는다. ## 팀 문화와 친목 활동 - FigJam은 업무 외 활동에도 활용됐다. - 생일 카드 만들기 - 스피드 드로잉 대회 - 보드게임 - 팀 행사와 온라인 모임 - Figma 마케팅팀은 전문 만화가와 함께 라마를 그리는 시간을 가졌고, Pen 도구를 사용해 온라인에서 동시에 그림을 그렸다. - 이러한 활동은 원격 근무 환경에서도 구성원 간 유대감과 소속감을 유지하는 데 도움을 준다. ## 실용적인 활용 방법 팀의 목적에 맞는 템플릿을 사용해 스탠드업, 회고, 사용자 조사, 아키텍처 다이어그램 등을 구성하고, 활동별 제한 시간을 타이머로 설정하면 효과적이다. 특히 회의 전에 구성원이 각자 의견을 작성하게 하면 실시간 회의 시간을 줄이면서도 더 폭넓은 참여와 깊이 있는 논의를 이끌어낼 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Inside Figma: 피그마를

Figma 팀은 Figma를 제품 디자인뿐 아니라 브레인스토밍, 팀 활동, 원격 리서치 등 다양한 협업에 활용한다고 소개합니다. 핵심은 특정 숙련도나 직무에 상관없이 누구나 쉽게 참여하도록 시각적 템플릿과 구조화된 프레임워크를 사용하는 것입니다. 특히 영감 수집과 연구 참여를 자연스럽게 만드는 방법을 통해 창의성과 협업을 촉진합니다. ## 다양한 직무에서 활용하는 Figma - 엔지니어링, 제품, 디자인, 리서치 등 여러 팀이 Figma를 업무 전반에 사용합니다. - 제품 디자인 외에도 다음과 같은 용도로 활용합니다. - 팀 빌딩 활동 - 원격 사용자 리서치 - 브레인스토밍과 아이디어 발상 - 협업을 통한 창작 작업 - 라이브스트림에서는 키보드 단축키, 빠른 작업 방법, 블렌드 모드, 이징 커브 등을 소개했습니다. - Figma의 장점은 다양한 숙련도의 사용자가 각자의 방식으로 활용할 수 있다는 점입니다. ## 마인드맵 스케치북으로 아이디어 확장 브랜드 디자이너 Remilla Ty는 영감을 모으고 여러 방향을 탐색하기 위한 ‘마인드맵 스케치북’ 방법을 소개합니다. - **Prompt** - 프로젝트 이름이나 작업의 핵심 문장을 적습니다. - **Image** - 작업에 영감을 주는 이미지를 수집합니다. - **Keywords** - 이미지와 관련된 단어나 문구를 적고, 이를 프로젝트의 프롬프트와 연결합니다. - 이미지와 키워드 사이의 공통 주제를 찾으면 새로운 크리에이티브 콘셉트로 발전시킬 수 있습니다. - Figma 브랜드 팀은 Figma Community의 브랜딩 방향을 탐색할 때 이 프레임워크를 사용했습니다. - 이 과정에서는 정답이나 오답을 판단하기보다 다양한 방향을 열어 두는 것이 중요합니다. ## 리스트와 무드 보드로 브랜드 방향 구체화 두 번째 방법은 프로젝트를 언어적으로 정리한 뒤 시각 자료로 확장하는 방식입니다. - 리스트를 다음 세 부분으로 나눕니다. - **Prompt:** 현재 작업 중인 내용을 있는 그대로 설명 - **Beyond:** 프로젝트의 추상적인 의미나 한 단계 확장된 해석 - **Look and feel:** 결과물을 본 사람이 느끼기를 원하는 분위기 - 작성한 내용에서 반복되는 테마와 키워드를 뽑아 무드 보드에 배치합니다. - 관련 이미지와 색상 팔레트를 추가해 여러 요소가 어떻게 조화를 이루는지 확인합니다. - 마지막으로 콘셉트 문장을 작성해 브랜드 아이덴티티의 방향을 정리합니다. - Figma 팀은 Maker Week의 새로운 방향을 탐색할 때 이 방법을 활용했습니다. - 이러한 프레임워크는 팀원들이 프로젝트를 어떻게 이해하고 있는지 공유하는 데도 도움이 됩니다. ## 창작 과정에서 ‘몰입 상태’ 만들기 - 브레인스토밍 초기에 결과의 완성도나 방향의 정답 여부를 판단하지 않습니다. - 이미지, 단어, 감정, 색상 등 다양한 재료를 자유롭게 모으며 사고를 확장합니다. - 시각적으로 아이디어를 공유하면 팀원들의 관심사와 프로젝트에 대한 관점을 빠르게 파악할 수 있습니다. - 목표는 올바른 답을 즉시 찾는 것이 아니라, 가장 창의적으로 생각할 수 있는 ‘몰입 상태’에 들어가는 것입니다. ## 리서치를 편안하게 만드는 활동 리서처 Nannearl Brown은 Figma를 활용해 연구 참여자가 부담을 덜 느끼도록 연구 과정을 구성한다고 설명합니다. - 연구 참여자가 자신의 정보를 공유할 때 편안함을 느끼도록 사전 활동과 인터랙티브한 연습을 제공합니다. - 연구 시작 전에 ‘Figma 트레이딩 카드’를 사전 과제로 보낼 수 있습니다. - 트레이딩 카드에는 다음과 같은 질문이 포함됩니다. - 가장 좋아하는 Figma 기능 - Figma를 사용하는 방식 - 참여자에 관한 개인적인 질문 - 이 활동은 참여자가 자신의 경험을 미리 정리하게 하고, 본격적인 연구 세션에 자연스럽게 참여하도록 돕습니다. Figma를 단순한 디자인 제작 도구로 보기보다, 아이디어를 구조화하고 팀의 생각을 공유하는 협업 공간으로 활용하는 것이 이 글의 실용적인 제안입니다. 처음에는 마인드맵이나 무드 보드 템플릿처럼 부담이 적은 방식부터 도입하고, 결과보다 탐색과 참여를 우선하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)