Search
Name
요약
태그
🧑🏻⚕️ 요약자
공유 날짜
is_오픈채팅
is_커리어리
is_HOLIX
타겟 오디언스
디자인 산출물을 개발자에게 완벽하게 전달(Hand-off)하는 방법
Open
핸드오프 용어 짚고가기
- 누가: 디자이너가
- 무엇을: 디자인 완료 후 취해야 하는 모든 작업
- 목표: 개발자가 구현을 시작하는데 필요한 모든 정보를 전달
디자인 스케치를 개발팀에 넘겨주고 디자이너가 구상한 대로 잘 돌아가게끔 하는 게 왜 그렇게 어려운 일일까요? 몇 가지 이유가 있습니다.
1) 커뮤니케이션 부족
협업을 시작하기까지 딜레이가 길어지는 실수가 흔합니다. 완벽한 디자인 결과물을 개발팀에 전하려고들 하지만, 개발자가 처음부터 참여했더라면 좀 더 시행착오를 줄일 수 있었을 것입니다.
모든 관련 당사자가 초대된 Slack 전용 채널을 만드세요.
이들과 하는 정기적인 회의를 계획하세요.
2) 불충분한 정보
사실 단순한 Figma UI 이미지가 제공하는 것보다 훨씬 더 많은 정보가 있어야 사물의 흐름, 움직임, 사용자 여정 단계 등을 알 수 있습니다.
트리거 및 사용자 여정의 여러 단계에 대한 추가 정보를 공유하세요.
디자인 도구의 상태 업데이트를 사용하여 디자인의 어떤 부분이 진행 중, 일시 중지 또는 완료되었는지 보여줍니다.
3) 불명확한 스펙 설명
Zeplin, Sketch, Figma 등의 툴로 최신 디자인 산출물과 목업을 온라인에 업로드함으로써 개발자는 UI에 쉽게 접근할 수 있습니다.
Photoshop이나 Illustrator와 같은 툴을 쓰고 있다면 적절한 클라우드 기반 UI 소프트웨어로 전환하십시오.
설계 시스템이 구현되고 선택한 플랫폼에서 쉽게 사용할 수 있는지 확인하십시오.
4) 디자인 시스템 부재
적절한 디자인 시스템이 없는 경우, 불필요한 잦은 반복이 발생할 수 있습니다. 제약이 없어 너무 창의적인 결과물이 나올 수 있고, 시각적으로 일관되는 최종 제품을 만들기가 어려워집니다. 디자인 시스템을 사용하면 일관성을 유지하면서 규모에 맞게 공동으로 디자인할 수 있습니다.
개발자를 위한 스타일 가이드를 구축하고 디자인 시스템으로 전환하십시오.
디자이너가 항상 어떤 요소를 만들어야 하고 누락된 항목이 없는지 알 수 있도록 체크리스트를 만드십시오.
5) 팀 간의 지식 격차
단순히 디자이너와 개발자가 서로가 말하는 내용을 모르는 경우가 종종 있습니다. 정기적인 지식 공유를 위한 시간과 공간을 만드는 것은 더 나은 제품과 더 행복한 동료의 관점에서 성과를 거둘 수 있는 투자입니다. 다른 팀의 답변과 행동 뒤에 숨겨진 "이유"를 이해하면 마찰과 좌절을 줄이고 더 나은 솔루션을 위한 길을 열 수 있습니다.
"학습" 또는 이와 유사한 이름의 Slack 채널을 만들고 모든 사람이 흥미로운 읽기, 비디오 및 팟캐스트를 공유하도록 권장합니다.
프로젝트가 완료된 후 피드백 및 후속 조치를 위한 프로세스를 만들어 모든 사람이 잘 된 부분과 개선할 수 있는 부분에서 모두 배울 수 있도록 합니다.
6) 사일로 현상과 팀스피릿 부족
모든 사람이 모든 아이디어를 환영하고 경청한다고 느끼는 심리적 안전의 견고한 기반을 만들도록 하십시오.
7) UX Writing 최종 결정이 프로세스 상에서 너무 뒤에 있음
디자인 구축을 시작하기 훨씬 전에 항상 카피라이터를 프로젝트에 참여시키십시오.
8) 디자인한 애니메이션이 제대로 수행되지 않음
필요한 경우 대화형 프로토타입을 만들어 사물의 흐름과 이동 방식을 정확히 보여줍니다.
* 이 글은 핸드오프를 어렵게 하는 8가지 원인과 총 40가지(8×5) 솔루션을 담고 있습니다. 짧은 요약글이라 일부만 소개드렸습니다만 원문을 살펴보시기를 추천드립니다! 이해하기 쉬우며 현실적인 해결책을 다수 제시하고 있습니다.
디자인 스케치를 개발팀에 넘겨주고 디자이너가 구상한 대로 잘 돌아가게끔 하는 게 왜 그렇게 어려운 일일까요? 몇 가지 이유가 있습니다.
1) 커뮤니케이션 부족
협업을 시작하기까지 딜레이가 길어지는 실수가 흔합니다. 완벽한 디자인 결과물을 개발팀에 전하려고들 하지만, 개발자가 처음부터 참여했더라면 좀 더 시행착오를 줄일 수 있었을 것입니다.
모든 관련 당사자가 초대된 Slack 전용 채널을 만드세요.
이들과 하는 정기적인 회의를 계획하세요.
2) 불충분한 정보
사실 단순한 Figma UI 이미지가 제공하는 것보다 훨씬 더 많은 정보가 있어야 사물의 흐름, 움직임, 사용자 여정 단계 등을 알 수 있습니다.
트리거 및 사용자 여정의 여러 단계에 대한 추가 정보를 공유하세요.
디자인 도구의 상태 업데이트를 사용하여 디자인의 어떤 부분이 진행 중, 일시 중지 또는 완료되었는지 보여줍니다.
3) 불명확한 스펙 설명
Zeplin, Sketch, Figma 등의 툴로 최신 디자인 산출물과 목업을 온라인에 업로드함으로써 개발자는 UI에 쉽게 접근할 수 있습니다.
Photoshop이나 Illustrator와 같은 툴을 쓰고 있다면 적절한 클라우드 기반 UI 소프트웨어로 전환하십시오.
설계 시스템이 구현되고 선택한 플랫폼에서 쉽게 사용할 수 있는지 확인하십시오.
4) 디자인 시스템 부재
적절한 디자인 시스템이 없는 경우, 불필요한 잦은 반복이 발생할 수 있습니다. 제약이 없어 너무 창의적인 결과물이 나올 수 있고, 시각적으로 일관되는 최종 제품을 만들기가 어려워집니다. 디자인 시스템을 사용하면 일관성을 유지하면서 규모에 맞게 공동으로 디자인할 수 있습니다.
개발자를 위한 스타일 가이드를 구축하고 디자인 시스템으로 전환하십시오.
디자이너가 항상 어떤 요소를 만들어야 하고 누락된 항목이 없는지 알 수 있도록 체크리스트를 만드십시오.
5) 팀 간의 지식 격차
단순히 디자이너와 개발자가 서로가 말하는 내용을 모르는 경우가 종종 있습니다. 정기적인 지식 공유를 위한 시간과 공간을 만드는 것은 더 나은 제품과 더 행복한 동료의 관점에서 성과를 거둘 수 있는 투자입니다. 다른 팀의 답변과 행동 뒤에 숨겨진 "이유"를 이해하면 마찰과 좌절을 줄이고 더 나은 솔루션을 위한 길을 열 수 있습니다.
"학습" 또는 이와 유사한 이름의 Slack 채널을 만들고 모든 사람이 흥미로운 읽기, 비디오 및 팟캐스트를 공유하도록 권장합니다.
프로젝트가 완료된 후 피드백 및 후속 조치를 위한 프로세스를 만들어 모든 사람이 잘 된 부분과 개선할 수 있는 부분에서 모두 배울 수 있도록 합니다.
6) 사일로 현상과 팀스피릿 부족
모든 사람이 모든 아이디어를 환영하고 경청한다고 느끼는 심리적 안전의 견고한 기반을 만들도록 하십시오.
7) UX Writing 최종 결정이 프로세스 상에서 너무 뒤에 있음
디자인 구축을 시작하기 훨씬 전에 항상 카피라이터를 프로젝트에 참여시키십시오.
8) 디자인한 애니메이션이 제대로 수행되지 않음
필요한 경우 대화형 프로토타입을 만들어 사물의 흐름과 이동 방식을 정확히 보여줍니다.
* 이 글은 핸드오프를 어렵게 하는 8가지 원인과 총 40가지(8×5) 솔루션을 담고 있습니다. 짧은 요약글이라 일부만 소개드렸습니다만 원문을 살펴보시기를 추천드립니다! 이해하기 쉬우며 현실적인 해결책을 다수 제시하고 있습니다.커뮤니케이션
일하는 방법
협업
2022/06/22
신입
주니어
고객 프로필을 만드는 10가지 쉬운 단계
Open
고객에게 효과적으로 서비스를 제공하고 고객의 요구 사항을 충족하려면 고객 프로파일링이 필수적
고객 프로파일링이란?
- 인구/심리 통계, 구매 패턴 등 요소로 고객을 설명하는 행위
- 제품이나 서비스를 구매할 가능성이 가장 높은 사람들을 식별
고객 프로파일링이 왜 중요한가요?
- 과거에 누가 제품을 구매했는지에 따라 미래에 누가 구매할 가능성이 높은지 알 수 있음
- 고객 프로필이 너무 광범위하면 제품의 가치가 희석됨
고객 프로파일링 장점
- 더 적합한 잠재 고객을 식별
- 고객 확보 비용(CAC)을 낮춤
- 고객에게 더 나은 서비스 제공
- 고객 이탈을 줄임
고객 프로필 데이터
- 인구 통계 (나이, 성별, 직위, 소득, 교육 수준, 가족 상태, 소속 회사 규모, 산업 속성)
- 심리 통계 (생활 양식, 목표, 고통, 버릇, 가치, 흥미)
- 행동 (관여도, 구매 준비, 구매 내역, 제품 사용정보, 만족도, 충성도, 주의 요망)
- 지리 (도시, 지역, 국가)
고객 프로필 만드는 방법 10단계
1. 고객 프로필 템플릿을 사용합니다. (원글에서 제공)
2. 고객 프로파일링 소프트웨어를 선택하십시오.
- CRM, 피드백 관리, 분석 툴
3. 인구 통계를 파헤쳐 보세요.
4. 고객 피드백을 수집합니다.
- 고객이 기꺼이 전화를 예약할 의사가 있다면 충성도가 높은 사용자
5. 고객 여정 지도를 검토하세요.
- 고객 여정 지도는 고객이 회사의 목표를 달성하기 위해 거쳐야 하는 모든 접점을 설명하는 문서
- 고객의 요구 사항, 과제 및 목표를 이해함으로써 고객이 비즈니스에서 원하는 것이 무엇인지 더 잘 이해
- 지도의 각 정류장에 대해 고객을 인터뷰하여 이 단계를 한 단계 더 발전 가능
6. 우리 비즈니스가 해결하려는 문제에 집중하세요.
- 데이터가 너무 많으면 길을 잃기 쉽습니다.
- 현재 사용자와 그들의 행동을 자세히 살펴보세요.
7. 상황에 맞는 세부 정보를 검토합니다.
- 올해 목표는 무엇입니까?
- 그들에게 완벽한 세상은 어떤 모습일까요?
- 그들은 오늘날 어떻게 문제를 해결하려고 합니까?
8. 산업을 이해하세요.
- 업계를 이해하면 브랜드 아이덴티티를 정의하는 데도 도움이 됩니다.
- 눈에 띄려면 제품과 서비스를 차별화할 방법을 찾아야 합니다.
9. 페르소나를 구축합니다.
10. 고객 페르소나를 분석하고 반복합니다.
PM/PO
GTM
2022/06/08
기획자
SaaS 제품 담당자
엔터프라이즈 모바일 앱의 올바른 UX를 위한 6가지 조언
Open
모바일 앱은 데스크탑 앱의 축소 버전이 아니다.
- 모바일 앱은 독립적인 프로세스로 진행되어야 함. 모바일 사용자의 요구를 파악하고 적절한 기능을 충족 시켜야함.
모바일 앱 사용자는 데스크탑 사용자는 동일 하면서도 다르다.
- 모바일 사용자는 작업 지향성 (task oriented)이 매우 높음. 즉 특정 작업을 신속하게 수행하려함.
- 여러 작업을 탐색, 학습 혹은 수행하려는 데스크탑 앱과 달리 모바일 앱은 달성하고자하는 명확한 목표가 있음.
- 목표가 분산되지 않도록 스텝, 클릭, 탭 수를 최소로 유지.
기능이 가치를 제공하는지 확인하기.
- 데스크탑 버전의 엔터프라이즈 앱은 매우 복잡하거나 사용 가능한 기능과 사용되지 않는 기능을 모두 갖추고 있음.
- 모든 기능을 항상 제공하는 것이 아니라 중요한 가치만 제공할 것.
엔터프라이즈 모바일 앱은 MVP 과정이 적합하다.
- 기본적이고 가장 중요한 기능을 갖춘 간단한 앱을 설계해 출시하고 사용성을 테스트해서 실행 가능성을 측정할 것.
- 범위를 단순하게 유지하면서 사용자의 반응을 보며 아이디어를 검증할 수 있음.
UX가 먼저, 그리고 UI
- 엔터프라이즈 앱 사용 환경 구축 시 적절한 백엔드 접속, 오프라인 지원 등 전체적인 신뢰성과 더불어 UI를 고려해야함
- 사용자의 불만을 방지하기 위해 UI보다 앱 퍼포먼스를 먼저 고려해야할 수도 있음.
- 모바일 앱은 항상 사용 가능해야하며 오프라인에서는 중요한 기능을 수행해야할 수도 있음.
성능을 측정할 수 있는 매개 변수 설정
- 비지니스 특성에 따라 측정이 가능하며 엔터프라이즈 앱으로 달성하고자 하는 목표와 관련된 KPI를 설정할 것.
- 사용자의 앱 체류 시간 및 로그인 횟수는 관련이 없을 수 있음.
- 응답 시간 단축 및 작업 완료 시간 단축을 KPI와 비교하기 시작하면 더 큰 그림에서 파악 가능함.마인드셋
UX
프로덕트 전략
2022/06/07
주니어
중니어
[Relate] Shape Up: Relate 팀의 제품 개발 프로세스
Open
Relate 팀이 업무 문화에서 많이 참고하고 있는 Basecamp의 제품 개발 프로세스를 소개합니다.
요약
• Shape Up 프로세스는 자율성을 기반으로한 프로젝트 개발에 대한 가이드라인이라고 할 수 있습니다.
• 제품 팀에게 프로젝트의 목표를 전달하되, 프로젝트를 성공적으로 개발하기 위한 의사결정과 진행은 제품 팀이 결정합니다.
• 고객에게 유의미한 프로젝트를 전달하기 위해 더 긴 기간의 개발 주기를 가지고, 매 개발 주기마다 할 일에 다한 의사결정을 새로 합니다.
• 개별 제품 개발 관계자들은 높은 자율성으로 일해야 하기 때문에 모두가 고객과 문제에 대해 잘 이해하고 있어야 하고, 실력이 뛰어나거나 빠르게 학습할 수 있어야 합니다.
Shape Up의 특징
6주 개발 + 2주 쿨다운 사이클
• 스크럼에 비해 더 긴 프로젝트 주기로, 유의미한 기능을 만들만큼 긴 기간과 관리할 수 있을만큼 짧은 기간 사이
명세가 아닌 형태를 전달
• 제품 팀에게 구체적인 명세가 아닌 적절히 추상화된 Shape을 전달
제품 팀이 책임지게 함
• 제품 팀에게 Shape이 배정되고 나면, 해당 Shape에 대한 실행과 커뮤니케이션은 제품 팀이 책임을 가져감
Shape Up 딘계
1. Shaping → 2. Betting → 3. Building
Shaping
제품 팀에게 프로젝트의 큰 틀과 완성 기준을 제시하되, 디테일은 제시하지 않습니다.
좋은 Shape은 충분히 추상적이지만(Rough), 문제를 해결할 수 있어야 하고(Solved), 프로젝트가 달성하거나 달성하지 않아야 할 목표가 확실해야 합니다(Bounded)
Betting
주요 의사결정자들이 올라온 Shape 들의 우선순위를 평가하여, 어떤 프로젝트에 리소스를 투자할 지 결정합니다.
Basecamp는 개발 6주, 쿨다운 2주의 8주 주기를 구성하지만, Relate은 초기 스타트업이기 때문에 개발 3주, 쿨다운 1주로 4주 주기를 적용하고 있습니다.
Relate은 100% 리모트 팀이기에 2주보다 더 긴 주기로 개발을 진행하는 것이 더 유리합니다. 불확실성이 높은 초기에 실시간 커뮤니케이션을 몰아서 하고 나면 해야 할 일이 명확해지기 때문에 비동기 커뮤니케이션으로도 충분하기 때문입니다.
Building
제품 팀은 Shape의 범위 안에서 실행을 위한 구체적인 Task 정의부터, 개발을 완료하고 테스트 하여 실제 제품에 반영시키는 지점까지의 모든 과정을 직접 결정하고 책임집니다.
그 과정에서 디자이너, 프론트, 백엔드 개발자들은 핵심 과제를 먼저 이해하고 확인할 수 있도록 노력해야 합니다.
개발을 진행하면서 관계있는 Task끼리 Scope으로 묶고, 더 불확실성이 높은 Scope의 우선순위를 높이면서 진행하는 방식으로 일합니다. 아직 알지 못하는 것들을 인정하고 계획을 세우면서 진행하기 때문에 개발 상황을 더 정확하게 예측할 수 있습니다.
요약
• Shape Up 프로세스는 자율성을 기반으로한 프로젝트 개발에 대한 가이드라인이라고 할 수 있습니다.
• 제품 팀에게 프로젝트의 목표를 전달하되, 프로젝트를 성공적으로 개발하기 위한 의사결정과 진행은 제품 팀이 결정합니다.
• 고객에게 유의미한 프로젝트를 전달하기 위해 더 긴 기간의 개발 주기를 가지고, 매 개발 주기마다 할 일에 다한 의사결정을 새로 합니다.
• 개별 제품 개발 관계자들은 높은 자율성으로 일해야 하기 때문에 모두가 고객과 문제에 대해 잘 이해하고 있어야 하고, 실력이 뛰어나거나 빠르게 학습할 수 있어야 합니다.
Shape Up의 특징
6주 개발 + 2주 쿨다운 사이클
• 스크럼에 비해 더 긴 프로젝트 주기로, 유의미한 기능을 만들만큼 긴 기간과 관리할 수 있을만큼 짧은 기간 사이
명세가 아닌 형태를 전달
• 제품 팀에게 구체적인 명세가 아닌 적절히 추상화된 Shape을 전달
제품 팀이 책임지게 함
• 제품 팀에게 Shape이 배정되고 나면, 해당 Shape에 대한 실행과 커뮤니케이션은 제품 팀이 책임을 가져감
Shape Up 딘계
1. Shaping → 2. Betting → 3. Building
Shaping
제품 팀에게 프로젝트의 큰 틀과 완성 기준을 제시하되, 디테일은 제시하지 않습니다.
좋은 Shape은 충분히 추상적이지만(Rough), 문제를 해결할 수 있어야 하고(Solved), 프로젝트가 달성하거나 달성하지 않아야 할 목표가 확실해야 합니다(Bounded)
Betting
주요 의사결정자들이 올라온 Shape 들의 우선순위를 평가하여, 어떤 프로젝트에 리소스를 투자할 지 결정합니다.
Basecamp는 개발 6주, 쿨다운 2주의 8주 주기를 구성하지만, Relate은 초기 스타트업이기 때문에 개발 3주, 쿨다운 1주로 4주 주기를 적용하고 있습니다.
Relate은 100% 리모트 팀이기에 2주보다 더 긴 주기로 개발을 진행하는 것이 더 유리합니다. 불확실성이 높은 초기에 실시간 커뮤니케이션을 몰아서 하고 나면 해야 할 일이 명확해지기 때문에 비동기 커뮤니케이션으로도 충분하기 때문입니다.
Building
제품 팀은 Shape의 범위 안에서 실행을 위한 구체적인 Task 정의부터, 개발을 완료하고 테스트 하여 실제 제품에 반영시키는 지점까지의 모든 과정을 직접 결정하고 책임집니다.
그 과정에서 디자이너, 프론트, 백엔드 개발자들은 핵심 과제를 먼저 이해하고 확인할 수 있도록 노력해야 합니다.
개발을 진행하면서 관계있는 Task끼리 Scope으로 묶고, 더 불확실성이 높은 Scope의 우선순위를 높이면서 진행하는 방식으로 일합니다. 아직 알지 못하는 것들을 인정하고 계획을 세우면서 진행하기 때문에 개발 상황을 더 정확하게 예측할 수 있습니다.일하는 방법
실 사례
경험 공유
2022/05/31
중니어
시니어
엔터프라이즈 스타트업, 애자일 다시 생각하기
Open
Flatiron Health의 CMO이자 제품전략 SVP인 Ogi Kavazoic가 B2B 제품 조직에 대한 생각을 인터뷰를 통해 나눈 내용입니다. 모든 내용이 정답이고, 모든 상황에 맞는 것은 아니지만, B2B 조직이 제품을 만들 때 참고하기 좋습니다.
<문제>
- 많은 제품 리더들이 B2C앱 플레이북으로 엔터프라이즈 소프트웨어를 개발하려고 함
- 하지만 제품 개발 사이클과 고객 관계가 (B2B와) 근본적으로 다름
주로 2가지 잘못된 방향으로 빠짐
1. 명확한 제품 비전을 희생하면서, 애자일과 사랑에 빠짐
- 스프린트와 단기 계획만을 강조하고, 더 큰 제품 비전이 부족해짐
- 이는 고객팀과 애자일 제품팀의 마찰로 이어짐
- 세일즈 reps: "내년에 뭘 만들지 고객이 물어보는데 어떤가요?"
- PM: "확실하지 않아요. 우리는 애자일해요."
- 제품 중심 팀은 1-3개월 단위로 일처리를 하는데 익숙함.
- 회사에서 긴장(tension)이 빠르게 생김.
2. 시장 역학을 더 잘 이해하는 대신, 사용자 연구에 집중함
- B2B 세상은, 구매 결정을 내릴 때 사용자(users)는 목소리가 그리 크지 않을 수 있다.
- 사용자의 목소리보다, 시장의 목소리에 귀기울여야한다.
- 기존 고객이 만족하는, 사용자 경험 관점에서 최고의 제품이어도, 신규 딜을 놓칠 수 있다.
- 알고보니 놓친 고객은 '시장이 어디로 가는지, 다음 제품은 어때야하는지' 더 큰 비전을 제시하는 다른 제품 쪽으로 넘어감.
<솔루션>
- 오해할 수 있지만, 애자일 개발과 장기 계획은 상호 배타적이지 않다.
- 물론 애자일은 성공적인 사용자 경험을 만드는데 정말 좋다.
- 그러나, 사용자 경험과 전체 제품 로드맵은 서로 분리해야함.
핵심은
1. 장기적인 제품 비전을 분명히 하고
2. 세부 사항에 관해서는 유연성의 문화를 확립하는 것
상위레벨 로드맵의 적당한 타임라인은 18-24개월
- 해당 문서는 비전 로드맵으로 불림
짧은 개발 로드맵도 필요한데, 이는 1-3개월 정도로, 기능 단위로 나뉨
장기 플랜과 로드맵
- 회사 전체가 비전을 이해하고 소유권을 느껴야함.
- 영업사원, 제품 마케팅 팀의 분석 등을 취합해 시장 요구사항 문서를 만듬.
- 이 문서는 제품 리더십으로 이동해서 현재 상태의 기술 스택에서 실행 가능하고 호환 가능한게 무엇인지 결정.
- 이렇게 나온 비전 로드맵은 리더십 팀 → 회사 전체 순서로 검토 및 피드백을 두번 이상 거침.
- 광범위한 네트워크를 구축하고, 체계적인 방식으로 모든 사람의 의견을 얻는 것은, 모두가 이해하고 흥미롭고 동기 부여되는 제품 비전과 전략을 갖게 된다는 것.
개발 로드맵
- 제품 관리자와 엔지니어의 영역
- 다음 빌드에 적합한 기능 세트를 알아냄
- 확정이 되면 특정 기능을 기다릴 수 있는 주요 고객에게 알리고, 마케팅 팀에게 캠페인용 콘텐츠를 제공하거나, 고객 성공 팀에게 예정된 제품 변경 사항을 알리도록 허용함.
<고객을 믿어주세요.>
많은 신생 기업이 앞으로 1-2년의 내용을 공유하는것을 우려함.
- '고객이 목업 기능에 집착하면 어쩌지?'
- '생각이 바뀌면? 아무말도 하지 않는게 안전하지 않을까?'
하지만 대부분의 고객은 상황이 바뀌고 우선순위가 바뀔 수 있다는 점을 이해함.
더 중요한 것은 우리가 더 나은 솔루션을 찾을 수 있다는걸 이해함.
만족스러운 로드맵이 있다면 더 많은 고객과 공유하세요.
- 무엇이 반향을 일으키는지, 그렇지 않은 것을 살펴보세요.
- 만들어지기 전에 고객을 확보할 수도 있어요.
- 스타트업의 현금 흐름에 긍정적.
- 경쟁자의 공간을 미리 없애버릴 수도 있음.
고객 교육은 끝이 없습니다.
- 장기 로드맵을 진행하면서 고객이 기대하는 개발/기능에서 벗어날 수도 있음
- 이럴 때는 반드시 설명하고 새로운 접근 방식이 더 나은 이유를 가르쳐 주세요.
PM/PO
프로덕트 전략
프레임워크
2022/05/24
기획자
SaaS 제품 담당자
더 나은 일반적인 사용자 인터뷰를 하는 5가지 방법
Open
이 아티클은 개인적인 편견을 배제하고 사용자 행동에 대한 통찰력을 발견하는 질문을 하는 방법을 소개합니다. 사용자 인터뷰를 진행할 때 아래 5가지 질문을 하고 있지 않은지, 하고 있다면 필자가 제안하는 더 나은 질문을 하는 방법을 참고해보세요.
1) "어떤 문제가 있나요?"
- 사용자들은 대부분 자신이 갖고 있는 문제를 알지 못한다. 사용자들은 현재 상태에 익숙하기 때문에 자신의 문제가 사소하거나 실수라고 생각할 경우 공유하지 못한다. (실제로 사용성 테스트 중 참가자가 태스크를 완료하기 전에 오류를 겪었음에도 불가하고 서비스가 사용하기 쉽고 UX가 직관적이라고 했다.)
더 나은 방법: 관찰하고 간접적 질문을 해라
- "태스크를 어떻게 수행하는지 보여주세요"
- "마지막으로 X를 수행했을 때 시간이 얼마나 걸렸나요? 결과는 어떘나요? 결과에 만족하나요?"
- "이 태스크를 대신 수행할 수 있는 보조자가 있다면, 무엇을 알려주고 뭘 할 것인가요?"
2) "당신을 __ 라고 생각하나요? 당신은 __ 하는 사람인가요? (자체 평가 질문)"
- 우리의 뇌는 자신을 호의적으로 인식하도록 연결되어 있다. 따라서 자신이 말하는 것과 실제 행동 차이에 괴리가 생긴다.
더 나은 방법: 구체적인 행동에 대해 질문 해라
- "마지막으로 __ 한 경험을 말해 주세요. (ex. 오늘 마지막으로 본 콘텐츠를 생각하세요. 왜 관심이 갔나요? 왜 보기로 결정했나요?)"
- "당신은 (가치의 부합하는 행동)을 어떻게 하고 있나요?"
- "지난주에 몇번 __ (구체적인 행동)를 하셨나요?"
3) "__하시겠습니까?"
- 사람들은 선택을 강요 받을 땐 의견이 바뀔 수 있다.
더 나은 방법: 기존 행동에 대해 질문 해라
- "당신은 무얼 하려고 했나요? 이 문제/태스크를 더 쉽게 하려고 무엇을 하고 있나요?"
- 팁: 사용자한테 특정 태스크를 말하도록 요청하지 말고 자연스럽게 수행하는지 확인해라.
4) "어떤 기능을 원하세요?"
- 안타깝지만 사용자의 제안은 인식 가능 범위에 제한이 있다. 사용자는 아직 존재하지 않는 기능을 상상하는 디자이너나 기술자가 아니다.
더 나은 방법: 이유를 파헤쳐라.
- "무엇을 끝내려 하나요? 왜 중요한가요?"
- "현재 어떻게 하나요?"
- "우리가 제안한 기능을 언제, 어떻게 사용하고싶나요?"
5) "__에 동의하나요?"
- 선행 질문은 질문자의 가정이나 의견이 내제한다.
더 나은 방법: 질문은 간단하게 열린 형대로 유지하기.
- "__에 대해 어떻게 생각하나요?"
더 나은 방법: 관찰하고 간접적 질문을 해라
- "태스크를 어떻게 수행하는지 보여주세요"
- "마지막으로 X를 수행했을 때 시간이 얼마나 걸렸나요? 결과는 어떘나요? 결과에 만족하나요?"
- "이 태스크를 대신 수행할 수 있는 보조자가 있다면, 무엇을 알려주고 뭘 할 것인가요?"
2) "당신을 __ 라고 생각하나요? 당신은 __ 하는 사람인가요? (자체 평가 질문)"
- 우리의 뇌는 자신을 호의적으로 인식하도록 연결되어 있다. 따라서 자신이 말하는 것과 실제 행동 차이에 괴리가 생긴다.
더 나은 방법: 구체적인 행동에 대해 질문 해라
- "마지막으로 __ 한 경험을 말해 주세요. (ex. 오늘 마지막으로 본 콘텐츠를 생각하세요. 왜 관심이 갔나요? 왜 보기로 결정했나요?)"
- "당신은 (가치의 부합하는 행동)을 어떻게 하고 있나요?"
- "지난주에 몇번 __ (구체적인 행동)를 하셨나요?"
3) "__하시겠습니까?"
- 사람들은 선택을 강요 받을 땐 의견이 바뀔 수 있다.
더 나은 방법: 기존 행동에 대해 질문 해라
- "당신은 무얼 하려고 했나요? 이 문제/태스크를 더 쉽게 하려고 무엇을 하고 있나요?"
- 팁: 사용자한테 특정 태스크를 말하도록 요청하지 말고 자연스럽게 수행하는지 확인해라.
4) "어떤 기능을 원하세요?"
- 안타깝지만 사용자의 제안은 인식 가능 범위에 제한이 있다. 사용자는 아직 존재하지 않는 기능을 상상하는 디자이너나 기술자가 아니다.
더 나은 방법: 이유를 파헤쳐라.
- "무엇을 끝내려 하나요? 왜 중요한가요?"
- "현재 어떻게 하나요?"
- "우리가 제안한 기능을 언제, 어떻게 사용하고싶나요?"
5) "__에 동의하나요?"
- 선행 질문은 질문자의 가정이나 의견이 내제한다.
더 나은 방법: 질문은 간단하게 열린 형대로 유지하기.
- "__에 대해 어떻게 생각하나요?"UX
리서치
사용자 조사
가이드
2022/05/23
주니어
중니어
모두가 즐길 수 있는 디자인 검토 회의 만들기
Open
UX디자인 프로세스에서 건설적인 피드백은 매우 중요합니다. 하지만 이러한 피드백이 서로에게 오히려 스트레스를 주는 경우가 생길 수 있습니다.
이 글은 멋진 프레젠테이션을 하거나 이해 관계자의 마음을 얻는 방법에 대한 팁을 제공하기 위한 글이 아닙니다. 대신, 여기에서는 사전 준비가 필요하지 않고 비판에서 자유로운 새로운 아이디어를 공유 방식을 제안합니다. 만약 여러분이 피드백의 품질을 높이고 보다 유기적인 협업을 장려하며 모두가 즐기는 회의를 원하신다면 이 글이 도움이 될 것입니다.
기존의 디자인 검토 회의와 문제점
목적 : 디자이너가 각자의 작업을 발표하고 개선을 위한 아이디어를 얻는 것
참석자 : 제품 디자이너 외에도 마케팅, 모션 디자이너, 연구원, 카피 전략가 등이 참석
문제점 :
깔끔하고 내용이 충실한 발표 자료를 준비해야 하는 부담
디자이너는 원할 때 동료와 즉석에서 만나 더 나은 피드백을 수집하는 것을 선호
회의 스케줄로 인해 더 빠른 피드백이 필요한 경우가 많음
피드백이 항상 유용한 것은 아니었고, 때로는 프로젝트 전체에 의문을 제기하는 데 초점을 둠
우리의 방식은 협업을 위한 친근한 검토가 아닌, 심사위원 앞에서 무대를 선보이고 비평 받는 자리와 같았습니다.
새로운 검토 방식 - 디자인 오픈 아워
당신이 가진 것을 보여주세요
많은 시간이 걸리는 발표 준비 없이 문서화와 세부 사항이 정해진 프로젝트 막바지라면 가지고 있는 산출물을 그대로 보여줍니다. 포스트잇이나 메모장에 휘갈긴 아이디어의 스케치라도 환영입니다.
내가 필요한 것은?
나에게 도움이 되는 피드백을 얻으려면 회의에 참가한 모든 디자이너에게 어떤 종류의 피드백이 필요한지 알려야 합니다.
보여드리는 프로세스 마지막 단계에 대한 여러분의 참신한 아이디어가 필요합니다.
제시된 고객 진입점이 직관적이고 사용자에게 도움이 된다고 느끼시나요?
가설에 대한 두 가지 아이디어가 있습니다. 그중 여러분은 어느 것을 선호하고 그 이유는 무엇인가요? 제가 생각하지 못하고 있는 더 나은 해결책이 있을까요?
이 솔루션을 개선하는 데 도움이 될 수 있는 데이터나 모범 사례를 찾고 있습니다.
액티브 피드백* 주고받기
*액티브 피드백은 자기 아이디어를 스케치로 표현하고, 다른 디자인 사례를 게시하고, 칭찬 남기기 등 구성원 모두가 프로젝트 개선을 위해 참여하는 활동을 말합니다.
피그마에서 짧은 10분 동안 스케치를 한 후 각 디자이너는 툴킷(toolkit)을 복사하여 자신의 화면에서 작업을 시작합니다. 이 작업의 목표는 잘 디자인된 부분에 대한 피드백을 남기고 개선이 필요한 부분에 대해 각자의 아이디어를 소개하는 것입니다.
다음 단계는 모두가 각자의 아이디어를 설명하는 열린 토론입니다. 이제 우리의 관심사는 특정 디자이너의 작업을 비판하는 것이 아니라 집단 지성을 통해 새로운 디자인을 구축하는 것입니다.
새로운 규칙
피그마는 우리의 화이트보드다
원격 근무 환경에서 원활하게 협업할 수 있는 공간을 찾으세요.
다른 프로젝트도 내 것처럼
이 규칙은 새로운 문화를 정착시키기 위해 가장 중요한 부분입니다. 이는 모든 참가자가 단순히 남의 프로젝트를 판단하는 위치에서, 프로젝트를 공동 소유하는 일원으로 전환해야합니다.
프로젝트 전체에 의문을 제기하지 말 것
때로는 그런 의견도 필요하지만, 디자인 오픈 아워는 그런 비판을 위한 공간이 아닙니다. 누군가가 프로젝트를 소개할 때, 이미 그 정당성에 대한 검증이 있었다고 믿고 해당 디자이너와 협업하여 도움을 주는 데 집중해야 합니다.
최종 결정은 디자이너의 몫이다
누군가는 자기 생각이 옳다고 굳게 믿습니다. 하지만 최선의 결정이 무엇인지 판단하고 어떤 피드백을 수용할 것인지 선택하는 것은 디자인 당사자라는 믿음을 주어야합니다.
기존의 디자인 검토 회의와 문제점
목적 : 디자이너가 각자의 작업을 발표하고 개선을 위한 아이디어를 얻는 것
참석자 : 제품 디자이너 외에도 마케팅, 모션 디자이너, 연구원, 카피 전략가 등이 참석
문제점 :
깔끔하고 내용이 충실한 발표 자료를 준비해야 하는 부담
디자이너는 원할 때 동료와 즉석에서 만나 더 나은 피드백을 수집하는 것을 선호
회의 스케줄로 인해 더 빠른 피드백이 필요한 경우가 많음
피드백이 항상 유용한 것은 아니었고, 때로는 프로젝트 전체에 의문을 제기하는 데 초점을 둠
우리의 방식은 협업을 위한 친근한 검토가 아닌, 심사위원 앞에서 무대를 선보이고 비평 받는 자리와 같았습니다.
새로운 검토 방식 - 디자인 오픈 아워
당신이 가진 것을 보여주세요
많은 시간이 걸리는 발표 준비 없이 문서화와 세부 사항이 정해진 프로젝트 막바지라면 가지고 있는 산출물을 그대로 보여줍니다. 포스트잇이나 메모장에 휘갈긴 아이디어의 스케치라도 환영입니다.
내가 필요한 것은?
나에게 도움이 되는 피드백을 얻으려면 회의에 참가한 모든 디자이너에게 어떤 종류의 피드백이 필요한지 알려야 합니다.
보여드리는 프로세스 마지막 단계에 대한 여러분의 참신한 아이디어가 필요합니다.
제시된 고객 진입점이 직관적이고 사용자에게 도움이 된다고 느끼시나요?
가설에 대한 두 가지 아이디어가 있습니다. 그중 여러분은 어느 것을 선호하고 그 이유는 무엇인가요? 제가 생각하지 못하고 있는 더 나은 해결책이 있을까요?
이 솔루션을 개선하는 데 도움이 될 수 있는 데이터나 모범 사례를 찾고 있습니다.
액티브 피드백* 주고받기
*액티브 피드백은 자기 아이디어를 스케치로 표현하고, 다른 디자인 사례를 게시하고, 칭찬 남기기 등 구성원 모두가 프로젝트 개선을 위해 참여하는 활동을 말합니다.
피그마에서 짧은 10분 동안 스케치를 한 후 각 디자이너는 툴킷(toolkit)을 복사하여 자신의 화면에서 작업을 시작합니다. 이 작업의 목표는 잘 디자인된 부분에 대한 피드백을 남기고 개선이 필요한 부분에 대해 각자의 아이디어를 소개하는 것입니다.
다음 단계는 모두가 각자의 아이디어를 설명하는 열린 토론입니다. 이제 우리의 관심사는 특정 디자이너의 작업을 비판하는 것이 아니라 집단 지성을 통해 새로운 디자인을 구축하는 것입니다.
새로운 규칙
피그마는 우리의 화이트보드다
원격 근무 환경에서 원활하게 협업할 수 있는 공간을 찾으세요.
다른 프로젝트도 내 것처럼
이 규칙은 새로운 문화를 정착시키기 위해 가장 중요한 부분입니다. 이는 모든 참가자가 단순히 남의 프로젝트를 판단하는 위치에서, 프로젝트를 공동 소유하는 일원으로 전환해야합니다.
프로젝트 전체에 의문을 제기하지 말 것
때로는 그런 의견도 필요하지만, 디자인 오픈 아워는 그런 비판을 위한 공간이 아닙니다. 누군가가 프로젝트를 소개할 때, 이미 그 정당성에 대한 검증이 있었다고 믿고 해당 디자이너와 협업하여 도움을 주는 데 집중해야 합니다.
최종 결정은 디자이너의 몫이다
누군가는 자기 생각이 옳다고 굳게 믿습니다. 하지만 최선의 결정이 무엇인지 판단하고 어떤 피드백을 수용할 것인지 선택하는 것은 디자인 당사자라는 믿음을 주어야합니다.UX
경험 공유
일하는 방법
마인드셋
2022/05/20
주니어
중니어
기획자
토스의 프로덕트 매니저가 하는 일
Open
국내에서는 서비스 기획자, PO와 PM 직무가 많이 혼용되어 사용되고 있습니다. 도그냥님이 브런치에서 역사적으로 각 직무가 왜 생기게 되었는지, 어떻게 발전하고 있는지를 고찰한 K-Product ownder의 탄생론이란 글도 있습니다.
쿠팡에 이어 대한민국 스타트업계를 리딩하고 있는 또 하나의 기업인 토스에서 프로덕트 매니저(PM)이 어떤 직무를 하고 있는지에 대한 글을 소개합니다.
요약
PO가 개울을 건너기 위해 바윗돌을 빠르게 놓아 가설을 검증한 다음, PM은 그 돌다리같은 제품을 넓고 튼튼한 다리로 만드는 역할을 합니다.
토스가 정의하는 PO와 PM
• PO는 혁신을 탄생시키는 것이 목표, PM은 그 혁신이 더 많은 이들에게 닿을 수 있도록 하는 것을 목표로 합니다.
• PO는 잠재적 고객, PM은 현재 고객에 집중합니다
• PO는 제품을 확장시키는 역할, PM은 현재 고객의 문제를 해결하는 역할을 합니다
• PO는 전략적 관점에서 가설을 세우고 실험을 설계하고, PM은 쌓아온 데이터를 분석해 가설을 설계합니다.
• PO는 제품이 일정 단계에 이르르면 다른 제품으로 이동, PM은 하나의 제품을 장기적인 관점으로 계속해서 관리, 개선해나갑니다.
PM에게 필요한 스킬셋
PM은 하나의 제품을 더 활성화 할 수 있도록 지속적으로 관리, 개선하는 업무를 담당하기 때문에 전체를 바라보는 눈이 중요합니다. 이는 즉 하나의 사안에서 발생할 수 있는 모든 케이스들을 상상하고 고려할 수 있는 역량입니다. 이 역량을 가졌다면 제품을 운영하는 과정에서 맞닥뜨리는 여러 리스크들을 미리 감지하고 관리할 수 있습니다.
다른 분들의 예상과 다르게, 금융 도메인 지식보다는 제품 고도화를 위한 데이터를 기반으로 의사결정 내릴 수 있는 역량, 제품 개선점을 발견하고 정의해 자동화, 효율화 할 수 있는 역량, 여러 내외부 이해관계자들과 원할한 의사소통 역량이 더 중요하다고 합니다.
요약
PO가 개울을 건너기 위해 바윗돌을 빠르게 놓아 가설을 검증한 다음, PM은 그 돌다리같은 제품을 넓고 튼튼한 다리로 만드는 역할을 합니다.
토스가 정의하는 PO와 PM
• PO는 혁신을 탄생시키는 것이 목표, PM은 그 혁신이 더 많은 이들에게 닿을 수 있도록 하는 것을 목표로 합니다.
• PO는 잠재적 고객, PM은 현재 고객에 집중합니다
• PO는 제품을 확장시키는 역할, PM은 현재 고객의 문제를 해결하는 역할을 합니다
• PO는 전략적 관점에서 가설을 세우고 실험을 설계하고, PM은 쌓아온 데이터를 분석해 가설을 설계합니다.
• PO는 제품이 일정 단계에 이르르면 다른 제품으로 이동, PM은 하나의 제품을 장기적인 관점으로 계속해서 관리, 개선해나갑니다.
PM에게 필요한 스킬셋
PM은 하나의 제품을 더 활성화 할 수 있도록 지속적으로 관리, 개선하는 업무를 담당하기 때문에 전체를 바라보는 눈이 중요합니다. 이는 즉 하나의 사안에서 발생할 수 있는 모든 케이스들을 상상하고 고려할 수 있는 역량입니다. 이 역량을 가졌다면 제품을 운영하는 과정에서 맞닥뜨리는 여러 리스크들을 미리 감지하고 관리할 수 있습니다.
다른 분들의 예상과 다르게, 금융 도메인 지식보다는 제품 고도화를 위한 데이터를 기반으로 의사결정 내릴 수 있는 역량, 제품 개선점을 발견하고 정의해 자동화, 효율화 할 수 있는 역량, 여러 내외부 이해관계자들과 원할한 의사소통 역량이 더 중요하다고 합니다.실 사례
직무 분석
PM/PO
2022/05/18
중니어
시니어
제품 로드맵에 대한 궁극적인 가이드
Open
제품 로드맵에 대한 궁극적인 가이드
제품 로드맵이란 무엇입니까?
- 제품 전략을 실행하기 위한 계획과 지침이 되는 전략 문서
제품 로드맵이 중요한 이유는 무엇입니까?
- 제품 로드맵은 제품 전략이 어떻게 현실화되는지 요약
- 제품과 제품의 성공에 대한 영감, 동기 부여 및 공유 소유권의 원천
- 조직이 혼란을 피하고, 소규모 프로젝트가 구현 대기열에 들어가지 않고, 덜 중요한 작업에 리소스를 낭비하는 것을 방지
<제품 로드맵 구축>
제품이 성숙해짐에 따라 로드맵이 발전함. 새로 만든 MVP와 성숙한 제품은 다르다.
- 지평(Horizon): 스타트업은 미래 요구사항과 기회를 예측하기 어렵고, 로드맵이 멀지 않음. 기존 제품은 고객과 시장을 더 잘 이해하고, 확고한 장기 계획을 세움.
- 빈도(Frequency): 미숙할 때는 "항상 배포"해야합니다. 성숙한 제품은 덜 긴급하게 릴리즈할 수 있다.
- 종속성(Dependencies): 스타트업은 빠르게 움직이고 부술 수 있다. 성숙한 제품은 레거시, 써드파티 통합, 역행 이슈 등이 있다.
- 목표(Goals): 스타트업은 생존 가능성을 증명하고, 견인력(traction)을 얻고, 성장하려고 노력해야함. 엔터프라이즈는 미묘한 전략적 목표와 다양한 타겟을 가진다.
제품 로드맵을 어떻게 계획합니까? 몇가지 필터가 있음.
- 사용자에게 실제 가치가 있는가?
- 그 가치에 대한 증거가 있는가?
- 소유자(owner)가 있는가? (챔피언 역할)
- (기존 로드맵에) 어울리는가?
제품 로드맵에서 기능의 우선 순위를 어떻게 정합니까?
- OKR, MoSCow , RICE Scoring Model 등 선택할 수 있는 프레임워크가 다양함.
- 궁극적으로 어떤 접근 방식을 선택하든지 가치, 노력 수준 및 기회 비용에 대해 각 항목을 평가해야함.
- 팀은 또한 단기 승리와 장기 목표를 향한 진전의 이점을 비교해야 함.
<추가 로드맵 팁>
로드맵에 여러 제품을 추가하는 방법
- 일관성은 이 문제를 해결하는 열쇠
- 로드맵 스타일, 범례, 색상 코딩, 시간대 및 세분성 수준에 대한 정렬은 필수
- 버전 관리 문제도 잊지 마세요!
애자일 로드맵은 무엇입니까?
- 훨씬 더 짧은 기간을 가지며 변화하는 우선순위와 시장 기회를 수용하기 위해 더 자주 조정
- 로드맵을 최신 상태로 유지하는 것이 성공의 가장 큰 비결 중 하나
다양한 유형의 제품 로드맵은 무엇입니까?
- 경영진을 위한 내부 로드맵: 계획된 작업이 제품(및 회사)의 가치를 어떻게 높일 것인지에 중점
- 엔지니어를 위한 내부 로드맵: 기능, 릴리스, 스프린트 및 이정표에 중점
- 판매를 위한 내부 로드맵: 기능과 고객 이점의 조합에 중점
- 고객 및 잠재 고객을 위한 외부 로드맵: 릴리스 또는 출시 날짜를 포함하지 않는 것이 가장 좋습니다.
<로드맵 발표 및 사용>
5단계로 로드맵을 제시하는 방법
1. 로드맵을 누구와 공유해야 합니까?
2. 청중을 파악하십시오.
3. 내러티브에 집중하세요.
4. 높은 수준을 유지하십시오.
5. 메시지에 몇 가지 메트릭을 추가합니다.
로드맵 실행이란 무엇입니까?
- 제품 로드맵과 그 목표를 실현하는 임무를 맡은 팀이 명확하게 이해하도록 해야함
- 프로세스의 설계, 개발, 테스트 및 배포 단계 전반에 걸쳐 계속 참여해야함
- 새로운 기능이 예상대로 작동하고 요구 사항을 충족하는 동시에 기존 기능도 계속 작동하는지 확인해야함
프로덕트 전략
2022/05/11
기획자
SaaS 제품 담당자
문제 해결을 위해 솔루션으로 달려가지 마세요
Open
우리의 인지적 편향과 제한된 의사결정 능력 사이에서, 문제를 생각하기 위한 정신적인 연료가 부족할 때, 우리는 고민중인 문제를 완전히 이해할 기회를 갖기 전에 결정을 피하거나 서둘러 해결책을 찾아 정신적 에너지를 절약하려는 경향이 있습니다.
우리가 이렇게 솔루션으로 바로 넘어가는 건 당연한 일입니다. 할 일 목록을 넘기고 문제를 해결하면 도파민이 급증합니다. 특히 우리 주변의 세계가 불안정하고 무언가 임박했다고 느낄 때 더 그렇습니다. 하지만 일시적인 솔루션은 상황을 악화시킬 수 있으며, 장기적으로 봤을 때 본래의 문제 만큼이나 해를 끼치는 요소가 될 수 있습니다.
서둘러 해결책을 내버리려는 충동을 극복하기 위해, 간단한 4단계 프로세스를 따라보세요.
1. 문제를 직접 관찰하세요.
문제의 사실(*Facts, 본질로 이해해도 됨)에 대한 이해가 없을 때 형편없는 솔루션으로 건너뛰기 쉽습니다. 문제의 사실을 수집하는 것은 면밀한 관찰로부터 시작됩니다.
우리가 종종 의지하는 스프레드시트와 보고서는 2차원으로 표현한 데이터에 불과합니다. 사실이 없는 데이터는 2차원의 시야는 제공하지만 인사이트를 제공하지 못합니다. 의미있는 결론에 도달하기 위해서는 [데이터]와 [사실 수집] 두가지를 모두 고려해야 합니다.
예시1
- 데이터가 얘기하는 것 : 조립 라인에서 기계가 얼마나 자주 고장났는가.
- 관찰로 알 수 있는 사실 : 기계가 더럽고 기름으로 덮혀있으며, 오랫동안 청소 및 관리되지 않았다.
예시2
- 데이터가 얘기하는 것 : 작업자가 Zoom 회의에 제시간에 맞춰 오지 않았다.
- 관찰로 알 수 있는 사실 : 부모가 자녀의 온라인 스쿨 적응을 도와주어야 하기 때문에 오전 9시 미팅을 하기가 어렵다. 또한 아이들 점심을 준비해야 하기 때문에 12:30 회의가 어렵다.
2. 문제의 프레임을 적절하게 정의하세요.
문제를 정의하는 것은 어렵습니다. 무엇보다도, 문제의 증상을 근본적 문제로 오인하기 쉽습니다. 잘 짜여진 문제 정의는 토론과 선택의 길을 열어주지만, 나쁜 문제 정의는 대안에 대한 생각을 막아버리고 쉽게 생각하게끔 막다른 골목으로 보내버립니다.
(A) 우리 병원에는 인공호흡기가 더 필요합니다.
(B) 우리 병원의 인공호흡 가용성이 더 높아져야 합니다.
첫 번째 문장(A)은 바로 결론을 내버립니다. 이 경우 유일한 해결책은 인공호흡기를 더 구입하는 것입니다. 두 번째 문장(B)은 암묵적인 판단(= 더 많은 인공호흡기가 필요함)을 피하고 있습니다. 이것은 더 나은 솔루션을 개발하는데 도움이 되는 질문으로 이어질 수 있습니다.
∙ 현재 수리중인 기계의 수는 얼마인가?
∙ 모든 장비가 작동 가능하도록 관리되고 있는가?
∙ 모든 인공호흡기가 어디에 있는지 간호사가 알고있는가?
∙ 한 환자에서 다음 환자로 인공호흡기를 옮기는데 소요되는 시간은 얼마인가?
3. 거꾸로 생각해보세요.
문제에 직면했을 때, 솔루션으로 바로 달려가기 보다는 뒤로 돌아서 어떻게 이 문제까지 오게 되었는지 ‘이유’를 정리해보세요. 문제의 ‘이유'에는 기본적으로 아래 6가지 범주가 있습니다. 예시와 함께 살펴보겠습니다.
문제 : 팬데믹 기간 동안 직원들의 사기가 저하됨
∙ 환경적 이유
e.g. 재택근무 환경이 갖춰지지 않아서 집중하기 어려움
∙ 심리학적 이유
e.g. 고립되었다고 느낌, 일상적인 대화를 할 수 없음
∙ 기술적 이유
e.g. 줌 사용이 어려움, 미팅중에 자주 끊김
∙ 규범적 이유
e.g. 업무시간이 명확하지 않음
∙ 커뮤니케이션 이유
e.g. 전사 미팅이 없음, 리더십의 메시지가 잘 전달되지 못함
4. 왜? 를 반복하세요.
답을 내리기 전에 반복적으로 “왜?”를 묻는 것은 성급한 결론을 내리거나 불충분한 솔루션을 구현하지 않도록 하는 강력한 방법입니다. 5번, 많게는 11번 "왜"를 물어보면 결국 근본 원인에 도달하게 될 것 입니다. 각 질문은 우리가 실제 문제에 대해 더 깊게 이해하도록 유도하기 때문입니다.
모든 복잡한 문제에는 명확하고 간단하며 잘못된 솔루션이 있습니다. 근본 원인을 찾으면 증상을 단순히 치료하는 반창고가 아닌 지속 가능한 솔루션을 갖게 됩니다.
PM/PO
마인드셋
가이드
2022/05/06
주니어
중니어
디자인 시스템 101 - 닐슨 노먼 그룹
Open
<디자인 시스템이란?>
- 중복성을 줄이고
- 다양한 페이지와 채널에서 공유된 언어와 시각적 일관성을 만들어
- 대규모로 디자인을 관리하기 위한 일련의 표준
UI 디자인
- UI 화면을 생성해야 하는 규모와 속도가 높아져
- 각 앱과 웹 사이트에는 수백 또는 수천 개의 페이지(또는 화면)가 필요
- 조직에서는 설계 작업을 간소화해야 할 절박한 필요성이 대두
디자인 시스템을 사용하는 이유
- 설계(및 개발) 작업을 신속하게 대규모로 생성하고 복제할 수 있다.
- 더 크고 복잡한 문제에 집중하기 위해 설계 리소스의 부담을 덜어준다.
- 교차 기능 팀 내에서 그리고 팀 간에 통합된 언어를 만든다.
- 제품, 채널 및 (잠재적으로 고립된) 부서 전반에 걸쳐 시각적 일관성을 만든다.
- 주니어 레벨 디자이너와 콘텐츠 기고가를 위한 교육 도구 및 참고 자료로 사용할 수 있다.
디자인 시스템을 사용하지 않는 이유는 무엇입니까? (잠재적인 장애물과 제한사항)
- 디자인 시스템을 만들고 유지 관리하는 것은 전담 팀이 필요한 시간 집약적인 활동이다.
- 디자인 시스템을 사용하는 방법을 다른 사람에게 가르치는 데는 시간이 걸린다.
- 프로젝트는 일반적으로 재사용 가능한 구성 요소가 필요하지 않은 정적인 일회성 생성이라는 인식이 있을 수 있다.
<디자인 시스템의 요소>
1. 디자인 저장소(repository)
2. 그것을 관리 하는 사람들
1. 디자인 저장소
- 스타일 가이드
- 일반적인 스타일 가이드는 브랜딩(색상, 타이포그래피, 상표, 로고 및 인쇄 매체)에 초점을 맞춤
- 콘텐츠( 목소리 및 언어 권장 사항 등)와 시각적 및 상호 작용 디자인 에 대한 지침도 제공
- 컴포넌트 라이브러리
- 구성 요소 이름
- 설명
- 속성
- 상태
- 코드 조각
- 프론트엔드 및 백엔드 프레임워크 (필요 시)
- 패턴 라이브러리
- 컴포넌트 라이브러리는 개별 UI 요소를 지정하는 반면, 패턴 라이브러리는 UI 요소 그룹화 또는 레이아웃 컬렉션을 제공
2. 디자인 시스템 팀
- 오래되거나 쓸모없거나 중복된 항목이나 제출로 인해 과밀화되지 않도록 지속적인 유지 관리와 감독이 필요
- 팀에는 최소한 1명의 인터랙션 디자이너, 1명의 비주얼 디자이너 및 1명의 개발자가 포함되어야 함
- 인터랙션 디자인 가이드라인을 만들고, 시각적 예제를 만들고, 각 요소에 대한 코드 스니펫과 구현 사양을 각각 제공
설계 시스템 노력을 조율하기 위해 경영진 후원자를 확보하는 것을 고려해야함
스폰서는 자금과 자원을 확보하는 동시에 나머지 조직에 디자인 시스템의 전략적 중요성을 전달할 수 있음
<디자인 시스템 채택에 접근하는 방법>
- 기존 디자인 시스템 채택
- 기존 디자인 시스템 적용
- 나만의 독점 또는 맞춤형 디자인 시스템 만들기
디자인 시스템 솔루션이 맞춤화될수록 구현하는 데 더 많은 시간과 비용이 소요
기존 설계 시스템을 사용하는 것이 가장 비용이 적게 드는 접근 방식
개념 증명(PoC)이나 변경될 가능성이 있는 초기 프로토타입의 경우
본격적인 설계 시스템을 만드는 것은 단기간에 원하는 ROI가 안 나옴
미래에 있을 디자인의 복제 가능성에 도움이 됨
디자인 시스템은 작업 포트폴리오로 생각해서는 안됨
디자이너와 개발자가 보다 빠르게 작업할 수 있는 기능적 툴킷 또는 리소스로 간주해야 함
디자인 시스템을 만들 때 고려해야 할 주요 요소
- 프로젝트의 규모와 복제 가능성
- 사용 가능한 리소스와 시간
제대로 구현 및 유지 관리하지 않으면 디자인 시스템이 구성 요소와 코드의 다루기 힘든 모음이 될 수 있음
그러나 잘 구현되면 팀 구성원을 교육하고 작업을 간소화하며 디자이너가 복잡한 UX 문제를 해결할 수 있음
디자인 시스템
가이드
2022/04/28
기획자
SaaS 제품 담당자
UX 설계 문서 작성이 필요한 이유
Open
많은 팀에서 "지금은 UX 설계 문서를 작성할 시간이 없다. 디자인과 개발에 집중하자"며 문서 작성을 연기합니다. 문서화의 부족은 설계의 구현 단계에서 혼란을 야기합니다. 이 아티클은 UX 디자인의 문서화의 개념을 알아보고 이것이 왜 중요한지, 어떻게 하면 올바르게 수행할 수 있는지 유용한 팁들을 알려줍니다.
UX 설계 문서란?
- 프로덕트의 설계의 모든 측면을 다루는 문서 및 리소스의 모음이다. 문서에는 사용자, 프로덕트 기능, 팀원과 이해관계자들이 합의한 디자인 결정 사항 및 필수 구현 정보 등이 포함되어야한다.
문서화에 시간 투자를 해야하는 이유는?
1. UX 설계 문서는 프로젝트 요구 사항을 명확히 한다.
- 이해관계자들은 설계 문서를 통해 디자인 결정 사항들이 회사의 비지니스 목표와 사용자 요구를 동시에 충족시키는 방법을 이해할 수 있다.
2. 구현 간소화
- 프로덕트 설계 시 다양한 사람들과 협업 하는데, 이때 설계 문서는 특정 목표 중심으로 팀을 결집 시키고 모든 사람에게 동일한 형태로 전달 되는 단일 정보 역할을 한다.
문서에 포함되어야 할 필수 사항
1. 프로젝트 개요 (UX팀이 달성 하고자하는 목표, 누구나 이해할 수 있어야함)
3. 팀 동기 부여
- 잘 설계된 문서는 프로덕트에 대한 높은 수준의 이야기를 전달하고 팀원들에게 프로덕트 비전을 심어주는 역할을 한다.
"프로덕트를 어떻게 구축하고 싶은가?" "왜 이걸 만들고 싶은가"와 같은 질문에 대답할 수 있게 된다.
문서에 포함되어야하는 필수 항목
1. 프로젝트 개요 (UX 팀이 달성하고자하는 목표)
2. 제품 요구 사항 (설계 비지니스 및 기술적인 요구사항)
3. 프로젝트 결과물 (구현이 완료되면 결과물로 제공되는 정보)
4. 타겟 사용자 정보 (페르소나, 유저 리서치 데이터 등은 디자인 결정에 대한 근거 참고 자료가 됨)
5. 사용자 여정 (사용자의 프로덕트 사용 플로우 설명)
6. 디자인 가이드 라인 및 스타일 가이드
7. 프로젝트 범위 및 구현 계획 (ex. 프로젝트 타임라인)
8. 디자인 검증 및 사용자테스트 (제품 주기동안 수행해야하는 것들)
9. 운영 지침 (ex. 새 버전의 앱을 출시하는 방법에 대한 가이드)
적절하게 문서화하는 팁
1, 문서를 볼 타켓 유저 고려해서 작성
2. 최신 문서 제공
3. 점진적인 업데이트 작업
4. 문서 테스트 하기
5. 전문적인 용어 피하기
6. 쉬운 접근성 제공 (온라인으로 제공)
7. 시각적 예시 혹은 코드 샘플 제공
8. 문서를 최신으로 유지
9. 기존 문서의 패턴을 찾아서 템플릿화 하기UX
문서 작성법
2022/04/15
주니어
중니어
UX 디자이너를 위한 커뮤니케이션 꿀팁
Open
성공적인 디자이너가 되기 위해서는 두가지 유형의 스킬이 필요합니다. 이것을 소프트스킬과 하드스킬이라고 합니다. 소프트스킬은 대인관계 스킬입니다. 하드스킬은 특정 분야에 특화된 전문스킬입니다.
소프트스킬 즉, 커뮤니케이션 스킬은 디자이너의 기본 스킬이자 업무의 핵심입니다. 팀에서 효과적으로 의사소통할 수 있고 좋은 평판을 얻을 수 있는 능력입니다. 좋은 커뮤니케이션을 통해 신뢰를 쌓을 수 있으며, 정직한 피드백을 나누고 작업에 대한 확신을 가질 수 있습니다.
디자이너는 마법사가 아닙니다.
주니어 디자이너는 종종 UX디자인 작업을 오랫동안 공유하지 않고 혼자서 작업하다가 최종 솔루션을 짠! 하고 보여줍니다. 대부분의 경우, 이 주니어 디자이너는 팀원들이 솔루션을 받아들이지 않는다는 사실에 화를 냅니다.
작업 중간중간 팀원들에게 작은 변화들을 공유하세요. 팀원들이 작업 프로세스에 기여하게 되면 솔루션을 더 잘 이해할 수 있으며, 솔루션을 수용할 가능성이 높아집니다. 하지만 모든 것을 전달할 필요는 없습니다. 유저에게 유효하지 않거나, 자신없는 아이디어는 공유하지 않는 것이 좋습니다.
진정한 마법은 경청에서 시작됩니다.
미팅은 디자이너 업무의 많은 비중을 차지합니다. 경청하지 않으면 올바른 솔루션을 설계할 수 없습니다. 다른 팀원의 말을 집중해서 듣고 ‘왜?’를 질문하세요. 개발자들에게 질문하는 것을 두려워하지마세요. 질문을 통해 발화 의도를 확인할 수 있고 새로운 지식을 얻을 수 있습니다. 또한, 다른 팀원의 말을 경청하면 그들의 상황과 고군분투에 공감하여 문제를 더 쉽게 해결할 수 있습니다.
회의를 적극적으로 활용하세요.
모든 회의에 참석할 필요는 없습니다. 그러나 중요한 회의에 참석하고 있다면, 질문을 통해 적극적으로 참여하세요. 다양한 주제를 이해할 수 있는 기회가 되며, 크리티컬할 수 있는 이슈를 사전에 논의할 수 있습니다.
특히 주니어 디자이너에게 중요한 것은 질문을 부끄러워하지 않는 것입니다. 많은 경우, 혼자만 이해하지 못하는 게 아닐 수 있습니다.
Flow Chart와 프로토타입을 사용하세요.
말로만 설명하기 힘든 경우들도 많습니다. 다양한 시각 자료를 활용하면 원활하게 커뮤니케이션을 할 수 있습니다.
팀원들에게 흐름을 설명하기 위해 플로우차트를 사용하면 요점을 설명하는데 도움이 될 수 있습니다. 또한 프로토타입을 활용하면 팀원들이 제품을 더 구체적으로 이해하고 피드백을 줄 수 있습니다.
논의하기 전에 주제를 공부하세요.
디자이너가 제품을 잘 모르거나 사용자 조사를 하지 않으면 잘못된 정보를 가지고 결정하게 되고, 비효율적인 논의를 반복하게 됩니다. 사람들이 전문가의 의견을 듣는 이유는 그들이 제시하는 정보를 신뢰할 수 있기 때문입니다. 사람들이 당신을 신뢰하기 시작하면 설득하기도 훨씬 쉬워지며 갈등과 오해가 줄어들 것입니다.
건설적인 피드백을 수용하여 전문성을 키우세요.
피드백은 가끔 가혹할 수도 있습니다. 하지만 팀원이 당신의 업무에 대해 어떻게 느끼는지 모르고 나쁜 습관을 유지하는 것보다는 건설적 비평을 듣는게 낫습니다. 사람들은 부정적 피드백을 주는 것을 꺼려하기 때문에, 피드백을 요청하기 전에 “정확한 의견이 더 나은 UX디자인을 만드는데 도움이 된다”는 것을 언급하는 것도 좋습니다.
프레젠테이션 스킬은 필수입니다.
오늘날의 디자이너는 디자인 작업 그 자체 보다 ‘작업에 대해 설명'하는 시간이 더 많은 것 같습니다. 회의에서, 개발자에게 디자인을 공유할 때, 디자인 크리틱 시간 등에서 디자인 작업을 시연해야 합니다. 팀이 이해하고 수용할 수 있도록 명확하고 간결한 메시지로 디자인을 전달하고, 의도를 묻는 질문에 대답할 수 있어야 합니다. 연습하면 더 나아집니다!
협상 능력은 사용자 경험 디자이너의 핵심 스킬입니다.
최종 제품의 성공 여부는 팀이 얼마나 잘 협력하고 타협점을 찾을 수 있을지에 달려있습니다. 개발자, PM 관점을 이해하고 작업 범위를 협상할 수 있어야 합니다. 예를 들어 복잡한 UX디자인을 개발해야 하는 경우, 개발팀이 현재 얼마나 개발해야 하는지, 개발할 수 있는 여력이 얼마나 있는지를 이해하고 협상해야 하는 경우가 많습니다.
디자이너는 마법사가 아닙니다.
주니어 디자이너는 종종 UX디자인 작업을 오랫동안 공유하지 않고 혼자서 작업하다가 최종 솔루션을 짠! 하고 보여줍니다. 대부분의 경우, 이 주니어 디자이너는 팀원들이 솔루션을 받아들이지 않는다는 사실에 화를 냅니다.
작업 중간중간 팀원들에게 작은 변화들을 공유하세요. 팀원들이 작업 프로세스에 기여하게 되면 솔루션을 더 잘 이해할 수 있으며, 솔루션을 수용할 가능성이 높아집니다. 하지만 모든 것을 전달할 필요는 없습니다. 유저에게 유효하지 않거나, 자신없는 아이디어는 공유하지 않는 것이 좋습니다.
진정한 마법은 경청에서 시작됩니다.
미팅은 디자이너 업무의 많은 비중을 차지합니다. 경청하지 않으면 올바른 솔루션을 설계할 수 없습니다. 다른 팀원의 말을 집중해서 듣고 ‘왜?’를 질문하세요. 개발자들에게 질문하는 것을 두려워하지마세요. 질문을 통해 발화 의도를 확인할 수 있고 새로운 지식을 얻을 수 있습니다. 또한, 다른 팀원의 말을 경청하면 그들의 상황과 고군분투에 공감하여 문제를 더 쉽게 해결할 수 있습니다.
회의를 적극적으로 활용하세요.
모든 회의에 참석할 필요는 없습니다. 그러나 중요한 회의에 참석하고 있다면, 질문을 통해 적극적으로 참여하세요. 다양한 주제를 이해할 수 있는 기회가 되며, 크리티컬할 수 있는 이슈를 사전에 논의할 수 있습니다.
특히 주니어 디자이너에게 중요한 것은 질문을 부끄러워하지 않는 것입니다. 많은 경우, 혼자만 이해하지 못하는 게 아닐 수 있습니다.
Flow Chart와 프로토타입을 사용하세요.
말로만 설명하기 힘든 경우들도 많습니다. 다양한 시각 자료를 활용하면 원활하게 커뮤니케이션을 할 수 있습니다.
팀원들에게 흐름을 설명하기 위해 플로우차트를 사용하면 요점을 설명하는데 도움이 될 수 있습니다. 또한 프로토타입을 활용하면 팀원들이 제품을 더 구체적으로 이해하고 피드백을 줄 수 있습니다.
논의하기 전에 주제를 공부하세요.
디자이너가 제품을 잘 모르거나 사용자 조사를 하지 않으면 잘못된 정보를 가지고 결정하게 되고, 비효율적인 논의를 반복하게 됩니다. 사람들이 전문가의 의견을 듣는 이유는 그들이 제시하는 정보를 신뢰할 수 있기 때문입니다. 사람들이 당신을 신뢰하기 시작하면 설득하기도 훨씬 쉬워지며 갈등과 오해가 줄어들 것입니다.
건설적인 피드백을 수용하여 전문성을 키우세요.
피드백은 가끔 가혹할 수도 있습니다. 하지만 팀원이 당신의 업무에 대해 어떻게 느끼는지 모르고 나쁜 습관을 유지하는 것보다는 건설적 비평을 듣는게 낫습니다. 사람들은 부정적 피드백을 주는 것을 꺼려하기 때문에, 피드백을 요청하기 전에 “정확한 의견이 더 나은 UX디자인을 만드는데 도움이 된다”는 것을 언급하는 것도 좋습니다.
프레젠테이션 스킬은 필수입니다.
오늘날의 디자이너는 디자인 작업 그 자체 보다 ‘작업에 대해 설명'하는 시간이 더 많은 것 같습니다. 회의에서, 개발자에게 디자인을 공유할 때, 디자인 크리틱 시간 등에서 디자인 작업을 시연해야 합니다. 팀이 이해하고 수용할 수 있도록 명확하고 간결한 메시지로 디자인을 전달하고, 의도를 묻는 질문에 대답할 수 있어야 합니다. 연습하면 더 나아집니다!
협상 능력은 사용자 경험 디자이너의 핵심 스킬입니다.
최종 제품의 성공 여부는 팀이 얼마나 잘 협력하고 타협점을 찾을 수 있을지에 달려있습니다. 개발자, PM 관점을 이해하고 작업 범위를 협상할 수 있어야 합니다. 예를 들어 복잡한 UX디자인을 개발해야 하는 경우, 개발팀이 현재 얼마나 개발해야 하는지, 개발할 수 있는 여력이 얼마나 있는지를 이해하고 협상해야 하는 경우가 많습니다.마인드셋
가이드
2022/03/31
주니어
중니어
팀이 사랑하게 될 백로그 만들기
Open
[성장을 위한 데일리 아티클] '팀이 사랑하게 될 백로그 만들기'
스타트업 씬에서 빠르게 프로덕트를 개발하다보면 백로그에 남아있는 이슈들이 점점 많아지게 되는 경험을 많이 해보셨을 것 같아요. 백로그에 등록된 이슈들은 우선순위를 관리해주지 않으면 이슈가 쌓이기만 하고, 스프린트로 올라와서 해결되는 이슈는 점점 적어지고, 그 크기나 중요도와 관계 없이 아이디어들만 중구난방으로 흩어져있는 창고가 되기 쉽습니다.
저도 B2B SaaS 프로덕트를 만들 때는 고객의 요구사항에 의해 짧은 기간에 해결해야 할 로드맵이 구성되기 쉽고, UX 개선이나 내부적으로 의미있는 기능들은 뒷단으로 밀리는것을 경험하고 있습니다. 백로그를 아이디어의 무덤이 되지 않게 활용할 수 있도록 소개하는 방법을 시도해보세요!
1. 들어오는 업무를 기록하기 쉽게 하기
새로 들어오는 업무 요청사항들은 여러 이해 관계자로부터 발생할 수 있습니다. 백로그는 앞으로 해야 할 업무가 쌓이기 시작하는 Source of Truth로 활용될 수 있어야 합니다. 이 Source of Truth에 쌓인 업무들으로 우선순위를 파악하는 작업이 이어집니다.
기록되어야 할 것: 모든 새로운 할 일
2. 그루밍이 필요한 할 일이 무엇인지 알기 쉽게 하기
백로그에 등록된 이슈들 모두가 업무할 수 있도록 정리될 필요는 없습니다. 한 백로그에서 장기, 중기, 단기 할일들이 쌓이게 될 것입니다. 백로그 그루밍을 시간 효율적으로 하려면 단기 할일들을 우선해서 그루밍 할 수 있도록 해야합니다.
기록되어야 할 것: 일이 처리되어야 하는 due
고객사 임팩트가 적거나, 실행 가능하지 않은 아이디어들에는 그루밍을 할 필요가 없습니다. 그런 이슈들은 Not Doing 로 태깅하고 다음 이슈로 넘어갈 수 있어야 합니다.
기록되어야 할 것: Status - Not Doing
장기적으로 미래 로드맵에서 가져가면 좋은 이슈들은 지금 내용을 정리할 필요는 없지만, 나중에 다시 와서 쉽게 확인할 수 있어야 합니다.
기록되어야 할 것: Status - Future Nice to Have
3. 우선순위가 높은 할 일을 찾기 쉽도록 하기
우선순위를 결정하는 것은 어려운 일입니다. 실행 하기로 결정되어 그루밍 된 이슈들 중 우선순위가 낮거나 아직 우선순위가 판단되지 않은 이슈와, 우선순위가 높은 이슈들을 구분해서 더 중요한 일을 쉽게 확인하도록 할 수 있습니다.
기록되어야 할 것: Status - 우선순위 낮거나 지정되지 않음
기록되어야 할 것: Status - 우선순위 높음
다음 스프린트에 할 일 / 이전 스프린트에서 못 한 일
백로그에 처음 등록된 할 일은 최종적으로 '다음 스프린트에 할 일'으로 이동하게 됩니다. 그리고 이번 스프린트 할 일은 새로 등록된 할 일과 지난 스프린트에서 끝내지 못한 일을 하게 됩니다.
기록되어야 할 것: Status - 이번 스프린트에서 할 일
기록되어야 할 것: Status - 지난 스프린트에서 못 한 일
4. 불필요한 일은 숨기기
보통 진행하지 않기로 한 업무는 히스토리 관리를 위해 삭제하지는 않습니다. 진행하지 않기로 한 업무들을 Archive하여 보이지 않도록 정리할 필요가 있습니다.
기록되어야 할 것: Status - Archive스타트업
PM/PO
문서 작성법
가이드
2022/03/30
중니어
시니어
PM을 설득하려면 어떻게 해야할까?
Open
이 글을 읽고 있는 디자이너분들께서는 제품이 잘못된 방향으로 가고 있다고 PM(Product Manager)에게 의견을 말해본 적이 있나요? 제품이 정말 의미없이 산으로 갈 것만 같아서 꼭 PM에게 말해야 하는 상황이라면 어떻게 할까요?
아래에서 PM이 의사결정 및 우선순위 지정에 활용하는 툴을 알아보고 이를 효과적인 커뮤니케이션의 발판으로 삼아보시기 바랍니다.
[간단하고 사용이 쉬운 툴] 순서도(Flow Chart)
논리적으로 파고들 수 있습니다.
ex. 타겟 고객층이 누구인지 아시나요? -> 현재 제품 상태가 그들의 문제를 해결해주나요? -> .......(계속되는 검증, 질문) -> 대안으로 이건 어떤가요? -> (우선순위 추려서) 이 솔루션으로 해봅시다.
[더 나은 툴 제안] 제품 두뇌(The Product Brain) 노드 해킹하기
아이디어를 명확하게 표현할 방법을 찾고 있다면, 가장 좋은 길은 PM이 어떤 방식으로 생각하고 무엇을 두려워하는지 이해하는 것입니다.
///노드로 표현되는 제품 두뇌 (본문에 그림 있습니다)///
리서치 -> 영감 획득 -> 아이디어 발전 -> 검증 -> 가치 따지기 -> 영향도 따지기 -> 기획 -> 구현 -> 측정 -> 학습
제품 두뇌는 일련의 '노드'를 통해 작동하는데, 노드 일부는 해킹할 가치가 있습니다. 다음은 커뮤니케이션에 임하기 위한 노력과 그 결과에 따르는 영향입니다. 처한 상황에 맞게 접근하면 좋을 것입니다.
- 리서치: 노력 중간, 영향 중간
- 영감과 아이디어: 노력 중간, 영향 낮음
- 검증 및 가치 따지기: 노력 높음, 영향 높음
초점은 정성적 평가입니다. 대상 사용자를 만나고, 설문 조사를 실행하고, 종이 프로토타입을 보여주고, 이벤트에 참석하고, 조사를 수행하십시오. 한 사람의 삶에 의미 있는 영향을 미칠 무언가를 만들고 있는지 확인하십시오. 그 과정에서 미래에 새로운 아이디어를 더 쉽게 검증할 수 있는 프레임워크를 개발하게 될 것입니다.
- 영향도 따지기: 노력 높음, 영향 높음
진정으로 가치 있는 문제를 찾아 검증한 경우에도 고려할 가치가 있는 적절한 사용자 집단를 충분히 배려해야 한다는 것이 요점입니다. 이 단계에서는 설문조사, a/b 테스트, Fake dore test 등 정량적 평가에 중점을 둡니다.
- 기획 및 구현: 노력 중간, 영향 낮음
[간단하고 사용이 쉬운 툴] 순서도(Flow Chart)
논리적으로 파고들 수 있습니다.
ex. 타겟 고객층이 누구인지 아시나요? -> 현재 제품 상태가 그들의 문제를 해결해주나요? -> .......(계속되는 검증, 질문) -> 대안으로 이건 어떤가요? -> (우선순위 추려서) 이 솔루션으로 해봅시다.
[더 나은 툴 제안] 제품 두뇌(The Product Brain) 노드 해킹하기
아이디어를 명확하게 표현할 방법을 찾고 있다면, 가장 좋은 길은 PM이 어떤 방식으로 생각하고 무엇을 두려워하는지 이해하는 것입니다.
///노드로 표현되는 제품 두뇌 (본문에 그림 있습니다)///
리서치 -> 영감 획득 -> 아이디어 발전 -> 검증 -> 가치 따지기 -> 영향도 따지기 -> 기획 -> 구현 -> 측정 -> 학습
제품 두뇌는 일련의 '노드'를 통해 작동하는데, 노드 일부는 해킹할 가치가 있습니다. 다음은 커뮤니케이션에 임하기 위한 노력과 그 결과에 따르는 영향입니다. 처한 상황에 맞게 접근하면 좋을 것입니다.
- 리서치: 노력 중간, 영향 중간
- 영감과 아이디어: 노력 중간, 영향 낮음
- 검증 및 가치 따지기: 노력 높음, 영향 높음
초점은 정성적 평가입니다. 대상 사용자를 만나고, 설문 조사를 실행하고, 종이 프로토타입을 보여주고, 이벤트에 참석하고, 조사를 수행하십시오. 한 사람의 삶에 의미 있는 영향을 미칠 무언가를 만들고 있는지 확인하십시오. 그 과정에서 미래에 새로운 아이디어를 더 쉽게 검증할 수 있는 프레임워크를 개발하게 될 것입니다.
- 영향도 따지기: 노력 높음, 영향 높음
진정으로 가치 있는 문제를 찾아 검증한 경우에도 고려할 가치가 있는 적절한 사용자 집단를 충분히 배려해야 한다는 것이 요점입니다. 이 단계에서는 설문조사, a/b 테스트, Fake dore test 등 정량적 평가에 중점을 둡니다.
- 기획 및 구현: 노력 중간, 영향 낮음
가이드
마인드셋
협업
커뮤니케이션
2022/03/24
신입
주니어
엔터프라이즈 UX리서치를 진행할 때 고려할 점
Open
UX리서치는 풍부하고 가치있는 사용자 경험을 만드는데에 있어 가장 중요합니다. 올바른 UX 리서치는 UX품질은 물론 사용성과 비즈니스 수익 측면에서 완성도 높은 제품을 만듭니다.
엔터프라이즈 서비스의 컨텍스트에는 수 많은 이해관계자와 레거시, 사용자와 구매자의 경험 차이 등의 과제가 있습니다. 따라서 엔터프라이즈 서비스의 UX리서치를 수행하기 위해서는 아래와 같은 키 포인트를 염두해 두어야합니다.
1. 서비스 구매자는 실제 사용자가 아니다
엔터프라이즈 서비스는 고객이 실제 사용자가 아니라는 점에서 일반 B2C앱과 차이가 있습니다. 엔터프라이즈 서비스는 실제 사용자의 요구사항을 이해하는 것이 중요합니다. 엔터프라이즈 프로젝트의 성공은 사용자의 요구가 얼마나 충족되었는지에 달려있으며, 이는 사용자의 생산성 향상으로 이어집니다. 따라서 제품 기획 초기에 사용자리서치를 진행하고 사용자의 요구를 파악하는데에서 부터 시작해야합니다.
2. UX 리서치를 통해 도메인에 대해 기본적인 이해하기
엔터프라이즈 서비스는 복잡한 인터페이스와 인터랙션으로 구성되어있어 워크플로우를 깊이있게 이해하는 것은 모든 리서치팀에게 필수적입니다. 엔터프라이즈 프로젝트를 진행하기 위해서는 도메인에 대한 철저한 이해가 바탕이 되어야합니다.
UX리서치의 장점은 서비스 사용에 대한 실제 전문가인 사용자를 찾고 도메인 관련한 내부 정보를 알 수 있다는 점입니다. 기본적인 도메인 지식을 쌓으면 의미있는 방식으로 결과를 매핑하고 분석할 수 있습니다.
3. 사용자의 행동은 레거시 시스템만큼 복잡합니다.
대부분의 사용자는 자신의 임무를 수행하기 위해서 작업을 수행합니다. 많은 사례에서 사용자는 본인이 필요한 작업을 완료하기 위해 선택적인 기능에 대해서만 공부한다는 것을 알 수 있습니다. 따라서 워크플로우를 조금만 변경해도 시스템 전체의 기능을 이해하지 못하는 사용자들은 업무 효율성이 저하될 수 있습니다.
따라서 리서처와 디자이너는 현재의 행동패턴과 새로운 시스템에서의 기대치를 이해하는 것 외에도 시스템의 역사, 변화, 사용자의 반응을 주의 깊게 조사해야합니다.
4. 사용자가 말하는 것과 실제로 하는것에는 차이가 있습니다.
UX리서치에서는 어떤 것도 표면 그대로 받아들여서는 안됩니다. 리서처로서 사람들의 인터뷰와 피드백 내용을 신뢰하고 싶겠지만 본질적인 인사이트를 얻기 위해서는 직감에 의존해야합니다. 이런 상황에서는 얻은 데이터를 교차 확인 및 분석하고 여러 시나리오에 대해 검증하는 것이 중요합니다. 또한 계층구조, 문화적 요인 등 의사결정에 영향을 줄 수 있는 다른 요인도 확인해야합니다.
5. 엔터프라이즈 시스템에서도 사용자는 즐거울 수 있습니다.
사용자는 오랜 세월 따분하고 복잡한 엔터프라이즈 서비스를 쓰고있습니다. 현재 서비스의 좋지 않은 경험을 쉽게 무시할 수도 있지만 워크플로우를 개선하는 사소한 변화에도 크게 기뻐할 수 있습니다. 제품 테스트 단계에서 이런 사용자의 사례를 자주 볼 수 있고, 이런 변경은 사용자의 작업을 더욱 쉽게 만듭니다.
모든 유저는 인간이며, 실제 경험에 맞추어 쾌적한 시스템으로 작업하고 싶어하는 공통의 욕구를 가지고 있습니다.
디자이너에게 엔터프라이즈 서비스를 만드는 것은 지뢰가 난무하는 들판을 걷는 것과 같은 느낌일 수 있습니다. 그러나 이러한 프로젝트를 수행함으로써 얻은 성공 또한 그만큼 더 달콤합니다.
엔터프라이즈 서비스의 성공은 리서치팀이 도출한 결과와 관찰의 질에 크게 좌우됩니다. 결국 UX리서치가 EUX(Enterprise UX)의 혁신이 실제로 시작되는 단계라고 할 수 있습니다.
마인드셋
UX
리서치
2022/03/21
주니어
중니어
기획자
중니어 프로덕트 디자이너를 위한 조언
Open
변경될 내용에 시간을 낭비하지 마세요.
이해 관계자를 설득 시키기위한 몇분을 위하여, 완벽한 디자인을 만들기 위해 몇 시간을 보낸 적이 있나요?
시안 중 하나만 선택되고 나머지는 폐기됩니다. 이 경우 각 시안의 개념을 전달할 수 있을 만큼만 디자인하고 명확한 피드백을 받은 후 디자인을 완성하는 데 시간을 투자해야 합니다. 따라서 작업에 투자하는 노력의 수준은 해당 위험의 양(즉, 크게 변경될 가능성)과 일치해야 합니다.
모든 회의의 아젠다를 설정하세요.
1. 우리가 이 회의를 하는 이유
2. 회의에서 논의될 내용
3. 이 회의에서 달성하고자 하는 것
해당 내용을 명확히 하면 4가지 주요 베네핏 있습니다.
- 회의중 논의하고 싶은 명확한 요점을 가지는데 도움이 됩니다.
- 구성원 모두 회의 목적에 대한 명확한 이해와 가시성을 이해할수 있습니다.
- 구성원 모두 같은 공동의 목표를 위해 일할 수 있습니다.
- 모든 논의를 체크하고 대화가 탈선하지 않도록 돕습니다.
주요 이해 관계자와 1:1로 인터뷰하세요.
새 제품에 합류할 때, 주요 이해 관계자 및 팀 구성원(PM, 엔지니어...)과 대화할 시간을 설정해 잠재적인 문제를 판별하는 데 도움이 되는 질문을 해보세요.
- 과거에는 무엇이 잘 되었습니까?
- 과거에 잘 되지 않은 것은 무엇입니까?
- 사람들이 제품을 사용하는 데 어떤 이의가 있습니까?
- 제품을 사용하기 어려운 이유는 무엇입니까?
- 기술적인 제약이 있습니까?
프레임워크 구축하세요.
프레임워크의 사용은 아마도 새로운 기능, 특히 매우 빠른 실행이 필요한 프로젝트에서 작업할 때 가장 좋아하는 것 중 하나입니다. 시간을 절약할 뿐만 아니라 설계자(심지어 이해 관계자)가 제공해야 하는 것을 진정으로 이해하도록 돕습니다.
다른 디자이너들과의 협력하세요.
디자인 페어링은 두 명의 디자이너가 문제, 제품 또는 프로젝트에 대해 함께 작업하는 경우입니다. 페어링은 협업을 통한 학습을 장려하고 팀에 많은 베네핏 제공합니다.
- 작업의 더 나은 목표설정과 우선 순위 지정
- 신선한 관점과 실시간 피드백
- 강화된 책임의식
- 빠른 지식 공유
- 빠른 피드백을 통한 더 나은 디자인
- 설계 결정에 대한 자신감 증가
- 미래 설계 부채 감소
작업한 디자인을 다시 리뷰하세요.
스스로에게 완성된 디자인에 다시 질문하세요. 화면에서 이 요소를 제거할 수 할수 있을까? 제거하면 어떻게 될까? 이는 불필요한 정보로 디자인을 깔끔하게 정리하는 데 도움이 될 뿐만 아니라 디자인 근거에 대한 확신을 얻는 데 도움이 됩니다.
증거로 결정 뒷받침하세요.
디자인 근거를 명확히 설명하고 뒷받침할 수 있다는 것은 제품 디자이너로 역할중 큰 부분입니다. 제품과 모범 사례를 수집하여 하나의 파일로 조합하고 특정 사용 사례에서 작동하거나 작동하지 않을 수 있는 항목을 강조 하세요. 이 사고 과정은 이해 관계자에게 2가지 모습을 보여줄 수 있습니다.
- 다른 대안을 시각화하고 그것이 효과가 있거나 없는 이유를 볼 수 있도록 돕습니다.
- 여러 옵션을 고려하고 있으며 정보에 입각한 결정을 내리고 있음을 보여주고 있습니다.
여러분은 디자이너입니다.
이 학습은 여러분이 디자이너로 고용된 이유가 있다는 것을 상기시켜줍니다.
디자인 관련 항목을 논의할 때 디자인에 대한 책임과 소유권이 부여되었음을 기억하세요. 주도권을 잡고 항상 더 선임 팀 구성원(특히 비디자이너)의 의견에 의존하지 마세요. 주도하는 것이 편하지 않다면 다음과 같은 것들이 도움이 될 수 있습니다.
- 다른 디자이너와 확신이 서지 않을 수 있는 부분을 논의하세요.
- 설계 프로세스를 최적화하기 위한 프레임워크 구축 시작하세요.
특정 문제나 기능의 중요성을 과대평가하고 마세요.
어려운 문제를 다룰 때 사용자와 완전히 공감할 수 있도록 몰입해야 합니다. 이러한 몰입은 우리가 이 문제의 중요성을 너무 많이 확대하는 결과를 초래할 수 있는 "집중 착시"로 이어질 수 있습니다. 이를 피하는 몇 가지 방법은 다음과 같습니다.
- 사용자 경험 맵 : 전체 경험에 대한 전체적 관점을 얻기 위해 살펴보세요.
- 사용자 조사 : 사용 상황 및 수행할 여러 작업에 대한 다양한 정보를 얻습니다.
- 디자인 페이링 : 집중 착시가 일어날 문제에 대해 다른 디자이너로부터 새로운 관점을 얻으세요.마인드셋
직무 분석
2022/03/16
주니어
중니어
UI/UX 디자인에서 프레젠테이션 스킬을 마스터 하는 법
Open
UI/UX 디자인에서 프레젠테이션 스킬을 마스터 하는 법
UI/UX 분야에서 첫 커리어를 시작할 때 대부분의 사람들은 디자인, 문제, 해결책, 분석, 연구, 프로토타이핑 또는 UX writing과 같은 어려운 기술을 생각합니다.
UX디자이너로서 성공하기 위한 기본적인 역량이지만, 프레젠테이션 및 커뮤니케이션 스킬의 중요성을 쉽게 생각하지 않는 것이 중요합니다.
프레젠테이션 기술은 아이디어, 개념 및 디자인 정보를 효과적으로 구현하는 데 사용되며, 프레젠테이션 기술이 UX/UI 디자이너로서의 커리어에 도움이 될 수 있는 방법이 있습니다.
왜 프레젠테이션 스킬은 UI/UX 역할에 중요한가?
디자인 프로세스는 커리어의 핵심일 수 있지만 모든 프로젝트에서 함께 일하는 사람들과 협력하고 설득해야 합니다.
1 : 포트폴리오 프레젠테이션
눈에 띄는 디자인 포트폴리오를 만드는 데 많은 시간과 에너지를 쏟아 부은 후에는 경쟁에서 눈에 띄는 데 도움이 될 것입니다.
자신의 작업을 명확하고 자신 있게 표현할 수 있는 것도 중요합니다.
2 : 반복적인 디자인 공유 (리뷰)
연구와 데이터를 기반으로 특정 디자인이나 목업을 어떻게 생각해 냈습니까? 전체적인 관점을 간결하게 제시하는 방법을 알면 팀이 훨씬 더 빨리 좋은 솔루션에 도달하는 데 도움이 될 수 있습니다.
3 : 최종 디자인 발표
자신감 있고 명확한 프레젠테이션은 최종 승인을 위한 강력한 스킬입니다. 긴장, 신뢰 부족 등으로 부적절한 소통을 하게되면 문제가 될 수 있으나, 강력하고 합리적인 프레젠테이션은 청중이 디자인 솔루션을 새롭고 긍정적인 관점에서 보도록 설득하는 데 도움이 될 수 있습니다.
UI/UX 프레젠테이션 스킬 향상을 위한 10가지 팁!
전략적 목표를 설정하고 청중의 참여를 유도하는 것부터 긍정적인 사고 방식을 위한 준비 및 계획에 이르기까지 프레젠테이션 기술을 향상시키는 데 도움이 될 수 있는
10가지 방법이 있습니다.
1 : 프레젠테이션의 명확한 목표 결정
- 프레젠테이션을 통해 달성하고자 하는 바를 파악하는 시간을 가지세요.
- 잠재적 고용주에게 포트폴리오를 보여주고 있는 지, 새로운 아이디어를 시도하도록 설득하려는 지 생각하세요.
- 프레젠테이션의 전체적인 구조와 전달하려는 요점을 계획하세요.
2 : 간결하고 명확한 주제 설정
- 간결하고 하나의 핵심 주제에 집중하세요.
- 글머리 기호를 사용하거나 시각적 그래프를 만드세요.
- 이해하기 쉬운 콘텐츠로 청중을 더 몰입하게 하세요.
3 : 프레젠테이션에 유머 가미
- 유머는 청중이 긴장을 풀고 친밀감을 형성하도록 도움되는 스킬입니다.
- 요점을 설명하기 위해 자신에 대한 재밌는 일화를 포함해보세요.
- 대규모 그룹에 전달하기 전에 신뢰할 수 있는 동료나 친구에게 유머를 시도해보세요.
4 : 프레젠테이션에 유머 가미
- 유머는 청중이 긴장을 풀고 친밀감을 형성하도록 도움되는 스킬입니다.
- 요점을 설명하기 위해 자신에 대한 재밌는 일화를 포함해보세요.
- 대규모 그룹에 전달하기 전에 신뢰할 수 있는 동료나 친구에게 유머를 시도해보세요.
5 : 청중 참여 유도
- 직접적인 질문을 사용하여 의견을 구하세요
- 손을 들어달라는 요청을 하여 청취자가 자신의 의견이 가치 있게 느끼도록 도와줄 수 있습니다.
6 : 프레젠테이션 마지막 요약 포함
- 프레젠테이션 길이가 아주 긴 경우, '마무리' 슬라이드를 넣어주세요.
- 이 페이지에서는 목표를 다시 확인하여 1~3가지 주요 요점으로 골라주세요.
7 : 열정 나누기
- 열정적인 대화를 나누기 위해 청중이 어떤것에 관심이 있는지 미리 생각해보세요.
- 청중과 소통하는 방법을 찾으세요.
8 : 내용 숙지
- 프레젠테이션의 전체적인 내용을 숙지하는 시간을 가지세요.
9 : 연습, 연습, 또 연습
- 집에 있는 거울이나 몇 명의 신뢰할 수 있는 동료나 친구 앞에서 수행해보세요.
10 : 긍정적인 마이드 유지
- 프레젠테이션 전에 숙면을 취하세요.
- 명상, 호흡운동, 아침 러닝 등 긍정적인 감정을 느끼는 데 도움되는 일을 해보세요.
- 발표에 대한 두려움이 있다면 마음속으로 아래 내용처럼 읊어보세요.
- 나는 잘 준비되어 있습니다. 나는 발표할 준비가 되어있다, 나는 사람들과 연결하는 것을 즐긴다, 이 정보를 공유하게 되어 기쁩니다
Conclusion
UX디자이너로서 커리어에 있어서는 프레젠테이션도 중요합니다.
효율성을 높이고 면접관, 이해 관계자 및 팀 구성원이 작업을 이해하도록 하려면 의사 소통 및 프레젠테이션 기술을 예리하게 유지하는 것도 똑같이 중요합니다.
이는 많은 연습과 경험을 통해 얻을 수 있는 기술이며, 해당 분야의 경험 많은 전문가로부터 피드백을 구할 때 향상될 수 있습니다.마인드셋
프로덕트 전략
PM/PO
워크플로우
2022/03/15
중니어
주니어
SaaS 스타트업에서 디자인 프로세스 실행하기
Open
2019년 약 3년 전 센드버드 디자인팀에서 작성한 글입니다.
알아보니 당시 센드버드는 시리즈 B 투자(약 586억원)를 받았네요.
실제 스타트업 팀의 경험에서 나온 이야기라 좋은 글이라고 생각합니다.
-
프로세스를 만들기 전 센드버드 디자인(UX)팀은 크게 3가지 문제를 발견
- 문제 1. 프로젝트 우선순위와 배경 공유
- 기존에는 프로젝트에 참여하는 디자이너, 개발자 모두 다수의 일을 동시에 진행하는 시스템
- 즉흥적 판단으로 우선순위를 정하고 의논
- 히스토리가 기록되지 않아 다른 사람이 배경을 이해하기 어려움
- 문제 2. 디자인 결정사항에 대한 기준과 자료 분석
- 벤치마킹, 고객의견, 페르소나, 시장조사 등이 개인적 차원에서만 이루어짐
- 결국 적절한 참고자료인지 재확인 필요
- 문제 3. 제품 전체에 대한 디자인 목표 정의
- 슬랙이나 구두로 급하게 오고간 경우가 많고 제품에 대한 균일한 목표가 없었음
- 이해하고 있는 정의와 목표도 멤버마다 다름
해결점: 우리에게 맞는 디자인 프로세스 만들기
- 작업과정 시각화 하기
- 전체 UX 설계 과정을 하나의 문서로 시각화
- 결과의 공유보다는 각 프로세스별 과정을 공유하는 것에 집중
- 프로젝트 배경과 요구사항 이해하기
- 현재의 UX 플로우 분석
- 고객이 제품을 쓰고 있는 상태를 파악하고 문제 찾기
- UX 관련 정량적, 정성적 데이터 사용하기
- 고도화된 비슷한 서비스 참고하고 표로 제작
- UX 문제 확인과 우선순위 정하기
- 기능 추가는 페이지 추가를 겸함
- 발생할 수 있는 문제를 미리 점검
- UX 플로우를 그려 변경되야하는 부분 파악
- 와이어프레임
- 문제의 본질에 집중하기 위해 일반적인 형태로 그리고 논의와 수정을 반복
디자인 프로세스의 결과
- 다른 팀과 협업 시, 공유 요소 전반을 파악하기 용이
- 제품에 대한 각기 다른 관점과 불확실성으로 인한 피로도 해소
- 투명한 소통으로 UX 개선에 대한 이해도 높임
- 개진 의견에 설득력이 높아짐
- 프로젝트 요구사항과 제한영역은 명료해짐
- 다른 팀과 협의가 편리해짐
배우게 된 것
- 처음에는 디자인 과정이 정방향일거라 예상
- 실제로는 전 단계로 돌아가 재검토와 개선을 거듭
- 이슈를 확인하고 UX 플로우가 맞는 방향으로 흐르는지 점검의 연속
- 아쉽게도 해야할 일은 더 늘어남
- 프로세스는 디자인 팀이 타 팀과 협의 시 도움이 됨
- 유동적으로 피드백이 반영된, 정보에 기반한 결정을 할 수 있게 됨
다음 단계는
- 잘 알려진 방법론이나 프로세스를 그대로 차용하지 않음
- 센드버드에 맞는 업무 방식과 부족한 부분이 무엇인지 생각하면서 실험
경험 공유
실 사례
프레임워크
2022/03/07
기획자
SaaS 제품 담당자
UX 디스커버리 단계에서의 문제 설명
Open
UX 디스커버리 단계에서의 문제 설명
요약: 문제 설명은 해결해야할 문제에 대한 간략한 설명이다. UX 디자인 프로세스의 초기단계인 ‘디스커버리’ 에서 문제 설명을 작성하면 문제에 대한 동의 및 추후 프로세스에 대한 방향을 제시할 수 있다. 문제 설명을 구성하려면 문제가 누구에게, 어떻게 영향을 미치는지, 문제를 해결하는 것이 왜 중요한지 중점을 둔다.
문제 설명에는 아래 사항들이 포함되어야 한다.
1. 문제의 배경
* 어떤 부서/조직이 문제를 겪고 있는가? 어떻게 대두 되었는가? 문제의 근본 원인 파해치기
2. 문제의 영향을 받는 사람들
3. 문제가 조직에 미치는 영향
* 문제가 해결되지 않았을 때 조직에 어떤 결과를 가져올지? 비용이 얼마나 드는지?
문제 설명에 도움을 주는 5Ws (다섯개의 W)
* 아래 질문들에 대한 답을 한번에 답하지 않아도 된다. ‘디스커버리' 단계에서 해결해야할 문제이며 언제든지 돌아가서 문장에 대한 답을 추가할 수 있다.
* 누가 문제의 영향을 받는지? (Who is affected by the problem)
* 문제가 무엇인지? (What is the problem?)
* 어디서 문제가 발생하는지? (Where does this problem occur?)
* 언제 문제가 발생하는지? (When does the problem occur?)
* 왜 문제가 발생한는지? 왜 이 문제가 중요한지? (Why does the problem occur? Why is the problem important?)
문제 설명은 목적에 맞게 잘 작성되어야한다.
* 하나의 문제에 초점을 맞출 것
* 관련 없는 문제를 나열하는 건 너무 많은 문제를 해결하려고 있다는 신호다.
* 솔루션을 포함하지 않는다.
* 디스커버리 단계는 최적의 솔루션이 뚜렷하게 그려지지 않는다.
* 간략하게 할 것.
* 문제 설명을 간단한 문장으로 표현할 수 있으면 그 문제에 집중하는 이유를 사람들이 빠르게 이해할 것이다.
문제는 항상 부정적이여야 한다? 오히려 기회를 포착할 수 있다!
* 우리의 현재 상태와 미래에 원하는 모습의 차이를 강조해야한다. 우리가 목표하는 것은 무엇인지?
문제 설명을 활용하는 법
* 문제를 설명하는 것은 디스커버리 단계를 구조화 하기 위한 출발점으로 활용할 수 있다. 문제에 대해 알고 싶은 여러 질문들을 통해 문제를 더욱 구체화 하며 ‘진짜' 문제가 무엇인지 파악할 수 있다UX
일반 이론
2022/03/04
주니어
중니어
'효율적인 B2B 데이터 시각화'를 위한 디자인
Open
2020년에 세일즈포스 분석 UX팀에서 작성한 B2B 데이터 시각화 디자인에 대한 이야기 입니다.
원글(링크)에 예시 디자인과 자세한 사례가 있으니 꼭 확인해보세요!
접근 방법
- 세일즈 매니저가 주간 팀미팅 때 20초 정도 쓰는 상황 상상해보기
- 팀의 세일즈 퍼포먼스를 읽는 가장 좋은 방법은 뭘까?
핵심 목표
- 데이터 시각화 디자인은 사용자가 리스크는 피하고, 좋은 비즈니스 결정을 할 수 있게 돕는 것
- 20초를 보든, 2시간 동안 숫자를 검토하든 마찬가지
- 아무리 복잡한 데이터여도, 넓은 산업분야 사용자들의 문제해결을 돕고자 했음
- 실행가능(인사이트 만들기)하고 효율적(즉각적인 행동 가능)이면서, 확장 가능하고 유연한 패턴이 필요했음
목표 지원을 위한 '3가지 단계' 요약
1. 사용자의 정보 수요 이해하기
- 페르소나 개발
- 질문 브레인스토밍해서 정보 수요 모으기
- 아이데이션 작업과 사용자 테스팅 진행
2. 근본적인 사용 케이스와 함께 설계하기
(모범 사례에 적용되는 것, 우리 분석 앱에서 주로 쓰이는 것들을)
5가지 기능적 패턴으로 분류함
- 벤치마킹
- 퍼포먼스 트렌딩
- 세그먼팅
- 포커스
- 상태 분포
3. 설계 모범 사례 확장하기
- 디자인 패턴을 만든 다음, 일치(align)시킬 시간
- 디자인 팀이 효율적으로 활용할 수 있게 라이브러리 제공
디자인 시 조언/팁 (recommendations)
- 목적을 염두해두기
- 이해관계자와 소통하기
- 라이브러리 만들기
원글(링크)에 예시 디자인과 자세한 사례가 있으니 꼭 확인해보세요!
접근 방법
- 세일즈 매니저가 주간 팀미팅 때 20초 정도 쓰는 상황 상상해보기
- 팀의 세일즈 퍼포먼스를 읽는 가장 좋은 방법은 뭘까?
핵심 목표
- 데이터 시각화 디자인은 사용자가 리스크는 피하고, 좋은 비즈니스 결정을 할 수 있게 돕는 것
- 20초를 보든, 2시간 동안 숫자를 검토하든 마찬가지
- 아무리 복잡한 데이터여도, 넓은 산업분야 사용자들의 문제해결을 돕고자 했음
- 실행가능(인사이트 만들기)하고 효율적(즉각적인 행동 가능)이면서, 확장 가능하고 유연한 패턴이 필요했음
목표 지원을 위한 '3가지 단계' 요약
1. 사용자의 정보 수요 이해하기
- 페르소나 개발
- 질문 브레인스토밍해서 정보 수요 모으기
- 아이데이션 작업과 사용자 테스팅 진행
2. 근본적인 사용 케이스와 함께 설계하기
(모범 사례에 적용되는 것, 우리 분석 앱에서 주로 쓰이는 것들을)
5가지 기능적 패턴으로 분류함
- 벤치마킹
- 퍼포먼스 트렌딩
- 세그먼팅
- 포커스
- 상태 분포
3. 설계 모범 사례 확장하기
- 디자인 패턴을 만든 다음, 일치(align)시킬 시간
- 디자인 팀이 효율적으로 활용할 수 있게 라이브러리 제공
디자인 시 조언/팁 (recommendations)
- 목적을 염두해두기
- 이해관계자와 소통하기
- 라이브러리 만들기UX
프레임워크
가이드
2022/02/21
기획자
SaaS 제품 담당자
훌륭한 문제 진술을 작성하기 위한 7가지 방법
Open
문제 진술 Problem Statement
유저가 사랑하는 프로덕트를 출시하고 싶다면, 당신이 풀고자 하는 문제가 무엇이고 왜 문제인지 명확하게 이해해야 합니다. 프로젝트를 시작할 때는 ‘문제'로부터 시작합니다. PM이라면 우리가 고객을 위해 실제로 풀고있는 문제가 무엇인지 깊게 리서치하고 이해해야합니다. 생각을 정리하고 팀에게 명확하게 전달하기 위해 ‘문제 진술'을 작성하세요.
문제 진술을 작성하는 것은 얼핏 형식적이고 간단한 작업처럼 보일 수 있지만, 막상 작성해보면 고객에 대한 깊은 이해와 추상적 개념을 명문화하는 능력이 요구되는 어려운 작업입니다. 생각하고, 쓰고, 다시쓰고, 연구해야합니다.
문제 진술 초안을 작성할 때 도움이 되는 7가지 방법을 소개합니다.
솔루션으로부터 시작하기
디자인 단계보다 문제 정의가 프로세스상 먼저이지만, 사람들은 솔루션을 먼저 떠올리는 경향이 있습니다. 솔루션이나 아이디어로부터 문제를 찾게되는 경우가 많습니다. 이런 경우 근본적인 문제를 향해 거꾸로 작업해야 합니다. 당신이 이미 특정 제품을 개발하고 있더라도, 좋은 문제 진술을 통해 어떤 부분이 고객에게 가장 유용할지 인지할 수 있으며, 보다 고객에게 중요한 문제를 푸는 곳에 팀의 에너지를 집중시킬 수 있습니다.
스스로 자문해 볼 질문
- 이 솔루션으로 풀 수 있는 문제가 무엇인가
- 왜 나는 고객이 이 솔루션을 선호할 것이라고 생각하는가
잘못된 답변 시도하기
보통, 고객의 진짜 문제가 무엇인지 찾는 것은 매우 도전적입니다. 딱 보기에 잘못된 솔루션에서부터 생각해나가는 것은 좋은 솔루션의 영역을 정의하는데 도움이 됩니다. 어떤 부분 때문에 이 솔루션을 적용할 수 없는지 스스로에게 물어보고 그것을 문제 진술에 포함시킵니다. 반대로, 고객 중심으로 생각했을 때 솔루션에서 잘못된 부분을 찾을 수 없다면 고려할 가치가 있는 솔루션이라는 증거입니다.
고객과 다시 이야기 나눠보기
"고객과 얘기하라"는 기본적인 조언이지만, 당신이 이미 고객의 세계에 빠져있다고 하더라도 고객이 달성하고자 하는 디테일들이 무엇인지, 문제가 무엇인지 정확히 설명하기가 어려울 수 있습니다. 이 시점에서 가장 빠른 방법은 다시 돌아가서 고객과 명확하게 얘기해보는 것입니다. 모호한 개념이나 문제의 우선순위는 제품을 사용하는 사람과 이야기할 때 명확하게 해소됩니다.
사람에게 초점 맞추기
솔루션을 구매하고 사용하는 것은 사람이기 때문에, 좋은 문제 진술은 사람(들)의 문제에 초점을 맞춰야 합니다. 만약 당신이 문제 정의에 어려움을 겪는다면 관련된 사람들이 느끼는 구체적인 문제를 설명하려고 노력하세요.
솔루션 디자인 시작하기
대부분의 문제 진술은 반복적으로 작성됩니다. 솔루션 앞에 놓여지는 모든 제약들을 미리 완벽하게 나열하는 것은 매우 어렵기 때문에, 때때로 솔루션 디자인을 시작하는게 더 쉽습니다. 특히 막혔다고 느낄 때 이렇게 접근하면 기존에 고려하지 못했던 관점과 가능성을 열어줄 수 있습니다.
서문 건너뛰기
몇몇 이유때문에 종종 PM은 문제 진술 초반에 히스토리를 추가합니다. 그러지 마세요. 그것은 보통 당신이 고객 문제를 명확하게 이해하지 못했다는 것을 의미합니다. “지난 분기에 우리는 XYZ 기능을 출시했고...”로 시작하는 대신, 고객이 무엇을 원하는지, 이러한 니즈가 발생하는 시기, 그들이 원하는것을 얻기 위해 무엇을 시도하는지로 바로 건너뛰세요. 포커싱된 문제 진술은 디자인 및 빌드 프로세스 전반에서 나머지 팀원들의 관점을 일치시키는데 도움이 됩니다.
판단하는 용어 쓰지않기
훌륭한 문제 진술은 당신의 고객과 고객의 니즈에 대한 팩트를 얘기합니다. 문제 프레임 안에서 솔루션을 판단하는 용어를 사용하지 마세요. “너무 느림”, “디자인이 나쁨", “혼란스러움" 과 같은 판단 용어는 모호하며 읽는이마다 다르게 해석할 수 있습니다. 이를 데이터 기반의 진술문으로 대체해야합니다. “우리의 온보딩 프로세스가 혼란스럽다”라는 말 대신, 고객이 무엇때문에 혼란스러워하는지 명확하게 언급하세요.
문제 진술은 어렵습니다. 그러나 올바른 작업을 수행하는 것이 팀이 딜리버리하는 제품의 퀄리티를 결정하기 때문에 매우 중요합니다. 제품이 얼마나 잘 설계되고 확장 가능한지 여부는 상관없습니다. 고객은 궁극적으로 의미있는 문제를 해결하지 못하는 제품을 사용하지 않을 것입니다.문서 작성법
2022/02/15
주니어
중니어
조직과 프로젝트를 성공적으로 매니징하기 위한 필독서 [The Goal]
Open
앨리 골드렛의 The Goal은 TOC(Theory of Constraints, 제약 이론)을 이해하기 쉽게 설명한 경제경영서 베스트셀러 중 하나입니다. 비록 제조업을 기반으로 이야기가 흘러가지만 그 안에 담긴 전체 최적화 프레임워크와 발전적 사고 프레임워크는 많은 곳에 적용 가능한 범용적인 방법론이 될 수 있습니다. 아래는 The Goal 책 내용과 재구조화 해 정리한 내용입니다.
회사의 목표는 ‘돈을 버는 것’
회사가 돈을 벌기 위해서는 무언가를 판매해야 하고, 무언가를 판매하기 위해서는 무언가를 생산해야 합니다.
• 생산하기 위해 드는 비용이 ‘운영 비용’
• 생산되었지만 판매되지는 않은 것들이 ‘재고’
• 판매를 통해 돈을 창출하는 비율이 ‘현금 창출률'입니다.
회사가 돈을 벌려면 재고와 운영 비용을 낮추면서 현금 창출률을 높여야 합니다.
생산 과정에서는 필요한 만큼 충분히 생산하지 못하는 병목이 있기 마련이고, 그 병목의 생산 효율성이 전체 생산 효율성을 결정합니다. (쇠사슬의 강도는 가장 약한 고리가 결정함)
병목 자원(=제약 자원)의 생산 효율성을 높이는 것이 전체 생산 효율성을 높이는데 가장 중요합니다.
제약 자원의 생산 효율성을 높이기 위해서는
1. 제약 자원이 현 상태에서 가장 효율적으로 일할 수 있도록 개선합니다.
- 끊임없이 일할 수 있도록 함
2. 해당 제약 자원을 기준으로 다른 공정의 생산 일정이 종속되도록 시스템을 조정합니다.
- 제약 자원에게 공급할 부품 생산을 역산하고, 제약 자원의 생산량으로 이후 생산 일정을 역산함
3. 제약 자원의 생산 효율성을 높입니다.
- Input을 개선
- 제약 자원이 필요로 하는 일을 먼저 하기
- 제약 자원이 하지 않아도 되는 일을 줄이기
- 1회 목표 생산량을 줄이기 (1회 목표 생산량을 줄이면 생산 속도가 빨라지고, 변동성에 대한 유연성이 높아짐)
- 제약 자원 자체를 개선
- 덜 효율적이더라도 같은 역할을 할 수 있는 자원을 추가 사용
- 한 번에 처리할 수 있는 업무는 동시에 처리하기
- Output을 개선
- 병목 자원이 생산한 부품을 먼저 판매할 수 있도록 우선 가공
공정 뿐 만 아니라, 일반적인 경우에도 통할 수 있는 발전적 사고 프레임워크로 치환할 수 있습니다.
1. 문제 정의 :: 무엇을 변화시켜야 할지 발견하기
2. 목표 설정 :: 어떤 방향으로 변화시켜야 하는지 결정하기
3. 실행 방법, Operation :: 어떻게 변화시킬지 결정하기
4. 수행한 변화가 더 이상 성과에 영향을 미치지 않게 되면 다시 1단계로 돌아가기
제약 자원의 생산 효율성 개선과 발전적 사고 프레임워크의 적용 예시
• 전략 보고서의 흐름을 문제 정의 → 목표 설정 → 실행 방법 순으로 전달
• 업무를 보고했을 때 상사가 원했던 퀄리티나 내용이 아니게 되는 문제 → 전체 업무를 한 번에 완성시켜 전달하기 때문에 개선할 시간이 없는것이 문제 → 1회 목표 생산량을 줄여 전체 드래프트를 자주 공유하고 디벨롭 시켜 나가기
• 시장의 수요가 생산력보다 넘친다면 ‘생산력’이 문제 → 생산력을 개선하는 목표 설정 → 설비를 더 들여오거나, 인력을 더 채용하는 결정
• 시장 수요보다 생산력이 넘친다면 ‘시장’이 문제 → 시장을 개선하는 목표 설정 → 마케팅을 강화하거나, 새로운 시장을 발굴하는 결정
회사의 목표는 ‘돈을 버는 것’
회사가 돈을 벌기 위해서는 무언가를 판매해야 하고, 무언가를 판매하기 위해서는 무언가를 생산해야 합니다.
• 생산하기 위해 드는 비용이 ‘운영 비용’
• 생산되었지만 판매되지는 않은 것들이 ‘재고’
• 판매를 통해 돈을 창출하는 비율이 ‘현금 창출률'입니다.
회사가 돈을 벌려면 재고와 운영 비용을 낮추면서 현금 창출률을 높여야 합니다.
생산 과정에서는 필요한 만큼 충분히 생산하지 못하는 병목이 있기 마련이고, 그 병목의 생산 효율성이 전체 생산 효율성을 결정합니다. (쇠사슬의 강도는 가장 약한 고리가 결정함)
병목 자원(=제약 자원)의 생산 효율성을 높이는 것이 전체 생산 효율성을 높이는데 가장 중요합니다.
제약 자원의 생산 효율성을 높이기 위해서는
1. 제약 자원이 현 상태에서 가장 효율적으로 일할 수 있도록 개선합니다.
- 끊임없이 일할 수 있도록 함
2. 해당 제약 자원을 기준으로 다른 공정의 생산 일정이 종속되도록 시스템을 조정합니다.
- 제약 자원에게 공급할 부품 생산을 역산하고, 제약 자원의 생산량으로 이후 생산 일정을 역산함
3. 제약 자원의 생산 효율성을 높입니다.
- Input을 개선
- 제약 자원이 필요로 하는 일을 먼저 하기
- 제약 자원이 하지 않아도 되는 일을 줄이기
- 1회 목표 생산량을 줄이기 (1회 목표 생산량을 줄이면 생산 속도가 빨라지고, 변동성에 대한 유연성이 높아짐)
- 제약 자원 자체를 개선
- 덜 효율적이더라도 같은 역할을 할 수 있는 자원을 추가 사용
- 한 번에 처리할 수 있는 업무는 동시에 처리하기
- Output을 개선
- 병목 자원이 생산한 부품을 먼저 판매할 수 있도록 우선 가공
공정 뿐 만 아니라, 일반적인 경우에도 통할 수 있는 발전적 사고 프레임워크로 치환할 수 있습니다.
1. 문제 정의 :: 무엇을 변화시켜야 할지 발견하기
2. 목표 설정 :: 어떤 방향으로 변화시켜야 하는지 결정하기
3. 실행 방법, Operation :: 어떻게 변화시킬지 결정하기
4. 수행한 변화가 더 이상 성과에 영향을 미치지 않게 되면 다시 1단계로 돌아가기
제약 자원의 생산 효율성 개선과 발전적 사고 프레임워크의 적용 예시
• 전략 보고서의 흐름을 문제 정의 → 목표 설정 → 실행 방법 순으로 전달
• 업무를 보고했을 때 상사가 원했던 퀄리티나 내용이 아니게 되는 문제 → 전체 업무를 한 번에 완성시켜 전달하기 때문에 개선할 시간이 없는것이 문제 → 1회 목표 생산량을 줄여 전체 드래프트를 자주 공유하고 디벨롭 시켜 나가기
• 시장의 수요가 생산력보다 넘친다면 ‘생산력’이 문제 → 생산력을 개선하는 목표 설정 → 설비를 더 들여오거나, 인력을 더 채용하는 결정
• 시장 수요보다 생산력이 넘친다면 ‘시장’이 문제 → 시장을 개선하는 목표 설정 → 마케팅을 강화하거나, 새로운 시장을 발굴하는 결정마인드셋
PM/PO
프레임워크
일반 이론
2022/02/14
중니어
시니어
비 디자이너에게 디자인 피드백 받는 방법
Open
[비 디자이너에게 디자인 피드백을 받는 방법]
대부분의 디자인 피드백은 디자인 이론과 테크닉에 익숙하지 않은 비 디자이너에게 받는 경우가 많습니다. 이럴 때 디자이너는 방어적이고 거만하게 반응됩니다. 하지만 이런 비 디자이너의 피드백은 비즈니스 가치 질문, 한 번도 고려하지 않은 상호 작용, 심지어 더 나은 아이디어를 포함한 정보를 가지고 있다는 것을 명심해야 합니다.
“조금더 튀어야해”
이 내용은 시각적 디자인에 문제가 있지만 그것을 표현할 수 있는 미적 어휘가 부족한 사람을 위한 포괄적인 피드백입니다.
이때에 디자이너들은 숨을 깊게 마신 다음, 무엇을 문제를 삼는지 심도 있게 확인할 필요가 있습니다.
“음, 사실… 우리는 이미 시도했습니다… 그것은 기술적으로 어렵습니다…우리 상황에서 알맞지 않아요.”
종종 이렇게 말하는 사람은 작업 중인 도메인이나 제품에 대한 깊은 지식을 가지고 있습니다. 그들은 현상 유지에서 최선이며 일반적으로 상당히 타당합니다. 이럴 때 그 과거의 상황을 자세히 알아보고, 좀 더 적극적으로 설득할 수 있는 방법을 찾아야 합니다.
“이미 유행에 지난 방식이에요”
이것은 방어적이고 사소한 피드백뿐입니다. 대부분의 사람들은 이 말을 하는 이유가 ... 단지 뭐라도 스마트에게 말 하고 싶은 것입니다. 열에 대부분은 이런 피드백에서 깊이를 찾기 어렵습니다.
“특정 앱과 많이 닮아 있어요”
간단하게 “사용자에게 친숙할 것입니다!”라는 피드백입니다. 심플하게 인정하고 마케팅이나 다른 요소를 통해 이 프로덕트를 돋 보일 수 있는 방향을 생각해 볼 수 있습니다.
"나는 좋아하지만, 가능한지 여부에 대한 파악이 필요해요.”
디자인을 지지를 주었으므로 이미 절반의 승리를 거둔 것입니다! 이런 대화 뒤에는 바로 디자인을 구현/판매/마케팅 방법이 파악되어야 합니다.
❗️이런 피드백을 더욱 현명하게 다룰수 있는 몇가지 팁을 소개하겠습니다.
공감하기
어렵겠지만 일단은 피드백에 공감을 표현한다면 친절한 디자이너가 되는 데 절반은 성공했습니다.
감정 컨트롤 하기
의식적으로 노력해야 하는 것입니다. 일시 정지, 호흡, 물 한 모금 같은 행동을 통해 단 몇 초 만에 즉각적인 방어 반응을 10에서 2로 낮출 것입니다. 추후에 이어지는 상황을 위해서라도, 이런 노력은 자신과 제품에 도움이 되고 유익하게 될것 입니다.
전문용어 피하기
스마트해 보이는 학문적이고 전문 용어가 많은 답변은 다른 사람들이 디자인 의도를 이해하기 어렵게 만듭니다.
설명 요청하기
성급하게 결론을 내리는 것이 논쟁을 일으킵니다. 의미하는 바가 즉시 명확하지 않은 경우 설명을 요청하는 습관을 가지세요.
중요하지 않은 것은 무시하기
주요 디자인 리뷰는 10~50개 정도 살펴봐야 합니다. 모든 사람을 방어하면 머리카락이 모두 빠질 뿐만 아니라 팀에서 신뢰도 잃게 됩니다. 깊이 관심을 갖는 것에 우선순위를 두고 나머지는 타협하세요.
솔루션의 일부로 만들기
마지막으로, 항상 비 디자이너가 솔루션을 제안하고 참여하도록 권장해야 합니다. 제품 팀의 모든 사람은 창의적인 솔루션을 만들 가능성이 열려 있습니다.
비 디자이너에게 디자인 피드백을 받는 방법]
대부분의 디자인 피드백은 디자인 이론과 테크닉에 익숙하지 않은 비 디자이너에게 받는 경우가 많습니다. 이럴 때 디자이너는 방어적이고 거만하게 반응됩니다. 하지만 이런 비 디자이너의 피드백은 비즈니스 가치 질문, 한 번도 고려하지 않은 상호 작용, 심지어 더 나은 아이디어를 포함한 정보를 가지고 있다는 것을 명심해야 합니다.
“조금더 튀어야해”
이 내용은 시각적 디자인에 문제가 있지만 그것을 표현할 수 있는 미적 어휘가 부족한 사람을 위한 포괄적인 피드백입니다.
이때에 디자이너들은 숨을 깊게 마신 다음, 무엇을 문제를 삼는지 심도 있게 확인할 필요가 있습니다.
“음, 사실… 우리는 이미 시도했습니다… 그것은 기술적으로 어렵습니다…우리 상황에서 알맞지 않아요.”
종종 이렇게 말하는 사람은 작업 중인 도메인이나 제품에 대한 깊은 지식을 가지고 있습니다. 그들은 현상 유지에서 최선이며 일반적으로 상당히 타당합니다. 이럴 때 그 과거의 상황을 자세히 알아보고, 좀 더 적극적으로 설득할 수 있는 방법을 찾아야 합니다.
“이미 유행에 지난 방식이에요”
이것은 방어적이고 사소한 피드백뿐입니다. 대부분의 사람들은 이 말을 하는 이유가 ... 단지 뭐라도 스마트에게 말 하고 싶은 것입니다. 열에 대부분은 이런 피드백에서 깊이를 찾기 어렵습니다.
“특정 앱과 많이 닮아 있어요”
간단하게 “사용자에게 친숙할 것입니다!”라는 피드백입니다. 심플하게 인정하고 마케팅이나 다른 요소를 통해 이 프로덕트를 돋 보일 수 있는 방향을 생각해 볼 수 있습니다.
"나는 좋아하지만, 가능한지 여부에 대한 파악이 필요해요.”
디자인을 지지를 주었으므로 이미 절반의 승리를 거둔 것입니다! 이런 대화 뒤에는 바로 디자인을 구현/판매/마케팅 방법이 파악되어야 합니다.
❗️이런 피드백을 더욱 현명하게 다룰수 있는 몇가지 팁을 소개하겠습니다.
공감하기
어렵겠지만 일단은 피드백에 공감을 표현한다면 친절한 디자이너가 되는 데 절반은 성공했습니다.
감정 컨트롤 하기
의식적으로 노력해야 하는 것입니다. 일시 정지, 호흡, 물 한 모금 같은 행동을 통해 단 몇 초 만에 즉각적인 방어 반응을 10에서 2로 낮출 것입니다. 추후에 이어지는 상황을 위해서라도, 이런 노력은 자신과 제품에 도움이 되고 유익하게 될것 입니다.
전문용어 피하기
스마트해 보이는 학문적이고 전문 용어가 많은 답변은 다른 사람들이 디자인 의도를 이해하기 어렵게 만듭니다.
설명 요청하기
성급하게 결론을 내리는 것이 논쟁을 일으킵니다. 의미하는 바가 즉시 명확하지 않은 경우 설명을 요청하는 습관을 가지세요.
중요하지 않은 것은 무시하기
주요 디자인 리뷰는 10~50개 정도 살펴봐야 합니다. 모든 사람을 방어하면 머리카락이 모두 빠질 뿐만 아니라 팀에서 신뢰도 잃게 됩니다. 깊이 관심을 갖는 것에 우선순위를 두고 나머지는 타협하세요.
솔루션의 일부로 만들기
마지막으로, 항상 비 디자이너가 솔루션을 제안하고 참여하도록 권장해야 합니다. 제품 팀의 모든 사람은 창의적인 솔루션을 만들 가능성이 열려 있습니다.마인드셋
심리학
프로덕트 분석
2022/02/10
주니어
중니어
PM의 전문성은 어떻게 찾아갈까요?
Open
PM의 전문성은 어떻게 찾아갈까요?
성공하는 PM이 되기 위해서는 ① PM으로서의 전문성을 정의하고 ② 어느 분야를 깊게 파고 들어야 하는지 ③ 언제/어느 방향으로 폭을 넓힐지 능동적으로 선택해야 합니다.
당신의 PM 전문성은 무엇인가요?
※ PM의 4가지 유형은 https://abr.ge/9hddym
에서 확인하세요.
(1) 최적의 PM 전문성을 찾기 위한 4가지 질문
① 어떤 종류의 프로덕트 업무에 매일 집중하고 있나요?
② 지적 호기심을 느끼는 분야는 무엇인가요?
③ 어떤 고유한 능력을 가지고 있고, 그 능력은 어떻게 다양한 프로덕트 업무들과 얼라인될 수 있나요?
④ 회사에서 팀원을 제외하고 누구와 가장 많은 이야기를 하나요?
⑤ 조직이나 프로덕트가 어느 단계에 속해 있나요? Ex. PMF 찾기 전/ 기능 업무 / 그로스 업무 / ...
※ 혹은 (링크) 내 'The PM Specialization' 표에 해당하는 영역을 색칠해보세요.
(2) 여러 개의 전문성을 가지고 있나요?
- 많은 것들을 책임져왔다는 것은 모든 것에 전문성을 가지고 있는 것이 아닙니다. 모든 것에 전문성을 가진다는 것은 불가능합니다.
- 커리어의 성장을 위해서는 스스로 어떤 것에 집중하고 싶은지 이해해야 합니다.
(3) 처음 시작하는 PM을 위한 전문성을 가지는 법
- 조직이나 산업 내에 어떤 전문성이 비워져있는지 고려해서 그 부분을 공략해야 합니다.
PM 전문성을 바꾸는 방법
(1) 언제 PM 전문성을 바꿔야 할까요?
① 당신의 역량과 흥미를 찾았을 때
- 당신의 프로덕트 업무가 맞지 않을 때, 다양한 업무 경험을 통해 타고난 흥미와 역량을 찾을 수 있습니다.
② 어느 정도 깊이를 갖춘 이후, 업무의 폭을 넓힐 때
- 현재 전문성을 어느 정도 성취하고, 그것을 입증하는 결과물까지 냈다면 전문성을 바꾸는 것을 고려할 수 있습니다.
③ 새로운 전문 분야에 베팅할 때
- 하나의 핵심 전문성을 확실하게 가지고 있다면 새롭게 탄생하는 전문성에 베팅할 수 있습니다.
- 공급은 적지만 수요는 늘어나는 곳에 스스로를 포지셔닝 하는 것은 커리어 성장의 방법 가운데 하나입니다.
(2) 전문성을 바꿔선 안되는 경우
① 혁신 신드롬 : 단지 "멋지게" 보이는 것은 커리어를 성장시키는 방법이 아닙니다.
② 기존 전문성에서 임팩트를 만들기가 갈수록 어려워질 때 : 포기하지 않고 린인(Lean-in)해야 하는 시기입니다. 크고 복잡한 문제 해결은 전문성의 깊이를 늘리고 훌륭한 PM을 만듭니다.
(3) 전문성을 바꾸는 법
- 현재 업무를 유지하면서 새로운 영역에서의 프로젝트를 시작해야 합니다. 조직에 속해 있다면 아래 두가지 방식이 있습니다.
① 기존 조직을 유지하면서 전문성 바꾸기
1) 변화를 만들어 내기 위해 구체적인 방안(Ex. 타임라인)에 대해 매니저, 리더, 멘토 등과 대화를 나누세요.
2) 바꾸고자 하는 전문 분야의 프로젝트에 참여할 기회를 요청하면서 변화를 위해 노력하고 있음을 어필하세요.
3) 해당 분야의 전문성을 가진 사람들에게 배우세요.
② 기존 조직을 바꾸면서 전문성 바꾸기
1) 당신의 프로젝트와 새로운 전문성의 연관성, 현재 가진 전문성의 가치를 설득해야 합니다.
2) 사이드 프로젝트를 통해 새로운 전문성에 대한 열의를 어필하세요.
3) 새로운 전문성에 대한 관련 지식을 계속 습득하세요.
장기적인 관점에서의 PM 커리어
- PM(Product Manager)에서 PL(Product Leader)로 나아가기 위한 4가지 변화
(1) 한 가지 유형은 업무는 깊이 있게 → 다양한 업무로 폭 넓히기
(2) 주어진 일 잘하기 → 다른 사람을 성장 시키기
(3) 당신이 가진 리소스로 해결해보기 → 리소스를 분배하고 다른 사람을 통해 해결하기
(4) 개개인을 잘 살피기 → 조직 단위까지 생각하기
조직이 성장할 때, 팀 차원에서는 전문성을 어떻게 찾아야 할까요?
- 조직의 시드 단계에 따라 필요로 하는 PM의 집단과 규모는 달라집니다.
- 조직이 전문성을 가진 PM을 채용하는데 있어서는 다음을 이해하고 있어야 합니다.
(1) 해당 전문성이 정말 필요한가요?
(2) 조직 내에 다른 사람을 가르치는 걸 좋아하는 사람이 있나요?
(3) 팀에서 누군가가 개인적으로 그 역할에 흥미를 가지고 있나요?PM/PO
온보딩
마인드셋
2022/02/08
주니어
B2B 제품에 대한 설계 우선적인 접근 방식
Open
B2B 제품에 대한 설계 우선적인 접근 방식
성공하는 B2B 제품은 여러 단계의 계획을 필요로 합니다. B2B 제품에 UX 우선적인 접근 방식을 도입하면 제품에 수명을 확보할 수 있습니다.
1. 유비쿼터스 언어 = 도메인 언어 설정하기.
- 해당 도메인에서만 사용되는 모든 특정 용어 이해
2. 이 제품이 해결해야하는 핵심 문제 설명하기
- 현존하는 제품보다 뭘 더 제공할 수 있는지?
- 고객을 확보할 수 있는 채널은 무엇인지?
- 이 제품의 시장은 어디에 있는지?
3. 시스템을 분해하고 나열하기
- 기능들을 아키텍쳐 관점에서 나열하기
- 나열하면 하위 시스템과 화면을 식별할 수 있다.
- 이 프로세스를 반복하면 보다 구체적인 문제에 대한 답을 찾을 수 있다.
이러한 아키텍쳐들을 구축하면 다른 비즈니스가 필요할 때 같은 방식으로 모듈화할 수 있다.
B2B와 B2C 프로덕트의 차이점 짚고 넘어가기
1. B2B 사용자는 숙련된 사용자
- B2B 사용자들은 제품에서 일을 하는 특정한 방법을 배우기 위해 노력한다.
2. 도메인의 복잡성
- B2B 사용자들은 이미 도메인 지식을 잘 알고 있을 가능성이 높다. 디자이너들은 도메인의 기본사항을 이해할 수 있어야한다.
3. B2B 사용자들은 대체 프로덕트를 이미 사용하고 있다.
- 우리 프로덕트 만의 차별점이 무엇일지 고민해야하고 그 가치를 구체적으로 전달할 수 있어야한다.
4. 피처의 깊이
- 올바른 프로덕트를 설계하기 위해 운영하는 세그먼트의 깊이를 이해할 필요가 있다.
5. B2B 디자인은 지루할 수 있다.
- B2B 비지니스에서 정말 필요로 하는 것을 생각함과 동시에 제약을 인정하고, 익숙함과 신선한 인터페이스 사이에서 균형을 잘 이루어라.
6. 제품이 구매과정을 거치도록 디자인해라
- B2B 제품의 판매 주기를 이해하고 적절한 시기에 효과적인 아키택쳐를 설계해라.
우선 버전 1을 만드는데에 집중하면서 버전 2에 대해 생각하기
어떤 결정을 내리든, 먼저 버전 하나를 만드는 데 집중하세요. 버전 1을 만들 때는 버전 2를 고려해야 합니다. 그리고 버전 2는 완전히 제거해야 하는 시스템의 특정 부분을 포함할 수 있습니다.UX
프로덕트 분석
경험 공유
2022/01/28
주니어
중니어
인공지능 B2B 기업의 UX Writing 가이드라인 제작기
Open
인공지능 B2B 기업의 UX Writing 가이드라인 제작기
UX Writing이란?
UX Writing은 사용자들이 서비스를 사용할 때 접하게되는 단어와 문구를 설계하는일
UX Writing은 왜 필요할까요?
⚬ Usability : 명확하고 간결하고 일관성 있는 내용 전달
⚬ Voice Tone : 브랜드의 특성을 알리는 역할
⚬ Raise Engagement : 접근성을 높이고 잘 팔릴 수 있는 효과
UX Writing 가이드라인을 만든 스켈터랩스의 프로세스
프로덕트의 가치에 맞는 원칙 세우기
프로덕트의 특성과 사용자층에 따른 Core Value를 정의하고 이를 바탕으로 UX Writing의 방향성에 대해 고민합니다.
원칙에 맞는 상세 규칙 세우기
보이스톤 : 똑똑하고 겸손한
⚬ 통상적인 전문용어는 활용하지만, 과도하게 어려운 용어는 지양합니다.
⚬ 소리내어 말하기 어색한 표현이나 극존칭은 사용하지 않습니다.
⚬ 신뢰도를 줄 수 있게 데이터를 활용합니다.
문장 구조 : 해결책을 순차적으로 제시하는
⚬ 문제가 무엇이고 어떻게 해결할 수 있는지에 집중합니다.
⚬ 사용자에게 무언가를 요구해야한다면 그것이 어떤 가치나 혜택을 줄 수 있는지 설명합니다.
⚬ 공백상태를 잘 활용해 서비스 이용에 도움을 주거나 동기부여할 수 있는 기회를 만듭니다.
사용성 : 빠르게 이해할 수 있는
⚬ 타이틀을 쉽고 명확하게, 제공할 수 있는 가치에 집중해 작성합니다.
⚬ 행동을 구체적이고 직관적으로 표현합니다.
⚬ 한번에 한가지 내용에 대해서만 이야기하고, 중복된 내용은 지양합니다.
⚬ 동일한 내용은 일관적으로 표현합니다.
⚬ 이해하기 어려운 용어 사용을 자제합니다. (외래어, 수동태)
정해진 원칙을 적용시키기
1. 텍스트를 한곳으로 모아 정한 원칙을 기준으로 재검토합니다.
2. 유사한 내용의 문장들을 분류합니다.
3. 원칙에 맞게 동일한 표현으로 적용합니다.
UX Writing 가이드라인 제작 후 긍정적인 효과
⚬ 새로운 디자인을 할 때 기존 예시를 찾아 적용하기 쉬워졌습니다.
⚬ 디자이너 뿐만 아니라 마케터, PM 등 이해관계자의 언어 표현을 일관적으로 맞추는데 용이합니다.
⚬ 프로덕트 담당자가 텍스트를 검토하는 시간을 줄일 수 있습니다.UX Writing
경험 공유
실 사례
2022/01/27
주니어
중니어
기획자
UX팀에서 효과적으로 피드백 주고 받기
Open
[UX를 위한 피드백을 구하고, 받기, 주기]
피드백에 대한 문제 상황들
*건설적인 피드백을 제공 해야하는 두려움
ex. 이런 점을 지적한 내가 바보라고 생각한다면?
* 피드백을 구할때의 상대의 반응에 대한 두려움
ex. 내 피드백 요청이 무시된다면?
* 피드백 받는 것 자체가 도전일때
ex. 모든 피드백을 수용해야 하나?
다음 체크리스트들은 상기의 피드백 문제사항에 도움이 될것입니다.
문맥을 생각하기
대부분 회사와 UX 부서는 피드백 문화를 만들기 위해 노력합니다. 그러나 모든 사람이 피드백을 주고받는 것을 이해하고 있지 않을 수 있습니다.
* 피드백을 받는/제공하는 사람과의 관계는 어떻습니까? 신뢰된 관계입니까?
* 동료들과 피드백이 필요한 이유, 상황을 공유하고 있습니까? 피드백 활용 방안을 설정했습니까? 모두가 약속하는 피드백 빈도가 설정되어 있습니까?
* 공동의 목표를 위해 노력하고 있습니까? 모두가 그 목표에 관심이 있습니까?
상대방을 이해하기
사람은 복잡하고, 서로를 이해는것은 쉽지 않습니다. 그렇기 때문에 상대방의 성향에 따라 피드백 방법을 다르게 접근해야 합니다. 피드백 대상은 고정마인드셋 or 성장 마인드셋 중 어디입니까?
* 성장 마인드셋 유형
이 유형의 사람들은 어디서든 발전 할 수 있다고 생각합니다.작업을 개선하는 데 도움이 되도록 적극적으로 피드백을 제공하거나 순수한 호기심으로 피드백을 받을 수 있습니다.
* 고정 마인드셋 유형
이 유형은 이전 경험, 외부 요인, 깊이 내재된 가정에 대해 고정된 사고 방식에 익숙합니다. 이 경향을 나타낼때, 피드백이 적절하게 전달되고 소화될 수 있도록 더 많은 시간을 주어야 합니다. 또한, 프로세스 전반에 걸쳐 더 많은 인내심을 갖고 피드백 단계를 진행해야합니다.
어조, 언어 및 의사 소통 스타일 생각하기
대면 대화를 진정으로 불편하게 여기는 사람들이 많고 전화를 받을 때 반응하기가 더 어렵습니다. 그런 사람들에게는 말을 하는 것보다 글로 나누는 것이 훨씬 쉬울 수 있습니다.
피드백 중심의 대화에서 나의 스타일보다는 상대방의 커뮤니케이션 스타일에 맞춰 조정하는 시도를 하는 것이 중요합니다. 우리는 피드백의 내용이 중요한것이라고 판단하지만 사실은 커뮤니케이션 스킬이 피드백에 결정적 요인이 됩니다.
시간을 가지기
피드백을 주거나 받는 사람 모두 시간이 필요하다는 것을 간과하지 마세요. 문제를 반영하고, 상호 작용을 요약하고, 실행 계획에 시간을 충분히 가져야합니다. 실행 계획이 세워진 후에도 부담 없이 성장 부분을 차분하게 집중할 수있는 시간과 공간을 제공하는 것이 중요합니다.
시간을 갖는 것은 문제를 놓고 잊어버리는 것이 아닙니다. 백로그에 피드백을 보관하고 내용이 더 이상 관련이 없을 때까지 계속 참조해야 합니다.
아무리 해도 피드백이 되지 않는다면 다른 방법을 시도해 보세요!
아무리 노력해도 피드백 메커니즘이 작동하지 않을 수 있습니다.
“사람들은 피드백을 받으면 본능적으로 그것을 위협으로 해석하여 방어적 반응 을 촉발할 수 있습니다. 다시 말해 건설적인 피드백은 사람들이 학습 하는 것을 방해 할 수 있습니다.” - Dave Bailey
그럴 때 “evidence-based coaching” 을 시도할 수 있습니다.
상대방의 목표와 성공 요인에 대해 성찰하도록 도와 보세요. 비 판단적이고 단순한 질문을 많이 해보세요.
* ex. A를 이해하는 방법을 이해하는 데 도움을 주시겠습니까?
* ex. 당신의 관점에 따라 A가 어떻게 작동하는지 확인하기 위해 고군분투하고 있습니다. 당신의 사고 과정을 안내해 주시겠습니까?
UX 작업의 상당 부분은 팀 또는 협력하는 팀과 피드백을 주고받는 것과 관련이 있습니다. 어떤 상황은 쉬울 수 있지만 다른 상황에서는 원하는 결과를 얻기 위해 철저한 준비가 필요합니다.
UX를 위한 피드백을 구하고, 받기, 주기]
피드백에 대한 문제 상황들
*건설적인 피드백을 제공 해야하는 두려움
ex. 이런 점을 지적한 내가 바보라고 생각한다면?
* 피드백을 구할때의 상대의 반응에 대한 두려움
ex. 내 피드백 요청이 무시된다면?
* 피드백 받는 것 자체가 도전일때
ex. 모든 피드백을 수용해야 하나?
다음 체크리스트들은 상기의 피드백 문제사항에 도움이 될것입니다.
문맥을 생각하기
대부분 회사와 UX 부서는 피드백 문화를 만들기 위해 노력합니다. 그러나 모든 사람이 피드백을 주고받는 것을 이해하고 있지 않을 수 있습니다.
* 피드백을 받는/제공하는 사람과의 관계는 어떻습니까? 신뢰된 관계입니까?
* 동료들과 피드백이 필요한 이유, 상황을 공유하고 있습니까? 피드백 활용 방안을 설정했습니까? 모두가 약속하는 피드백 빈도가 설정되어 있습니까?
* 공동의 목표를 위해 노력하고 있습니까? 모두가 그 목표에 관심이 있습니까?
상대방을 이해하기
사람은 복잡하고, 서로를 이해는것은 쉽지 않습니다. 그렇기 때문에 상대방의 성향에 따라 피드백 방법을 다르게 접근해야 합니다. 피드백 대상은 고정마인드셋 or 성장 마인드셋 중 어디입니까?
* 성장 마인드셋 유형
이 유형의 사람들은 어디서든 발전 할 수 있다고 생각합니다.작업을 개선하는 데 도움이 되도록 적극적으로 피드백을 제공하거나 순수한 호기심으로 피드백을 받을 수 있습니다.
* 고정 마인드셋 유형
이 유형은 이전 경험, 외부 요인, 깊이 내재된 가정에 대해 고정된 사고 방식에 익숙합니다. 이 경향을 나타낼때, 피드백이 적절하게 전달되고 소화될 수 있도록 더 많은 시간을 주어야 합니다. 또한, 프로세스 전반에 걸쳐 더 많은 인내심을 갖고 피드백 단계를 진행해야합니다.
어조, 언어 및 의사 소통 스타일 생각하기
대면 대화를 진정으로 불편하게 여기는 사람들이 많고 전화를 받을 때 반응하기가 더 어렵습니다. 그런 사람들에게는 말을 하는 것보다 글로 나누는 것이 훨씬 쉬울 수 있습니다.
피드백 중심의 대화에서 나의 스타일보다는 상대방의 커뮤니케이션 스타일에 맞춰 조정하는 시도를 하는 것이 중요합니다. 우리는 피드백의 내용이 중요한것이라고 판단하지만 사실은 커뮤니케이션 스킬이 피드백에 결정적 요인이 됩니다.
시간을 가지기
피드백을 주거나 받는 사람 모두 시간이 필요하다는 것을 간과하지 마세요. 문제를 반영하고, 상호 작용을 요약하고, 실행 계획에 시간을 충분히 가져야합니다. 실행 계획이 세워진 후에도 부담 없이 성장 부분을 차분하게 집중할 수있는 시간과 공간을 제공하는 것이 중요합니다.
시간을 갖는 것은 문제를 놓고 잊어버리는 것이 아닙니다. 백로그에 피드백을 보관하고 내용이 더 이상 관련이 없을 때까지 계속 참조해야 합니다.
아무리 해도 피드백이 되지 않는다면 다른 방법을 시도해 보세요!
아무리 노력해도 피드백 메커니즘이 작동하지 않을 수 있습니다.
“사람들은 피드백을 받으면 본능적으로 그것을 위협으로 해석하여 방어적 반응 을 촉발할 수 있습니다. 다시 말해 건설적인 피드백은 사람들이 학습 하는 것을 방해 할 수 있습니다.” - Dave Bailey
그럴 때 “evidence-based coaching” 을 시도할 수 있습니다.
상대방의 목표와 성공 요인에 대해 성찰하도록 도와 보세요. 비 판단적이고 단순한 질문을 많이 해보세요.
* ex. A를 이해하는 방법을 이해하는 데 도움을 주시겠습니까?
* ex. 당신의 관점에 따라 A가 어떻게 작동하는지 확인하기 위해 고군분투하고 있습니다. 당신의 사고 과정을 안내해 주시겠습니까?
UX 작업의 상당 부분은 팀 또는 협력하는 팀과 피드백을 주고받는 것과 관련이 있습니다. 어떤 상황은 쉬울 수 있지만 다른 상황에서는 원하는 결과를 얻기 위해 철저한 준비가 필요합니다.
마인드셋
UX
일반 이론
2022/01/21
주니어
중니어
당신은 어떤 전문성을 가진 PM인가요?
Open
당신은 어떤 전문성을 가진 PM인가요? Product Manager의 4가지 유형
프로덕트 매니지먼트(PM)는 아직 전문 분야가 정의되지 않았습니다.
하지만 많은 사람들이 오해하듯이 PM은 다양한 유형의 프로덕트 작업/단계를 모두 알고 있는 사람이 아닙니다.
물론 PM에게 공통적으로 요구되는 능력은 있습니다.
(아래 5개)
① 기술 & 데이터에 친숙할 것
② 커뮤니케이션 & 협업에 능숙할 것
③ 문제 해결 & 반복 실험(AB테스트)
④ 유저 이해 & 페인 포인트 해결
⑤ 전략적 사고
그러나 모든 PM들의 역할이 동일하다고 생각하면
아래와 같은 문제를 겪게 될 수 있습니다.
① PM이 모든 상황에서 같은 해결책을 적용합니다.
② PM이 이유도 모른 채 천천히 지속적으로 어려움을 겪습니다.
③ PM이 어디에 집중해야 할지 모르기 때문에 학습 속도가 느려집니다.
④ 회사는 왜 그들의 PM 고용이 잘 이뤄지지 않는지 알지 못합니다.
⑤ PM들이 올바르지 못한 기준으로 서로 간에 비교 당하게 됩니다.
PM은 전문성에 따라 4가지 유형으로 분류되고, 각 유형은 서로 다른 역할을 부여 받습니다.
전문성에 따른 PM의 4가지 유형은 아래와 같습니다.
코어 PM : '기능 관련 업무'로 고객의 니즈와 페인 포인트를 해결하는데 집중하는 PM
프로덕트 기능 관련 업무를 하는 대부분의 PM들은 코어 PM입니다.
코어 PM은 고객들의 페인 포인트나 니즈를 해결하는데 집중합니다.
핵심 능력 : 고객 중심 마인드, 넓은 시야의 프로덕트 사고, 문제 및 가설 중심 접근, 사용자 경험 집착, 고객 공감, 수준급의 리서치
협업 대상 : 리서치, 다자인, 서포트 직군
코어 PM을 세분화 시키는 요소 : 프로덕트/산업의 유형(Ex. B2B, B2C, 소셜, 뉴스피드, ...)
그로스 PM : '비즈니스 지표를 향상'시킨다는 관점으로 고객의 경험을 분석하는 PM
그로스 업무에 집중하는 프로덕트 매니저입니다.
획득, 전환 등과 같은 비즈니스 지표들의 관점으로 고객 여정을 분석합니다.
지표의 성장에 집중한다는 점에서 코어 PM과 차별화됩니다.
핵심 능력 : 실험, 최적화, 전개 속도, 마케팅 스킬, 재무/실험 모델링, 빠른 의사 결정, SEO 같은 채널 기반 스킬, 프라이싱 철학, 탄탄한 데이터와 통계 스킬, 반복(iteractive) 개발
협업 대상 : 데이터, 마케팅 직군
그로스 PM을 세분화 시키는 요소 : 퍼널 스테이지(Ex. 획득, 활성, 리텐션, ...)
플랫폼 PM : 비즈니스 규모를 효율적으로 확장시키는 '스케일링' 업무에 집중하는 PM
내부 서비스와 플랫폼의 스케일링을 통해
회사 내부 구성원들의 니즈에 집중하고 조직의 계속적인 성장을 목적으로 하는 PM입니다.
외부 유저가 아닌 내부 이해 관계자를 대상으로 한다는 점에서 타 PM과 차별화됩니다.
핵심 능력 : 확장 가능한 개발 사고, 테크니컬/엔지니어링/데이터 사고, 기술 스택 이해도, 기술과 비즈니스 이해 관계자를 넘나들 수 있는 능력, 빌드 vs 구매 결정, 고객으로서 내부 동료/이해자 관리, 효율 전문가, 서비스 디자인
협업 대상 : 데이터/데이터 사이언스, 고객 지원, 법률, 재무/회계 직군
플랫폼 PM을 세분화 시키는 요소 : 플랫폼 지식의 유형(Ex. 보안, 개인화, 머신러닝, ...)
혁신 PM : '새로운 기회를 발굴'하고 PMF를 확장시키는데 집중하는 PM
혁신 PM은 PMF(Product-Market Fit)에 도달하고 확장하기 위한 새로운 기회를 확인하고 실험하는데 집중합니다.
인접 유저 이론을 탐구하며 추가적인 페인 포인트를 해결하기 위해 새로운 영역을 발굴하거나
새로운 프로덕트를 만들어내거나, 새로운 매출 창출을 위해 고민합니다.
핵심 능력 : 새로운 걸 만들어내는 사고, 애매모호하지 않아야 함, 고객 개발, 강력한 비전을 그릴 수 있는 능력, PMF 발견, 피벗, 자금 조달, 설득 능력
협업 대상 : 경영진, 러서치, 고객군
혁신 PM을 세분화 시키는 요소 : 조직의 규모(Ex. 초기 조직 = 제로 투 원, 확장 조직 또는 PMF를 찾은 조직 = 새로운 영역 확장, ...)
성공하는 PM이 되기 위해서는 이 중 어느 분야를 깊게 파고 들어야 하는지, 언제/어느 방향으로 폭을 넓힐지 능동적으로 선택해야 합니다.
—
번역 및 요약 : 이근학PM/PO
마인드셋
온보딩
2022/01/19
주니어
Workflow 자동화의 ROI를 측정하는 방법
Open
워크플로우 자동화의 ROI를 측정하는 방법
생산성을 향상시키기 위해 워크플로우를 설계하지만, 생산성은 어떻게 측정할 수 있을까? 생산성을 늘리기 위해 사용하는 유료 소프트웨어나 서비스를 계속 유지할 가치가 있는지 궁금하지 않은가?
이처럼 선택한 전략이 조직에 실질적인 영향을 미치고 있는지 알기 위해서는 워크플로우의 효율성과 ROI 측정은 필수다.
Hard ROI와 Soft ROI
Hard ROI는 비용이나 시간 절약과 관련된 수치로 아래와 같은 수치들을 볼 수 있다.
- 업무당 절감한 시간
- 프로세스 비용 절감
- 스케줄링이나 문서화에 소요되는 시간 절감
- 운영이나 스토리지 비용 절감
- 에러 고치는 시간 절감
- 인건비
반면 Soft ROI는 일반적으로 효율성 향상이나 직원 또는 고객의 만족을 의미하며 정량화하기 어렵다.
- 직원의 생산성 향상
- 회사의 사기 향상
- 긍정적인 회사 문화와 직원 복지
- 향상된 브랜드 평판과 인식
- 완료 시간 단축
- 팀 협업 개선
- 유실된 문서의 수 감소
- 원격 근무하는 직원들의 효율성 증대
- 병목의 수 감소
Hard ROI 측정 공식
한 업무에 사용하는 시간 x 매달 업무를 수행하는 빈도 x 시간당 비용 x 12개월 = 연간 ROI
Soft ROI 측정
공식은 없지만 워크플로우가 전반적인 프로세스를 향상시키는지 아닌지를 통해 간접적으로 측정할 수 있다.
예를 들어, 새로운 워크플로우의 구현을 고려한다면 해당 워크플로우가 달성해야 하는 특정 목표가 있을 것이다. 그렇다면 목표 달성에 소요된 시간과 함께 목표 달성 여부를 측정하면 해당 워크플로우가 효과적이었는지 아니었는지 판단하는 데 도움이 될 것이다.
또 직원 대상 설문조사를 통해 생산성 수준과 전반적인 만족도를 측정하는 것도 도움이 될 수 있다.워크플로우
지표
2022/01/14
주니어
중니어
복잡한 B2B 제품에 대한 연구 수행 방법
Open
[복잡한 B2B 제품에 대한 연구 수행 방법]
B2B 프로덕트에는 '최상의 경로'와 같은 명백한 사용자 흐름은 없습니다. B2B 프로덕트는 사용자를 메인 페이지에서 부터 [결제하기] 버튼으로 유도하는 퍼널을 만드는 것이 아닙니다. 우리의 고객은 전문가 입니다. 그들은 복잡한 툴을 배우는 데에 수년을 보냅니다. UX에 대한 사람들의 기대치가 바뀌게 되죠.
*사용자에게 바로 다가가세요. 사용자 여정 지도(CJM), 사용성 테스트(UT), 인터뷰, 상호 제작, 섀도잉 등을 수행하세요.
*대부분의 B2B 디자이너들은 UT와 인터뷰를 진행합니다. 사용자들의 컨텍스트와 관찰하고 컨텍스트 인터뷰를 진행합니다. '관찰과 질문' 그게 다입니다.
*관찰하고 질문하면서 사용자가 작업을 수행한 방법을 다시 보고 모든 단계에 대해 질문하는 것을 잊지 마세요.
B2B UX 문서화의 중요성
사용성 테스트에서 응답한 고객들이 사용한 전문적인 언어를 우리의 제품이나 문서에 추가해야 합니다. 문서화를 잊지 마세요.
설문 조사 기법 추천
- 사후 시나리오 설문지(ASQ)
- 주관적 정신 노력 질문(SMEQ)
- 기대 등급(ER)
- 사용성 크기 추정(UME)
- 단일 용이성 질문(SEQ)
가장 추천하는 건 'SUPR-Q' 입니다.
부연 설명: SUPR-Q(Standardized User Experience Percentile Rank Questionnaire)는 사용성, 신뢰 및 신뢰성, 외관 및 충성도를 포함하여 웹사이트의 여러 구성 요소에 대한 사용자의 인식을 측정하는 8개의 표준화된 질문 세트
참고: https://trymyui.com/supr-q
B2B UX 문서화의 중요성
사용성 테스트에서 응답한 고객들이 사용한 전문적인 언어를 우리의 제품이나 문서에 추가해야 합니다. 문서화를 잊지 마세요.
설문 조사 기법 추천
- 사후 시나리오 설문지(ASQ)
- 주관적 정신 노력 질문(SMEQ)
- 기대 등급(ER)
- 사용성 크기 추정(UME)
- 단일 용이성 질문(SEQ)
가장 추천하는 건 'SUPR-Q' 입니다.
부연 설명: SUPR-Q(Standardized User Experience Percentile Rank Questionnaire)는 사용성, 신뢰 및 신뢰성, 외관 및 충성도를 포함하여 웹사이트의 여러 구성 요소에 대한 사용자의 인식을 측정하는 8개의 표준화된 질문 세트
참고: https://trymyui.com/supr-qUX
리서치
프로덕트 분석
2022/01/13
주니어
중니어
베조스의 의사결정 프레임워크
Open
Jeff Bezos가 의사결정 하는 방법
Bezos는 의사결정을 두 가지로 구분합니다.
• Type 1: 되돌리기 거의 불가능한 결정. 회사를 매각하거나, 퇴사하거나, 절벽에서 떨어지는 행위 등. 행동하기 전에 반드시 충분히 생각해야 하며 가능한 여러 시나리오를 고려해 올바른 결정을 내려야 합니다.
• Type 2: 되돌리기 쉬운 결정. 사이드 프로젝트를 시작하거나, 새로운 서비스를 만들거나, 새로운 가격 정책을 선보이는 행위 등. Type 2 의사결정은 중요하게 느껴질 순 있지만, 약간의 시간과 노력만 있다면 되돌릴 수 있는 의사결정입니다. 정보가 모자라더라도 의사결정을 빨리 하고 잘못된 결과가 나올 수 있음을 감안해야 합니다.
되돌릴 수 있는지 여부와 중요도에 따라 2x2 의사결정 매트릭스를 그려볼 수 있습니다.
• 되돌릴 수 있고 중요하지 않은 것
- 경험에 입각해 즉시 결정함
- 이후 결과와 변화를 확인할 수 있도록 리마인더를 설정함
• ❗️되돌릴 수 있고 중요한것
- 되돌릴 수 없는 결정이라고 착각하게 되는 유의해야 하는 유형임
- 실험하고 정보를 수집해 올바른 결정으로 나아가야 함
• 되돌릴 수없고 중요하지 않은 것
- 경험에 입각해 즉시 결정함
• ❗️되돌릴 수 없고 중요한것
- 정보를 최대한 많이 수집하고 가능한 시나리오들을 평가해야 함
- 리스크를 정량적으로 판단하고 이성적인 판단을 해야 함
다음은 베조스의 주주서한의 일부입니다.
> …조직이 커지게 되면서, Type 2 의사결정인 경우에도 Type 1 의사결정에 필요한 프로세스를 따라가는 경우가 많습니다. 이로 인해 의사결정이 느려지고, 리스크를 지기 싫어하며, 실험을 충분히 하지 않게 되고, 따라서 더 적게 생산하게 됩니다. 우리는 이런 경향성에 맞서 싸울 방법을 찾아야 합니다.
️ 빠른 의사결정을 위한 5가지 규칙
1. 한 가지 의사결정 프로세스 방식만을 사용하지 말기
- 많은 결정들은 되돌릴 수 있기 때문에 가벼운 의사결정 프로세스만으로 충분합니다.
2. 모든 의사결정을 혼자서 내리지 않기
- 의사결정권자가 중앙집중화 되어있다면 그 사람은 곧 빠른 성장을 저해하는 병목이 될 것입니다.
3. 모든 정보가 모일 때 까지 기다리지 않기
- 베조스는 2016년 주주서한에서 '목표했던 양 보다 약 70%의 정보만으로 대부분의 의사결정이 되어야 하고, 만약 정보가 90%가 있다면 느리게 결정하는 것'이라고 했습니다. '우리는 나쁜 의사결정을 빠르게 발견하고 수정하는것을 잘 해야 합니다. 방향을 수정하는데 뛰어나다면, 틀린 결정은 생각만큼 비싸지 않지만 느린것은 확실하게 비쌀 것입니다.'
4. 의사결정 과정에 많은 계층이나 사람을 통과해야 하지 않도록 하기
- Type 2 의사결정은 전통적인 선형적 프로세스를 대화 프로세스로 변경하여 빠르고 양질의 의사결정을 내릴 수 있습니다.
5. 모든 사람이 동의할 때 까지 기다리지 않기
- 모든 사람이 동의하지 않고도 실행할 수 있기 위해서는 "Disagree and Commit" 정신이 필요합니다.
- 잘못된 결정이 결정을 못 내리는 것 보다 낫고, 모두의 동의를 얻지 못했더라도 모두가 최선을 다해 실행하여 더 효율적으로 일할 수 있습니다.PM/PO
프레임워크
마인드셋
2022/01/10
중니어
시니어
회사 보고서의 두 종류
Open
회사 생활을 하면서 나의 디자인, 기획내용을 전달하거나 프로젝트 진행 내용을 보고하는 등 누군가에게 보고하는 상황이 종종 발생합니다. 이런 경우 회사에서 사용되는 보고서는 두 가지 목적으로 분류할 수 있습니다.
1) 문제 해결을 위해 어떤 행동을 해야하며, 이를 위해 어떤것이 필요하다
2) 문제 해결을 위해 어떤 행동을 했고, 이로 인해 어떤 성과가 났다
직장 상사와 하는 커뮤니케이션은 누구의 말이 옳은지 시시비비를 가리거나, 의미없이 수다를 떨기 위함이 아닙니다. 회사는 어떤 문제를 해결하기 위해 존재하는 조직이며, 특히 상사와 하는 커뮤니케이션은 해당 문제를 해결하기 위한 목적이 바탕이되어야 하고, 해당 목적이 빠져서는 안됩니다.
직장상사가 프로젝트의 진행 상황에 대해 요목조목 문제사항이라고 생각되는 점을 짚으며 지적을 했을 때, 그 지적사항들에 대해 '이미 조사했으며, 이러이러한 이유 때문에 불가하다'고 커뮤니케이션하면 안됩니다. 이런 경우엔 '해당 사항들은 어떤 상황들은 미달되었고, 이런 실행가능한 대안이 있으며 이를 위해 시간이나 의사결정이 필요합니다' 라는 커뮤니케이션이어야 합니다.
회사에서 내 기획이나 디자인에 대해 전달하는 경우도 마찬가지입니다. 1번의 경우엔 '현재 해결해야 할 어떤 문제 상황이 있고, 이를 해결하기 위해 어떤 기획이나 디자인을 제시하고, 이를 위해 선제 프로세스가 진행되어야 하거나, 여러 대안 중 의사결정이 필요하다'는 방식으로 커뮤니케이션 할 수 있고, 2번의 경우엔 '해결해야 할 문제 상황에 대해 이렇게 처리했고, 이를 통해 어떤 성과가 있었다' 고 커뮤니케이션 할 수 있겠습니다.
문서 작성법
일하는 방법
디자이너 성장
마인드셋
SaaS 프로덕트 릴리즈 노트 템플릿
Open
프로덕트의 새로운 기능에 대한 릴리즈 노트는 사용자 Engagement에 큰 영향을 줄 수 있는 요소입니다.
잠깐, 릴리즈 노트란?
SaaS 회사가 매 프로덕트 릴리즈에 제작하고 배포하는 기술 문서입니다. 릴리즈 노트는 계속 발전해갈 SaaS 프로덕트를 구매한 사용자에게 변경사항을 알려주고 고객의 목소리에 귀를 기울이고 있다고 알릴 수 있는 좋은 방법입니다.
요약
• 릴리즈 노트에는 헤더, 개괄, 이슈 요약, 해결, 임팩트, 그리고 추가 자료를 포함해야 합니다.
• 릴리즈 노트 템플릿을 사용하면 사용자와 일관되게 커뮤니케이션 할 수 있습니다.
• 릴리즈 노트는 애플리케이션, 이메일, 웹사이트, 블로그, 소셜 미디어 등에서 배포할 수 있습니다.
릴리즈 노트를 잘 작성하는 방법
• 관련 지식이 없는 사람도 쉽게 이해할 수 있도록 평이한 언어를 사용하기
• 브랜드 정체성을 반영하기
• 이 릴리즈가 사용자에게 어떤 가치를 제공할 지에 집중하기
• 매 릴리즈마다 일관된 릴리즈 노트 작성하기
• 가능하다면 이미지와 스크린샷을 포함하기
• 최적의 Engagement와 지식 전달을 원한다면 비디오 튜토리얼을 제공하기
• 버그의 경우 재현 방법을 기록하기
• 릴리즈 노트에 수정사항이 있다면, 버저닝 하기
• 사용자에게 더 자세한 정보로 이어지는 링크 제공하기
• 최종 사용자로부터 피드백을 제공하도록 요청하기
릴리즈 노트의 템플릿과 제공하는 실제 사례, What's New 섹션을 잘 만들어둔 Mailchimp, Retool, UiPath, Amplitude의 예시는 원 글에서 확인하실 수 있습니다.
잠깐, 릴리즈 노트란?
SaaS 회사가 매 프로덕트 릴리즈에 제작하고 배포하는 기술 문서입니다. 릴리즈 노트는 계속 발전해갈 SaaS 프로덕트를 구매한 사용자에게 변경사항을 알려주고 고객의 목소리에 귀를 기울이고 있다고 알릴 수 있는 좋은 방법입니다.
요약
• 릴리즈 노트에는 헤더, 개괄, 이슈 요약, 해결, 임팩트, 그리고 추가 자료를 포함해야 합니다.
• 릴리즈 노트 템플릿을 사용하면 사용자와 일관되게 커뮤니케이션 할 수 있습니다.
• 릴리즈 노트는 애플리케이션, 이메일, 웹사이트, 블로그, 소셜 미디어 등에서 배포할 수 있습니다.
릴리즈 노트를 잘 작성하는 방법
• 관련 지식이 없는 사람도 쉽게 이해할 수 있도록 평이한 언어를 사용하기
• 브랜드 정체성을 반영하기
• 이 릴리즈가 사용자에게 어떤 가치를 제공할 지에 집중하기
• 매 릴리즈마다 일관된 릴리즈 노트 작성하기
• 가능하다면 이미지와 스크린샷을 포함하기
• 최적의 Engagement와 지식 전달을 원한다면 비디오 튜토리얼을 제공하기
• 버그의 경우 재현 방법을 기록하기
• 릴리즈 노트에 수정사항이 있다면, 버저닝 하기
• 사용자에게 더 자세한 정보로 이어지는 링크 제공하기
• 최종 사용자로부터 피드백을 제공하도록 요청하기
릴리즈 노트의 템플릿과 제공하는 실제 사례, What's New 섹션을 잘 만들어둔 Mailchimp, Retool, UiPath, Amplitude의 예시는 원 글에서 확인하실 수 있습니다.프로덕트 전략
문서 작성법
스타트업
가이드
[Slack] 우리는 말 안장을 파는게 아니다
Open
[성장을 위한 데일리 아티클]
목요일 주제는 '워크 프로세스'입니다.
[Slack] 우리는 말 안장을 파는게 아니다.
이 글은 Slack의 CEO가 Slack의 프리뷰 릴리즈 2주 전 사내에 전파한 내용(에 대한 번역글)입니다.
Slack은 Slack이 만들어지기 이전에는 존재하지 않던 업무용 커뮤니케이션 SaaS 라는 새로운 시장을 타겟으로 만들어진 프로덕트입니다. 이 때문에 본인의 Painpoint를 잘 알고, 니즈를 설명할 수 있고, 어떤 프로덕트를 상상하는지 그려낼 수 있는 사용자는 없었습니다. Slack은 사람들이 '자신이 원한다고 믿는 것'들을 이해해 Slack의 가치를 그에 맞게 적절한 형태로 풀어내는 일에 집중했습니다. Slack은 디지털 프로덕트 뿐 만 아니라 회원가입 양식 문구, 로딩 페이지, 환영 이메일, 정확하고 이해도 높은 검색 결과, 사려 깊게 적용된 멋진 기능들에서 겪는 모든 경험들을 잘 디자인 했습니다.
Slack은 다른 수많은 스타트업들과 다르게 경쟁자가 명확하고 시장이 잘 정의된 상황에서 싸우지 않았습니다. 직접적인 경쟁자가 없고, 조악한 툴들로 니즈를 해소하던 시장을 뒤로하고 새로운 시장을 정의해야 했습니다.
Slack은 '그룹 채팅 시스템'을 파는게 아니라 '조직 혁신(Organizational Transformation)'을 판매합니다. '그룹 채팅 시스템'을 구매할 고객을 그리 많지 않지만, '스트레스로부터 해방', '지금까지 쌓은 데이터로부터 가치를 뽑아낼 수 있는 능력', '커뮤니케이션 비용 감소', '더 빠르고 좋은 결정', '75% 더 적은 이메일'을 구매할 사람들은 많습니다.
말 안장을 판매하는 회사가 있다고 가정했을 때, 이 회사는 말 안장 가죽의 질, 장신구 등을 강조하면서 말 안장만 팔 수도 있습니다. 하지만 그들이 '승마'를 파는데 성공한다면, 그들은 말 안장에 대한 다양한 이야기를 풀어갈 수 있는 완벽한 맥락을 갖추는 동시에 시장을 그들의 제품에 맞게 키울 수도 있습니다.
실제로 최근까지 핫한 기업으로 알려진 Lululemon은 요가복과 요가 장비를 판매한 것이 아니라 '요가'를 판매했습니다. Lululemon은 요가를 팔기 위해 사람들의 집 근처 요가 스튜디오를 찾아주는 일부터 공짜 강좌를 개설하고, 스폰서쉽과 학위도 지원하고, 지역 홍보대사와 교육까지 했습니다.
기존 이메일 방식의 업무 커뮤니케이션에 익숙한 고객들에게 공개가 기본인 커뮤니케이션 툴을 사용하라고 요구하는 것은 거의 불가능한 일일 것입니다. 이를 위해 Slack의 고객은 정보의 흐름에 압도당하는 사람이 아닌, 자신의 정보를 관장하는 사람이 되길 원하고, 자신의 팀에 어떤 일이 벌어지는지 몰라 느끼는 당황스러움을 덜 느끼길 원하고, 분명한 목적의식을 가지고 소통하며, 자신의 질문 하나하나가 팀에게 가치를 가져다주는 사람이기를 원합니다. 그리고 고객이 분명히 이것을 얻을 수 있도록 노력해야 합니다.
기존에 없던 시장을 만들어나가는 불확실하고 힘든 상황에서 Slack의 CEO는 바라봐야 하는 지점에 대한 영감과 최선을 다해 일해야하는 이유를 훌륭하게 전달했습니다. 8년 전 글인 것이 믿기지 않을 정도입니다.
말 안장을 판매하는 회사가 있다고 가정했을 때, 이 회사는 말 안장 가죽의 질, 장신구 등을 강조하면서 말 안장만 팔 수도 있습니다. 하지만 그들이 '승마'를 파는데 성공한다면, 그들은 말 안장에 대한 다양한 이야기를 풀어갈 수 있는 완벽한 맥락을 갖추는 동시에 시장을 그들의 제품에 맞게 키울 수도 있습니다.
실제로 최근까지 핫한 기업으로 알려진 Lululemon은 요가복과 요가 장비를 판매한 것이 아니라 '요가'를 판매했습니다. Lululemon은 요가를 팔기 위해 사람들의 집 근처 요가 스튜디오를 찾아주는 일부터 공짜 강좌를 개설하고, 스폰서쉽과 학위도 지원하고, 지역 홍보대사와 교육까지 했습니다.
기존 이메일 방식의 업무 커뮤니케이션에 익숙한 고객들에게 공개가 기본인 커뮤니케이션 툴을 사용하라고 요구하는 것은 거의 불가능한 일일 것입니다. 이를 위해 Slack의 고객은 정보의 흐름에 압도당하는 사람이 아닌, 자신의 정보를 관장하는 사람이 되길 원하고, 자신의 팀에 어떤 일이 벌어지는지 몰라 느끼는 당황스러움을 덜 느끼길 원하고, 분명한 목적의식을 가지고 소통하며, 자신의 질문 하나하나가 팀에게 가치를 가져다주는 사람이기를 원합니다. 그리고 고객이 분명히 이것을 얻을 수 있도록 노력해야 합니다.
기존에 없던 시장을 만들어나가는 불확실하고 힘든 상황에서 Slack의 CEO는 바라봐야 하는 지점에 대한 영감과 최선을 다해 일해야하는 이유를 훌륭하게 전달했습니다. 8년 전 글인 것이 믿기지 않을 정도입니다.디자이너 성장
일하는 방법
마인드셋
프로덕트 전략
비즈니스 전략
경험 공유
훌륭한 팀원의 조건- Strong Opinions, Weakly Held
Open
훌륭한 팀원의 조건 - Strong Opinions, Weakly Held
실리콘 밸리의 많은 구성원들은 자기의견이 강한 사람들이 훌륭한 인재라는 일반적인 견해가 있습니다.
실리콘 밸리의 테크 회사들은 불확실한 IT 시장에서 새로운 제품을 기획하고 만들어나가는것이 주된 업무입니다. 그리고 이런 제품 개발 과정은 끊임없는 결정의 연속입니다. 소프트웨어 아키텍쳐부터 홈페이지 버튼 색깔에 대한 결정까지 서로 끊임없이 토론하고 대화합니다. 이 때 강한 의견을 가진 사람이 있다면 강한 실행력으로 빠르게 제품 개발을 진행할 수 있을 것입니다.
하지만 이 때 의견이 강한 사람이 고집이 세서 개인의 의견만 내세우고 상대의 의견을 듣지 않을 수도 있습니다. 발전적인 조직을 만들고 개개인이 훌륭한 조직원이 되기 위해서는 본인의 의견만 강한 것이 아니라(Strong Opinions), 그 의견에 반대되는 의견이나 정보에 대해 적극적으로 알아보고, 내 의견을 바꿀 수도 있는 유연성을 지녀야 합니다(Weakly Held).
많은 사람들이 누군가가 본인의 의견과 다른 의견을 내세웠을 때 나의 말에 인정을 해주지 않아 기분이 나쁘거나 본인의 의견을 굽히는것을 자존심 상해 합니다. 조직에서는 여러 팀원들이 함께 더 나은 결과를 만들어 내기 위해 의견을 조율해 나가는 과정이 끊임없이 필요합니다. 한 사람의 강한 의견을 바탕으로 잘못된 목표를 향해 달려나가지 않기 위해서라도 다른 의견에 대해 열려있는 마음을 갖고 내 의견을 뒤집을 수 있는 유연성을 함께 가진 상태로 일하는 자세가 필요합니다.
마인드셋
일하는 방법
디자이너 성장
PM/PO가 주의해야 할 4가지 의사결정 편향
Open
불확실성이 가득한 비즈니스 세상에서 PM/PO가 의사결정할 때 꾸준히 주의하고 극복해야 하는 4가지 인지편향을 소개합니다.
1. 확증 편향 (Confirmation Bias)
• 가장 흔향 편향입니다
• 자신이 옳다고 여기는 정보만 받아들이고 신념과 일치하지 않는 정보는 무시하는 경향
• 검색, 추천 콘텐츠에서 개인화가 발달하면서 내 신념과 연관된 정보나 광고가 지속적으로 노출되면서 확증 편항은 더 빠져나오기 힘든 성향을 가집니다
• 사용자에게 던지는 질문을 내가 옳다고 생각하는바를 유도하는 문장으로 만들 수 있습니다
• 대시보드의 지표가 편향되어 설정될 수도, 여러 지표 중 긍정적인 지표만 사용하게 될 수도 있습니다
확증 편향을 극복하는 방법
• 편향을 가지고 있다는 사실을 늘 인식합니다
• 유도 질문을 철저하게 피합니다
• 여러 이해관계자로부터 균형된 피드백을 받습니다
• 목표치 설정을 각 팀 리더와 함께 셋팅하거나, '왜'에 대한 배경을 설명하고 의견을 구합니다
• 매 결정 시 'What'이 아닌 의사결정이 필요했던 'Why'를 충분히 만족하는지 리뷰합니다
노트
• 확증 편향을 극복하기 위해서는 먼저 반대되는 의견에 충분히 리서치하거나 노출될 필요가 있고, 반대되는 의견이 충분히 설득력 있다면 내 의견을 바꿀 수 있는 유연성을 가지고 있어야 합니다.
• 이러한 마인드셋을 'Strong views, Wealky held' 라고 합니다.
• Strong views, Wealky held에 대한 아티클을 첨부합니다 https://abit.ly/ksp_sv_wh
2. 매몰비용 오류 편향 (Sunk-cost Fallacy Bias)
• 이미 투자한 시간, 노력, 비용 때문에 미래의 불확실한 결과를 예상함에도 투자와 작업을 지속하고자 하는 편향입니다
• 손실 회피(Loss Aversion) 경향이 이런 편향을 만들어냅니다
매몰비용 오류 편향을 극복하는 방법
• 간단하지만 가장 근본적인 지표가 될 수 있는 질문에 답변할 수 있는지 스스로 물어봅니다
• 만약 전사가 목숨을 걸어야 하는 상황에도 동일한 결정을 할 것인가?
• 기존 코드가 모두 날아가서 없어졌음에도 같은 방법으로 코드를 유지보수 할 것인가?
• 내 동료가 진행하는 프로젝트에도 내가 그 방법이 옳다고 해줄 수 있을 것인가?
노트
• 매몰비용을 생각하지 않는 방법의 핵심은 지금까지 발생한 비용이 0이라고 가정하는 것입니다
• 지금부터 들일 노력과 노력에 따르는 이후 발생 가능한 이득만 객관적으로 비교하는것이 필요합니다
3. 이케아 효과/편향 (IKEA Effect/Bias)
• 본인이 직접 만든 제품에 대해 실제보다 더 큰 가치를 부여한다는 편향입니다
• 내가 노력을 기울였다고 해서, 투자를 했다고 해서 꼭 그 제품/서비스가 성공하지는 않습니다.
• 위 '매몰비용 오류 편향'과 이어져 내가 이만큼 노력을 했으니 그 노력만큼 성공적이지 못한 것은 다른 탓이라고 원인을 돌리게 됩니다
• 자신의 성과에 자부심을 갖는 것은 당연하지만, 노력과 투자부분이 제품과 서비스의 결과보다 강조되는 부분은 경계해야 하는 편향입니다
이케아 효과/편향을 극복하는 방법
• 내가 PM으로서 개발/디자인/지원팀 간 적절한 조율을 하고 있는지 항상 체크합니다
• 올바른 성과 지표를 프로젝트 시작에 맞춰 준비하고, 지속적으로 리뷰합니다
• 팀 간의 우위를 경쟁하는 것이 아닌 제품/서비스를 성공시킨다는 공통의 목표를 꾸준히 자주 주지시킵니다
• 우리 팀 결과물을 다른 팀에 제공하는 등 크로스 레퍼런스를 적극 활용하고, 경쟁 제품/서비스에 대한 분석을 본인의 고객/사용자 관점에서 진행해봅니다
4. 오류 합의 편향 (False-Consensus Bias)
• 내가 생각하고 행동하는것 처럼 다른 사람도 생각하고 행동할 것이다라는 '오류 합의'를 하는 편향입니다
• 이 편향을 가지는 경우 본인이 생각한 UX Flow대로 모든 사용자/고객이 이용할 것이라고 생각 됩니다
• 이 편향이 발전하게 되면 우리의 생각과 다른 생각이나 아이디어를 가진 사람들을 배제하거나 무시하는 현상이 나타납니다
오류 합의 편향을 극복하는 방법
• 본인의 목표를 항상 명확히 리뷰하고 팀 멤버들과 함께 리뷰합니다: '이 제품/서비스/기능은 고객/사용자에게 과연 합당한 것인가?'
• 고객/사용자에게 내 목표를 설명하고 그것이 맞는지 확인합니다
• 제품/서비스가 만들어지는 과정에 다양한 사용자군과 프로덕트 팀간의 피드백 프로세스를 통해 상호 생각의 오차를 줄여나갑니다
확증 편향을 극복하는 방법
• 편향을 가지고 있다는 사실을 늘 인식합니다
• 유도 질문을 철저하게 피합니다
• 여러 이해관계자로부터 균형된 피드백을 받습니다
• 목표치 설정을 각 팀 리더와 함께 셋팅하거나, '왜'에 대한 배경을 설명하고 의견을 구합니다
• 매 결정 시 'What'이 아닌 의사결정이 필요했던 'Why'를 충분히 만족하는지 리뷰합니다
노트
• 확증 편향을 극복하기 위해서는 먼저 반대되는 의견에 충분히 리서치하거나 노출될 필요가 있고, 반대되는 의견이 충분히 설득력 있다면 내 의견을 바꿀 수 있는 유연성을 가지고 있어야 합니다.
• 이러한 마인드셋을 'Strong views, Wealky held' 라고 합니다.
• Strong views, Wealky held에 대한 아티클을 첨부합니다 https://abit.ly/ksp_sv_wh
2. 매몰비용 오류 편향 (Sunk-cost Fallacy Bias)
• 이미 투자한 시간, 노력, 비용 때문에 미래의 불확실한 결과를 예상함에도 투자와 작업을 지속하고자 하는 편향입니다
• 손실 회피(Loss Aversion) 경향이 이런 편향을 만들어냅니다
매몰비용 오류 편향을 극복하는 방법
• 간단하지만 가장 근본적인 지표가 될 수 있는 질문에 답변할 수 있는지 스스로 물어봅니다
• 만약 전사가 목숨을 걸어야 하는 상황에도 동일한 결정을 할 것인가?
• 기존 코드가 모두 날아가서 없어졌음에도 같은 방법으로 코드를 유지보수 할 것인가?
• 내 동료가 진행하는 프로젝트에도 내가 그 방법이 옳다고 해줄 수 있을 것인가?
노트
• 매몰비용을 생각하지 않는 방법의 핵심은 지금까지 발생한 비용이 0이라고 가정하는 것입니다
• 지금부터 들일 노력과 노력에 따르는 이후 발생 가능한 이득만 객관적으로 비교하는것이 필요합니다
3. 이케아 효과/편향 (IKEA Effect/Bias)
• 본인이 직접 만든 제품에 대해 실제보다 더 큰 가치를 부여한다는 편향입니다
• 내가 노력을 기울였다고 해서, 투자를 했다고 해서 꼭 그 제품/서비스가 성공하지는 않습니다.
• 위 '매몰비용 오류 편향'과 이어져 내가 이만큼 노력을 했으니 그 노력만큼 성공적이지 못한 것은 다른 탓이라고 원인을 돌리게 됩니다
• 자신의 성과에 자부심을 갖는 것은 당연하지만, 노력과 투자부분이 제품과 서비스의 결과보다 강조되는 부분은 경계해야 하는 편향입니다
이케아 효과/편향을 극복하는 방법
• 내가 PM으로서 개발/디자인/지원팀 간 적절한 조율을 하고 있는지 항상 체크합니다
• 올바른 성과 지표를 프로젝트 시작에 맞춰 준비하고, 지속적으로 리뷰합니다
• 팀 간의 우위를 경쟁하는 것이 아닌 제품/서비스를 성공시킨다는 공통의 목표를 꾸준히 자주 주지시킵니다
• 우리 팀 결과물을 다른 팀에 제공하는 등 크로스 레퍼런스를 적극 활용하고, 경쟁 제품/서비스에 대한 분석을 본인의 고객/사용자 관점에서 진행해봅니다
4. 오류 합의 편향 (False-Consensus Bias)
• 내가 생각하고 행동하는것 처럼 다른 사람도 생각하고 행동할 것이다라는 '오류 합의'를 하는 편향입니다
• 이 편향을 가지는 경우 본인이 생각한 UX Flow대로 모든 사용자/고객이 이용할 것이라고 생각 됩니다
• 이 편향이 발전하게 되면 우리의 생각과 다른 생각이나 아이디어를 가진 사람들을 배제하거나 무시하는 현상이 나타납니다
오류 합의 편향을 극복하는 방법
• 본인의 목표를 항상 명확히 리뷰하고 팀 멤버들과 함께 리뷰합니다: '이 제품/서비스/기능은 고객/사용자에게 과연 합당한 것인가?'
• 고객/사용자에게 내 목표를 설명하고 그것이 맞는지 확인합니다
• 제품/서비스가 만들어지는 과정에 다양한 사용자군과 프로덕트 팀간의 피드백 프로세스를 통해 상호 생각의 오차를 줄여나갑니다PM/PO
마인드셋
일하는 방법
디자이너 성장
[Coinbase] 코인베이스의 의사결정 방법 (RAPID)
Open
코인베이스는 어떻게 의사결정 할까?
코인베이스는 사내 정치와 관료적인 의사결정 체계의 한계를 극복하고 노이즈를 줄여서 효율적인 결정을 위해 두 가지 방법을 사용합니다. 두 방법 모두 구글닥과 같이 모두가 함께 확인할 수 있고, 동시에 협업이 가능한 문서 형태로 커뮤니케이션 합니다.
Problem / Proposed Solution
• 일반적인 의사결정할 때 노이즈를 줄이는데 유용한 도구
• 문제와 제안 솔루션이 15분 안에 쓸 수 있게 간단하게 정리할 수 있어야 함
• 문제와 제안하는 솔루션을 담당자들과 관련 직원들에게 문서를 전달
• 담당자들은 문서에서 토론을 이어가거나, 미팅을 하거나 혹은 동의하거나 다른 솔루션을 제안할 수 있음
• 결정된 솔루션이 생가면 이것을 액션아이템으로 만들고, 1명의 직원에게 책임을 맡기고 데드라인을 정함
RAPID
• 여러 부서 간 협의로 결정을 내려야 할 때 사용되는 프레임워크
• Recommend (추천) 1명
• Agree (동의): 1-2명
• Perform (실행): 결정에 대해 실행을 책임질 사람
• Input (인풋): 이 결정에 대해 의견을 제공할 사람들
• Decide (결정): 아직 RAPID 팀에 들어오지 않은, 결정 할 1명
• 1명이 추천하고, 1주 이내에 결정을 합니다. 이 추천은 Type 1(되돌릴 수 없는 결정)인지, Type 2(되돌릴 수 있는 결정)인지 명시함
• 각 역할을 맡은 사람들은 이유와 함께 동의와 비동의 의견을 남김
Problem / Proposed Solution
• 일반적인 의사결정할 때 노이즈를 줄이는데 유용한 도구
• 문제와 제안 솔루션이 15분 안에 쓸 수 있게 간단하게 정리할 수 있어야 함
• 문제와 제안하는 솔루션을 담당자들과 관련 직원들에게 문서를 전달
• 담당자들은 문서에서 토론을 이어가거나, 미팅을 하거나 혹은 동의하거나 다른 솔루션을 제안할 수 있음
• 결정된 솔루션이 생가면 이것을 액션아이템으로 만들고, 1명의 직원에게 책임을 맡기고 데드라인을 정함
RAPID
• 여러 부서 간 협의로 결정을 내려야 할 때 사용되는 프레임워크
• Recommend (추천) 1명
• Agree (동의): 1-2명
• Perform (실행): 결정에 대해 실행을 책임질 사람
• Input (인풋): 이 결정에 대해 의견을 제공할 사람들
• Decide (결정): 아직 RAPID 팀에 들어오지 않은, 결정 할 1명
• 1명이 추천하고, 1주 이내에 결정을 합니다. 이 추천은 Type 1(되돌릴 수 없는 결정)인지, Type 2(되돌릴 수 있는 결정)인지 명시함
• 각 역할을 맡은 사람들은 이유와 함께 동의와 비동의 의견을 남김일하는 방법
마인드셋
가이드
프레임워크
스타트업
리소스
[세탁특공대] PM/PO 역할 정의
Open
'세탁특공대의 PM/PO 역할에 대한 정의'
세탁특공대가 PM/PO 역할을 정의한 노션 페이지입니다. 많은 회사에서 PM과 PO에 대한 역할을 명확하게 구분하지 않고/못하고 모호하게 사용하고 있습니다. 이 때문에 일을 하다보면 이 일이 PM의 일인지, PO의 일인지 명확하게 나뉘지 않아 R&R을 나누거나 커뮤니케이션에 리소스 낭비가 되는 경우가 있습니다. 세탁특공대는 두 직무를 담당하는 사람의 역할을 명확히 하고, 두 직무와 협업하는 다른 사람의 기대를 명확하게 서술해두었습니다.
세탁특공대의 PO는 제품의 방향성을 결정하고, 사업의 미션을 정의해 타당성을 설득하고 이 미션의 끝까지 도달하는 방법의 우선순위를 결정하며 제품의 기획부터 배포 이후의 디벨롭 프로세스 과정을 총괄 매니징 하는 사람입니다.
세탁특공대의 PM은 PO가 제시한 비전을 실제 제품으로 만드는 역할을 중심으로 수행합니다. PO, Stakeholder의 요구사항을 정확하게 이해해 크루에게 전파합니다. 제품화 까지 필요한 요소를 정의하고 필요한 인력, 시간 리소스를 책임지며 적절히 배치합니다. 제품화를 방해하는 요소를 제거해 다른 크루들이 업무에 집중할 수 있는 환경을 제공합니다.
PO는 다음과 같은 역할을 합니다.
비전 계획서 작성: 비전, 현재 상황 분석, 비전을 달성할 수 있는 전략과 전술
Epic 기획서 작성: 목적, 타당성, 목표, 주요 수치, 예산 등
데이터 기반 분석: (환경 요소를 고려한) 액셔너블한 데이터에 집중, 핵심 지표를 기준으로 하위 데이터 항목 설정
설득
PM은 다음과 같은 역할을 합니다.
비전을 제품화 하기: 미션을 제품에 제대로 녹여낼 수 있는 프로덕트 기능 목표 제시
스토리 Flow 완성
스프린트 계획: 플래닝 미팅에서 만들어진 태스크를 기록하고, 진행상황을 업데이트
스크럼 마스터: 데일리 스크럼 주도, 다른 Stakeholder로부터 내부 크루 보호, 태스크 병목상황에서 우선순위 조정, 멘탈 관리
실무 크루와 커뮤니케이션
나아가 세탁특공대가 스크럼, 스프린트를 사용해 일하는 방식도 함께 엿볼 수 있습니다.
비전 계획서 작성: 비전, 현재 상황 분석, 비전을 달성할 수 있는 전략과 전술
Epic 기획서 작성: 목적, 타당성, 목표, 주요 수치, 예산 등
데이터 기반 분석: (환경 요소를 고려한) 액셔너블한 데이터에 집중, 핵심 지표를 기준으로 하위 데이터 항목 설정
설득
PM은 다음과 같은 역할을 합니다.
비전을 제품화 하기: 미션을 제품에 제대로 녹여낼 수 있는 프로덕트 기능 목표 제시
스토리 Flow 완성
스프린트 계획: 플래닝 미팅에서 만들어진 태스크를 기록하고, 진행상황을 업데이트
스크럼 마스터: 데일리 스크럼 주도, 다른 Stakeholder로부터 내부 크루 보호, 태스크 병목상황에서 우선순위 조정, 멘탈 관리
실무 크루와 커뮤니케이션
나아가 세탁특공대가 스크럼, 스프린트를 사용해 일하는 방식도 함께 엿볼 수 있습니다.PM/PO
직무 분석
스타트업
일하는 방법
크래프톤 웨이에서 배운 사람에 관한 61가지
Open
'크래프톤 웨이'에서 배운 사람에 관한 61가지
크래프톤 웨이는 크래프톤이라는 스타트업이 어떻게 성공했는지 그 비결에 대해 이야기 하는 책이 아니라 창업이 어떻게 이루어 졌으며, 어떤 경영 원칙을 세웠고, 누가 어떤 조직을 맡고 떠났으며, 어떤 고난을 겪었고 어떻게 성공을 했는지 있는 그대로 이야기하는 역사서와 같은 책입니다.
ASH님이 뽑은 61가지 인사이트 중 일부를 발췌합니다.
3. 우리에겐 노동자 대신 인재가 필요합니다. 노동자와 인재의 근본적인 차이는 무엇일까요? 바로 대체 가능 여부입니다. 노동자는 대체가 가능합니다. 공장에서 사람 하나 빠지면 2~3일 지나 곧바로 다른 인력으로 대체할 수 있습니다. 그런데 인재는 대체 불가능합니다. 그 사람이 하던 일을 다른 사람이 그 수준으로 못합니다. 인재는 회사가 싫어지면 회사를 나가면 끝입니다. 오히려 회사가 인재를 잃기 싫어 남아주도록 매달려야 하죠. 그만큼 인재와 노동자는 다른 것이고, 인재의 힘은 큽니다.
9. 라스트맨인데 고독하지 않다는 것은, 어쩌면 권한과 보상을 누리면서, 주체적이고 능동적으로 책임을 다하지 않고 있다는 방증일지도 모른다. 조직 내에서 고독을 느끼지 못한다면, 본인에게 주어진 역할과 책임이 그만큼 중요하지 않다는 의미일 수 있다. 그렇다. 의사결정은 라스트맨이 짊어져야 할 숙명이며, 그 과정은 고독하다.
10. 상급자가 어떤 의사결정을 내렸으면, 최소한 왜 이런 결정을 내렸는지 설명하고 공유하는 문화가 필요했다. “까라면 까"와 “따라주세요"는 엄연히 다르다. 팀원도 의사결정의 근거를 알 권리가 있다. 납득이 되어야 자발적으로 일한다.
23. 도전을 시작한 누구라도, 여전히 가치 있는 도전인지, 실패해도 후회하지 않을지 등을 주기적으로 돌아봐야 한다. 대부분의 경우 무언가를 이루기 위해 도전하지만 실은 실패가 더 많다는 점을 인식해야 한다. 성취보다 그 과정이 훨씬 중요하다는 점도 인식해야 한다. 우리 삶은 성취의 결과물보다 도전의 과정으로 정의된다.
30. 조직과 팀은, 신뢰 위에서 올라가요. 법 위에서 올라가지 않아요. 법이라는 건 신뢰가 지켜지지 않을 때를 대비한 최소한의 안전장치입니다. 조직은 기본적으로 신뢰라는 강점을 기반으로 올라가야 돼요.
34. 부하 직원은 상급자가 왜 그런 결정을 했는지 이해하려고 노력하면서도, 틀렸다고 생각하면 언제라도 이의를 제기할 수 있어야 합니다. 또한 말과 글을 옮기기는 어렵다는 사실을 통렬히 인식해야 합니다. 경영진과 본부장의 생각이 동일한 것으로 보이더라도, 메시지가 팀원 수준까지 전달되면 분명히 다르게 이해될 가능성이 상당히 높습니다. 의도적으로 커뮤니케이션을 챙겨야 합니다.
51. 많은 리더가 착각한다. 옳은 결정을 내리는 일이 자신의 역할이라고 말이다. 결정은 시작일 뿐이다. 리더는 사람들이 옳은 일을 하게 만들어야 한다. 리더가 스스로 판단하기에 좋은 생각과 결정을 했더라도 그건 아무런 가치가 없다. 그 일이 실제로 수행돼 결과를 만들어내기 전까지는.
54. 좋은 리더는 자기보다 능력이 뛰어난 사람들을 많이 모아 최상의 결과를 끌어낸다.
59. 최고를 위한 전략은 심플합니다. 누구보다 빠르게 혁신하고 최고의 퀄리티를 유지하면 됩니다. 최고가 될 수 없기 때문에 복잡하고 얕은 수를 사용하는 겁니다. 최고가 될 수 있다면 다른 복잡한 것을 생각할 이유가 없습니다. 심플하게 최고의 제품과 서비스를 만듭시다.
독후감
스타트업
일하는 방법
[토스] 토스가 보이스톤 메이커를 만들게 된 배경
Open
지난 토스의 Simplicity 21 컨퍼런스에서 발표된 적 있는 토스 보이스톤 메이커를 만들게된 과정에 대한 글입니다.
팀이 작을때는 내가 주로 작성하는 어투만 프로덕트에 반영되기 때문에 프로덕트의 보이스톤을 일관되게 유지하기가 더 쉽습니다. 하지만 팀이 커지고 많은 사람들이 프로덕트에 사용되는 레이블을 작성하기 시작하면서 보이스톤을 일관되게 유지하기 어려워지기 시작합니다.
토스에서도 프로덕트 디자이너, UX Writer, PO, Legal 등 다양한 이해관계자가 레이블에 영향을 주고 있다보니 개인이 UX Writing에 대해 신경을 많이 쓴다고 해도 보이스톤이 하나로 통일되기는 어려운 상황이었습니다.
토스는 UX Writer의 리소스를 반복적으로 사용하지 않는 확장가능한 방법을 위해 프로덕트 디자이너가 사용하는 프레이머 툴에 더 나은 단어를 제시해주는 보이스톤 메이커를 도입하였습니다. 보이스톤 메이커를 통해 디자이너들은 디자인 과정에서 즉시 적절한 단어를 추천받아 수정하고, 통일된 보이스톤을 구현할 수 있도록 했습니다.
보이스톤 메이커를 도입하기 위해 UX Writer, UX 엔지니어가 TF를 구성해 작업하였는데, 회사 입장에서도 보이스톤 메이커라는 내부 워크 프로세스를 위해 리소스를 사용하도록 결정할 수 있었다는것이 놀라운 결정입니다.
관련한 Simplicity 21 영상입니다.
https://www.youtube.com/watch?v=zRm5JNcC_Bw
UX Writing
일하는 방법
실 사례
경험 공유
제품 방향성을 알려주는 사용자 인터뷰하는 방법
Open
사용자의 행동 데이터나 사용자의 피드백은 현재 솔루션이 사용자의 문제를 해결해 주는지, Frictionless 한 사용 경험을 제공하는지를 알려주긴 하지만 제품의 방향성을 어떻게 해야 하는지는 알려주지 않습니다.
제품의 방향성을 알기 위해서는 사용자 인터뷰가 필요합니다. 사용자 인터뷰를 할 때 유의해야 할 점은 다음과 같습니다.
사용자의 경험과 현재 painpoint에 대해 질문해야 합니다.
사용자가 현재 겪고 있는 문제와 그 문제를 해결하기 위해 하고있는 방법에 대해 물어보아야 합니다. 만약 사용자에게 원하는 것이 무엇인지, 어떤 기능을 만들면 사용하겠는지 등에 대해 물어보는것은 잘못된 방향으로 가기 쉬운 방법입니다. '사용자는 반만 믿어야 한다', '사용자는 본인이 원하는것이 무엇인지 모른다'라는 격언과 그 맥락이 동일합니다.
사용자의 생각을 파악해야하지, 나의 생각을 심으려고 해서는 안됩니다.
사용자를 인터뷰할 때 원하는 답을 유도할 의도를 가지고 질문해서는 안됩니다. 사람들은 상대에게 나쁜 이야기를 하고싶지 않는 성향을 기본적으로 가지고 있기 때문에 사람 간 인터랙션인 인터뷰에서는 사용자가 진실된 내용을 말하지 않을 수도 있습니다. 만약 '개선 전과 개선 후 디자인 중 어느 쪽이 더 편한가요?' 와 같이 '개선된' 디자인이 더 좋다는 편향적인 질문을 하는 경우 사용자는 그 경향성에 편승하는게 쉬운 선택이 될 수 있습니다.
인터뷰 할 대상은 다음과 같이 나눌 수 있습니다.
현재 우리 솔루션을 사용하는 유저
→ 어떻게 하면 유저 플로우를 최적화 시키고 사용자 경험을 개선시킬 수 있을지를 알 수 있습니다.
경쟁 솔루션을 사용하는 유저
→ 경쟁 솔루션이 아닌 우리 솔루션을 사용하게끔 하려면 어떤 니즈를 충족시켜줘야 되는지를 알 수 있습니다.
우리 솔루션도 경쟁 솔루션도 사용하지 않는 Non-유저
→ 우리가 시장을 확장하려면 어떻게 해야 되는지를 알 수 있습니다.
많은 사람들이 간과하는 점은 경쟁 솔루션을 사용하는 사용자를 인터뷰 하는것이 매우 중요하다는 점입니다. 현재 우리 솔루션 사용자는 이미 핵심 기능에 만족하고 계속 사용하는 사용자이기 때문에 그들의 Painpoint는 핵심적인 문제가 아닐 수 있습니다. 반면 우리 프로덕트를 사용하지 않고 경쟁 프로덕트를 사용하는 경우엔 우리 프로덕트에서 제공해주지 못하고 있는 핵심 문제를 경쟁 솔루션에서 해결하고 있다는 의미이기 때문입니다.
사용자의 경험과 현재 painpoint에 대해 질문해야 합니다.
사용자가 현재 겪고 있는 문제와 그 문제를 해결하기 위해 하고있는 방법에 대해 물어보아야 합니다. 만약 사용자에게 원하는 것이 무엇인지, 어떤 기능을 만들면 사용하겠는지 등에 대해 물어보는것은 잘못된 방향으로 가기 쉬운 방법입니다. '사용자는 반만 믿어야 한다', '사용자는 본인이 원하는것이 무엇인지 모른다'라는 격언과 그 맥락이 동일합니다.
사용자의 생각을 파악해야하지, 나의 생각을 심으려고 해서는 안됩니다.
사용자를 인터뷰할 때 원하는 답을 유도할 의도를 가지고 질문해서는 안됩니다. 사람들은 상대에게 나쁜 이야기를 하고싶지 않는 성향을 기본적으로 가지고 있기 때문에 사람 간 인터랙션인 인터뷰에서는 사용자가 진실된 내용을 말하지 않을 수도 있습니다. 만약 '개선 전과 개선 후 디자인 중 어느 쪽이 더 편한가요?' 와 같이 '개선된' 디자인이 더 좋다는 편향적인 질문을 하는 경우 사용자는 그 경향성에 편승하는게 쉬운 선택이 될 수 있습니다.
인터뷰 할 대상은 다음과 같이 나눌 수 있습니다.
현재 우리 솔루션을 사용하는 유저
→ 어떻게 하면 유저 플로우를 최적화 시키고 사용자 경험을 개선시킬 수 있을지를 알 수 있습니다.
경쟁 솔루션을 사용하는 유저
→ 경쟁 솔루션이 아닌 우리 솔루션을 사용하게끔 하려면 어떤 니즈를 충족시켜줘야 되는지를 알 수 있습니다.
우리 솔루션도 경쟁 솔루션도 사용하지 않는 Non-유저
→ 우리가 시장을 확장하려면 어떻게 해야 되는지를 알 수 있습니다.
많은 사람들이 간과하는 점은 경쟁 솔루션을 사용하는 사용자를 인터뷰 하는것이 매우 중요하다는 점입니다. 현재 우리 솔루션 사용자는 이미 핵심 기능에 만족하고 계속 사용하는 사용자이기 때문에 그들의 Painpoint는 핵심적인 문제가 아닐 수 있습니다. 반면 우리 프로덕트를 사용하지 않고 경쟁 프로덕트를 사용하는 경우엔 우리 프로덕트에서 제공해주지 못하고 있는 핵심 문제를 경쟁 솔루션에서 해결하고 있다는 의미이기 때문입니다.사용자 조사
경험 공유
프레임워크
일하는 방법
디자이너 성장
데이터로 문제를 해결하기 위해서는? (feat. ICE, PSW 프레임워크)
Open
데이터 사이언티스트 하용호님의 인터뷰 글입니다. 하용호님은 스스로 하는 일을 데이터로 회사의 문제를 해결해주는 사람이라고 합니다. '데이터'라는 점을 빼면 디자이너가 하는 일과 맥락을 같이한다고 볼 수 있겠습니다.
회사들은 데이터 사이언티스트에게 어려운 문제를 던져주기 마련입니다. 눈에 보이는것 뒤에 숨은 문제까지 발견할 수 있어야 진짜 문제를 발견하고 해결할 수 있습니다. 지금 바라보는 문제가 진짜로 해결할 만 한 문제인지 판별하기 위해 ICE 프레임워크를 사용합니다.
• Impact: 얼마나 많은 유저들에게 영향이 가는가
• Confidence: 성공 가능성
• Ease: 도입 난이도
해결할 만한 수준의 문제라는것을 알게 되었다면, 이 문제를 정확하게 바라보고 문제 해결을 위한 방법을 아이데이션 하는 방법으로는 PSW 프레임워크를 사용합니다.
• Problem: 누가, 얼마나 심하게, 어떻게 겪고 있는 고통인가?
• Solution: 이 고통을 해결해주는 방법
• Why: 우리가 왜 해야하는가. 다른 이들보다 더 나은 장점 (Unfair Advantage)
이외에도 하용호님의 문제해결능력에 대한 조언과 데이터 리터러시에 대한 이야기들이 담겨있습니다
경험 공유
실 사례
직무 분석
일하는 방법
B2B 사용자 리서치 필수 가이드
Open
B2B 프로덕트는 B2C 프로덕트보다 사용자와 만나 리서치를 진행하기 더 어렵기 때문에 셜록 홈즈와 같이 상세하게 리서치 해야 PMF를 달성할 수 있는 가능성이 높아질 수 있습니다.
• 먼저 프로덕트가 풀고자 하는 문제를 명확하게 정의할 수 있어야 합니다. 블로그에서는 엘레베이터 피치에서 사용하는 템플릿으로 Product Statement를 만드는 예시를 들었습니다.
• 또 매크로, 메소, 마이크로 3가지 레벨에서 리서치를 해야 합니다. 시장과 경쟁 상황에 대해 알고, 사용자와 경쟁자가 누구인지, 구매자와 사용자가 누구인지 알고, 사용자를 인터뷰 하여 사용자의 이야기를 들어야 합니다.
사용자 조사
가이드
프로덕트 분석
6 페이저 작성방법과 활용법
Open
아마존은 6 Page Narrative 라는 문화를 가지고 있는 것으로 유명합니다. 사람들의 눈을 현혹시킬 수 있는 슬라이드를 만드는 것 보다 줄글로만 이루어진 문서를 만들다 보면 자신의 생각을 더 날카롭게 다듬을 수 있기 때문이라고 하죠. 도표, 그래프, 디테일한 레퍼런스는 모두 Appendix에 들어갑니다.
저자는 이러한 60 min 회의를 위한 6 Page 문서 작성법과 담겨야 할 내용, 6 Page를 활용한 미팅을 진행하는 방법에 대해서 이야히 하고 있습니다.
일하는 방법
문서 작성법
가이드
PM/PO
[구글] HEART 프레임워크 가이드
Open
구글은 고객 중심 디자인 지표로 HEART 프레임워크를 적용하고 있습니다. 각각 Happiness, Engagement, Adoption, Retention, Task Success를 의미합니다. 각 항목이 어떤 내용을 의미하고 실제로 어떤 지표들을 활용해야 하는지 간단히 확인할 수 있습니다.
프로덕트 분석
프레임워크
가이드
PM/PO
잘 읽히는 티켓 작성법
Open
잘 읽히는 티켓 작성법입니다.
디자이너로서 개발자에게 요구사항과 작업 명세서를 전달할 일이 많은데, 상대가 이해를 못하거나, 꼼꼼히 읽지 못해 발생하는 커뮤니케이션 코스트를 모두 경험해보셨을 것 같아요 읽는이의 입장에서 명확하고 이해하기 쉬운 티켓 명세서를 작성하는 법을 다룬 글입니다.
읽는이의 입장에서 명확하고 이해하기 쉬운 티켓 명세서를 작성하는 법을 다룬 글입니다.문서 작성법
일하는 방법
경험 공유
UX Writer는 어떤 역할을 하는가
Open
화면에 정보가 많은 B2B 프로덕트를 디자인 하는 과정에서는 수 없이 많은 레이블을 만들어야 합니다. 점점 찾는 기업이 많아지는 그 UX Writer가 우리 회사에도 있었으면 하고 바라지만 당분간은 이루어질 수 없는 꿈으로 남아있을 확률이 높은 것 같습니다.
UX Writer 없이도 B2B 프로덕트의 레이블을 작성할 때 꼭 유념해야 할 항목들을 잘 꼽은 글입니다.
1. 책임질 수 있는 언어를 사용하고, 브랜드 이미지에 결맞춤이 되어야 합니다.
2. 어떤 상황에서 사용되는지를 알고 이에 맞는 용어를 사용해야 합니다.
3. 내 세계에서만 통할 언어를 사용해서는 안됩니다.
UX Writing
직무 분석
[Spotify] 디자인 프레임워크
Open
글로벌 음악 스트리밍 기업인 Spotify가 가지고 있는 디자인 프레임워크에 대한 설명입니다. Spotify 디자인 팀이 어떤 마인드셋으로 일하는지, 디자인을 위한 기회를 찾고 솔루션을 내기까지 과정을 잘 설명하고 있습니다. 어떤 곳에서 일하더라도 적용해볼 수 있을만큼 잘 정리된 프레임워크입니다.
케이스 스터디
실 사례
프레임워크
일하는 방법
마인드셋
Load more