🔗 이 글은 Nielson Norman 그룹이 NN Group 사이트에 올린 아티클을 번역, 요약한 글입니다.

B2B 프로덕트는 많은 양의 데이터를 한 번에 보여주기 위해 테이블을 사용하는 경우가 많습니다. 테이블을 사용할 때 어떤 점을 고려해서 디자인 해야할까요?

📎 테이블의 특징과 장점 (특히 카드 UI와 비교했을 때)

1. 확장성
   • 데이터가 변경되었을 때 행 방향, 열 방향으로 쉽게 확장할 수 있습니다
2. 비교 용이성
   • 두 인접한 데이터들을 눈을 많이 움직이거나 머릿속에 정보를 기억해둘 필요가 없이 편리하게 비교할 수 있습니다

📌 테이블에서 수행되는 4가지 핵심 사용자 태스크

1. 특정 레코드 검색
2. 데이터 비교
3. 한 행의 데이터를 확인하고, 편집하고, 추가하기
4. 레코드 관리 작업

1) 특정 레코드 검색

사용자의 검색 행동은 이미 알고있는 특정 항목을 찾거나, 어떤 기준을 충족하는 여러 항목을 찾는 행동입니다.
이를 위해 필터링, 정렬, 검색, 눈으로 스캔할 수 있습니다. 하지만 어떤 방식을 취할지 예측하기 어렵고, 사용자가 생각하는 가장 쉬운 방법에 대한 기대를 바탕으로 결정하게 됩니다.

🔑 Key Point

• 첫 번째 열은 읽을 수 있는 식별자를 제공해야 합니다
• 각 열은 데이터의 중요성과 각 열 간의 관련성에 따라 배치해야 합니다
• 필터는 발견하기 쉽고 빠르게 사용할 수 있어야 합니다. 또한 데이터를 확인할 때 필터링된 데이터를 보고있다는 것을 쉽게 인지할 수 있어야 합니다.

2) 데이터 비교

복잡하고 큰 테이블에서 비교 작업할 때 아래 문제들을 경험할 수 있습니다.

• 많은 양의 데이터 중 각 셀이 무엇을 나타내며, 어떤 레코드에 속하는지 알기 어렵습니다
• 비교하려는 열 혹은 행이 서로 멀리 떨어진 경우 비교하기 쉽지 않습니다

이를 해결하기 위해 아래 방법을 사용할 수 있습니다.

2-1) 찾는 정보를 쉽게 확인할 수 있게 하기

• 화면보다 큰 테이블일 경우 헤더 행과 헤더 열을 고정하기
• 행과 열 사이로 움직일 때 위치를 유지할 수 있도록 보더, 지브라 스타일, 호버 스타일을 제공하기

2-2) 비교할 정보를 가까이 위치할 수 있게 하기

• 행, 열을 숨기거나 행, 열 순서를 변경할 수 있도록 하기 (숨긴 경우 숨겨져있는 표시가 있어야 합니다!)

3) 한 행의 데이터를 확인하고, 편집하고, 추가하기

한 레코드에 대한 위 세가지 액션을 하기에는 테이블 형식이 적절하지 않을 수 있습니다

• 테이블에서 직접 수정 : 좁은 테이블에서 가능한 방식입니다. 읽기 모드와 수정 모드는 시각적으로 구분해 실수로 편집되는 경우를 방지해야 합니다.
• 모달 팝업 : 하나의 레코드만 확인할 수 있기 때문에 인접하거나 유사한 레코드의 데이터를 참조하거나 복사할 수 없는 단점이 있습니다.
• 비모달 팝업, 개별 윈도우 : 테이블의 일부에 접근할 수 있도록 하는 옵션입니다.
• 아코디언으로 행 확장 : 편집 중인 경우 인접 레코드를 참조하는데 어려울 수 있고, 시각적으로 어수선하게 될 수 있습니다.

4) 레코드 관리 작업

레코드 내용을 편집하는것 외에도 하나 혹은 그 이상의 레코드에 대한 관리 작업이 있을 수 있습니다.

4-1) 단일 액션
액션이 1개, 2개인 경우 행 내 인라인으로 배치할 수 있습니다. 그 이상인 경우엔 보통

• 공간이 없어 레이블을 생략하게 되면서 버튼을 식별하고 클릭하기 어렵게 됩니다
• 액션 버튼이 호버 혹은 Action 메뉴 아래에 숨겨져 발견하기 어렵게됩니다.

4-2) 배치 액션
여러 레코드에 대한 동시 액션을 위해서는 보통 레코드를 선택하는 과정이나 메뉴가 포함됩니다. 공간 효율적으로 옵션을 배치할 수 있습니다.

🔗 이 글은 Relate가 Relate 블로그에 올린 아티클을 번역, 요약한 글입니다.

Relate 팀이 업무 문화에서 많이 참고하고 있는 Basecamp의 제품 개발 프로세스를 소개합니다.

✍️ 요약

• Shape Up 프로세스는 자율성을 기반으로한 프로젝트 개발에 대한 가이드라인이라고 할 수 있습니다.
• 제품 팀에게 프로젝트의 목표를 전달하되, 프로젝트를 성공적으로 개발하기 위한 의사결정과 진행은 제품 팀이 결정합니다.
• 고객에게 유의미한 프로젝트를 전달하기 위해 더 긴 기간의 개발 주기를 가지고, 매 개발 주기마다 할 일에 다한 의사결정을 새로 합니다.
• 개별 제품 개발 관계자들은 높은 자율성으로 일해야 하기 때문에 모두가 고객과 문제에 대해 잘 이해하고 있어야 하고, 실력이 뛰어나거나 빠르게 학습할 수 있어야 합니다.

📌 Shape Up 프로세스의 특징

1️⃣ 6주 개발 + 2주 쿨다운 사이클
• 스크럼에 비해 더 긴 프로젝트 주기로, 유의미한 기능을 만들만큼 긴 기간과 관리할 수 있을만큼 짧은 기간 사이

2️⃣ 명세가 아닌 형태를 전달
• 제품 팀에게 구체적인 명세가 아닌 적절히 추상화된 Shape을 전달

3️⃣ 제품 팀이 책임지게 함
• 제품 팀에게 Shape이 배정되고 나면, 해당 Shape에 대한 실행과 커뮤니케이션은 제품 팀이 책임을 가져감

⏭ Shape Up 딘계

1. Shaping → 2. Betting → 3. Building

🔵 1. Shaping

제품 팀에게 프로젝트의 큰 틀과 완성 기준을 제시하되, 디테일은 제시하지 않습니다.

좋은 Shape은 충분히 추상적이지만(Rough), 문제를 해결할 수 있어야 하고(Solved), 프로젝트가 달성하거나 달성하지 않아야 할 목표가 확실해야 합니다(Bounded)

💬 2. Betting

주요 의사결정자들이 올라온 Shape 들의 우선순위를 평가하여, 어떤 프로젝트에 리소스를 투자할 지 결정합니다.

Basecamp는 개발 6주, 쿨다운 2주의 8주 주기를 구성하지만, Relate은 초기 스타트업이기 때문에 개발 3주, 쿨다운 1주로 4주 주기를 적용하고 있습니다.

Relate은 100% 리모트 팀이기에 2주보다 더 긴 주기로 개발을 진행하는 것이 더 유리합니다. 불확실성이 높은 초기에 실시간 커뮤니케이션을 몰아서 하고 나면 해야 할 일이 명확해지기 때문에 비동기 커뮤니케이션으로도 충분하기 때문입니다.

🏗 3. Building

제품 팀은 Shape의 범위 안에서 실행을 위한 구체적인 Task 정의부터, 개발을 완료하고 테스트 하여 실제 제품에 반영시키는 지점까지의 모든 과정을 직접 결정하고 책임집니다.

그 과정에서 디자이너, 프론트, 백엔드 개발자들은 핵심 과제를 먼저 이해하고 확인할 수 있도록 노력해야 합니다.

개발을 진행하면서 관계있는 Task끼리 Scope으로 묶고, 더 불확실성이 높은 Scope의 우선순위를 높이면서 진행하는 방식으로 일합니다. 아직 알지 못하는 것들을 인정하고 계획을 세우면서 진행하기 때문에 개발 상황을 더 정확하게 예측할 수 있습니다.

🔗 이 글은 토스가 toss 블로그에 올린 아티클을 번역, 요약한 글입니다.

국내에서는 서비스 기획자, PO와 PM 직무가 많이 혼용되어 사용되고 있습니다. 도그냥님이 브런치에서 역사적으로 각 직무가 왜 생기게 되었는지, 어떻게 발전하고 있는지를 고찰한 K-Product ownder의 탄생론이란 글도 있습니다.

쿠팡에 이어 대한민국 스타트업계를 리딩하고 있는 또 하나의 기업인 토스에서 프로덕트 매니저(PM)이 어떤 직무를 하고 있는지에 대한 글을 소개합니다.

✍️ 요약

PO가 개울을 건너기 위해 바윗돌을 빠르게 놓아 가설을 검증한 다음,
PM은 그 돌다리같은 제품을 넓고 튼튼한 다리로 만드는 역할을 합니다.

🔍 토스가 정의하는 PO와 PM

• PO는 혁신을 탄생시키는 것이 목표,
  PM은 그 혁신이 더 많은 이들에게 닿을 수 있도록 하는 것을 목표로 합니다.
• PO는 잠재적 고객,
  PM은 현재 고객에 집중합니다
• PO는 제품을 확장시키는 역할,
  PM은 현재 고객의 문제를 해결하는 역할을 합니다
• PO는 전략적 관점에서 가설을 세우고 실험을 설계하고,
  PM은 쌓아온 데이터를 분석해 가설을 설계합니다.
• PO는 제품이 일정 단계에 이르르면 다른 제품으로 이동,
  PM은 하나의 제품을 장기적인 관점으로 계속해서 관리, 개선해나갑니다.

💪 PM에게 필요한 스킬셋

PM은 하나의 제품을 더 활성화 할 수 있도록 지속적으로 관리, 개선하는 업무를 담당하기 때문에 전체를 바라보는 눈이 중요합니다. 이는 즉 하나의 사안에서 발생할 수 있는 모든 케이스들을 상상하고 고려할 수 있는 역량입니다. 이 역량을 가졌다면 제품을 운영하는 과정에서 맞닥뜨리는 여러 리스크들을 미리 감지하고 관리할 수 있습니다.

다른 분들의 예상과 다르게, 금융 도메인 지식보다는 제품 고도화를 위한 데이터를 기반으로 의사결정 내릴 수 있는 역량, 제품 개선점을 발견하고 정의해 자동화, 효율화 할 수 있는 역량, 여러 내외부 이해관계자들과 원할한 의사소통 역량이 더 중요하다고 합니다.

🔗 이 글은 Caitlin Brisson님이 Tally의 미디엄에 올린 아티클을 번역, 요약한 글입니다.

이 글은 프로덕트 디자이너인 저자가 Tally의 그로쓰 팀 PM으로 250일 동안 업무하면서 얻은 4가지 레슨 런에 대한 글입니다. 저도 현재 회사에서 프로덕트 디자이너와 PM 역할을 동시에 수행하고 있어 공감하며 읽을 수 있었습니다.

1. 목표를 우선순위화 하고, 결과물을 최적화 하는데 사용하기

프로덕트 디자이너와 PM으로서 함께 일할 때, 두 역할을 동시에 해야하는 날들이 많았고, 업무를 분배하는데 고민인 생겼습니다. SMART¹ 방법으로 목표를 설정하고, 내 시간을 투자할 방법으로 사용했습니다.

어떤 목표에 시간을 더 많이 사용할 지는 다음과 같이 결정합니다.

• 주 별, 분기 별 목표를 설정하자
• 목표 간 상충 관계를 파악하고 덜 중요한 요청엔 잘 거절하자
• 도중에 문제가 생겼을 때 어떤 것이 더 임팩트가 큰 지를 파악하자

2. 변화가 있을 때(혹은 문제가 있을 때) 적절한 태도를 취하기

지난 가을, 그로쓰 로드맵을 마무리 하고 새로운 업무를 시작하려 할 때 앱의 크리티컬 패쓰의 경험에 문제가 있는걸 발견했습니다. 이런 복잡한 상황에서 사람들은 무엇을 해야하는지에 대한 답을 찾으려고 하는게 아니라, 안정되고 긍정적인 환경을 원했습니다. 디자이너로서도 여러 사람들과 문제를 facilitating 하게 됩니다. 팀이 더 일을 잘 하도록 도우면서 리더십 스킬을 성장시키고 더 탄탄한 솔루션을 만들 수 있게 됩니다.

• 인간적인 모습을 취하고, 변화의 중심에 있는 사람들의 이야기를 듣자
• 솔직한 모습을 취하지만 도움이 되지 않는 피드백이나 문제로부터 팀을 보호하자
• 답을 모르는건 괜찮다. 함께 일을 굴릴 사람들을 불러들이자.

3. 데이터를 문제 발견, 우선순위화, 평가하는데 사용하기

PM으로서 다른 사람들이 성과 지표, 상태, 사용자 행동에 대해 물어보는 일이 많았는데, 데이터 분석 코스를 수강하고 이런 질문들에 스스로 답변할 수 있게 되었습니다. 또, 내 디자인 결과에 이벤트를 추가하고 이벤트 간 비주얼 맵을 그려 여러 팀이 목표를 얼라인하고 이해하는데 도움이 되었습니다.

• 프로덕트 분석과 분석 툴을 공부하는데 시간을 쓰자
• 데이터를 확인할 때 기준선(베이스라인)을 지정해, 어디에 시간을 더 써야 하는지 확인하자
• 디자인 결과물에 수집될/되는 이벤트를 명시해 디자인 의사결정에 참고하고, 엔지니어들과 더 원할하게 대화할 수 있다

4. 나 혼자 뿐 만 아니라 다른 모든 사람들이 장기 계획을 바라보고 있도록 하기

현재 진행중인 일에만 집중하면, 한 Phase가 끝나고 다음 Phase로 넘어갈 때 팀원들이 예상치 못한 목표를 발견하고 놀라는 일이 생기게 됩니다.

• 눈 앞만 바라보지 말고 장기적 관점을 생각하는데 시간을 쓰자
• 계속해서 팀이 나아가야 할 방향을 리마인드 하고 목표를 이해시키자
• 파트너와 이해관계자들에게 장기 계획을 이해하고 참여할 수 있도록 내 계획을 지도 삼아 이야기하자

디자이너로서 만드는 결과물들은 목표 얼라인, 협업, 영감에 도움을 줄 수 있습니다. 무언가를 만들 때 청중들이 어떻게 사용하게될 지를 고려해 만들어야 합니다.

🔗 이 글은 린스프린트님이 본인의 티스토리에 올린 아티클을 번역, 요약한 글입니다.

사용자의 업무상 발생하는 워크플로우 내 문제를 해결하기 위해 존재하는 것이 B2B SaaS의 존재 의의입니다. 과업을 수행하기 위해 제품이나 서비스를 구매한다는 JTBD(Jobs to be Done) 프레임워크는 B2B 프로덕트를 만들고 있는 사람들이 필수적인 프레임워크입니다. 고객이 수행하고자 하는 과업을 명확하게 정의하지 않고 제품 개발에만 몰두하는 것은 방향 없이 속력만 내는 것입니다.

원문에서는 JTBD 프레임워크의 9가지 원칙에 대해 상세한 설명과 함께 소개하지만, 일부만 옮기겠습니다. 궁금하신 분들은 원문 링크를 참조하세요. 🔮

1. 고객의 과업(JTBD)는 오랜 시간에 걸쳐 안정적이게 되었다

• ‘부모가 자녀에게 삶의 교훈 물려주기’ 과업은 인류만큼 오래된 과업입니다
• ‘출근길의 무료함 달래기’는 지역과 관계 없이 동일하게 적용되는 과업입니다
• Amazon은 ‘고객에게 가장 좋은 것을, 가장 저렴하게, 가장 편리하게 제공하는 것’을 과업으로 정의했기 때문에 이커머스 플랫폼 뿐 만 아니라 다양하게 비즈니스를 운영할 수 있습니다

4. 고객의 과업은 솔루션이나 기술과 무관하다

• 자신의 제품이 최적의 솔루션이 될 수 있도록 고객의 불편함과 니즈를 입맛대로 정의하고 싶은 욕구에 매몰되어서는 안됩니다
• 킥보드 대여 서비스가 해결하고자 하는 과업은 킥보드를 더 쉽게 빌리는 것이 아니라, 도심 속 이동을 더 편리하게 하는 것입니다
• 이미 고객은 현존하는 기술이나 자신만의 솔루션으로 해당 과업을 수행하고 있다는 것을 잊어서는 안됩니다

5. 제품의 성공은 제품이나 고객에 대한 분석이 아닌 고객 과업의 단위 분석(Unit Analysis)에서 창출된다

• 고객은 자신의 과업에 대해서는 알고 있지만, 그 과업의 최적 솔루션에 대해서는 모르기 때문입니다
• 헨리 포드가 ‘고객에게 무엇이 필요한지 묻는다면, 그들은 더 빠르고 지치지 않는 말이 필요하다고 답할 뿐이다’고 한 말과 일맥 상통합니다
• 고객의 과업은 시작과 끝이 존재하는 프로세스 형태로, 대여섯 가지에서 많게는 20~30개의 단위 과업으로 이루어져 있습니다
• 각 단위 과업 중 어떤 부분이 병목이며, 예측이 불가능 하고 비효율이 발생하는지에 대해 학습 해야합니다

7. 과업을 정의함으로서 니즈 해결의 성공을 측정할 수 있는 측정 지표로 활용 가능하다

1) 고객이 과업 수행에서 진정으로 원하는 Desired Outcome을 정의합니다
2) 이를 달성하기 위한 측정 지표와 기준값을 정의합니다
3) 이 기준값을 달성할 수 있도록 제품을 개발하고 마케팅을 수행합니다

• Desired Outcome: ‘중고 아이폰을 제 값에 빠르게 판매하기’
• 측정 지표와 기준값: 제 값 = 60만원+, 빠르게 = 7일-
• 달성 방법: 물건을 먼저 수령해 위탁 판매하고, 판매 고객에게는 최소 가격을 보증한다

8. 사람들은 과업을 더 잘 수행하거나, 더 저렴하게 수행할 수 있는 제품이나 서비스를 원한다

• ↕️ 과업을 더 잘 / 덜 잘 수행한다, ↔️ 가격을 더 많이 / 더 저렴하게 제공한다 두 축으로 2x2 매트릭스를 그릴 수 있습니다
• 고객이 과업을 해결하기 위해 사용중인 솔루션의 기능이 과다하다면 덜 제공하는 것도 하나의 방법이될 수 있습니다

🔗 이 글은 서혜림님이 본인의 브런치에 올린 아티클을 번역, 요약한 글입니다.

디자이너에게 요구되는 직무적 역할이 늘어나고 있는 요즘, 나를 포함한 많은 디자이너들은 처리해야 할 업무들에 둘러쌓여 있는 상태다. 나의 일을 효율적으로 처리하기 위해서는 똑똑하게 일하는 방법을 알아야 한다.

내가 야근을 했다는 것은 내가 효율적으로 일을 처리하고 있지 못하다는 뜻이다. 구조적으로 업무량에 비해 디자이너 리소스가 부족한 경우를 제외하고, 내가 가진 리소스로 내가 맡은 업무를 처리할 수 있다면 내가 야근하게 되는 이유는 아래와 같은 이유들로 발생하게 된다(이외에도 여러 이유가 있을 수 있지만 원 글의 내용을 기반으로 합니다).

• 1. 내가 가진 업무에 대해 제대로 파악하지 못했다
• 2. 일의 우선순위를 제대로 세우지 못했다
• 3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다
• 4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다

이 중 1, 2, 3은 업무 효율성을 높이기 위한 순서이자 방법이다.

1. 내가 가진 업무에 대해 제대로 파악하지 못했다

나의 시간을 효율적으로 배분하고 어떤 일을 먼저 집중해서 처리해야 하는지 아는 것은 내가 가진 업무가 무엇인지, 왜 그 일을 해야하는지를 파악하는 것으로부터 시작한다. 업무를 완료하면 어떤것이 더 나아지는가? 누구를 위한 작업인가? 작업을 완료하기 위해서는 어떤 리소스가 필요한가? 작업을 완료하기 위해서는 어떤 일들을 해야 하는가?

2. 일의 우선순위를 제대로 세우지 못했다

각 업무를 왜 해야하는지를 알면 우선순위를 세울 수 있다. 다른 팀 지원 업무, 쉽게 끝낼 수 있는 일이지만 중요하진 않은 업무, 내부 회의에서만 쓰고 실제 프로덕트로 개발되지 않을 장표들의 경우 우선순위를 낮게 가져갸야 한다. 내 업무시간은 나의 팀의 목표에 맞고, 고객에게 더 중요한 일이며, 시간이 많이 필요하더라도 꼭 달성해야하는 어떤 것이다.

3. 작업 방향을 잘못 잡았거나 완성도에 집착하다 마감 기한을 놓친다

주로 주니어에게서 많이 발견되기도 하는 이 문제는 시간이 오래 걸리는 일이거나 아직 익숙하지 않은 일 일수록 쉽게 발생할 수 있는 문제이다. 내 상관이 원하는 방향은 이미 있는데 그것을 제대로 파악하지 못하고 잘못된 방향으로 일하고 있다거나, 중요하지 않은 디테일을 먼저 신경써서는 안된다. 전체적인 얼개를 그려 드래프트를 자주 공유해 방향을 자주 점검하고, 큰 줄기에서 작은 줄기, 마지막 디테일 순으로 작업해야 진짜 중요한 작업을 놓치지 않을 수 있다.

4. 물리적인 업무 시간 중 이미 시간을 배정해둔 협업 시간들을 유의미하게 보내지 못했다

스크럼, 회고, 의사결정을 위한 회의 등 다른 사람들과 협업하기 위한 시간은 고정되어있고, 여러 사람의 시간을 동시에 사용하기 때문에 더욱 귀중하게 쓰여야 한다. 회의 어젠다는 참석자에게 전달하고 수렴하고 싶은 내용이 확실하게 정해져야 한다. 이를 위해 주도적으로 회의를 준비해보는 것도 도움이 되겠다.

🔗 이 글은 Amy Ly님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

스타트업 씬에서 빠르게 프로덕트를 개발하다보면 백로그에 남아있는 이슈들이 점점 많아지게 되는 경험을 많이 해보셨을 것 같아요. 백로그에 등록된 이슈들은 우선순위를 관리해주지 않으면 이슈가 쌓이기만 하고, 스프린트로 올라와서 해결되는 이슈는 점점 적어지고, 그 크기나 중요도와 관계 없이 아이디어들만 중구난방으로 흩어져있는 창고가 되기 쉽습니다.

저도 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

🔗 이 글은 Jim Lewis가 Measuring U에 올린 아티클을 번역, 요약한 글입니다.

통계 연구 결과는 어떤 내러티브로 전달하는지가 아주 중요합니다. 통계학 졸업반 학생들을 대상으로 하는 Statistics as Principled Argument 라는 책의 저자인 Abelson의 법칙 8가지를 소개합니다. 전달을 위해 의역을 많이 했으니 원문이 궁금하신 분들은 원문을 확인해주세요.

1. 확률은 생각만큼 매끄럽게 발생하지 않는다
   • 동전 던지기가 50% 확률이라고 해서 앞면 다음에 반드시 뒷면이 나오진 않습니다
   • 실제 랜덤 함수의 결과는 결과들이 생각보다 뭉쳐있습니다
2. 사람들은 표본 간 차이를 무시하려는 경향이 있다
   • 표본마다 측정치는 다를 수 있는데, 이를 무시하고 잘못된 확신을 가지려 하는 경우가 많습니다
   • 특히 표본 크기가 작을 때 추정된 값을 중심으로 신뢰 구간을 계산하는 것이 중요합니다
3. 통계적 관행은 한 번만 다시 생각하라
   • 오랜 시간동안 유의성 실험에 p < 0.05를 사용하는건 관행이었습니다
   • 하지만 현대 UX 분석에서 p < 0.10이라는 덜 엄격한 기준을 적용했을 때 더 높은 통계적 힘을 낼 수 있었습니다
   • 마음에 드는 결과를 찾기 위해 p < 0.05와 p < 0.10 사이를 왔다갔다 하면 안됩니다
4. 복잡한 분석 방식으로 뭘 분석해야할 지 모름을 덮으려 하지 마라
   • 다변량 분석 방식은 유의미할 수 있는 종속 변수를 결합할 수 있는 어떤 방법이 있음을 나타낼 뿐, 그 조합이 어떤 실제적 의미를 갖는지는 고려되지 않았습니다
   • 각각 단일 분석 결과는 상관 관계가 있지만 UX 관점에서 다르게 해석되는 경우가 있습니다. 이런 분석 결과를 맹목적으로 조합 해 그 조합을 이해하려는 노력보다는 각각을 별도로 분석하는것이 더 옳습니다 (예: 성공률, 용이성 등급, 완료 시간)
5. 아무 할 말이 없을 땐 아무 말도 하지 마라
   • 종종 분석 결과가 어떤 유의성도 보이지 않는 경우가 있을 수 있습니다
   • 여기서 어떤 의미를 뽑아내기 위해 데이터를 이리 저리 쥐어짜기 보다는 다음 연구로 넘어가는게 맞습니다
   • 거짓으로 결과를 뽑아내는것 보다는 아무 말도 하지 않는 것이 낫습니다
6. 공짜 점심은 없다
   • 단일 실험 결과는 실험 맥락을 벗어나는 일반적인 경우까지 일반화되어 적용될 순 없습니다
7. 소파를 움직이지 않으면 먼지를 볼 수 없다
   • 한 분석 결과가 컨텍스트가 다른 상황에 적용 가능할 지 확인하는 방법은 그 컨텍스트를 변수화 하는 것입니다
8. 비판은 방법론의 어머니다
   • 모든 답을 내려주는 한 가지 실험은 있을 수 없고, 한 실험은 어떤 종류든 비판에 노출될 것입니다
   • 적절한 비판을 받았다면 연구자들은 그러한 비판을 극복할 수 있는 추가적인 연구를 수행하게 될 것입니다
   • 이런 결과로 기존 일반론이 지지되거나, 수정되거나, 파기되기도 하며, 새로운 일반론이 등장하기도 합니다

🔗 이 글은 엘리 골드렛의 경영 필독서 [The Goal] 을 요약한 글입니다.

앨리 골드렛의 The Goal은 TOC(Theory of Constraints, 제약 이론)을 이해하기 쉽게 설명한 경제경영서 베스트셀러 중 하나입니다. 비록 제조업을 기반으로 이야기가 흘러가지만 그 안에 담긴 전체 최적화 프레임워크와 발전적 사고 프레임워크는 많은 곳에 적용 가능한 범용적인 방법론이 될 수 있습니다. 아래는 The Goal 책 내용과 재구조화 해 정리한 내용입니다.

🏢 회사의 목표는 ‘돈을 버는 것’

회사가 돈을 벌기 위해서는 무언가를 판매해야 하고, 무언가를 판매하기 위해서는 무언가를 생산해야 합니다.

• 생산하기 위해 드는 비용이 ‘운영 비용’
• 생산되었지만 판매되지는 않은 것들이 ‘재고’
• 판매를 통해 돈을 창출하는 비율이 ‘현금 창출률’입니다.
  👆 회사가 돈을 벌려면 재고와 운영 비용을 낮추면서 현금 창출률을 높여야 합니다.

생산 과정에서는 필요한 만큼 충분히 생산하지 못하는 병목이 있기 마련이고, 그 병목의 생산 효율성이 전체 생산 효율성을 결정합니다. (쇠사슬의 강도는 가장 약한 고리가 결정함)
병목 자원(=제약 자원)의 생산 효율성을 높이는 것이 전체 생산 효율성을 높이는데 가장 중요합니다.

🎯 제약 자원의 생산 효율성을 높이기 위해서는

1. 제약 자원이 현 상태에서 가장 효율적으로 일할 수 있도록 개선합니다.
   • 끊임없이 일할 수 있도록 함
2. 해당 제약 자원을 기준으로 다른 공정의 생산 일정이 종속되도록 시스템을 조정합니다.
   • 제약 자원에게 공급할 부품 생산을 역산하고, 제약 자원의 생산량으로 이후 생산 일정을 역산함
3. 제약 자원의 생산 효율성을 높입니다.
   • Input을 개선
   • 제약 자원이 필요로 하는 일을 먼저 하기
   • 제약 자원이 하지 않아도 되는 일을 줄이기
   • 1회 목표 생산량을 줄이기 (1회 목표 생산량을 줄이면 생산 속도가 빨라지고, 변동성에 대한 유연성이 높아짐) - 제약 자원 자체를 개선
   • 덜 효율적이더라도 같은 역할을 할 수 있는 자원을 추가 사용
   • 한 번에 처리할 수 있는 업무는 동시에 처리하기 - Output을 개선
   • 병목 자원이 생산한 부품을 먼저 판매할 수 있도록 우선 가공

⛹️ 공정 뿐 만 아니라, 일반적인 경우에도 통할 수 있는 발전적 사고 프레임워크로 치환할 수 있습니다.

1. 문제 정의 :: 무엇을 변화시켜야 할지 발견하기
2. 목표 설정 :: 어떤 방향으로 변화시켜야 하는지 결정하기
3. 실행 방법, Operation :: 어떻게 변화시킬지 결정하기
4. 수행한 변화가 더 이상 성과에 영향을 미치지 않게 되면 다시 1단계로 돌아가기

👀 제약 자원의 생산 효율성 개선과 발전적 사고 프레임워크의 적용 예시

• 전략 보고서의 흐름을 문제 정의 → 목표 설정 → 실행 방법 순으로 전달
• 업무를 보고했을 때 상사가 원했던 퀄리티나 내용이 아니게 되는 문제
  → 전체 업무를 한 번에 완성시켜 전달하기 때문에 개선할 시간이 없는것이 문제
  → 1회 목표 생산량을 줄여 전체 드래프트를 자주 공유하고 디벨롭 시켜 나가기
• 시장의 수요가 생산력보다 넘친다면 ‘생산력’이 문제
  → 생산력을 개선하는 목표 설정
  → 설비를 더 들여오거나, 인력을 더 채용하는 결정
• 시장 수요보다 생산력이 넘친다면 ‘시장’이 문제
  → 시장을 개선하는 목표 설정 → 마케팅을 강화하거나, 새로운 시장을 발굴하는 결정

🔗 이 글은 Elon Musk가 Twitter에 올린 쓰레드를 옮겨 소개한 아티클을 번역, 요약한 글입니다.

일론 머스크는 여러 논란이 있지만 성공한 혁신가라는 점은 부인할 수 없습니다. 그는 이 성공의 주요한 요인 중 하나로 ‘제 1 원칙 사고’라고 부르는 명확하게 사고하는 법을 꼽았습니다.

급변하는 시장 상황에서 여러 상반되는 요구사항을 가지는 사용자를 상대로 올바른 결정을 내리기 위해서는 머릿 속에서 일어날 수 있는 오류나 편향을 피해야 합니다. 다음은 일론 머스크가 모든 어린이들에게 가르쳐야 하는 50가지 인지편향, 사고 오류, 인간의 비합리적 경향을 옮긴 내용입니다. 가까이에 두고 내 의사결정이 올바른 것인지 점검하는 용도로 사용해봅시다.

업무와 개인 생활에 있어 더 중요하다고 생각되는 경우엔 별도 표기했습니다
💼 : 업무 중 의사결정 오류를 유의해야 하는 경우
🏡 : 개인 생활 중 유의해야 하는 경향

1. 🏡 근본적 귀인 오류 (Fundamental Attribution Error): 다른 사람의 잘못은 상황보다는 성향에서 이유를 찾고, 자신의 잘못은 성향 보다는 상황에서 이유를 찾는 것
2. 🏡 자기 고양적 편견 (Self-serving Bias): 성공적인 일은 자신의 역할을 강조하고, 실패한 일에는 다른 사람이나 상황 요인을 탓하는 것
3. 내집단 편애 (In-Group Favoritism): 다른 집단에 속한 사람들에 비해 나와 같은 집단에 속한 사람들을 편애하는 것
4. 💼 밴드웨건 효과/편승 효과(Bandwagon Effect): 대중으로 유행하고 있다는 사실이 그 선택에 더욱 힘을 실어주는 것
5. 💼 집단 사고 (Groupthink): 의견의 일치만을 위해 갈등을 최소화 하여 비판적인 생각을 하지 않는 것
6. 후광 효과 (Halo Effect): 일부의 긍정적인 혹은 부정적인 특정에 주목해 전체의 평가에 영향을 주는 것
7. 도덕적 운 (Moral Luck): 성공한 사람은 도덕적으로도 우월할 것이라는 생각
8. 💼 합의 착각 효과 (False Consensus): 객관적 사실 없이 다른 사람들이 나와 같은 생각을 가질 것이라고 생각하는 것
9. 💼 지식의 저주 (Curse of Knowledge): 내가 새로운 사실을 알게 되었을 때 다른 사람도 그 사실을 알고 있을것이라는 생각
10. 스포트라이트 효과 (Spotlight Effect): 자신의 특징이나 행동에 대해 다른 사람이 생각하는 정도를 과대평가 하는 것. 다른 사람들은 생각보다 나에게 관심이 없음.
11. 가용성 휴리스틱 (Availability Heuristic): 머릿속에 더 쉽게 떠오르는 사건을 중심으로 생각하는 것. 자동차 사고가 더 빈번하지만 떠올리기 쉬운 비행기 사고에 대해 더 많이 걱정하는 것
12. 귀인 편향 (Defensive Attribution): 자신이 경험할 수도 있는 사건에 대해 더 화를 내는 것
13. 🏡 공정한 세상 가설 (Just-World Hypothesis): 세상은 공정하다고 가정하므로 공정하지 않은 일을 당한 사람은 그 사람이 잘못했다고 생각하는 것
14. 소박한 현실주의 (Naive Realism): 자신이 다른 사람 보다 더 객관적으로 바라본다고 생각하는 것
15. 순진한 냉소주의 (Naive Cynicism): 다른 사람이 실제보다 이기적일 것이라고 생각하는 것
16. 포러 효과/바넘 효과(Forer Effect (aka Barnum Effect)): 모든 사람에게 적용될 수 있는 모호한 말이지만 나에게만 해당하는 것으로 착각하는 것. 예: 점성술이나 타로, 사주
17. 🏡 더닝 크루거 효과 (Dunning Kruger Effect): 능력이 부족한 사람은 자신의 능력을 제대로 이해할 수 없기 때문에 과대평가 하고, 능력이 뛰어난 사람은 자신의 능력을 너무 잘 이해하고 있기 때문에 과소평가 하는 현상.
18. 정박 효과 (Anchoring): 첫 정보가 전체 논의에 영향을 미치거나 프레이밍 하는 것
19. 자동화 편향 (Automation Bias): 시스템이 사람보다 더 나은 결과를 제공한다고 생각하는 것
20. 구글 효과 (Google Effect (aka Digital Amnesia)): 쉽게 검색할 수 있는 것이라면 더 잊을 확률이 높다
21. 💼 청개구리 효과 (Reactance): 선택의 여지가 없는 상황에서 주어진 것에 반대로 하고싶어 하거나, 금지된 것일수록 더욱 갖고 싶어지는 것
22. 💼 확증 편향 (Confirmation Bias): 현재 가지고 있는 신념을 반증해주는 정보를 더 찾으려 하거나 더 잘 설득되는 것
23. 💼 역효과 법칙 (Backfire Effect): 현재 가지고 있는 신념에 반대되는 정보와 사실이 있더라도 원래 가지고 있는 신념을 강화하려는 것
24. 제 3자 효과 (Third-Person Effect): 일반적인 현상이 자신보다 타인에게 미칠 영향을 더 크게 생각해 태도와 행동에 변화가 나타나는 것
25. 💼 신념 편향 (Belief Bias): 주장의 타당성을 평가할 때 그 주장의 논리성이나 사실에 근거하는지와 강관 없이, 내가 현재 가지고 있는 믿음이나 가치관, 정보에 기반하여 평가하는 것
26. 🏡 가용성 폭포 (Availability Cascade): 더 많은 사람이 믿거나, 이야기할 때 그것이 사실이라고 믿게 되는 것. 집단적 믿음에 대한 자기 강화 프로세스
27. 비관론 (Declinism): 과거를 미화하고 현재를 쇠퇴하는 시기라고 생각하는 것
28. 💼 현상 유지 편향 (Status Quo Bias): 변화가 더 도움이 되더라도 지금 현상을 유지하려고 하는 것
29. 💼 매몰 비용 오류/몰입 상승 효과 (Sunk Cost Fallacy (AKA Escalation of Commitment)): 잘못된 결정이나 실패할 것이 확실한 일에 계속해서 투자하고 노력하는 것
30. 도박사의 오류 (Gambler's Fallacy): 사건이 일어날 확률이 결정되어 있음에도 전후에 일어난 사건에 영향을 받아 확률이 변화될 것으로 생각하는 것
31. 💼 제로 리스크 편향 (Zero-Risk Bias): 여러 위험 요소가 공존할 때 전체 리스크의 확률을 낮추기 보다 최소한 하나의 위험 요소를 완벽히 없애는 것을 선호하는 것
32. 프레이밍 효과 (Framing Effect): 동일한 사건이나 상황도 표현 방식에 따라 판단이나 행동이 달라질 수 있는 것
33. 고정 관념 (Stereotyping): 그룹에 대해 일반적인 신념을 가지고 있으면서 그룹 내 개인도 동일할 것이라고 생각하는 것
34. 외부 그룹 동질성 효과 (Out-group Homogeneity Bias): 그룹 내부 사람들은 다양하다고 생각하고, 그룹 외부 사람들은 비슷하다고 생각하는 것
35. 💼 권위자 편향 (Authority Bias): 이치에 맞지 않고 도덕적으로 의미가 없다고 하더라도 권위를 가진 사람의 말에 귀를 귀울이는 것
36. 플라시보 효과 (Placebo Effect): 어떤 것이 통할 것이라고 생각한다면 실제로 성공했는지 여부와 관계 없이 작은 긍정적인 효과를 경험하는 것
37. 생존자 편향 오류 (Survivorship Bias): 생존한 사람들만 생각하고, 사라진 사람들은 생각하지 못하는 것. 2차 세계대전 당시 생존한 비행기의 탄착흔이 날개에 있었다고 해서 날개를 보강해서는 안됨. 엔진에 맞은 비행기는 살아남지 못한 것이기 때문에.
38. 타키사이키아/빠른 마음 (Tachypsychia): 약, 긴박한 사건, 트라우마 등으로 시간이 느리게 느껴지는 것
39. 💼 사소함의 법칙 (Law of Triviality (AKA Bike-Shedding)): 더 중요한 것은 무시하면서 사소한 것을 필요 이상으로 중요하게 생각하는 것
40. 미완성 효과/자이가르닉 효과 (Zeigarnik Effect): 미완성된 일을 완성할 때 까지 더 잘 기억하는 것
41. 💼 이케아 효과 (Ikea Effect): 우리가 직접 만든 것의 가치를 과대평가 하는 것
42. 벤저민 프랭클린 효과 (Ben Franklin Effect): 우리가 호의를 베푼 상대에 대해 더 긍정적으로 생각하는 것
43. 방관자 효과 (Bystander Effect): 군중 속에 있을 때 사람들이 의무를 지려 하지 않는 것
44. 🏡 피암시성 (Suggestibility): 외부의 생각이나 영향력에 순응하고 무비판적으로 순응하는 것
45. 거짓 기억 (False Memory): 일어나지 않았던 사실을 실제 있었던 것으로 기억하는 것
46. 잠복 기억 (Cryptomnesia): 실제 기억을 상상이라고 생각하는 것
47. 클러스터 착각 (Clustering Illusion): 랜덤하게 일어난 사건에 대해 경향성을 찾으려고 하는 것
48. 염세주의 편향 (Pessimism Bias): 사건을 염세적으로만 바라보는 것
49. 낙관주의 편향 (Optimism Bias): 사건을 낙관적으로만 바라보는 것
50. 💼 맹점 오류 (Blind Spot Bias): 다른 사람의 오류는 쉽게 눈치 채지만 자신의 오류는 깨닫지 못하는 것

🔗 이 글은 Product Mindset님이 Substack에 올린 아티클을 번역, 요약한 글입니다.

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 정신이 필요합니다.
   • 잘못된 결정이 결정을 못 내리는 것 보다 낫고, 모두의 동의를 얻지 못했더라도 모두가 최선을 다해 실행하여 더 효율적으로 일할 수 있습니다.

🔗 이 글은 Lee J. H님이 ㅍㅍㅅㅅ에 올린 아티클을 요약한 글입니다.

회사 생활을 하면서 나의 디자인, 기획내용을 전달하거나 프로젝트 진행 내용을 보고하는 등 누군가에게 보고하는 상황이 종종 발생합니다. 이런 경우 회사에서 사용되는 보고서는 두 가지 목적으로 분류할 수 있습니다.

1. 문제 해결을 위해 어떤 행동을 해야하며, 이를 위해 어떤것이 필요하다
2. 문제 해결을 위해 어떤 행동을 했고, 이로 인해 어떤 성과가 났다

직장 상사와 하는 커뮤니케이션은 누구의 말이 옳은지 시시비비를 가리거나, 의미없이 수다를 떨기 위함이 아닙니다. 회사는 어떤 문제를 해결하기 위해 존재하는 조직이며, 특히 상사와 하는 커뮤니케이션은 해당 문제를 해결하기 위한 목적이 바탕이되어야 하고, 해당 목적이 빠져서는 안됩니다.

직장상사가 프로젝트의 진행 상황에 대해 요목조목 문제사항이라고 생각되는 점을 짚으며 지적을 했을 때, 그 지적사항들에 대해 ‘이미 조사했으며, 이러이러한 이유 때문에 불가하다’고 커뮤니케이션하면 안됩니다. 이런 경우엔 ‘해당 사항들은 어떤 상황들은 미달되었고, 이런 실행가능한 대안이 있으며 이를 위해 시간이나 의사결정이 필요합니다’ 라는 커뮤니케이션이어야 합니다.

회사에서 내 기획이나 디자인에 대해 전달하는 경우도 마찬가지입니다.
1번 목적인 경우엔 ‘현재 해결해야 할 어떤 문제 상황이 있고, 이를 해결하기 위해 어떤 기획이나 디자인을 제시하고, 이를 위해 선제 프로세스가 진행되어야 하거나, 여러 대안 중 의사결정이 필요하다‘는 방식으로 커뮤니케이션 할 수 있고

2번 목적인 경우엔 ‘해결해야 할 문제 상황에 대해 이렇게 처리했고, 이를 통해 어떤 성과가 있었다’ 고 커뮤니케이션 할 수 있겠습니다.

🔗 이 글은 Akash M Dubey님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

아무리 프로덕트 전략을 세세하게 짜뒀다고 해도 전략의 본질만 남겨 몇 문장만으로 간소하고 명확하게 표현할 수 있어야 합니다. 그렇게 표현하지 못한다면, 그 전략에 중요한 포인트가 없거나 짚어내지 못하는것입니다. 목표한 성공을 달성하기 위해서는 최적의 길을 선택할 수 있도록 돕는 훌륭한 전략이 필요합니다.

Geoffrey Moore의 Value proposition statement나 Positioning 프레임워크를 통해 다음과 같이 프로덕트 전략을 몇 문장으로 요약할 수 있습니다.

For (타겟 고객), Who has (니즈), (프로덕트 이름) Is a (시장 카테고리) that (핵심 가치/구매해야 할 이유). Unlike (핵심 경쟁 대체제), the product (경쟁 우위).

한글로 옮기자면 다음처럼 만들 수 있겠습니다.

(니즈)를 가진 (타겟 고객)에게, (프로덕트 이름)은 (핵심 가치/구매해야 할 이유)를 가진 (시장 카테고리)이다. (핵심 경쟁 대체제)와는 다르게, (프로덕트 이름)은 (경쟁 우위)를 제공합니다.

👇 몇 가지 예시로 프레임워크를 어떻게 활용할 수 있는지 확인해봅시다.

Netflix

엔터테인먼트를 원하는 밀레니얼들에게, Netflix는 심리스하게 작동하는 TV 시리즈의 온라인 구독 서비스입니다. HBO나 HULU와는 다르게, Netflix는 몰아서 볼 수 있는 오리지널 컨텐츠를 제공합니다.

AWS

회사가 성장하면서 인프라 비용을 컨트롤 하고 싶은 성장하는 회사들에게 AWS는 아주 유연한 클라우드 호스팅 서비스입니다. Google Cloud나 Microsoft Azure와 달리, AWS는 클라우드 서비스 일체를 제공합니다.

Uber

지역구 내에서 탈 것이 필요한 스마트폰을 가진 모두에게, Uber는 기존 택시 서비스보다 더 간단하고, 더 편리하고, 더 높은 퀄리티를 가진 이동수단 경험을 제공하는 차세대 택시 서비스입니다.

🔗 이 글은 Product Mindset님이 Substack에 올린 아티클을 번역, 요약한 글입니다.

프로덕트의 전략과 앞으로 수행할 로드맵을 결정하기 위해서는 프로덕트가 처해진 환경을 분석하는것이 중요합니다. 프로덕트의 경쟁 상황을 이해하는데 유용한 프레임워크인 마이클 포터의 5 Forces (5가지 경쟁요인) 프레임워크를 소개합니다.

마이클 포터의 5가지 경쟁요인을 잘 사용하기 위해서는 각 5가지 경쟁요인을 분석하고, 각자의 산업에 어떻게 적용될 수 있는지 알아봐야 합니다. 현실적으로 모든 분석 결과가 아름다운 모습을 가질수는 없지만, 산업을 이 프레임워크로 분석하는것은 더 강력한 경쟁자로 변화할 수 있는 방법과 수익성을 개선할 수 있는 방법에 대해 생각해볼 수 있는 기회를 제공합니다.

마이클 포터의 5 Forces

1) 신규 진입자의 위협
2) 대체제의 위협
3) 구매자 교섭력
4) 공급자 교섭력
5) 경쟁 강도

1) 신규 진입자의 위협
새로운 경쟁자의 등장은 산업에 남아 비즈니스를 유지하기 위한 가격, 비용, 투자율에 압박을 줍니다. 이러한 신규 진입자를 막을 수 있는 방법은 진입 장벽입니다. 마이클 포터는 진입 장벽의 7가지 핵심 소스를 소개합니다.

• 공급자의 규모의 경제
• 수요자의 규모의 혜택
• 고객의 전환 비용
• 최소 자본비용
• 규모와 무관한 현재 가지고있는 우위 (브랜드 자산, 고객 충성도 등)
• 유통 채널을 선점
• 정부 정책

2) 대체제의 위협
대체제는 동일한 경제적 니즈를 해소하기 위해 다른 기술을 사용한 제품입니다. 비행기와 기차, 맥주와 와인, 콜라와 생수를 예시로 들 수 있습니다. 하지만 코카콜라와 펩시콜라는 동일한 기술으로 경쟁하는 관계이기 때문에 대체제 관계가 아닙니다. 생수를 마시자는 마케팅은 코카콜라와 펩시콜라 두 시장 전체 파이를 줄어들게 할 수 있지만 펩시콜라 마케팅은 탄산음료 시장의 파이를 증가시킬 수 있기 때문입니다.

• 구매자의 대체 의향
• 대체제의 가격 대비 성능 비율
• 구매자의 전환 비용
• 제품 차이에 대한 인지
• 대체제의 수
• 대체 용이성

3) 구매자 교섭력
구매자는 제품을 대체할 수단이 많으면 교섭력이 올라가고, 대체한 수단이 적으면 교섭력이 낮아집니다.

• 구매 독과점 비율
• 유통 채널 의존도
• 가격 협상 영향력
• 구매자 전환 비용
• 구매자 정보 접근 가능성
• 현 대체제 접근 가능성
• 구매자 가격 민감도
• 제품 경쟁 우위
• 구매자 가치 분석 - RFM(Recency, Frequency, Monetary)(최근성, 구매빈도, 구매금액)

4) 공급자 교섭력
제품을 만드는데 필요한 원자재, 부품, 노동력, 전문 서비스 등을 제공하는 공급자의 힘입니다. 대체할 수 있는 공급자가 적을수록 공급자의 교섭력은 높아집니다.

• 공급자 전환 비용
• 공급의 경쟁 우위
• 공급의 비용 대비 경쟁력
• 대체제의 존재
• 유통 채널의 힘
• 공급 독과점 비율
• 노동조합
• 공급자간 경쟁

5) 경쟁 강도
산업 내 경쟁자를 이해하는것은 제품을 성공적으로 홍보하는데 중요합니다. 포지셔닝은 대중이 프로덕트를 어떻게 인지하고 경쟁자들과 어떻게 구분하고 있는지에 따라 달라집니다. 조직은 경쟁자의 마케팅 전략, 가격 정책에 대해 잘 알고 있어야 하며 경쟁자의 변화에 따라 대응해야 합니다.

• 혁신으로 경쟁을 지속 가능함
• 온라인 오프라인 조직 간 경쟁
• 마케팅 지출
• 강력한 경쟁 전략
• 독과점 비율

🔗 이 글은 Jordan Bowman님이 블로그에 올린 아티클을 번역, 요약한 글입니다.

B2B 프로덕트는 사용자의 업무를 성공적으로 도와주기 위해 존재합니다

비즈니스 업무를 수행하는 사용자에겐 시스템에서 발생한 오류로 인해 사용자의 업무에 영향이 가기도 하고, 고객 비즈니스 전반에 악영향을 주기도 합니다. 이러한 사용자 오류를 B2B 프로덕트 디자이너로서 방지할 수 있는 방법은 무엇이 있을까요?

1. 오류를 사전에 방지하기

1. 가드레일 설치하기
   • 사용자가 잘못된 선택을 하지 않을 수 있도록 도움을 주는 제약사항을 제공합니다.
   • 핸드폰 번호, 카드 정보 입력 필드에 숫자만 입력될 수 있도록 하기. 도착 날짜를 출발 날짜 이전으로 선택할 수 없도록 하기
2. 먼저 제안하기
   • (우버)최근 방문한 위치를 목적지로 제안하기. 사용자가 타이핑 중 자동 완성 문구를 제공하기
3. 더 나은 기본값 제공하기
   • 일반적인 값으로 혹은 개인화된 정보로 입력 필드를 미리 채워주기, 미리 알림 앱에서 ‘내일’을 기본값으로 제공하기
4. 표준 따르기
   • 사용자들은 이미 다른 사이트와 앱 등을 통해 어떤 것이 어떻게 작동할 지 이미 훈련되어 있습니다.
   • 일반적인 위치에 네비게이션 메뉴 제공하기
5. 액션을 명확하게 하기
   • 어떤 것이 어떻게 사용되어야 할 지 충분한 어포던스가 제공되어야 합니다.
   • 입력 필드의 설명 레이블, 다른 요소와 구분되어 보이고 클릭커블 해 보이는 링크와 버튼 제공하기
6. 결과 미리보기
   • 사용자는 자신의 액션이 어떤 임팩트가 있을지 충분히 알지 못하는 경우가 있습니다.
   • 결과 미리보기를 제공하면 사용자는 실제로 뭔가를 망가뜨리지 않고도 이리저리 실험적으로 사용해볼 수 있습니다.
   • 이메일 보내기 전에 미리보기, 블로그 포스팅 전에 미리보기, 인쇄하기 전에 미리보기
7. 실시간 경고 제공하기
   • 사용자가 에러를 만들어내는 중에 제공되는 미묘하고 맥락에 맞는 경고는 빠르게 상황을 인지하고 올바르게 수정할 수 있도록 도움을 줍니다.
   • (트위터) 글자 제한을 넘었을 때 제공되는 붉은 색 음수값,
     (MailChimp) 비밀번호 조건을 만족했을 때 조건마다 제공하는 체크마크
8. 중요한 액션은 다시 확인하기
   • 컨펌창은 사용자의 액션을 다시 확인하는 직접적인 방법입니다. 하지만 사용자의 워크플로우를 방해하지 않는 선에서 사용되어야 하고, 남용되지 않아야 합니다.
   • (페이스북) 메신저에서 대화를 지울 때 다시 물어보기,
     (Gmail) ‘첨부’ 단어가 있는데 첨부된 파일이 없는 상태로 발송하려 할 때 다시 물어보기

2. 실수가 일어난 다음 대응해야 하는 방법

1. 되돌리기 옵션 제공하기
   • 지운 파일을 보관하는 ‘휴지통’ 기능, 이메일 발송 후 발송 취소하기
2. 에러 피드백 제공하기
   • 무슨 일이 발생했고, 어떻게 해결할 수 있고, 미래에 다시 동일한 에러를 겪지 않는 방법을 알려줘야 합니다.

🔗 이 글은 백승엽님이 브런치에 올린 아티클을 읽고 적은 감상글입니다.

많은 사람들이 진로를 결정하거나 커리어의 다음 스텝을 고려할 때 한 가지 전문성을 더 파고들지, 더 폭넓은 방향으로 성장할지에 대해 고민한 적이 있을 것입니다.

제 나름의 결론은 스페셜리스트 먼저, 그 다음 제너럴리스트 였는데, 글의 저자분의 생각과 어느정도 일치하는 부분이 있는 것 같습니다.

먼저 취업이라는 좁은 관문을 뚫고 안정적으로 자리잡기 위해서는 처음엔 스페셜리스트의 뾰족함이 필요할 것입니다. 그리고 퇴직할 때 까지 실무를 하는 경우는 그렇게 많이 발견되지 않습니다(본인이 월클 디자이너가 되지 않는다면). 이후 커리어의 방향을 결정할 수 있는 후보를 다양하게 준비해 결정할 수 있기 위해서는 좀 더 다양한 분야에 대한 지식을 쌓아 제너럴리스트의 역량을 쌓는 것이 도움이 될 것입니다.

일반적인 직장을 다니는 경우를 생각했을 때, 완전한 스페셜리스트나 완전한 제너럴리스트는 존재할 수 없습니다.

만약 어느 한 분야의 전문성을 가지지 못했던 사람이라면 팀장과 같은 여러 직무의 사람들을 매니징하는 관리직으로 대표할 수 있는 제너럴리스트의 역할을 맡을 수 없을 것입니다.

또, 아주 좁은 분야에 대해 연구하는 연구자라고 하더라도, 그 연구자가 본인의 연구 분야를 결정하기 까지는 더 많은 분야에 대해 학습하고, 협력했을 것입니다. 그리고 아무리 좁은 분야라도 심리학/인류학/통계학/물리학 등 다양한 인접 학문과 연계해야만 하는 지점도 존재합니다.

원 글에서는 두 사람의 다양성과 전문성의 분포를 블럭으로 표현하여 겹치는 부분이 70% 정도임을 시각적으로 보여줍니다. 만약 자신이 들고 있는 블럭의 개수가 적다면 어디에 블럭을 쌓을지 보다는 눈앞에 당장 쌓아야 할 블럭을 놓치고 있는 것일지도 모릅니다.

🔗 이 글은 지원준님이 브런치에 올린 아티클을 요약한 글입니다.

이 글은 Slack의 CEO가 Slack의 프리뷰 릴리즈 2주 전 사내에 전파한 내용(에 대한 번역글)입니다.

Slack은 Slack이 만들어지기 이전에는 존재하지 않던 업무용 커뮤니케이션 SaaS 라는 새로운 시장을 타겟으로 만들어진 프로덕트입니다. 이 때문에 본인의 Painpoint를 잘 알고, 니즈를 설명할 수 있고, 어떤 프로덕트를 상상하는지 그려낼 수 있는 사용자는 없었습니다. Slack은 사람들이 ‘자신이 원한다고 믿는 것’들을 이해해 Slack의 가치를 그에 맞게 적절한 형태로 풀어내는 일에 집중했습니다. Slack은 디지털 프로덕트 뿐 만 아니라 회원가입 양식 문구, 로딩 페이지, 환영 이메일, 정확하고 이해도 높은 검색 결과, 사려 깊게 적용된 멋진 기능들에서 겪는 모든 경험들을 잘 디자인 했습니다.

Slack은 다른 수많은 스타트업들과 다르게 경쟁자가 명확하고 시장이 잘 정의된 상황에서 싸우지 않았습니다. 직접적인 경쟁자가 없고, 조악한 툴들로 니즈를 해소하던 시장을 뒤로하고 새로운 시장을 정의해야 했습니다.

Slack은 그룹 채팅 시스템을 파는게 아니라 조직 혁신(Organizational Transformation)을 판매합니다. ‘그룹 채팅 시스템’을 구매할 고객을 그리 많지 않지만, 스트레스로부터 해방, 지금까지 쌓은 데이터로부터 가치를 뽑아낼 수 있는 능력, 커뮤니케이션 비용 감소, 더 빠르고 좋은 결정, 75% 더 적은 이메일을 구매할 사람들은 많습니다.

🐴  말 안장을 판매하는 회사가 있다고 가정했을 때, 이 회사는 말 안장 가죽의 질, 장신구 등을 강조하면서 말 안장만 팔 수도 있습니다. 하지만 그들이 승마를 파는데 성공한다면, 그들은 말 안장에 대한 다양한 이야기를 풀어갈 수 있는 완벽한 맥락을 갖추는 동시에 시장을 그들의 제품에 맞게 키울 수도 있습니다.

🍋  실제로 최근까지 핫한 기업으로 알려진 Lululemon은 요가복과 요가 장비를 판매한 것이 아니라 요가를 판매했습니다. Lululemon은 요가를 팔기 위해 사람들의 집 근처 요가 스튜디오를 찾아주는 일부터 공짜 강좌를 개설하고, 스폰서쉽과 학위도 지원하고, 지역 홍보대사와 교육까지 했습니다.

기존 이메일 방식의 업무 커뮤니케이션에 익숙한 고객들에게 공개가 기본인 커뮤니케이션 툴을 사용하라고 요구하는 것은 거의 불가능한 일일 것입니다. 이를 위해 Slack의 고객은 정보의 흐름에 압도당하는 사람이 아닌, 자신의 정보를 관장하는 사람이 되길 원하고, 자신의 팀에 어떤 일이 벌어지는지 몰라 느끼는 당황스러움을 덜 느끼길 원하고, 분명한 목적의식을 가지고 소통하며, 자신의 질문 하나하나가 팀에게 가치를 가져다주는 사람이기를 원합니다. 그리고 고객이 분명히 이것을 얻을 수 있도록 노력해야 합니다.

기존에 없던 시장을 만들어나가는 불확실하고 힘든 상황에서 Slack의 CEO는 바라봐야 하는 지점에 대한 영감과 최선을 다해 일해야하는 이유를 훌륭하게 전달했습니다. 8년 전 글인 것이 믿기지 않을 정도입니다.

🔗 이 글은 Clement Kao님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

B2B 프로덕트는 B2C 프로덕트와 가지는 성향이 달라 B2C 프로덕트를 분석하던 방식을 사용할 경우 잘못된 분석을 하게 될 가능성이 있습니다. B2C 프로덕트와 B2B 프로덕트 사용자들은 크게 두 가지 다른점을 가지고 있습니다.

1. 새로운 사용자가 계속해서 들어오지 않음
   • B2B 프로덕트는 ‘도입 시기’가 정해져 있는 경우가 많고, 한 번에 많은 사용자가 들어오는 날이 정해져 있습니다.
2. 자주 사용하지 않음
   • B2C 프로덕트처럼 매일 일정하게 사용하기 보다는 워크플로우의 특징에 따라 사용하는 빈도와 주기가 정해져 있습니다.

(여기서부터는 원 글의 이미지와 함께 보시면 더 좋습니다)

ABC 회사는 1월 첫 주에 많은 사용자가 들어왔고, 각 주별 코호트는 거의 동일한 양상을 보입니다. XYZ 회사는 2월 마지막 주에 많은 사용자가 들어왔고, 역시 각 주별 코호트는 거의 동일한 양상을 보입니다. ABC 보다는 리텐션율이 떨어집니다.

하지만 이 두 회사를 합쳐서 확인했을 땐 1월 첫 주 코호트의 리텐션은 높고, 2월 마지막 주 코호트의 리텐션은 낮다는 분석 결과가 도출됩니다. 또, 일자별 리텐션을 확인했을 땐 모든 코호트가 동일한 양상을 보이기 때문에 코호트별 특징을 발견할 수 없습니다. 만약 두 회사가 어떤 특징으로 프로덕트를 사용하고 있는지 알지 못했다면 잘못된 분석을 바탕으로 의사결정 했을지도 모릅니다.

💡  B2B 프로덕트에서 실제 인사이트를 발견할 수 있는 코호트 분석 방식은 다음과 같습니다.

• 고객 특징으로 분류 (회사 규모, 비즈니스 모델, 플랜)
  • 내 프로덕트가 어떤 사이즈의 고객에게 더 잘 먹히는지 발견해 로드맵 우선순위를 정하는데 도움이 될 수 있습니다.
  • 내 프로덕트가 목표로한 시장에 잘 먹히는지 확인해 PMF를 달성하는지 확인할 수 있습니다.
  • 내 프로덕트를 구매한 사용자가 어떤 행동양상을 보이는지 확인할 수 있습니다.
• 사용자 역할으로 분류
  • 각 사용자는 본인의 역할에 따라 서로다른 업무적 니즈를 프로덕트를 통해 해결하고 있습니다. 프로덕트의 변경사항이 각 사용자에게 어떤 역할을 미치는지 발견할 수 있습니다.
  • 프로덕트의 개선은 결국 한 역할을 강화하고, 다른 역할에 영향이 갈 수 밖에 없습니다. 사용자 역할에 따른 코호트 분석으로 이 Tradeoff를 감수할만 한 지 결정할 수 있습니다.

⭐️ B2B 코호트를 시간 단위로 더 잘 분석할 수 있는 방법은 다음과 같습니다.

• 더 큰 시간 단위로 자르기 (월 단위 이상)
  • 사용자 행태에 따른 노이즈를 감소시킬 수 있습니다.
• 중요한 이벤트와 자르는 시간을 일치시키기
  • ‘날짜’는 얼마나 오래 사용자가 프로덕트를 사용했는지 알려주지 않습니다.
  • 출시일, 도입일, 캠페인 집행일 등 중요한 이벤트로부터 얼마동안 프로덕트를 사용했는지를 알 수 있습니다.

🔗 이 글은 Kyle Poyar님이 Openview에 올린 아티클을 번역, 요약한 글입니다.

최근 SaaS 가격 모델링 방식 중 사용량 기반 가격 정책이 뜨고 있습니다. OpenView 조사 결과 지난 해 34%에서 올해 45%의 SaaS 회사가 사용량 기반 가격 정책을 어느정도 가지고 있다고 조사되었습니다. 이렇게 사용량 기반 가격 정책이 뜨고 있는 이유는 무엇일까요?

1. 소프트웨어 구매에서 최종 사용자(end user)의 시대에 살고 있기 때문
   기존 SaaS 프로덕트의 구매 방식이 점점 최종 사용자가 프로덕트를 발견하고, 의사결정권자에게 어떤 프로덕트를 살 지 알려주는 방식으로 변하고 있습니다. 조직 입장에서도 수 년짜리 이용권을 구매한 프로덕트가 사용되지도 않는 것 보다 실제 사용량에 기반해 비용을 지불하는것이 이득입니다.

2. 비용을 책정 할 ‘사용자’가 점점 사라지고 있기 때문
   기존 사용자 수(seat count)에 비용을 책정하는 방식이 적용될 수 있었던 SaaS 트렌드와 달리, 최근 SaaS 트렌드는 자동화, AI, API 프로덕트입니다. 이런 프로덕트는 더 많은 사용자가 로그인 했을 때 성장할 수 있는것이 아니라, 오히려 반대로 접속하는 사용자가 적을수록 성장한다고 볼 수 있는 프로덕트입니다.

3. 사용량 기반 가격 정책을 가진 회사가 더 재정 성과가 좋기 때문
   사용량 기반 가격 정책을 더 적극적으로 사용한 회사가 그렇지 않은 회사보다 Net dollar retention 혹은 Net revenue retention과 같은 SaaS 비즈니스 건정성과 성장 잠재력을 보여주는 지표가 더 높았습니다.

4. 투자자들 역시 사용량 기반 가격 정책에 익숙하고, 또 선호하기 때문
   이전에는 일반적인 구독 모델보다 사용량 기반 가격 정책이 예측하기 어렵다는 이유로 기피되었지만, 점차 이러한 기조는 사라지고 반대로 사용량 기반 가격 정책에 익숙해지는 모습을 보이기 시작했습니다. HashiCorp는 최근 S-1(IPO를 위해 미국 증권거래위원회에 등록하는 공시자료)에서 사용량 기반 가격 정책을 통해 더 많은 가치 전달과 시장 점유율 확보를 한다고 했습니다.

5. 사용량 기반 가격 정책은 사용자에게 프로덕트가 모방하기 힘들다는 메세지를 전달하기 때문
   사용량에 기반해 돈을 받겠다는 정책은 사용자가 그 프로덕트를 실제로 성공적으로 도입하지 않고서는 돈을 받을 수 없다는 말이기 때문에 사용자가 이 프로덕트를 통해 성공할 수 있다는 자신감을 보여줍니다.

🔗 이 글은 Kate Kaplan님이 NN Group에 올린 아티클을 번역, 요약한 글입니다.

B2B 프로덕트는 기업 사용자의 다양한 업무적 요구사항을 충족하기 위해, 다루는 데이터 자체가 복잡하기 때문 등 다양한 이유로 복잡해지기 마련입니다. 복잡한 프로덕트를 디자인 하면서 놓칠 수 있는 10가지 휴리스틱을 소개합니다.

1. 시스템 상태에 대한 가시성 (Visibility of System Status)
   사용자의 행동에 대한 적절한 피드백은 가장 기본적인 디자인 가이드라인입니다. 가장 대표적인 피드백으로는 프로그레스 인디케이터를 꼽을 수 있습니다. 프로그레스 인디케이터는 전체 소요시간이 10초 이내로 걸릴 때 사용하면 좋습니다. 그보다 더 많이 걸리는 때에는 프로세스가 얼마나 걸릴 지 추가적인 정보를 제공해야 합니다.

2. 현실 세상과 시스템을 일치시키기 (Match Between System and the Real World)
   인터페이스를 디자인 할 때 이미 현실에 구축된 문화적 메타포와 용어를 이용하면 사용자가 컨셉을 더 잘 이해하고 조작할 수 있는 이점을 누릴 수 있습니다. 하지만 만약 이런 문화적 메타포가 유효하지 않다면 반대로 혼란이 야기될 수 있습니다. 미국에서는 ‘Coffee break’라는 문화가 형성되어있어 근무자 옆에 커피 아이콘을 제공하는 것이 해당 근무자가 휴식중이라는 의미를 잘 전달할 수 있지만 이 문화가 없는 곳에서는 의도한 의미가 제대로 전달되지 못할 수 있습니다.

3. 사용자 통제감과 자유 (User Control and Freedom)
   사용자는 실수하기 마련입니다. B2B 프로덕트를 통해 복잡한 업무를 하는 사용자에게는 더 높은 인지와 시간이 필요합니다. 우리의 사용자에게 오류, 실수와 선택을 되돌릴 수 있는 방법을 제공해야 합니다. 대표적으로는 뒤로가기, 되돌리기 기능을 꼽을 수 있습니다.

4. 일관성과 표준 (Consistency and Standards)
   사용자가 각 단어, 상황, 액션이 같은 의미를 가지는지 고민하도록 해서는 안됩니다. 플랫폼과 산업군에서 사용중인 표준에 따라야 합니다. 사용자가 속해있는 특정한 도메인과 관련이 깊은 기능을 수행하는 B2B 프로덕트에서는 사용자의 학습 용이성을 위해 표준 용어를 일관되게 사용해야 합니다. 표준과 일관성은 프로덕트 내에서 사용되는 컴포넌트의 색상, 위치, 레이블 뿐 만 아니라 다른 일반적인 프로덕트에서 사용되는 기능에 대한 메타포 또한 포함합니다.

5. 오류 방지 (Error Prevention)
   잘 작성된 오류 메세지는 중요하지만, 에러 상황을 마주하지 않도록 디자인 하는것이 먼저입니다. 사용자는 (특히 한국 사용자는!) 프로덕트나 기능에 대해 이해를 하기 보다는 먼저 사용해보는 경향이 있습니다. 세일즈포스는 대시보드를 만들 때 위젯을 추가하기 전에 실시간 프리뷰를 제공해 그들이 원하는 설정이 반영된 모습을 제공하여 발생할 수 있는 오류를 방지하고 더 빨리 수정할 수 있도록 합니다.

6. 회상보다는 인지 (Recognition Rather than Recall)
   사용자가 선택 가능한 요소, 액션, 옵션들을 보여줘서 사용자의 기억 부하를 최소화 해야 합니다. 복잡한 프로덕트에서는 이미 제공해야 하는 데이터나 옵션, 정보가 많아서 공간이 부족할 수도 있습니다. 3D 모델링 소프트웨어에서는 사용 할 요소의 모델명(‘ML-38’)에 마우스를 올리면 3D 이미지와 자세한 이름을 툴팁으로 제공합니다.

7. 유연성과 사용 효율성 (Flexibility and Efficiency of Use)
   사용자가 프로덕트를 얼마나 능숙하게 사용하는지와 별개로, 효율성은 높아지는 데 한계가 있습니다. 이럴 때 능숙한 사용자는 숏컷, 매크로, 제스쳐 등을 통해 더 빠르게 워크플로우를 수행할 수 있습니다.

8. 미려하면서 미니멀한 디자인 (Aesthetic and Minimalist design)
   인터페이스에는 현재 태스크와 무관하거나 별로 필요 없는 정보를 포함해서는 안됩니다. 인터페이스에서 모든 요소들은 주목도 경쟁을 하기 때문에 복잡한 B2B 프로덕트에서는 불필요한 정보가 많을 때 사용자가 필요한 요소를 찾기 힘들어집니다. 만약 일부 사용자에게 유용하거나 유즈케이스가 드문 경우, 해당 요소는 점진적 공개를 사용해 제공할 수 있습니다. (점진적 공개에 대해서는 이전 글을 참고해주세요)

9. 사용자가 에러를 인지하고, 진단하고, 복구할 수 있도록 하기 (Help Users Recognize, Diagnose, and Recover from Errors)
   에러 메세지는 발견 가능해야하고, 상황을 명확하게 설명해야하며, 에러를 수정할 수 있는 방법을 일반적인 용어로 안내해야 합니다.

10. 도움말과 문서 (Help and Documentation)
    프로덕트를 사용하는데 추가적인 안내가 필요하지 않는것이 가장 좋은 방법이겠지만, 복잡한 B2B 프로덕트를 사용해 태스크를 수행하는데는 종종 추가적인 안내나 교육이 필요한 경우가 있습니다. 하지만 일반적인 사용자는 태스크를 수행하기 전에 수많은 가이드 문서를 모두 읽지 않기 때문에 사용자의 컨텍스트에 맞게, 축약된 정보를 제공하는것이 좋습니다.

🔗 이 글은 Ryan Cornelius님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

만약 당신에게 가장 큰 경쟁자가 누구냐고 물어본다면 스타트업부터 대기업까지 당신이 경쟁자라고 생각하는 많은 기업들을 줄줄 읊을 수 있을지도 모릅니다. 기능 별로 누가 더 잘하고 있는지도 다 알고 있을 수 있습니다. 하지만 대부분의 경우에, 특히 세상에 없던 혁신적인 프로덕트를 만들어내는 중이라고 한다면 가장 큰 경쟁자는 어떤 ‘회사’가 아닙니다.

📌 당신의 가장 큰 경쟁자는 ‘현상 유지’ 입니다.

사람들은 다양한 이유로 다양한 결정을 합니다. 어떤 사람은 본인이 가장 잘 아는 큰 명성을 가진 회사의 프로덕트를 선택하기도 하고, 어떤 사람은 가장 저렴한 프로덕트를 구매하기도 하지만, 어떤 사람은 본인이 가장 잘 아는, 가장 저렴한 옵션을 선택합니다. 바로 아무것도 하지 않는 선택입니다.

📌 당신이 해결하고자 하는 문제를 가진 사용자들은 그 문제를 해결하기 위해 어떤 방법이든 사용하고 있습니다.

스프레드 시트로 관리하거나, 인턴을 고용하거나, 이메일으로 대체하거나, 혹은 그냥 참고 있기도 합니다. 어느 쪽이든 ‘현상 유지‘는 전통적인 경쟁자들보다 더 많은 시장 점유율을 가지고 있는 경우가 많습니다.

📌 Jira의 ‘현상 유지’ 경쟁은 다음과 같습니다.

Jira와 경쟁하고 있는 회사들은 Monday.com, Basecamp, Productboard, Trello 등을 꼽을 수 있습니다. 하지만 ‘현상 유지’의 경쟁자는 다릅니다.

• MS 워드로 기획하고, 엑셀로 로드맵을 정리하고, 이메일로 태스크를 할당하는 것
• 데일리 미팅에서 각자 자신의 업무 진행상황을 보고하고 PM은 전달사항을 전파하는 것
• 팀의 업무 생산성을 위해 팀 사이즈를 5명 이하로 유지하고 있는것

📌 경쟁 회사들은 눈에 잘 보이고, 비교 경쟁하기도 쉽습니다.

하지만 이 함정에 빠져 ‘현상 유지’중인 고객들을 빼먹는 것은 위험합니다. 당신이 프로덕트를 만들고 있는 이유는 고객의 문제를 해결하기 위함이지, 경쟁 회사를 뒤쫒는게 아니기 때문입니다.

🔗 이 글은 Userpilot Team이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

프로덕트의 새로운 기능에 대한 릴리즈 노트는 사용자 Engagement에 큰 영향을 줄 수 있는 요소입니다.

👀 잠깐, 릴리즈 노트란?

SaaS 회사가 매 프로덕트 릴리즈에 제작하고 배포하는 기술 문서입니다. 릴리즈 노트는 계속 발전해갈 SaaS 프로덕트를 구매한 사용자에게 변경사항을 알려주고 고객의 목소리에 귀를 기울이고 있다고 알릴 수 있는 좋은 방법입니다.

📝 요약

• 릴리즈 노트에는 헤더, 개괄, 이슈 요약, 해결, 임팩트, 그리고 추가 자료를 포함해야 합니다.
• 릴리즈 노트 템플릿을 사용하면 사용자와 일관되게 커뮤니케이션 할 수 있습니다.
• 릴리즈 노트는 애플리케이션, 이메일, 웹사이트, 블로그, 소셜 미디어 등에서 배포할 수 있습니다.

💪 릴리즈 노트를 잘 작성하는 방법

• 관련 지식이 없는 사람도 쉽게 이해할 수 있도록 평이한 언어를 사용하기
• 브랜드 정체성을 반영하기
• 이 릴리즈가 사용자에게 어떤 가치를 제공할 지에 집중하기
• 매 릴리즈마다 일관된 릴리즈 노트 작성하기
• 가능하다면 이미지와 스크린샷을 포함하기
• 최적의 Engagement와 지식 전달을 원한다면 비디오 튜토리얼을 제공하기
• 버그의 경우 재현 방법을 기록하기
• 릴리즈 노트에 수정사항이 있다면, 버저닝 하기
• 사용자에게 더 자세한 정보로 이어지는 링크 제공하기
• 최종 사용자로부터 피드백을 제공하도록 요청하기

릴리즈 노트의 템플릿과 제공하는 실제 사례, What’s New 섹션을 잘 만들어둔 Mailchimp, Retool, UiPath, Amplitude의 예시는 원 글에서 확인하실 수 있습니다.

🔗 이 글은 Sequoia가 미디엄에 올린 아티클을 번역, 요약한 글입니다.

데이터에 대한 중요성은 나날이 높아져가고 있습니다. 일부 회사들은 더 많은 A/B 테스팅을 하거나 실험을 통해 더 많이 프로덕트를 이터레이션 하고, 더 많은 릴리즈를 통해 더 빠른 프로덕트 성장을 이뤄내기도 했습니다. 여러 소스에서 수집된, 정형화 되지 않은 수많은 데이터들 속에서 인사이트를 성공적으로 발견할 수 있느냐가 회사의 경쟁력과 프로덕트의 혁신을 이끌어내기 시작했습니다. 어떻게 하면 우리 회사도 Data Informed Company가 될 수 있을까요?

🐒 데이터 분석의 진화 과정

1. 숫자를 세는것 (우리의 사용자는 몇 명인지? 수익은 얼마인지?)
   → 단순 통계이며, ‘과학’은 없습니다
2. 계산을 자동화 하는 것
   → 올바른 데이터를 정의하고, 로깅하고, 확장 가능한 방식으로 자동화된 도구를 만듭니다
3. 중요한 기능이 제공되는데 사용되는것
   → ‘과학’의 시작입니다. 작은 성공을 자주 달성할 수 있도록 하고 직관을 이기는 의사결정을 할 수 있도록 합니다.
4. 비즈니스 목표와 전략을 수립하는데 사용되는것
   → 데이터 분석의 가능한 가장 큰 성과입니다

👑 Data Informed 회사의 특징

• 하나의 통합 지표 아래 조직되어있고 통합 지표를 목표로 일합니다.
• 상위 그룹이 주축이되어 목표와 통합 지표를 중심으로 일하며, 다른 조직원들에게도 명확하게 전달해 모두의 생산성이 높아지고 필요없는 논의가 줄어들 수 있습니다.
• 데이터 인프라가 장기적인 요구에 잘 적응할 수 있도록 구성되어있습니다.
• 실험하는 문화를 가지고 있습니다.
• 프로덕트 개발의 모든 단계에 데이터 분석이 포함되어 있습니다.
• 데이터 분석 팀은 프로덕트 성공에 대한 지표를 지속적으로 측정하고, 비즈니스의 위험과 성장할 수 있는 영역을 식별하는데 도움을 줍니다.
• 이 모든 과정을 지원할 수 있는 탄탄한 로드맵 프로세스가 있습니다.
• 이 과정들을 지속적으로 실행할 수 있도록 조직을 구성하고 권한을 부여합니다. 대부분의 성공하지 못한 사례들은 실행을 제대로 하지 못했기 때문입니다.

🔗 이 글은 Richard Yang님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

기능이 너무 많은 프로덕트는 대부분의 경우 UX를 저해합니다. 모두가 이를 알고 있지만 대부분의 프로덕트, 특히 B2B 프로덕트는 기능 비대 상태가 되어버리곤 합니다. 최 상위 가치를 가진 기업 고객들을 잃지는 않겠지만(보통 그들이 그 기능들을 요구했기 때문에), 일반적인 사용자 대부분에게 거리감을 두게 됩니다. 이런 경우 비싸고 비대해진 프로덕트가 커버하지 못하는 작은 핵심 영역을 ‘언번들링’한 경쟁 프로덕트가 나타나곤 합니다.

기능이 비대해지면 새로운 사용자가 첫 ‘아하’ 모먼트를 경험하게 되기 어려워 집니다.

→ 이는 결국 TTV(Time To Value)를 상승시키고, 사용자 리텐션에도 영향을 줍니다.

하지만 핵심 경험을 제외하고 나머지 기능들을 모조리 덜어내야 한다는 것은 아닙니다. 우리는 어떤 기능을 제거했을 때 몇몇 사용자에게 어떤 임팩트가 있을지를 알아야 합니다.

🎙 Hyrum’s Law

구글 엔지니어인 Hyrum Wright는 API를 사용하는 사용자가 충분하다면, 그것이 어떤 기능을 제공하기로 계획되어있든 상관 없이 시스템의 모든 확인 가능한 행동들은 누군가에게 의해 결정될 것이다 라고 말했습니다.

이를 프로덕트 레벨으로 다시 해석해보자면, 충분한 크기에서, 프로덕트가 제공하는 모든것은 누군가가 원하는 방식으로 (옳은 방식이든 아니든) 사용되게 될 것이다가 될 것입니다.

우리가 어떤 목적으로 기능을 제공한다고 하더라도, 실제 사용자는 우리의 의도대로 사용할 수도 있고, 각자의 의도대로 그 기능을 (우리의 입장에서)잘못 사용하고 있을수도 있습니다. 그렇다면 기능을 제거할 때 어떤 기준을 사용해야 할까요?

👑 최소 사용률 (Minimum Usage)

• 팀이 계획한 최소 사용률을 한참이나 밑돌거나, 리텐션율을 높이는데 영향이 없는 기능들은 제거되어야 합니다
• 만약 두 조건을 모두 만족했으나 우리의 의도대로 기능을 사용하지 않는다면 그 기능은 리디자인이 필요한 기능입니다
• 리디자인 할 때는 기존 TTV에 부정적인 영향을 주지 않도록 유의해야 하고, 리디자인 된 기능은 동일한 페이지에서(이상적으로는 같은 위치에서) 제공되어야 합니다

🔗 이 글은 한봄소리님이 브런치에 올린 아티클을 요약한 글입니다.

수집한 데이터를 상대방에게 표현할 때 어떤 시각화 방법을 선택해야 가장 잘 전달할 수 있을까요? 데이터를 시각화 하는 방법은 수없이 많지만, 목적에 맞는 차트는 생각보다 선택 할 종류가 제한되어 있습니다.

데이터 시각화 이론에서 가장 많이 활용되고 있는 표는 앤드류 아벨라(Andrew V. Abela)의 차트 선택 방법이 있습니다. 앤드류는 무엇을 보여주고 싶은지 목적에 따라 크게 비교(Comparison), 분포(Distribution), 구성(Comparison), 관계(relationship)의 카테고리로 차트를 구분하고 있습니다.

앤드류의 데이터 시각화 방법을 정리한 표가 궁금하시다면 원문 링크를 참조해주시기 바랍니다.

🙆‍♀️ 테이블을 잘 사용하는 경우

• 개별 값을 비교하거나 조회하는 경우
• 정확한 값을 보여줘야 함
• 값에 측정 단위가 여러 개일 경우
• 양적 정보를 전달하는것이 목적

🙅‍♀️ 테이블을 잘못 사용하는 경우

• 추세를 보여줘야 하는 경우
• 형태를 바탕으로 메세지를 전달하고 싶은 경우
• 여러 값 간의 관계를 표현하고 싶은 경우

🙆‍♀️ 막대 차트를 잘 사용하는 경우

• 시간 축이 있는 경우 가로 축을 시간으로 설정 (시간은 위에서 아래가 아닌 왼쪽에서 오른쪽으로)
• 세로 숫자 축은 0에서 시작하기
• 구성 항목이 4개 이하일 때, 구성 비중이 비교적 유사할 때 누적 차트를 사용
• 카테고리 이름이 긴 경우 가로 막대 차트를 사용
• 범주가 7~15개 이거나, 음수로 집합을 표시하는 경우 가로 막대 차트 사용
• 구성 항목 간 비중만 중요할 경우 100% 누적 차트를 사용

🙆‍♀️ 라인 차트를 잘 사용하는 경우

• 시간 등 연속적인 데이터를 표시하는 경우
• 데이터 포인트 수가 매우 많을 때(20개 이상) 일정 기간 동안 트렌드를 표현하는 경우

🙅‍♀️ 라인 차트를 잘못 사용하는 경우

• 간격의 크기가 동일하지 않은 경우 (값이 0인 경우라도 값을 건너뛰지 않기)
• 차트의 종횡비를 과도하게 늘리거나 줄이는 경우 (1:1 비율이 가장 인식하기 좋음)

🙆‍♀️ 영역 차트를 잘 사용하는 경우

• 시간에 따른 누적되는 가치를 표현하는 경우
• 시간 경과에 따른 구성 항목 별 변화를 나타내는 경우

🙅‍♀️ 영역 차트를 잘못 사용하는 경우

• 주식 시장이나 가격 변동과 같이 변동되는 값을 표시하는 경우

🙆‍♀️ 파이 차트, 도넛 차트를 잘 사용하는 경우

• 카테고리의 전체 관계 혹은 일부 지배적인 구성을 시각화 하는 경우

🙅‍♀️ 파이 차트, 도넛 차트를 잘못 사용하는 경우

• 표현하고자 하는 카테고리가 너무 많은 경우 (사람은 면적 비교에 약합니다)
• 각 카테고리의 값이 유사한 경우 (개별 카테고리를 비교하거나 정확한 값을 나타내기 위함이 아님)
• 누적 도넛 차트를 사용하는 경우. 대다수 누적 막대 차트가 더 나은 결과를 제공합니다
• 모든 카테고리의 합이 100%가 아닌 경우
• 비교하고자 하는 축이 2개 이상인 경우

🙆‍♀️ 분산 차트(Scatter Plot)를 잘 사용하는 경우

• 연관되거나 서로 다른 두 변수의 관계를 표현하는 경우
• Outlier를 파악하거나 데이터 분포를 클러스터링 하는 경우

🙆‍♀️ 버블 차트를 잘 사용하는 경우

• 분산 차트의 축(2개) 보다 하나 더 많은 3개의 축으로 비교하는 경우

🔗 이 글은 Product Mindset님이 Substack에 올린 아티클을 번역, 요약한 글입니다.

STAR 프레임워크는 내가 내린 의사결정의 배경과 이후 학습한 결과를 자연스럽게 보여줄 수 있는 프레임워크입니다. 일반적인 경우 How에 해당하는 내가 생각한 아이디어, 실행한 방법만 집중적으로 묘사하게되는 경우가 많은데, STAR 프레임워크를 사용한다면 내 포트폴리오를 읽게 될 면접관들에게 문제의 배경, 목표, 행동과 결과를 빠짐없이, 이해하기 쉬운 순서로 전달할 수 있게 됩니다.

⭐️ STAR 프레임워크란?

• S(Situation / 배경): 어떤 것을 달성해야 하는 상황에 대한 설명
• T(Task / 목표): 나 혹은 팀이 달성해야 하는 목표 혹은 문제
• A(Action / 행동): 목표를 달성 혹은 문제를 해결하기 위해 취한 행동
• R(Result / 결과): 행동에 따른 결과

포트폴리오 뿐 만 아니라 인터뷰 질문에 답변할 때도 STAR 프레임워크를 사용해 본인의 이야기를 잘 정리해서 전달할 수 있습니다.

🧑🏻‍💻 압박감이 컸던 상황에서 업무했던 경험에 대해 알려주세요.
(S)지난 직장에서, 팀원 중 한 명이 장기 휴가를 가면서 맡고 있던 프로젝트를 담당할 수 없는 상황이 있었습니다.
(T)제 팀장은 저를 그 프로젝트에 할당했고, 기존 데드라인을 수정해주지 않아 몇 주는 걸릴 일이었지만 남은 시간은 며칠밖에 없었습니다.
(A)저는 그 프로젝트에 몰입하기 위해 기존 반복 업무를 줄이는 것을 요청했고,
(R)결국 데드라인을 맞추면서도 프로젝트 퀄리티를 만족시킬 수 있었습니다. 팀장은 저의 태도와 실행력에 감명을 받아 이후에도 추가 프로젝트를 맡아 진행하도록 했고 이후 승진과 연봉 상승에 긍정적인 영향을 주었습니다

🔗 이 글은 Kisang Pak님이 미디엄에 올린 아티클을 요약한 글입니다.

실리콘 밸리의 많은 구성원들은 자기의견이 강한 사람들이 훌륭한 인재라는 일반적인 견해가 있습니다.

실리콘 밸리의 테크 회사들은 불확실한 IT 시장에서 새로운 제품을 기획하고 만들어나가는것이 주된 업무입니다. 그리고 이런 제품 개발 과정은 끊임없는 결정의 연속입니다. 소프트웨어 아키텍쳐부터 홈페이지 버튼 색깔에 대한 결정까지 서로 끊임없이 토론하고 대화합니다. 이 때 강한 의견을 가진 사람이 있다면 강한 실행력으로 빠르게 제품 개발을 진행할 수 있을 것입니다.

하지만 이 때 의견이 강한 사람이 고집이 세서 개인의 의견만 내세우고 상대의 의견을 듣지 않을 수도 있습니다. 발전적인 조직을 만들고 개개인이 훌륭한 조직원이 되기 위해서는 본인의 의견만 강한 것이 아니라(Strong Opinions), 그 의견에 반대되는 의견이나 정보에 대해 적극적으로 알아보고, 내 의견을 바꿀 수도 있는 유연성을 지녀야 합니다(Weakly Held).

많은 사람들이 누군가가 본인의 의견과 다른 의견을 내세웠을 때 나의 말에 인정을 해주지 않아 기분이 나쁘거나 본인의 의견을 굽히는것을 자존심 상해 합니다. 조직에서는 여러 팀원들이 함께 더 나은 결과를 만들어 내기 위해 의견을 조율해 나가는 과정이 끊임없이 필요합니다. 한 사람의 강한 의견을 바탕으로 잘못된 목표를 향해 달려나가지 않기 위해서라도 다른 의견에 대해 열려있는 마음을 갖고 내 의견을 뒤집을 수 있는 유연성을 함께 가진 상태로 일하는 자세가 필요합니다.

🔗 이 글은 SalRite님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

잘못된 해석을 유도하는 통계 자료. 어떤 상황에서 통계 자료를 잘못 해석할 수 있을까요?

1. 통계적 유의성이 있다는 것이 실제로 유의미한 내용이라는 말은 아닙니다. 분석 결과가 통계적 유의성을 확보했더라도 샘플이 모집단을 적절히 대변하지 못할 수도, 리스크가 너무 커서 1%의 오차라도 용납할 수 없을수도 있습니다.

2. 잘못된 도표를 사용하는 경우. Y축이 전체가 보여야 할 때 숨기거나 숨겨야 할 때 전체를 보이도록 하거나, 오르내리는 변동을 트렌드처럼 표시하지 않아야 합니다.

3. 연관 관계는 인과관계가 아닙니다. 아이스크림 판매량과 상어 공격으로 인한 사상자는 여름에 동시에 오르지만 서로 인과관계가 있는것은 아닙니다.

4. 심슨의 역설. 1973년 버클리 대학교는 전체 지원자 대비 남여 입학 비율(남: 44%, 여: 35%) 차이에 대한 자료를 바탕으로 성차별로 고소되었습니다. 추가 조사 결과 각 학과별 지원자 대비 입학 비율에서는 여성이 더 높은 비율임이 밝혀졌습니다. 이 통계에서는 남여 지원 모수가 차이가 있었고, 전체를 평균했을 때 발생하는 대표적인 통계적 역설입니다.

5. 샘플링 방식. 샘플링은 전체 모수를 대변할 수 있는 일부를 수집하고, 통계적으로 분석해 전체 모수를 해석하기 위한 방법입니다. 따라서 샘플링 된 데이터는 전체 모수를 대변할 수 있다는 점을 확신할 수 있어야 합니다. 샘플링 할 때는 일관성, 다양성, 투명성을 유지할 수 있도록 유의해야 합니다. 또 샘플링에는 여러 방식(Random, Systemic, Stratified 등)이 있으니 각 장단점을 고려해 선택해야 합니다.

통계는 결국 숫자일 뿐이고, 전달하고자 하는 이야기의 일부일 뿐입니다. 통계 자료를 만드는 사람은 해결하고자 하는 문제에 대해 잘 알고, 자료를 바탕으로 어떤 결론을 내리기 전에 데이터를 잘 다뤄야 합니다. 다음번 통계 자료를 바라볼 땐 해석을 잘못할 수 있는 여지가 있는지 스스로에게 잘 질문할 수 있어야겠습니다.

🔗 이 글은 Christopher Chae님이 릴레잇 블로그에 올린 아티클을 요약한 글입니다.

B2B 프로덕트를 세일즈를 하려면 어디서부터 시작해야할 지 막막할 때가 있습니다. B2B SaaS 프로덕트를 검증하고 싶은데, 어떤 고객이 도와줄 수 있을까요?

1. 주변 잠재고객(Lead)에게 연락하기
   첫 고객을 개발해야 하는 관문에 있는 스타트업은 PMF(Product Market Fit)를 찾는 과정일 것입니다. 시장의 니즈를 확인하는 가장 손쉬운 방법은 바로 주변 네트워크를 활용하는 것입니다. 가장 가까운 네트워크에서부터 내 프로덕트의 PMF를 검증해보세요.

2. 랜딩 페이지 만들기
   랜딩 페이지는 온라인 공간에서 프로덕트를 소개하고 사용자의 구매 의향을 실험해볼 수 있는 좋은 공간입니다. PMF를 간단하게 확인해볼 수 있는 GTM 전략 중 하나로 Fake door 전략이 있습니다. 프로덕트가 어떤 문제를 해결하는지에 대한 설명과 구매를 위한 간단한 등록 폼 만으로도 런칭해 리드를 확보할 수 있습니다.

3. 세일즈 자료 만들기
   이렇게 확보한 리드를 바탕으로 고객사와 세일즈 미팅을 하거나, 도입 문의가 왔을 때 전달 할 세일즈 자료를 준비합니다. 세일즈 자료의 구성과 템플릿은 릴레잇 블로그의 원본 글에서 확인할 수 있습니다.

4. 커뮤니티 활용하기
   제품에 관심이 있어 할 사람들이 모인 커뮤니티를 잘 활용하면 제품을 효과적으로 알릴 수도, 실제 구매로 이어질 리드를 확보하는것도 가능합니다. 커뮤니티에서 잘 먹히는 홍보를 위해서는 그 커뮤니티에 모인 사람들의 목적이 무엇인지 잘 고민하고, 목적을 달성하는데 도움이 될 수 있는 방향으로 메세지를 만들면 오히려 ‘콘텐츠’ 로서 다가갈 수 있습니다.

   • 디스콰이엇
   • Relate GTM 오픈카톡방
   • Product Hunt
   • B2B 디자이너들의 모임 (소개 감사합니다!!🙏)

1. 인터뷰 요청하기
   바로 세일즈 미팅에 들어가는것이 부담스럽다면, 먼저 인터뷰나 UT(Usability Testing)을 요청해 자리를 마련하는것도 좋은 방법이 될 수 있습니다. 고객 입장에서는 크게 돈 들지 않는 일이면서도 어느정도 문제에 공감을 하고 있다면 흔쾌히 수락해줄 가능성이 높기 때문입니다. 더불어 잠재 고객의 니즈까지 발견할 수 있는 기회도 될 수 있습니다.

   고객 인터뷰에서는 질문할 때 어떤 문장으로 질문하는지, 무엇을 물어봐야 하는지가 굉장히 중요한데, 원 글에서 더 자세하게 안내하고 있습니다.

2. 수요조사 서베이 만들기
   수요조사 서베이는 랜딩 페이지와 인터뷰 요청을 적절하게 합친 방법입니다. 랜딩 페이지는 나의 프로덕트를 소개하고 고객이 프로덕트를 ‘고용’할 지를 파악하는 것이라면, 서베이는 고객이 프로덕트를 ‘고용’해 해결하고자 하는 문제에 대해 더 자세히 파악하기 위한 목적입니다.

🔗 이 글은 Stephan Walter님이 블로그에 올린 리소스 소개 글을 번역, 요약한 글입니다.

B2B SaaS 프로덕트에서 가장 많이 사용되는 컴포넌트 중 하나는 테이블입니다. 제공하는 내용과 기능이 복잡한 데이터 테이블을 디자인 하기 위해서는 고려해야 할 점이 많습니다.

복잡한 데이터 테이블을 디자인 하기 위한 디자인 리소스 모음 페이지입니다. 각 리소스들이 조명하는 분야가 다양하니, 데이터 테이블을 디자인하는데 필요한 다양한 고민들을 해결할 단서들을 얻을 수 있겠습니다.

• 데이터 테이블의 기본 구조
• 데이터 테이블의 사용성
• 컴포넌트의 재사용성
• 복잡한 내용을 제공하는 방법
• 기업에 제공하기 적합한 위한 테이블
• 브라우저 크기에 따른 반응형
• 데이터 테이블에 사용될 타이포그래피

🔗 이 글은 김영욱님이 브런치에 올린 아티클을 요약한 글입니다.

불확실성이 가득한 비즈니스 세상에서 PM/PO가 의사결정할 때 꾸준히 주의하고 극복해야 하는 4가지 인지편향을 소개합니다.

1. 확증 편향 (Confirmation Bias)

• 가장 흔향 편향입니다
• 자신이 옳다고 여기는 정보만 받아들이고 신념과 일치하지 않는 정보는 무시하는 경향
• 검색, 추천 콘텐츠에서 개인화가 발달하면서 내 신념과 연관된 정보나 광고가 지속적으로 노출되면서 확증 편항은 더 빠져나오기 힘든 성향을 가집니다
• 사용자에게 던지는 질문을 내가 옳다고 생각하는바를 유도하는 문장으로 만들 수 있습니다
• 대시보드의 지표가 편향되어 설정될 수도, 여러 지표 중 긍정적인 지표만 사용하게 될 수도 있습니다

💪 확증 편향을 극복하는 방법

• 편향을 가지고 있다는 사실을 늘 인식합니다
• 유도 질문을 철저하게 피합니다
• 여러 이해관계자로부터 균형된 피드백을 받습니다
• 목표치 설정을 각 팀 리더와 함께 셋팅하거나, ‘왜’에 대한 배경을 설명하고 의견을 구합니다
• 매 결정 시 ‘What’이 아닌 의사결정이 필요했던 ‘Why’를 충분히 만족하는지 리뷰합니다

📝 노트

• 확증 편향을 극복하기 위해서는 먼저 반대되는 의견에 충분히 리서치하거나 노출될 필요가 있고, 반대되는 의견이 충분히 설득력 있다면 내 의견을 바꿀 수 있는 유연성을 가지고 있어야 합니다.
• 이러한 마인드셋을 ‘Strong views, Wealky held’ 라고 합니다.
• Strong views, Wealky held에 대한 아티클을 첨부합니다

2. 매몰비용 오류 편향 (Sunk-cost Fallacy Bias)

• 이미 투자한 시간, 노력, 비용 때문에 미래의 불확실한 결과를 예상함에도 투자와 작업을 지속하고자 하는 편향입니다
• 손실 회피(Loss Aversion) 경향이 이런 편향을 만들어냅니다

💪 매몰비용 오류 편향을 극복하는 방법

• 간단하지만 가장 근본적인 지표가 될 수 있는 질문에 답변할 수 있는지 스스로 물어봅니다
• 만약 전사가 목숨을 걸어야 하는 상황에도 동일한 결정을 할 것인가?
• 기존 코드가 모두 날아가서 없어졌음에도 같은 방법으로 코드를 유지보수 할 것인가?
• 내 동료가 진행하는 프로젝트에도 내가 그 방법이 옳다고 해줄 수 있을 것인가?

📝 노트

• 매몰비용을 생각하지 않는 방법의 핵심은 지금까지 발생한 비용이 0이라고 가정하는 것입니다
• 지금부터 들일 노력과 노력에 따르는 이후 발생 가능한 이득만 객관적으로 비교하는것이 필요합니다

3. 이케아 효과/편향 (IKEA Effect/Bias)

• 본인이 직접 만든 제품에 대해 실제보다 더 큰 가치를 부여한다는 편향입니다
• 내가 노력을 기울였다고 해서, 투자를 했다고 해서 꼭 그 제품/서비스가 성공하지는 않습니다.
• 위 ‘매몰비용 오류 편향’과 이어져 내가 이만큼 노력을 했으니 그 노력만큼 성공적이지 못한 것은 다른 탓이라고 원인을 돌리게 됩니다
• 자신의 성과에 자부심을 갖는 것은 당연하지만, 노력과 투자부분이 제품과 서비스의 결과보다 강조되는 부분은 경계해야 하는 편향입니다

💪 이케아 효과/편향을 극복하는 방법

• 내가 PM으로서 개발/디자인/지원팀 간 적절한 조율을 하고 있는지 항상 체크합니다
• 올바른 성과 지표를 프로젝트 시작에 맞춰 준비하고, 지속적으로 리뷰합니다
• 팀 간의 우위를 경쟁하는 것이 아닌 제품/서비스를 성공시킨다는 공통의 목표를 꾸준히 자주 주지시킵니다
• 우리 팀 결과물을 다른 팀에 제공하는 등 크로스 레퍼런스를 적극 활용하고, 경쟁 제품/서비스에 대한 분석을 본인의 고객/사용자 관점에서 진행해봅니다

4. 오류 합의 편향 (False-Consensus Bias)

• 내가 생각하고 행동하는것 처럼 다른 사람도 생각하고 행동할 것이다라는 ‘오류 합의’를 하는 편향입니다
• 이 편향을 가지는 경우 본인이 생각한 UX Flow대로 모든 사용자/고객이 이용할 것이라고 생각 됩니다
• 이 편향이 발전하게 되면 우리의 생각과 다른 생각이나 아이디어를 가진 사람들을 배제하거나 무시하는 현상이 나타납니다

💪 오류 합의 편향을 극복하는 방법

• 본인의 목표를 항상 명확히 리뷰하고 팀 멤버들과 함께 리뷰합니다: ‘이 제품/서비스/기능은 고객/사용자에게 과연 합당한 것인가?’
• 고객/사용자에게 내 목표를 설명하고 그것이 맞는지 확인합니다
• 제품/서비스가 만들어지는 과정에 다양한 사용자군과 프로덕트 팀간의 피드백 프로세스를 통해 상호 생각의 오차를 줄여나갑니다

🔗 이 글은 Christopher Chae님이 릴레잇 블로그에 올린 아티클을 요약한 글입니다.

Product-Led Growth SaaS 프로덕트는 Free Trial과 Freemium 을 사용해 Lead를 유도하는 경우가 많습니다. 그 중 Free Trial을 실행하고 있는 SaaS 기업을 설문조사하여 분석한 결과를 Relate에서 번역을 제공 해주셨습니다.

1. 연간 계약이 최고다
2. 로고 리텐션(‘고객사’ 유지)은 90%+ 이상으로 목표를 설정하라
   • SMB < Mid-market 혹은 Enterprise
3. 100-140% NDR (Net Dollar Retention)을 목표로 설정하라
4. 시간/사용량 기반의 Free Trial 의 Conversion이 훨씬 더 높다
   • 시간 혹은 사용량 제한 방식이 최소 2배 이상 더 높은 Conversion을 가져감
5. 무료 Trial 기간은 큰 영향을 주지 않는다. 무료기간을 줄여라
6. Direct Sales 팀은 Conversion을 최소 3.5배 높인다
7. Organic Conversion은 4%+ 면 충분하다
8. Assisted Conversion은 15%+ 이상으로 목표를 설정하라
   • Trial 고객을 세일즈 팀원이 개입해서 유료 고객으로 전환시키는 경우
9. Lead에 점수를 매기는 것은 잘못된 결론을 도출할 수 있다
   • 사용 데이터 만으로는 필터에 걸리지 않은 수 있다
   • Enterprise/Mid-market 고객들은 SMB와 달리 제품을 많이 써보지 않고도 큰 돈을 지불할 수 있음
10. Free Trial에 크레딧 카드를 걸게 하면 Conversion이 2.5배 증가한다
    • SMB와 Mid-market에서 결제 수단을 사전에 등록하는 경우 전환율이 더 높다

🔗 이 글은 Jordan Bowman님이 블로그에 올린 아티클을 번역, 요약한 글입니다.

발견하고자 하는 리서치 결과가 매번 다르기 때문에 각 상황에 가장 효율적인 UX 리서치 방법론이 필요합니다. 이 아티클에서는 다음 6가지 방법을 사용할 상황을 안내합니다.

어떤 상황에 어떤 방법론을 사용해야 하는지 알기 위해서는 우리가 알아내고자 하는것이 무엇인지, 목표가 무엇인지, 어떤 문제를 해결하려고 하는지 스스로에게 질문해야 합니다.

1. 사용자 인터뷰 (User interview)

• 목표: 특정 주제에 대한 사용자의 멘탈 모델, 태도, 의견에 대해서 발견하고자 할 경우

2. 사용성 테스트 (Usability test)

• 목표: 이미 가지고 있는 어떤 아이디어를 평가하고자 할 경우

3. 다이어리 스터디 (Diary study)

• 목표: 사용자의 프로덕트에 대한 현재 행동과 관계를 분석하고자 할 경우
• 사용자가 프로덕트를 매일 사용하는 경우 유리함

4. 카드 소팅 (Card sort)

• 목표: Information Architecture를 만들고자 할 경우

5. A/B 테스트 혹은 다중 변수 테스트 (A/B (or multivariate) test)

• 목표: 여러 아이디어 중 목표를 달성하는 가장 좋은 방법을 알아내고자 하는 경우

6. 설문조사 (Survey)

• 목표: 사용자를 기반으로 문제의 우선순위나 문제의 규모를 결정하고자 할 경우

🔗 이 글은 김형석님이 브런치에 올린 아티클을 요약한 글입니다.

질문하는것은 매우 중요합니다. 하지만 무제한적인 호기심은 가장 먼저 스스로에게 물어야 하고, 다른 사람에게 질문을 할 때에는 그 목적이 분명해야 합니다.

질문을 하는 제 1 목적은 ‘모르는 것에 대한 답‘을 얻기 위함입니다. 아는 것도 물어보고, 모르는 것도 물어보는것은 민폐입니다. 바쁘디 바쁜 동료의 시간을 의미없이 사용해버리기만 합니다. 책임을 회피하기 위해 질문을 이용하는것은 생각하는 머리가 없다고 고백하는것과 다름 없습니다. 책임을 져야 할 것 같은 느낌이 왔다면 누군가의 말에 그 책임을 전가시키는게 아니라 이 행동을 하지 않아야 하는 이유를 설득해야 합니다.

내가 모르는 것은 두 가지 경우가 있습니다.

1. A와 B 중에 어떤 결정을 내려야 할 지 모르겠다 (객관식)
2. 어디서부터 시작해야할 지 단초를 찾고 싶다 (주관식)

1번의 경우

질문하기 전에 어떤 답을 들을지 미리 예측해보는것이 중요합니다. 나라면 어떻게 결정할까? 그리고 질문을 받게될 사람은 어떻게 결정할까? 이런 예측을 연습한다면 다음에 있을 유사한 상황에서 질문을 반복해서 해야할 지, 내가 예측하고 있는 모델이 잘못된 것인지를 확인할 수 있습니다.

2번의 경우

특별한 경우가 아니라면 최대한 피하는게 좋다. 먼저 내가 치열하게 고민한 다음에도 답이 나오지 않는 경우에만 유효하합니다.

그리고 질문을 습관적으로, 시간 단축용으로 하지 않아야 합니다.

시간 단축용으로 질문하는것이 습관이 될 경우, 간단하고 중요도가 낮고 반복적으로 발생하는 업무에도, 혹은 새로운 상황이 발생할 때 마다 조건 반사적으로 질문을하게 됩니다. 본인의 리소스는 줄어들 수 있지만 그 만큼 상대방의 리소스를 뺏어가게 됩니다. 이 질문을 했을 때 그 사람은 어떻게 의사결정을 할 지 예측하는 연습을 하고 묻지 말아야 할 때와 물어야 할 때를 구분하려는 노력이 필요합니다.

🔗 이 글은 Sacony님이 글리버리에 올린 아티클을 요약한 글입니다.

코인베이스는 사내 정치와 관료적인 의사결정 체계의 한계를 극복하고 노이즈를 줄여서 효율적인 결정을 위해 두 가지 방법을 사용합니다. 두 방법 모두 구글닥과 같이 모두가 함께 확인할 수 있고, 동시에 협업이 가능한 문서 형태로 커뮤니케이션 합니다.

1️⃣ Problem / Proposed Solution

• 일반적인 의사결정할 때 노이즈를 줄이는데 유용한 도구
• 문제와 제안 솔루션이 15분 안에 쓸 수 있게 간단하게 정리할 수 있어야 함
• 문제와 제안하는 솔루션을 담당자들과 관련 직원들에게 문서를 전달
• 담당자들은 문서에서 토론을 이어가거나, 미팅을 하거나 혹은 동의하거나 다른 솔루션을 제안할 수 있음
• 결정된 솔루션이 생가면 이것을 액션아이템으로 만들고, 1명의 직원에게 책임을 맡기고 데드라인을 정함

2️⃣ RAPID

• 여러 부서 간 협의로 결정을 내려야 할 때 사용되는 프레임워크
• Recommend (추천) 1명
• Agree (동의): 1-2명
• Perform (실행): 결정에 대해 실행을 책임질 사람
• Input (인풋): 이 결정에 대해 의견을 제공할 사람들
• Decide (결정): 아직 RAPID 팀에 들어오지 않은, 결정 할 1명
• 1명이 추천하고, 1주 이내에 결정을 합니다. 이 추천은 Type 1(되돌릴 수 없는 결정)인지, Type 2(되돌릴 수 있는 결정)인지 명시함
• 각 역할을 맡은 사람들은 이유와 함께 동의와 비동의 의견을 남김

🔗 이 글은 쿠팡 디자인이 브런치에 올린 아티클을 요약한 글입니다.

문제를 명확하게 가정했고, 이를 검증하기 위한 가설과 솔루션을 마련했다면, 개선을 위한 솔루션이 제대로 가정했던 문제를 해결하는지를 확인하기 위해 테스트를 진행합니다. 테스트 결과는 미리 설정해 둔 주요 지표가 어떤 값으로 변화했는지에 따라 테스트의 성공 여부를 판단하게 됩니다. 만약 테스트 결과가 예상과 다를 경우 기존에 정의한 문제와 가설, 솔루션이 제대로 되었는지 면밀하게 분석해야 합니다.

실패한 테스트를 그저 지나가는 결과로 바라보지 않고 새로운 인사이트를 얻기 위해서 활용한다면 몇 번의 이터레이션을 거쳐 성공적인 결과로 이끌어낼 수 있습니다. 쿠팡은 ‘패션 상품을 구매를 시도했으나 구매하지 않은 고객‘을 대상으로 사용자 조사를 거쳐 문제를 정의하고 그 문제를 해결할 것이라고 생각한 솔루션을 개발해 테스트 해보았습니다.

🤔

대다수의 고객이 패션 제품을 구매하는데 사이즈를 중요한 요소로 꼽았으며 구매를 포기한 이유로는 내게 맞는 사이즈를 확인할 수 있는 정보가 부족하다는 응답이 많았습니다. 패션 제품의 구매 전환율을 높이기 위해 상품 페이지 상단에 ‘사이즈 안내’ 버튼을 추가해 테스트를 진행했지만 클릭율은 현저하게 낮았습니다.

🔄

여기서 문제나 솔루션이 잘못되었다고 생각하고 그만두지 않고, 왜 솔루션이 실패했는지 다시 한 번 UT를 진행한 결과, 고객에게 상품 페이지 상단은 가격과 결제 혜택을 파악하는 영역으로 익숙해져 있어 새로 추가된 기능을 발견하기 어려웠다는 점을 발견할 수 있었습니다. 또한 새로 추가된 ‘사이즈 안내’ 버튼을 한 번 이상 눌러본 고객의 구매 전환율이 그렇지 않은 고객보다 2배 이상 높았다는 긍정적인 시그널도 발견할 수 있었습니다.

💡

이런 새로운 발견으로 구매 의사가 있는 고객에게 이 버튼을 적절한 시기에 제공할 수 있도록 수정해 PO와 비즈니스 리더에게 다시 설득했고, 주요 지표가 상승하고 상품군의 총 거래액까지 증가하는 결과를 가져올 수 있었습니다.

테스트가 실패했다고 바로 좌절하지 않고 기존 결과를 활용해 다음 이터레이션을 설계하는데 데이터 드리븐한 근거 자료로 활용하여 새로운 인사이트를 계속해서 얻어가는것이 중요하겠습니다.

🔗 이 글은 Val Geisler님이 블로그에 올린 아티클을 번역, 요약한 글입니다.

아래 6가지 원칙을 실현할 수 있는 온보딩 이메일용 템플릿 예시를 제공합니다.

원칙 1️⃣ : 첫 환영 이메일을 커스텀 하기

• Groove에 가입한 직후 받는 이메일의 예시에서 ‘왜 가입했는지’에 대한 질문을 포함하였다
• 이를 통해 각 고객이 원하는 ‘성공’이 뭔지 알 수 있게 되고, 고객과 더 깊은 관계를 맺을 수 있게 되었다

원칙2️⃣ : 고객이 원하는 핵심 정보를 빨리 알려주기

• SaaS 온보딩의 목적은 단 하나이다: 사용자에게 ‘아하’ 모먼트를 제공하는 것
• 온보딩 이메일의 역할은 따뜻하게 맞이해주는 것 뿐만 아니라 사용자에게 햑심적인 기능, 사용자가 꼭 알아야 하는 모듈, 당신이 제공하는 Q&A 콜에 대해 알려주어야 한다

원칙3️⃣ : 사용자에게 그들이 구매한 이유를 상기시키

• 구매한 지 3일정도 된 사용자들은 왜 프로덕트를 구매했는지, 이 프로덕트에 왜 관심을 가지게 되었는지를 까먹었을 수도 있다
• 고객이 프로덕트를 사용하지 않는다면 내 계좌에 돈이 찍힐 진 몰라도 Success case, 래퍼럴 등은 쌓일 수 없다. 이런 것들은 프로덕트를 사용하면서 나온다.

원칙4️⃣ : 키 플레이어를 소개하기

• 팀이나 프로덕트를 뒷받침 하는 핵심적인 사람들을 소개하면 한 번 오고 말았을 고객과 훌륭한 관계를 맺게될 수 있다

원칙5️⃣ : 계속 Engage 시키기

• 모든 SaaS 회사에게 리텐션은 힘든 것이고, 계속해서 더 힘들어 지고 있다
• 이메일은 좋은 리텐션 캠페인 채널이 될 수 있다
• 하지만 이메일이 넘치는 세상이므로 양보다 질에 힘써야 한다

원칙6️⃣ : 사용자를 유지시키기

• 온보딩은 사용자의 전체 라이프사이클에서 여러 순간에 일어나는 프로세스이다
• 프로덕트의 새로운 기능, 인터뷰, 새로운 프로덕트 안내 등으로 사용자를 계속 활성화 시켜야 한다
• 온보딩은 사용자를 획득하는 것으로 끝나지 않는다. 획득하는것은 시작일 뿐이다.

🔗 이 글은 uxdesign.cc가 미디엄에 올린 아티클을 번역, 요약한 글입니다.

B2B SaaS 프로덕트는 글로벌로 진출하기 용이한 프로덕트입니다. SaaS에서 날짜는 자주 사용되는 컴포넌트인데, 국가 별로 날짜를 표기하는 법은 각자 상이합니다. 다국어 프로덕트에서 날짜는 어떤 방법으로 표기해야 할까요?

각 지역 별로 주로 사용하는 날짜 표기법은 다음과 같습니다.

• 년-월-일(2021-10-25) :: 주로 동북아시아
• 일-월-년(25-10-2021) :: 남미, 아시아, 오세아니아
• 월-일-년(10-25-2021) :: 북미 이외에도 여러 방식을 혼용하는 지역도 많습니다.

이런 혼란을 방지하기 위해 만들어진 ISO 8601은 우리에게 익숙한 YYYY-MM-DD 방식으로 표기를 하도록 합니다.

하지만 ISO 방식으로 표시하는것이 항상 좋은 방식은 아닙니다. 컨텍스트에 맞는 유용한 정보 형태로 제공해야 할 것입니다.

• 각 국가에 적합한 포맷으로 제공하되, 레이블을 제공하고 필드를 구분해 인지를 돕고 오류를 방지할 수 있습니다
• 캘린더를 활용한 Date Picker를 제공해 사용자 구분 없이 인지를 쉽게 합니다
• 월과 일을 헷갈릴 수 있다면 월 이름을 제공하거나(Oct) 일에 요일(25 Mon)을 함께 제공하여 인지를 구분하고 오류를 방지할 수 있습니다.
• 다국적 팀에서 사용할 때는 기준이 필요하기 때문에 ISO 방식(YYYY-MM-DD)으로 표기하는것이 좋습니다
• 외부로 데이터를 가져가 활용하거나 테크니컬한 사용 케이스에서 역시 ISO 방식으로 표기하는것이 좋습니다.

🔗 이 글은 박진우님이 브런치에 올린 아티클을 요약한 글입니다.

불만이 생길 수 있는 요소들을 모두 제거한 Friction-less 한 프로덕트를 만든다고 해서 그 프로덕트가 가장 좋은 프로덕트 일까요? 답은 ‘아니오’ 입니다. 불만 요소를 모두 제거한다고 해서 없던 만족이 생기는게 아니기 때문입니다. 우리 마음 속에선 불만과 만족을 처리하는 방식이 다르기 때문입니다.

불만은 보통 비교에서 기반합니다. 반면 만족은 그것이 가지는 독특함에서 옵니다. 이 개념은 ‘카노 모델‘과도 관련된 이야기이기도 합니다.

• 당연한 품질은 모든 프로덕트가 가지고 있어야 하는 요소이며, 따라서 비교 가능합니다. 당연한 품질이 불만족된 경우 다른 프로덕트에 비해 ‘모자란’ 프로덕트가 되며, 불만이 만들어집니다. 하지만 당연한 품질을 모두 만족시킨다고 해서 그 프로덕트가 매력적인 프로덕트가 되는것은 아닙니다.
• 반대로 매력적 품질은 없어도 불만을 형성시키진 않지만 있을 때 만족을 만들어내는 요소입니다.

나의 프로덕트가 사용자의 마음속에 만족감을 주는 프로덕트로 자리잡기 위해서는 다른 프로덕트와 비교가 될 만한 요소보다 프로덕트가 만족감을 줄 수 있는 독특한 요소에 대해 주의를 기울이도록 해야겠습니다.

🔗 이 글은 세탁 특공대가 노션에 올린 아티클을 요약한 글입니다.

세탁특공대가 PM/PO 역할을 정의한 노션 페이지입니다. 많은 회사에서 PM과 PO에 대한 역할을 명확하게 구분하지 않고/못하고 모호하게 사용하고 있습니다. 이 때문에 일을 하다보면 이 일이 PM의 일인지, PO의 일인지 명확하게 나뉘지 않아 R&R을 나누거나 커뮤니케이션에 리소스 낭비가 되는 경우가 있습니다. 세탁특공대는 두 직무를 담당하는 사람의 역할을 명확히 하고, 두 직무와 협업하는 다른 사람의 기대를 명확하게 서술해두었습니다.

세탁특공대의 PO는 제품의 방향성을 결정하고, 사업의 미션을 정의해 타당성을 설득하고 이 미션의 끝까지 도달하는 방법의 우선순위를 결정하며 제품의 기획부터 배포 이후의 디벨롭 프로세스 과정을 총괄 매니징 하는 사람입니다.

세탁특공대의 PM은 PO가 제시한 비전을 실제 제품으로 만드는 역할을 중심으로 수행합니다. PO, Stakeholder의 요구사항을 정확하게 이해해 크루에게 전파합니다. 제품화 까지 필요한 요소를 정의하고 필요한 인력, 시간 리소스를 책임지며 적절히 배치합니다. 제품화를 방해하는 요소를 제거해 다른 크루들이 업무에 집중할 수 있는 환경을 제공합니다.

PO는 다음과 같은 역할을 합니다.

1. 비전 계획서 작성: 비전, 현재 상황 분석, 비전을 달성할 수 있는 전략과 전술
2. Epic 기획서 작성: 목적, 타당성, 목표, 주요 수치, 예산 등
3. 데이터 기반 분석: (환경 요소를 고려한) 액셔너블한 데이터에 집중, 핵심 지표를 기준으로 하위 데이터 항목 설정
4. 설득

PM은 다음과 같은 역할을 합니다.

1. 비전을 제품화 하기: 미션을 제품에 제대로 녹여낼 수 있는 프로덕트 기능 목표 제시
2. 스토리 Flow 완성
3. 스프린트 계획: 플래닝 미팅에서 만들어진 태스크를 기록하고, 진행상황을 업데이트
4. 스크럼 마스터: 데일리 스크럼 주도, 다른 Stakeholder로부터 내부 크루 보호, 태스크 병목상황에서 우선순위 조정, 멘탈 관리
5. 실무 크루와 커뮤니케이션

나아가 세탁특공대가 스크럼, 스프린트를 사용해 일하는 방식도 함께 엿볼 수 있습니다.

🔗 이 글은 Userpilot Team이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

데이터 기반 UX의 대표적인 방법으로는 프로덕트 분석 툴으로 데이터를 활용하여 Frictionless한 프로덕트를 만드는 것이 있습니다.

프로덕트 분석 툴은 다음과 같은 방법으로 User Friction의 원인을 밝히는데 도움을 줄 수 있습니다.

1. 프로덕트 사용성을 테스트 하기
2. 기능 사용률 확인하기
3. User Journey에서 과정을 따라가고 Churn을 발생시키는 지표를 확인하기
4. 사용자 세그먼트 별 트렌드를 그리기
5. 기능과 Flow를 실험하기
6. 사용자의 기분을 측정하기
7. 정성적인 사용자 피드백 측정하기

🔗 이 글은 xguru님이 GeekNews에 올린 아티클을 요약한 글입니다.

사용자 4억명에서 10억명이 된 3년간 Growth팀 헤드였던 Bangaly의 경험을 공유한 글입니다.

인접 사용자(The Adjacent User)는 제품을 알고, 사용해봤지만 참여하지는 못하는 사용자를 의미합니다. 인접 사용자가 사용자가 되지 못하는것은 제품 포지셔닝이나 제품을 경험하는데 장벽이 있음을 의미합니다. 제품의 Growth를 위해서는 지속적으로 인접 사용자를 정의하고, 그들이 뭘 어려워 하는지를 이해하고 공감하면서 문제를 해결해야 합니다.

제품을 여러 개의 단계 별 서클으로 생각해보면, 각 서클은 다음과 같이 나눠볼 수 있습니다.

Power User > Core User > Casual User > Signed Up > Visitor

사용자들은 각 서클 안 궤도에 머무르며, 이 사용자들은 다음 단계로 넘어가지 않고 그 안에 남아있을 확률이 높습니다. 사용자가 다음 단계로 넘어가는데 방해하는 진입장벽이 있기 때문입니다. 각 서클에 진입하지 못하는 사용자들도 인접 사용자로 정의할 수 있습니다. 그들이 더 안쪽의 서클로 진입하지 못하는 이유를 발견하고, 해결해 준다면 더 많은 고객을 끌어들이면서 서클을 더 확장할 수 있을 것입니다.

인스타그램에서는 인접 사용자의 단계를 다음과 같이 구분했습니다.

• Not Signed Up (비가입) → Signed Up (가입)
• Signed Up (가입) → Activated (활성)
• Casual (가끔 쓰는 일반 사용자) → Core Usage (매일 쓰는 핵심 사용자)

슬랙은 인접 사용자를 다음과 같이 구분하고, 각 단계를 관리 할 팀을 다음과 같이 구분했습니다.

• Not Signed Up → Signed Up (Acquisition Team)
• Signed Up → Casual (Activation Team)
• Casual → Core Free (Engagement Team)
• Core Free → Monetized (Monetization Team)

보통 제품 팀이 인접 사용자들을 신경쓰지 않는 이유는 제품 팀이 자신 제품의 파워 유저이고, 현재 사용자에 대해 가장 잘 알고 있는 반면 인접 사용자는 아직 고객이 되지 않은 (우리가 모르는)미래 사용자이며 그 정의는 계속해서 변하기 때문입니다.

인접 사용자를 개발하는 방법

1. 사용자의 특성 중 하나 혹은 두개의 속성만 달라야 함. 하나의 큰 집단을 새로 발견하는게 아니라 미세하게 정의하고, 그 단계를 늘려가는 것임
2. 모든 인접 사용자가 기회는 아님. 해당 세그먼트가 제품의 전략적 방향과 일치해야 함
3. 내부의 문제를 먼저 해결해야 함. 내부 퍼널에서 보이는 인접 사용자군의 문제를 해결하는것이 단기적인 영향을 보일 수 있음

🔗 이 글은 Aashiq Babu님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

대시보드를 디자인 하면서 사용자의 권한이나 태스크의 상태에 따라 몇몇 옵션을 사용하지 못하는 경우가 발생하게 됩니다. 이 떄 메뉴에서 해당 옵션을 숨기는게 좋을까요, Disable 처리하는게 좋을까요?

Disable 처리했을때는,

• 장 해당 옵션의 발견 가능성을 높이고, 학습 용이성을 높이는 장점이 있지만
• 단 인지 부하가 높을 수 있고, 클릭 가능한 요소로 오해할 수 있으며 접근성 측면(WCAG)에서 충분한 대비를 주지 못한다는 단점이 있습니다.

숨김 처리했을때는,

• 장 인지 부하를 낮출 수 있고, 단순함을 확보할 수 있다는 장점이 있지만
• 단 계속 옵션이 나타났다 사라졌다를 반복하면 주의를 뺐어갈 수 있고, 발견 가능성이 낮다는 단점이 있습니다.

⛄️ Disabled 처리는 다음 경우에 사용하면 좋습니다:

• 해당 옵션이 일시적으로 사용되지 못하는 경우나 활성화를 위해서는 사용자의 행동이 필요한 경우. 이 때 툴팁 등으로 원인과 해야 할 액션에 대해 설명해주어야 합니다.
• 사용자에게 옵션이 존재함을 알리고 싶은 경우

🙈 숨김 처리는 다음 경우에 사용하면 좋습니다:

• 사용자에게 사용 권한이 없어 항상 사용하지 못하는 경우
• 활성화 상태로 제공되는 경우가 극히 드문 경우
• 한 페이지 내에 사용하지 못하는 옵션이 많은 경우

📝 노트

B2B 디자인을 하면서 대부분의 경우 Disabled 처리하는 편이 더 낫다고 느꼈습니다.

1. B2B 프로덕트는 인터랙티브한 모습이 아닌 정지한 모습에서도 사용자가 할 수 있는 행동과 그렇지 않은 행동이 명확하게 인지되어야 하기 때문입니다.
2. 또 여러 이해관계자가 서로 다른 화면으로 커뮤니케이션 했을 때 발생하는 비용을 최소화 하기 위해 권한이 없는 화면이나 옵션이 어디에 존재하는지 확인할 수 있어야 하기 때문입니다.

🔗 이 글은 Michelle Yick님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

최근 성공적으로 성장한 SaaS 프로덕트를 이야기할 때 빠질 수 없는 개념이 ‘Product-led’ 입니다. Product-led를 간단히 설명하자면 프로덕트의 매력을 중심으로 프로덕트와 비즈니스를 성장시키는 프레임워크입니다. 하지만 모든 SaaS 비즈니스가 Product-led는 아닙니다. Product-led 가 아닌 다른 성장 방식으로는 어떤 것들이 있을까요?

💰 Sales-led

• 구매자와 좋은 고객 관계를 만드는데 투자합니다.
• 새로운 고객을 유치하는게 가장 어려운 부분입니다.
• 전환 비용이 커서 Churn 하기 어렵고, 리뉴얼과 업셀이 핵심 수익 원천입니다.
• 높은 가치를 가진 고객일 수록 기능과 커스텀을 요구할 수 있는 힘이 있습니다.

📣 Marketing-led

• 퍼포먼스 마케팅, 컨텐츠, SEO에 투자합니다.
• 고객 유치 비용이 높은 것은 높은 전환율과 강력한 레퍼러 프로그램으로 합리화 될 수 있습니다.
• 경쟁이 심하고 전환 비용이 낮아 Paying User를 전환시키는게 중요합니다.

🧑‍💻 Engineering-led

• 최신 기술, R&D, 업계의 인정(특허 등), IP를 구축하는데 투자합니다.
• 가진 기술을 상업화 하는 것이 중요합니다.
• 기술팀과 비즈니스팀엔 지식의 차이가 있어 프로덕트의 가치를 모두 알지 못해 효과적으로 대중에게 판매하지 못하기도 합니다.

💻 Product-led

• 경쟁에서 이기고 시장 파괴적인 힘을 가지기 위해 시장과 사용자 리서치, 프로덕트 개발, 분석에 투자합니다.
• 성장을 유지하고 사용자를 수익화 하고 효율적으로 스케일업 하는게 중요합니다.

🔗 이 글은 ASH님이 브런치에 올린 아티클을 요약한 글입니다.

크래프톤 웨이는 크래프톤이라는 스타트업이 어떻게 성공했는지 그 비결에 대해 이야기 하는 책이 아니라 창업이 어떻게 이루어 졌으며, 어떤 경영 원칙을 세웠고, 누가 어떤 조직을 맡고 떠났으며, 어떤 고난을 겪었고 어떻게 성공을 했는지 있는 그대로 이야기하는 역사서와 같은 책입니다.

ASH님이 뽑은 61가지 인사이트 중 일부를 발췌합니다.

1. 우리에겐 노동자 대신 인재가 필요합니다. 노동자와 인재의 근본적인 차이는 무엇일까요? 바로 대체 가능 여부입니다. 노동자는 대체가 가능합니다. 공장에서 사람 하나 빠지면 2~3일 지나 곧바로 다른 인력으로 대체할 수 있습니다. 그런데 인재는 대체 불가능합니다. 그 사람이 하던 일을 다른 사람이 그 수준으로 못합니다. 인재는 회사가 싫어지면 회사를 나가면 끝입니다. 오히려 회사가 인재를 잃기 싫어 남아주도록 매달려야 하죠. 그만큼 인재와 노동자는 다른 것이고, 인재의 힘은 큽니다.

2. 라스트맨인데 고독하지 않다는 것은, 어쩌면 권한과 보상을 누리면서, 주체적이고 능동적으로 책임을 다하지 않고 있다는 방증일지도 모른다. 조직 내에서 고독을 느끼지 못한다면, 본인에게 주어진 역할과 책임이 그만큼 중요하지 않다는 의미일 수 있다. 그렇다. 의사결정은 라스트맨이 짊어져야 할 숙명이며, 그 과정은 고독하다.

3. 상급자가 어떤 의사결정을 내렸으면, 최소한 왜 이런 결정을 내렸는지 설명하고 공유하는 문화가 필요했다. 까라면 까와 따라주세요는 엄연히 다르다. 팀원도 의사결정의 근거를 알 권리가 있다. 납득이 되어야 자발적으로 일한다.

4. 도전을 시작한 누구라도, 여전히 가치 있는 도전인지, 실패해도 후회하지 않을지 등을 주기적으로 돌아봐야 한다. 대부분의 경우 무언가를 이루기 위해 도전하지만 실은 실패가 더 많다는 점을 인식해야 한다. 성취보다 그 과정이 훨씬 중요하다는 점도 인식해야 한다. 우리 삶은 성취의 결과물보다 도전의 과정으로 정의된다.

5. 조직과 팀은, 신뢰 위에서 올라가요. 법 위에서 올라가지 않아요. 법이라는 건 신뢰가 지켜지지 않을 때를 대비한 최소한의 안전장치입니다. 조직은 기본적으로 신뢰라는 강점을 기반으로 올라가야 돼요.

6. 부하 직원은 상급자가 왜 그런 결정을 했는지 이해하려고 노력하면서도, 틀렸다고 생각하면 언제라도 이의를 제기할 수 있어야 합니다. 또한 말과 글을 옮기기는 어렵다는 사실을 통렬히 인식해야 합니다. 경영진과 본부장의 생각이 동일한 것으로 보이더라도, 메시지가 팀원 수준까지 전달되면 분명히 다르게 이해될 가능성이 상당히 높습니다. 의도적으로 커뮤니케이션을 챙겨야 합니다.

7. 많은 리더가 착각한다. 옳은 결정을 내리는 일이 자신의 역할이라고 말이다. 결정은 시작일 뿐이다. 리더는 사람들이 옳은 일을 하게 만들어야 한다. 리더가 스스로 판단하기에 좋은 생각과 결정을 했더라도 그건 아무런 가치가 없다. 그 일이 실제로 수행돼 결과를 만들어내기 전까지는.

8. 좋은 리더는 자기보다 능력이 뛰어난 사람들을 많이 모아 최상의 결과를 끌어낸다.

9. 최고를 위한 전략은 심플합니다. 누구보다 빠르게 혁신하고 최고의 퀄리티를 유지하면 됩니다. 최고가 될 수 없기 때문에 복잡하고 얕은 수를 사용하는 겁니다. 최고가 될 수 있다면 다른 복잡한 것을 생각할 이유가 없습니다. 심플하게 최고의 제품과 서비스를 만듭시다.

🔗 이 글은 Jinhee Park님이 브런치에 올린 아티클을 요약한 글입니다.

마케터, PM이 가장 기본적으로 보는 프로덕트 데이터 지표로는 활성 사용자 수(Active Users)를 꼽을 수 있습니다. DAU(Daily Active Users), WAU(Weelky Active Users), MAU(Monthly Active Users)는 활성 사용자를 일 단위로 볼 것인지, 주 단위, 월 단위로 볼 것인지에 따라 나눠진 지표입니다.

DAU, WAU, MAU가 유의미한 지표가 되려면 어떤 사용자가 ‘활성 사용자(Active Users)‘인 지를 먼저 프로덕트에 맞게 정의하는게 필요합니다.

DAU, WAU, MAU와 같은 지표는 특정 일자에 발생한 데이터를 그대로 보여주기 때문에 일자 별 발생할 수 있는 자연스러운 오차까지 그대로 나타내게 됩니다. ‘이동 평균(Rolling Metrics)‘을 활용하여 이러한 오차를 줄일 수 있습니다. Rolling Metrics는 N일 간 발생한 데이터를 평균한 값이기 때문에 더 넓은 시야에서 트렌드를 정확히 확인할 수 있도록 도와줍니다.

→ 7일, 30일 등 사용자의 프로덕트 사용 패턴에 따라 적합한 기간을 설정해야 합니다.

🔗 이 글은 Victor Eduoh님이 Openview에 올린 아티클을 번역, 요약한 글입니다.

6가지 Product-led SaaS 온보딩 레슨

Product-led Growth를 지향하는 프로덕트라면 Freemium이나 Trial 비즈니스 모델으로 새로운 사용자를 획득하고 있을 것입니다. 하지만 적절한 사용자 온보딩이 준비되어있지 않으면 새로 획득된 사용자는 다시 돌아오지 않을 수도 있습니다.

40-60%의 사용자들은 SaaS 앱을 한 번만 열어보고 다시 돌아오지 않는다고 합니다.

Slack, Keap, Calendly와 같은 성공한 PLG SaaS의 예시와 함께 좋은 사용자 온보딩 레슨을 볼 수 있습니다.

1. 기대 조정하기
2. 꼭 필요한 것만 전달하고, 수집하기
3. 새로운 사용자를 가이드 하기
4. 집중할 기능을 선별하고, 핵심 기능에 대해 강조하기
5. 프로덕트 뽐내기
6. 고객 팔로업 하기

하지만 프로덕트 온보딩에는 단 하나의 정답은 존재하지 않습니다. 자신의 프로덕트에 맞는 온보딩을 만들어야겠습니다.

🔗 이 글은 Lenny님이 Substack에 올린 아티클을 번역, 요약한 글입니다.

연봉협상은 언제나 어려운 일입니다. 내가 협상을 하는건지, 통보를 받는것인지.. 이직할 때 더 나은 연봉협상을 위한 10계명입니다.

1. 협상은 생각보다 일찍 시작한다

• 첫 만남에서 원하는 금액을 물어보는 경우가 있는데, 절대 숫자를 얘기해선 안됩니다.
• 오히려 역으로 예산이 어느정도인지 물어보고 내 예상과 일치하는지 확인하세요.

2. 인터뷰에서 정보를 더 얻기

• 인터뷰할 땐 답변만 하는것이 아니라 정보도 얻어야 합니다.
• 지금 팀이 가장 주요하게 생각하는것은 무엇인가요? 왜 이 포지션이 필요한가요?

3. 압박에 굴하지 않기

• 포지션에 오퍼를 받은 다음엔 리크루터의 목표는 평가에서 클로징(계약 완료)로 옮겨갑니다
• 이 때 다시금 원하는 금액을 물어보는데 이 때도 숫자를 말해서는 안됩니다.
• 금액을 말씀하시면 거기에 맞춰드릴게요 = 비슷하지만 더 낮은 금액으로 계약합시다

4. 대기업에서는 리쿠르터의 발언권이 없습니다

• 대기업일수록 연봉 테이블이 단단하게 형성되어 있습니다.
• 리쿠르터는 ‘급여 위원회’로 부터 숫자를 받고, 협상을 원할 땐 리쿠르터가 위원회로 가 재평가를 받아야 합니다. 따라서 리크루터는 위원회와 면접자를 여러 번 다녀가지 않기 위해 금액을 먼저 받고싶어 합니다.
• 기존 연봉 테이블의 범위에 들어가버리게 되었다면 다른 곳에서 받은 오퍼 등으로 다시 협상의 기회를 열어야 합니다.

5. 제안의 문맥 읽기

• 제안 금액이 낮은 경우: 협상하기 전 인터뷰어에게 다른 사람들이 생각한 자신의 가치에 대해 피드백을 요청해 내가 생각하는 나의 가치와 상대가 받아들인 가치의 갭을 줄여야 합니다.
• 제안 금액이 중간인 경우: 가장 일반적인 경우입니다. 인터뷰 과정에서 강한 옹호자를 만들지 못했다는 의미입니다. 매니저가 당신을 위해 금액을 배팅하기 위해 마음먹기 전에 협상하지 않아야 합니다.
• 제안 금액이 테이블 꼭대기 일 경우: 더 높은 밴드 금액을 제시할 논의가 있었을 가능성이 있습니다. 이런 경우 밴드를 넘어선 금액을 제시할 수 있습니다.

6. 스타트업에선 다른 방식이 필요함

• 현재 회사의 재무적 상황, 포지션에 대한 계획, 엑싯했을 때 지분가치를 이해하고 협상해야 합니다.

7. 마음을 얻어야 함

• 의사결정권자와 팔로업 미팅을 요청해 그들의 마음을 얻어야 연봉이 나의 가치를 반영할 수 있습니다

8. 데이터를 얻기

• 다른 오퍼와 비교해 경쟁력 있는가? 이야기 나눈 내용은 어떻게 실현되고, 모두 사실인가? 등 데이터를 얻어야 합니다.

9. 오퍼 비교하기

• 오퍼는 회사별로 다양한 방식으로 구성되어 있습니다. 선금을 많이 책정할 수도, 스톡이나 보너스 등으로 나눠져 있을 수도 있습니다.
• 어떤 회사가 더 유망한지, 승진은 어떻게 되는지, 매니저의 영향력은 어떠한지 등을 비교해야 합니다.

10. 미신을 딛고 제대로 요구하기

• 실제로 다른 곳에서 받은 오퍼가 있어야 한다, 리크루터에게 내가 얼마나 적합한지 이야기하는게 가장 확실한 방법이다, 오퍼와 기대가 맞지 않으면 포기할 수 있다고 강력하게 이야기 해야 한다 등은 모두 미신이고 잘못된 방법입니다.
• 큰 액수로 금액을 성공적으로 올리기 위해서는 올바른 방법이 필요합니다.

🔗 이 글은 Disquite 팀이 커뮤니티에 올린 아티클을 번역, 요약한 글입니다.

사용자의 행동 데이터나 사용자의 피드백은 현재 솔루션이 사용자의 문제를 해결해 주는지, Frictionless 한 사용 경험을 제공하는지를 알려주긴 하지만 제품의 방향성을 어떻게 해야 하는지는 알려주지 않습니다.

제품의 방향성을 알기 위해서는 사용자 인터뷰가 필요합니다.

사용자 인터뷰를 할 때 유의해야 할 점은 다음과 같습니다.

1. 사용자의 경험과 현재 painpoint에 대해 질문해야 합니다.

사용자가 현재 겪고 있는 문제와 그 문제를 해결하기 위해 하고있는 방법에 대해 물어보아야 합니다. 만약 사용자에게 원하는 것이 무엇인지, 어떤 기능을 만들면 사용하겠는지 등에 대해 물어보는것은 잘못된 방향으로 가기 쉬운 방법입니다. ‘사용자는 반만 믿어야 한다’, ‘사용자는 본인이 원하는것이 무엇인지 모른다’라는 격언과 그 맥락이 동일합니다.

1. 사용자의 생각을 파악해야하지, 나의 생각을 심으려고 해서는 안됩니다.

사용자를 인터뷰할 때 원하는 답을 유도할 의도를 가지고 질문해서는 안됩니다. 사람들은 상대에게 나쁜 이야기를 하고싶지 않는 성향을 기본적으로 가지고 있기 때문에 사람 간 인터랙션인 인터뷰에서는 사용자가 진실된 내용을 말하지 않을 수도 있습니다. 만약 ‘개선 전과 개선 후 디자인 중 어느 쪽이 더 편한가요?’ 와 같이 ‘개선된’ 디자인이 더 좋다는 편향적인 질문을 하는 경우 사용자는 그 경향성에 편승하는게 쉬운 선택이 될 수 있습니다.

인터뷰 할 대상은 다음과 같이 나눌 수 있습니다.

1. 현재 우리 솔루션을 사용하는 유저
   → 어떻게 하면 유저 플로우를 최적화 시키고 사용자 경험을 개선시킬 수 있을지를 알 수 있습니다.
2. 경쟁 솔루션을 사용하는 유저
   → 경쟁 솔루션이 아닌 우리 솔루션을 사용하게끔 하려면 어떤 니즈를 충족시켜줘야 되는지를 알 수 있습니다.
3. 우리 솔루션도 경쟁 솔루션도 사용하지 않는 Non-유저
   → 우리가 시장을 확장하려면 어떻게 해야 되는지를 알 수 있습니다.

많은 사람들이 간과하는 점은 경쟁 솔루션을 사용하는 사용자를 인터뷰 하는것이 매우 중요하다는 점입니다. 현재 우리 솔루션 사용자는 이미 핵심 기능에 만족하고 계속 사용하는 사용자이기 때문에 그들의 Painpoint는 핵심적인 문제가 아닐 수 있습니다. 반면 우리 프로덕트를 사용하지 않고 경쟁 프로덕트를 사용하는 경우엔 우리 프로덕트에서 제공해주지 못하고 있는 핵심 문제를 경쟁 솔루션에서 해결하고 있다는 의미이기 때문입니다.

🔗 이 글은 Angshuman Gupta님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

어떤 ‘지표’가 중요할까요?

우리가 만들고 출시하게 되는 기능은 어떤 문제를 해결하기 위한 것이고, 그 문제는 회사의 목표와 맥락을 같이해야 합니다. 이 말은 즉 기능의 성공은 회사의 목표에 기여하는 바를 통해 측정할 수 있다는 것입니다.

지표에는 여러 종류가 있을 수 있습니다.

1. 주요 지표 (Primary Metric / Goal Metric / North-Star Metric)
   • 여러 보조 지표를 포괄하는 지표
   • 기능의 목표를 측정. 프로덕트와 회사의 목표와 깊게 연관되어 있음
2. 보조 지표 (Secondary Metric / Product Metric / Supporting Metric)
   • 기능의 상태를 측정하는 지표
   • 사용자의 퍼널¹를 위한 프로덕트의 액션²에 관한 지표
3. 대항 지표 (Guardrail Metric / Counter Metric)
   • 주요 지표를 달성하면서 반대급부로 얻게 되는 요소에 대한 지표
     예: 어떤 곳에 빠르게 도달하는것이 목표일 때 주요 지표는 ‘속도 증대’ 이지만 이 지표는 ‘연료 소비’라는 반대급부 지표를 가지게 됨

여러 지표를 측정하면서 각 지표 간 Trade-off와 리스크를 분석할 수 있어야 합니다.

🔗 이 글은 Jakob Nielson님이 NN Group 블로그에 올린 아티클을 번역, 요약한 글입니다.

🤔 사용자는 모든 요구사항을 처리할 수 있는 강력한 기능과 통제감을 원하기도 하지만 현재 요구사항에 가장 적합한 몇 가지만 볼 수 있고 추가적으로 학습하지 않아도 알 수 있는 단순함을 동시에 원하기 때문에 복잡한 프로덕트를 디자인 하는 우리는 종종 딜레마에 직면하게 됩니다.

💎 점진적 공개

이 때 사용되는 ‘점진적 공개(Progressive Disclosure)‘는 고급 기능이나 거의 사용되지 않는 기능을 숨겨둠으로써 핵심 기능을 더 쉽게 배우게 하고 오류 발생을 줄이기 위해 사용되는 방법입니다. 위와같은 상충되는 요구사항을 충족하기 위해 처음엔 가장 중요한 몇 가지 옵션만 제공하고, 사용자가 요청하는 경우에 더 많은 전문 옵션을 제공할 수 있습니다.

⚙️ 점진적 공개의 장점

점진적 공개는 사용성의 구성 요소 5가지 중 1️⃣ 학습 용이성, 2️⃣ 효율성, 3️⃣ 오류 방지 3가지 항목을 개선할 수 있습니다. 사용자는 가장 초기에 제공되는 기능이 가장 중요하고, 메인 태스크를 수행하는데 사용되는 것을 인지할 수 있습니다.

• 초보 사용자는 기본적인 유용한 기능에 집중해 쉽게 학습할 수 있고, 고급 기능의 잘못된 사용으로 인한 오류를 방지할 수 있습니다.
• 고급 사용자는 현재 과업에서 필요 없는 기능을 쉽게 스캔할 수도 있습니다.

🚧 점진적 공개를 위해 해야할 일

1. 초기 핵심 기능과 보조 고급 기능을 명확히 분리해야 하고
2. 초기 핵심 기능에서 보조 고급 기능으로 진입하는 플로우를 명확하게 제공해야 합니다.

이는 사용 빈도나 사용 사나리오 관찰으로 구분할 수 있습니다.

🍢 ‘단계적 공개’도 고려하기

점진적 공개와 더불어 함께 고려할 수 있는 개념은 단계적 공개입니다.

• 점진적 공개는 기능 간 네비게이션이 계층적이고, 고급 기능은 필요시에만 접근할 수 있는 경우 사용이 유리합니다.
• 단계적 공개는 네비게이션이 선형적이고 사용자가 한 번에 한 단계씩 태스크를 수행하는 경우 사용이 유리합니다. 각 단계가 가지는 목적이 명확하고 단계 별 상호작용이 거의 없는 경우에 유용합니다. 만약 각 단계가 상호 의존적이면 사용성 문제를 야기할 수도 있습니다. 또, 작업 단계가 많으면 사용자가 과도한 탐색을 해야하는 단점도 있을 수 있습니다.

두 가지 방식의 장단점을 고려해 적절한 UX, UI를 제공 해야겠습니다.

🔗 이 글은 이상희님이 블로그에 올린 아티클을 요약한 글입니다.

알토스 벤처스의 Han Kim 대표님이 B2B 회사 경영진에게 던지는 질문에 대해 Sendbird의 Country Manager 이상희님의 주관적인 답변이 담긴 글입니다.

Sendbird가 성공을 위해 달려가고 있는 과정과 생각을 엿볼 수 있으니 본인의 프로덕트/회사가 답할 수 있는 내용과 어떻게 다른지 생각해보는것도 도움이 될 것 같습니다.

6가지 질문은 다음과 같습니다.

1. 왜 이 제품을 쓰나요? 이 제품은 어떤 문제를 해결하죠?
2. 타겍 고객이 누구인지? 어떤 크기 기업들이 중심인지? 설득해야 하는 사람이 누군지? 구매자와 사용자가 다른지? 제품은 한 기업에서 몇 명이나 쓰는지? 얼마나 자주 쓰는지?
3. 어떻게 타겟 고객이 이 제품이 있다는 것을 알게 되는지? 알고, 경험하고, 구해하고, 실제로 사용하는데 어떤 프로세스를 겪는지? 처음부터 끝까지 시간이 줄었는지? 어떻게 줄었는지? (어떤 곳들은 어떤 요일 몇시에 어떤 이메일을 어떤 고객에게 보내니 응답률이 좋았다는 실험을 한 곳도 있음)
4. 고객들은 구매 이전에 내부적으로 어떻게 승인을 얻는지? 그게 고객마다 다른지? 다르다면 왜 다른지?
5. (무료에서 유료로 전환하는 모델) 한 번 쓰기 시작한 고객을 어떻게 유료로 전환시키는지? 어떤 실험을 해보았는지?
6. (유료 전환 후) 고객들에게 어떻게 추가로 가치를 줄 수 있는지? 고객 안에서 더 많은 사람들이 쓸 수 있는 것인지? 그러려면 제품 기능 중 어떤 것을 추가해야 하는지?

🔗 이 글은 김자유(김강령)님이 브런치에 올린 아티클을 요약한 글입니다.

지난 토스의 Simplicity 21 컨퍼런스에서 발표된 적 있는 토스 보이스톤 메이커를 만들게된 과정에 대한 글입니다.

팀이 작을때는 내가 주로 작성하는 어투만 프로덕트에 반영되기 때문에 프로덕트의 보이스톤을 일관되게 유지하기가 더 쉽습니다. 하지만 팀이 커지고 많은 사람들이 프로덕트에 사용되는 레이블을 작성하기 시작하면서 보이스톤을 일관되게 유지하기 어려워지기 시작합니다.

토스에서도 프로덕트 디자이너, UX Writer, PO, Legal 등 다양한 이해관계자가 레이블에 영향을 주고 있다보니 개인이 UX Writing에 대해 신경을 많이 쓴다고 해도 보이스톤이 하나로 통일되기는 어려운 상황이었습니다.

토스는 UX Writer의 리소스를 반복적으로 사용하지 않는 확장가능한 방법을 위해 프로덕트 디자이너가 사용하는 프레이머 툴에 더 나은 단어를 제시해주는 보이스톤 메이커를 도입하였습니다. 보이스톤 메이커를 통해 디자이너들은 디자인 과정에서 즉시 적절한 단어를 추천받아 수정하고, 통일된 보이스톤을 구현할 수 있도록 했습니다.

보이스톤 메이커를 도입하기 위해 UX Writer, UX 엔지니어가 TF를 구성해 작업하였는데, 회사 입장에서도 보이스톤 메이커라는 내부 워크 프로세스를 위해 리소스를 사용하도록 결정할 수 있었다는것이 놀라운 결정입니다.

위 내용과 관련한 토스의 Simplicity 21 영상입니다.

🔗 이 글은 오일나우의 지연님이 미디엄에 올린 아티클을 요약한 글입니다.

오일나우가 UX 개선만으로 회원가입 퍼널 전환률을 높인 사례입니다. 오일나우는 처음엔 핵심 저니를 짧게 구성하고자 회원가입 단계를 뒤로 미뤘었는데요, 시간이 지나자 리텐션에 유리한 로그인이 필요한 행동들을 유도하기가 힘들다는 한계에 부딪혔습니다.

1. 회원가입 전환율을 위해서는 근처 저렴한 주유소를 찾아준다는 오일나우의 핵심 가치를 전달하기 위해 딱딱한 회원가입 프로세스 대신 월 주유비의 10%를 절약해준다는 핵심가치를 숫자로 확연하게 느낄 수 있도록 하는 과정을 먼저 배치했습니다.
2. 로그인 전환율을 위해서는 기존 사용하던 기능 외에 23개의 주유비를 절약할 수 있는 기능이 있음을 알려 로그인에 대한 가치를 구체인 숫자로 전달했습니다.
3. 회원가입과 로그인 시 여러 방식 중 어떤 방식을 선택해야 할 지 생각해야 하는 사용자의 고민을 줄여주기 위해 ‘카카오톡’ 과 ‘애플’ 두 가지 로그인 방식만 메인으로 제공했습니다.
   → 카카오톡을 가장 핵심으로 밀어줬던 이유는 기존 고객 중 가장 많은 사용자 비율을 차지하고 있었고, 추후 리타겟팅에도 활용할 수 있기 때문입니다
   → 애플 로그인은 iOS에서는 필수로 제공해야 해 뺄 수 없었을겁니다

최종적으로는 235%의 전환율 증가를 얻었긴 했지만, 모수를 밝혀주시진 않았기 때문에 기대하는 것 만큼 유의미한 증가였는지는 확인하기는 어렵습니다만 성공적인 프로젝트였던 것으로 보입니다.

🔗 이 글은 Josh님이 페이스북에 올린 포스트를 요약한 글입니다.

채널톡이 채널톡 마케팅에 적용하기 위해 B2B 마케팅 사례를 분석한 결과에 대한 경험을 공유했습니다.

잘 된 스타트업, 최근 SaaS 붐을 이끌고 있는 사례, 유명한 B2C 서비스까지 다양하게 살펴 본 결과, 공통점은 거의 없고, 두 가지 공통점만 발견할 수 있었다고 합니다.

1. 시장에서 두드러지게 뛰어난 제품(Outstanding Product)
2. 뛰어난 제품에 기반한 입소문(Word Of Mouth)

모두들 다른 방식을 사용했음에도 불구하고 결과적으로는 성공한 사례가 된것을 보면 어떤 성공 방정식은 없는것 같습니다. 다만 모두들 ‘자신다운’ 마케팅을 했다는 점은 눈에 띄었습니다.

채널톡도 채널톡의 마케팅 활동을 돌아봤을 때 자신답지 않은 활동이 많이 발견되었다고 합니다. 특히 ‘매출이 오른다’는 점을 강조한 광고들은 대표님들의 눈과 귀를 혹하게 만들긴 하지만 결국 뻔한 ‘쉽게 돈 버는법’ 같은 내용에 지나지 않게 될 것입니다.

채널톡은 채널톡을 사용하는 최 우선 목적이 ‘매출을 올리고 싶어서’가 아니라 ‘고객과 대화하고 싶어서’가 되면 좋겠다고 합니다. 이런 목적이 실현된 사례를 성공사례로, 광고로 만들어 다시 한번 좋은 마케팅의 Flywheel을 만들 계획이라고 합니다.

우리 프로덕트는 고객에게 어떤 말을 하고 있나요? 우리 프로덕트다운 말을 하고 있나요?

🔗 이 글은 마미새(마케팅에 미친 새싹들)님이 브런치에 올린 아티클을 요약한 글입니다.

데이터 사이언티스트 하용호님의 인터뷰 글입니다. 하용호님은 스스로 하는 일을 데이터로 회사의 문제를 해결해주는 사람이라고 합니다. ‘데이터’라는 점을 빼면 디자이너가 하는 일과 맥락을 같이한다고 볼 수 있겠습니다.

회사들은 데이터 사이언티스트에게 어려운 문제를 던져주기 마련입니다. 눈에 보이는것 뒤에 숨은 문제까지 발견할 수 있어야 진짜 문제를 발견하고 해결할 수 있습니다. 지금 바라보는 문제가 진짜로 해결할 만 한 문제인지 판별하기 위해 ICE 프레임워크를 사용합니다.

• Impact: 얼마나 많은 유저들에게 영향이 가는가
• Confidence: 성공 가능성
• Ease: 도입 난이도

해결할 만한 수준의 문제라는것을 알게 되었다면, 이 문제를 정확하게 바라보고 문제 해결을 위한 방법을 아이데이션 하는 방법으로는 PSW 프레임워크를 사용합니다.

• Problem: 누가, 얼마나 심하게, 어떻게 겪고 있는 고통인가?
• Solution: 이 고통을 해결해주는 방법
• Why: 우리가 왜 해야하는가. 다른 이들보다 더 나은 장점 (Unfair Advantage)

이외에도 하용호님의 문제해결능력에 대한 조언과 데이터 리터러시에 대한 이야기들이 담겨있습니다

🔗 이 글은 박창선님이 브런치에 올린 아티클을 요약한 글입니다.

화면에 정보가 많은 B2B 프로덕트를 디자인 하는 과정에서는 수 없이 많은 레이블을 만들어야 합니다. 점점 찾는 기업이 많아지는 그 UX Writer가 우리 회사에도 있었으면 하고 바라지만 당분간은 이루어질 수 없는 꿈으로 남아있을 확률이 높은 것 같습니다.

UX Writer 없이도 B2B 프로덕트의 레이블을 작성할 때 꼭 유념해야 할 항목들을 잘 꼽은 글입니다.

1. 책임질 수 있는 언어를 사용하고, 브랜드 이미지에 결맞춤이 되어야 합니다.
2. 어떤 상황에서 사용되는지를 알고 이에 맞는 용어를 사용해야 합니다.
3. 내 세계에서만 통할 언어를 사용해서는 안됩니다.

🔗 이 글은 김민우님이 블로그에 올린 아티클을 요약한 글입니다.

최근 데이터 기반 의사결정, 사용자 행동 분석 등 데이터 분석을 활용하는 곳이 많아졌습니다. 주변에서 많이 이야기 하는 ‘실험’과 ‘가설’에 대한 개념을 얼마나 정확하게 알고 있나요?

1. 실험은 몰랐던 것을 알아내기 위해 (=지식을 얻기 위해) 하는 활동입니다. 만약 실험으로 뭔가를 알아내지 못했다면 잘못된 실험입니다.
2. 가설은 반증할 수 있도록 구체적인 형태와 숫자로 표현된 문장입니다. 가설과 유사한 의미로 사용되는 가정은 반증 가능할 정도로 구체적이지 못한 암묵적인 믿음입니다.

스타트업의 실험은 다음과 같이 실행되어야 합니다.

1. 의사결정 하기에 충분한 꼭 필요한 만큼의 정보를 얻기 위해
2. 반증 가능할 정도로 구체적인 가설을 세우고
3. 그 검증 방법을 설계해
4. 가설을 실험하여 최종적으로 정보를 얻는다.

🔗 이 글은 David Sacks님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

첫 B2B SaaS 첫 고객으로는 대기업을 타겟으로 하는 것이 좋을까요 SMB를 타겟으로 하는 것이 좋을까요? 저자는 이전에는 큰 기업이 더 가치가 높은 고객이라고 생각했지만, 새로운 시각에서는 빠르게 딜을 마무리할 수 있는 SMB가 PMF를 찾는 초기 기업 입장에서 더 좋다는 관점이라고 합니다.

기존 대기업이 더 좋은 고객이 될 수 있는 이유와, SMB가 더 좋은 고객이 될 수 있는 최근 새로운 시각의 이유를 모두 살펴보고, 중간 사이즈의 고객이 좋을 수 있는 하이브리드 모델도 살펴보고 있습니다.

본인의 프로덕트의 특징이 어떤지 고심해보고 첫 고객을 어느 사이즈의 고객으로 잡고 일해야할 지 생각해보면 좋을 것 같습니다.

🔗 이 글은 Linzi Berry님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

B2B 프로덕트를 사용하는 플로우에서는 시스템이 사용자에게 정보를 제공해야 하는 경우가 많습니다. 이 때 정보를 어떤 방식으로 제공하는게 가장 적절할 지 여러 UI 컴포넌트 중에서 고민해본 적이 많으실 것 같아요. 경고 모달, 노티 스낵바, 드로어, 툴팁 등등 정보를 전달 할 방법은 많으니까요.

사용자에게 전달해야 할 정보는 사용자의 결정이 필요한 정보인지 vs 정보를 전달하는 메세지인지에 따라 크게 구분할 수 있습니다. 이렇게 나뉜 메세지에서 제공 할 정보의 특징에 따라 사용해야 할 컴포넌트를 결정할 수 있습니다.

저자는 로직 트리로 시각화를 해 메세지를 어떤 컴포넌트로 제공해야할 지 쉽게 결정할 수 있도록 하였습니다. 비록 모바일 앱 UI를 중심이긴 하지만 각 컴포넌트의 정의와 예시, 특징도 함께 제공하고 있으니 디자인 프로세스에 참고할 수 있겠습니다.

🔗 이 글은 A Junior VC님이 블로그에 올린 아티클을 번역, 요약한 글입니다.

스타트업 업계에 종사하다보면 다양한 용어를 만나게 됩니다. 업무나 회의 중 나만 모르는 단어를 모두가 이해하고 쓰고 있으면 대화의 흐름을 따라가기 벅찹니다. 스타트업 업계에서 자주 사용되는 용어들을 쉽게 이해할 수 있도록 만화로 풀어낸 곳입니다. 문제는 만화인데 영어로된 만화라는 점..?

👇 배울 수 있는 단어들의 예시는 아래와 같습니다

[지표 & 분석]

• A/B Testing
• ARR & MRR
• LTV/CAC
• Cohort Analysis
• ARPU & AOV
• Churn and Bounce rate
• Payback Period
• DAU/WAU/MAU

[프로덕트]

• Product Market Fit
• MVP
• Pivot
• Growth Hacking
• Traction
• B2B vs B2C

[비즈니스]

• Burn rate and Runway
• Unit Economics
• Moat
• Bootstrapping vs Raising Funds
• Valuation and Stages

🔗 이 글은 Lenny Rachitsky님이 a16z 블로그에 올린 아티클을 번역, 요약한 글입니다.

내 프로덕트의 특징에 따라 더 잘 맞는 북극성 지표가 있을 수 있을까요? 저자는 북극성 지표를 6가지 카테고리로 나누고, 각 카테고리가 더 적합한 프로덕트 형태를 정의하고 있습니다. 다만 각 회사들이 한 카테고리의 북극성 지표만 가지고 있는 것은 아니라는 점을 인지해야 합니다.

각 카테고리의 회사가 어떤 곳인지 들여다 보시면 저절로 고개를 끄덕일 수 있을 만큼 잘 분석한 글입니다.

1. 수익 (ARR, GMV): (?)
2. 고객 증가 (유료 사용자, 시장 점유율): 플랫폼, 마켓플레이스 기업, Freemium 프로덕트, 소비자 구독 중심 프로덕트
3. 고객 지출 증가 (보낸 메세지 수, 예약한 날짜 수): UGC 구독 중심 프로덕트
4. 인게이지먼트 증가 (MAU, DAU): Freemium 프로덕트, 광고 기반 비즈니스, 소비자 구독 중심 프로덕트
5. 성장 효율성 (LTV/CAC, 마진): 퍼포먼스 마케팅으로 성장하는 비즈니스
6. 사용자 경험 (NPS): 색다른 사용자 경험이 중요한 프로덕트

🔗 이 글은 Lenny님이 Substack에 올린 아티클을 번역, 요약한 글입니다.

빠르게 성장한 B2B 비즈니스는 어떻게 첫 고객을 확보했을까요? 우리가 잘 아는 슬랙, 피그마, 앰플리튜드, 아틀라시안, 드롭박스 등 B2B 솔루션들의 시작과 첫 고객을 확보한 방법에 대해 소개하고 있습니다.

크게 PLG(Product Led Growth) 방식인 바텀-업 혹은 고객의 셀프 서비스로 확보한 방법과, 세일즈를 통해 확보하는 방법이 있습니다.

또 두 방법 내에서도 다음과 같은 방법으로 프로덕트를 알리고 고객을 확보할 수 있습니다.

1. 👋 개인 인적 네트워크를 활용 (친구 등)
2. 🧗‍♀️ 고객이 있는곳을 찾아가기 (트위터 등)
3. 🗞 언론에 노출되기

🔗 이 글은 정선우님이 본인의 블로그에 올린 아티클을 요약한 글입니다.

식스샵 정선우님의 스타트업에서 프로덕트 디자인을 한다는것에 대한 인사이트를 담은 글입니다.

현 시대에 프로덕트 디자이너라는 직무를 많은 기업이 찾는데에는 기존 기능 중심 조직에서 제품 중심 조직으로 많은 기업이 거듭나고 있기 때문이라고 합니다. 제품 중심 조직의 구성원들은 도메인에 대한 지식을 바탕으로 본인이 맡고있는 제품에 대한 오너십을 가지고 (워터폴 방식이 아닌) 애자일하게 일하기를 기대합니다.

스타트업의 성장 과정에서 프로덕트 디자이너가 집중해야 할 일의 구분과 프로덕트 디자이너가 가져야 할 마인드셋과 업무적 역량도 정리하였습니다. 디자이너에게는 다음과 같은 역량이 필요합니다

• 사고 역량
• 끝없는 호기심과 질문
• 사용자 경험에 대한 이해
• 인터페이스 디자인 역량

이러한 역량을 기르기 위해서는 프로덕트 사고, 도메인, 제품 구현에 대한 훈련을 해야합니다.

🔗 이 글은 Chris님이 CandA 블로그에 올린 아티클을 요약한 글입니다.

사용자들이 Churn 하는것을 방지하기 위해서는 어떤 전략이 필요할까요? 사용자가 이탈하지 못하도록 해지 버튼을 숨기고, 긴 입력 폼을 작성하도록 하고, 해지 과정을 복잡하게 만드는 것으로 이탈을 방지할 수 있을까요?

우리가 만드는 제품의 미션은 고객을 감동하게 하고, 실질적인 가치를 전달해야 합니다. SaaS와 구독 비즈니스 사업 특성 상 Churn이 없을 수는 없습니다. 모두를 만족시킬 수는 없으니까요. 고객이 이탈하려 한다면 다운그레이드를 제시하거나, 제품의 가치를 더 느낄 수 있도록 크레딧을 제공하는 등 다양한 노력을 하고, 그래도 이탈하려는 고객은 깔끔하게 보내주어야 한다. 추후 프로덕트가 개선한 다음 다시 돌아올 수 있는 여지를 만들 수 있습니다.

고객 중심의 경영을 한다면 정말로 고객이 원하는것을 주어야 합니다.

🔗 이 글은 Saurabh Sahni, Taylot Singletary님이 슬랙 엔지니어링 블로그에 올린 아티클을 번역, 요약한 글입니다.

슬랙이 API를 디자인하는 설계 원칙에 대한 이야기입니다. API를 디자인하는 일이지만 B2B 프로덕트를 설계하는 원칙이라고 해도 전혀 어색하지 않습니다.

1. 한가지 동작만 아주 잘 할 것
2. 빠르고 쉽게 사용할 수 있게 만들 것
3. 직관적인 일관성을 위해 노력하기
4. 의미있는 에러 리턴하기
5. 확장성과 성능을 고려한 설계
6. 호환성을 깨는 변경 피하기

더해서, 예상 못한 상황들이 있을 수 있으니 Stay Flexible(유연성을 유지하기)

🔗 이 글은 Anne Siing Blond님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

B2B 프로덕트는 B2C 프로덕트보다 사용자와 만나 리서치를 진행하기 더 어렵기 때문에 셜록 홈즈와 같이 상세하게 리서치 해야 PMF를 달성할 수 있는 가능성이 높아질 수 있습니다.

• 먼저 프로덕트가 풀고자 하는 문제를 명확하게 정의할 수 있어야 합니다. 블로그에서는 엘레베이터 피치에서 사용하는 템플릿으로 Product Statement를 만드는 예시를 들었습니다.
• 또 매크로, 메소, 마이크로 3가지 레벨에서 리서치를 해야 합니다.
  • 시장과 경쟁 상황에 대해 알고,
  • 사용자와 경쟁자가 누구인지 알고,
  • 구매자와 사용자가 누구인지 알고,
  • 사용자를 인터뷰 하여 사용자의 이야기를 들어야 합니다.

🔗 이 글은 David Sacks님이 미디엄에 올린 아티클을 번역, 요약한 글입니다.

SaaS 프로덕트를 잠재 고객에게 경험하도록 제공하는 대표적인 두 가지 방식인 Freemium과 Free Trial 중 어떤 방법이 내 프로덕트와 더 잘 맞는 방법일까요?
Freemium은 프로덕트의 제한적인 기능을 항시 무료로 제공하여 더 강화된 기능을 사용하기 위해 결제를 유도하는 방식이고,
Free Trial은 보통 모든 기능을 제한적인 시간동안 사용할 수 있도록 하여 프로덕트를 경험하게 하는 방식입니다.

Freemium 방식이 더 잘 맞는 프로덕트

• 사용자 모집이 바텀업이거나 바이럴을 통해서 얻어지는 경우
• 무료 사용자가 컨텐츠를 만들거나 네트워크 효과에 도움이 되는 경우
• 무료 사용자가 없을 때 구매자의 효용이 크게 감소하는 경우
• 무료 사용자의 지불 의향이 낮아서 비용을 청구하는것이 비효율적인 경우
• 무료 사용자가 많아짐에 따라 판매가 더 늘어나는 경우
• 무료 사용자와 유료 사용자의 기능 요구가 달라 기능을 제한하는 방식이 두 사용자군을 구분하기 쉬운 경우

Free Trial 방식이 더 잘 맞는 프로덕트

• 관리자에 사용자가 의해 공급되는 경우
• 유료 마케팅을 통해 주로 리드가 만들어지는 경우
• 무료 체험 가입자가 잠재 고객으로 연결된다는 근거가 없는 경우
• 시간을 제한하는 방식으로 세일즈 과정에 조급성을 추가하는것이 도움이 되는 경우
• 유료 사용자의 제품 사용 경험이 무료 사용자가 줄어들어도 크게 감소하지 않는 경우

🔗 이 글은 Ally님이 강남언니 블로그에 올린 아티클을 요약한 글입니다.

강남언니가 일본 유저 대상으로 온보딩 화면을 AB 테스팅 하여 회원가입 전환율을 높이려는 과정에 대한 글입니다. 첫 번째 시도는 실패하고, 실패를 딛고 다시 설계하여 두 번째 시도에서 유의미한 개선을 경험하는 과정이 담겨있습니다.

✌️ Key point

• 욕심을 내려놓고 한가지만 물어보자
• 문제상황을 명확히 설정한 뒤 가설을 날카롭게 가다듬어 한가지로 통일하는것이 중요
• 다른 개선까지 테스트하고 싶은 욕심이 나더라도 가설을 검증하기 위해 다른 변수들을 통제해야함

🔗 이 글은 Jun Joo님이 브런치에 올린 아티클을 요약한 글입니다.

최근 점점 더 중요성이 높아지고 있는 UX Writing에 대한 글입니다.

B2B SaaS 에서는 특수한 도메인에서만 통용되는 전문용어들이 사용되는 환경일 가능성이 더 높습니다. 초보 사용자들에겐 잘 쓰이지도 않고 정확한 의미를 이해하기 힘든 전문용어를 대시보드에서 만나는건 프로덕트 사용성을 저해하는 큰 요인인데요, 그렇다고 마음대로 용어를 풀이해버려 어디에서도 쓰이지 않는 단어로 만들었다간 잘못된 정보 전달을 할 수도 있고 추후 해당 사용자가 정확한 용어를 익혀 도메인의 전문가로 성장하는것을 방해할 수도 있어 유의해야 합니다.

또한, 이 글에선 이러한 자곤(Jargon, 도메인 전문용어)를 어떻게 사용해야하는지에 대해 고민하고 가이드 합니다.

🔗 이 글은 Varun Mohapatra가 UX Collective에 올린 아티클을 번역, 요약한 글입니다.

저자는 B2B 프로덕트와 기업용 애플리케이션을 동일하게 간주하여 말하고 있습니다. 저자는 B2B를 Enterprise로 표현하고 있지만 번역 후 해석의 용이성을 위해 이 글에서는 모두 B2B로 표현합니다.

2018년 1월 글이지만 제가 B2B, SaaS를 디자인하면서 공감이 되는 글이라 번역에 옮깁니다.

⚡️ 요약

1. 기능적 복잡도 😓

B2B 프로덕트는 복잡합니다. 사용자도 B2B 프로덕트를 익혀 잘 사용하기까지 리소스를 투자해야 합니다. 이 말은 B2B 프로덕트의 기능 릴리즈는 아주 비싸다는 말입니다. 하나의 기능을 릴리즈하기 전에 충분히 디자인씽킹 하고, 모든 가능성을 점검한 후 인터페이스를 디자인해야 합니다.

2. 근로자(실사용자) 마인드셋을 위해 디자인하기 💼

B2C 프로덕트와 가장 다른 점이라고 할 수 있습니다. B2B 프로덕트는 기업 사용자의 업무를 효율적으로 처리하기 위해 존재하므로 사용자의 사용 목적부터 다릅니다. 사용자의 도메인에 대해 자세하게 이해하고 그들의 워크플로우를 뜯어볼 수 있어야만 진정으로 사용자에게 유용한 B2B 프로덕트를 만들 수 있습니다.

3. 높은 전환 비용을 인지하기 😟

B2B 프로덕트는 이미 존재하는 워크플로우를 빠르고/효율적이고/더 낫고/더 저렴한 방식으로 해결할 방법을 제안하는 것입니다. 따라서 경쟁 프로덕트가 있는 경우가 많은데, 한 프로덕트에서 다른 프로덕트로 옮겨가는 전환 비용이 B2B 프로덕트에서는 더 클 수밖에 없습니다. 높은 전환 비용이 있음에도 불구하고 우리 프로덕트를 사용할 수 있도록 데이터 마이그레이션 과정을 최적화 고, 사용법을 쉽게 익힐 수 있게 하고, 경쟁 프로덕트보다 더 저렴하면서도 더 효율적으로 일을 처리할 수 있는 프로덕트를 만들어야 합니다.

4. 새로운 기능과 가능성을 만드는 것을 우선순위로 두기 😤

B2B 프로덕트는 사용자들의 끊임없는 요구사항을 프로덕트의 비전에 맞추어 달성 해나가야 합니다. 하지만 혁신적인 프로덕트는 사용자의 이야기를 실현하는 것만으로는 달성할 수 없습니다. 포드가 자동차를 처음으로 만들 때 사람들은 더 빠른 말만을 원하고 있던 것처럼요. B2B 디자이너는 사용자가 원하는 새로운 기능을 만드는 것과 혁신의 가능성을 만드는 두 측면을 항상 생각해야 합니다.

5. UX 일관성을 유지하기 😊

원 글은 2018년에 작성되었기 때문에 저자의 요점과 다른 점에서 풀어보도록 하겠습니다. B2B 프로덕트는 다양한 사용자가 각자의 워크플로우에 맞는 다양한 기능을 사용하기 때문에 한 프로덕트에서도 사용 케이스가 세세하게 분화되기 마련입니다. 한 사용자의 사용 케이스가 변화하더라도 일관된 UX를 제공해야 하는데, 프로덕트 팀이 커질수록 이를 지키기가 어려워집니다. 작게는 디스크립션 레이블 어미에서 크게는 특정 기능이 사용되는 방식까지 달라지는 것을 경험할 수 있습니다. 항상 내가 디자인 하는 기능이나 개선사항이 다양하게 사용될 수 있음을 인지하고 일관된 UX를 구현할 수 있도록 여러 업무 유관자와 커뮤니케이션 하는 것이 중요합니다.

6. 모든 디자이너가 B2B 프로덕트를 좋아하진 않는다 😢

많은 디자이너들의 호불호가 갈리는 지점은 B2B 프로덕트는 화려하고 심플한 UI로 사용자들을 사로잡는 게 아니라, 업무를 잘 도와줄 수 있도록 예측가능하고 명확한 디자인을 해야한다는 점입니다. B2B 디자인은 익숙하지 않은 도메인과 복잡한 프로덕트 구조 속에서 기업 사용자가 가지는 복잡한 문제를 해결해나가면서 빠르게 개인의 역량을 성장시킬 수 있습니다.

Intro

내가 VWO에서 일을 시작하면서 이런 의문을 느낄만 한 순간들이 많이 있었다. 기업용 애플리케이션(B2B)는 정말 일반 소비자용 앱(B2C)와 다른가? 다른 점이 있다면 디자이너와 디자인 프로세스에 어떤 영향을 미치는가?

지난 몇 년간 내가 경험한 점들을 B2B 팀에 입사하려고 하거나 이미 일하고 있는 사람들에게 공유한다.

기업용 애플리케이션이란 무엇인가?

위키피디아는 다음과 같이 정의하고 있다.

An enterprise application is a computer software used to satisfy the needs of an organization rather than those of individual users.
기업용 애플리케이션은 개인 사용자보다 조직의 니즈를 충족시키기 위한 컴퓨터 소프트웨어이다.

오늘날의 기업 환경에서, 대부분의 B2B 프로덕트는 복잡하고, 확장성 있고, 분산되어있고, 컴포넌트 중심이고, 중요한 미션을 가지고 있다. 기업용 애플리케이션은 비즈니스 프로세스를 지원하거나 자동화하기 위해 복잡하고 많은 양의 데이터를 적재하고, 가공하고, 제공하는 데 의의가 있다.

기업용 툴은 조직과 그 구성원들이 더 잘 일할 수 있도록 하는 프로덕트를 만드는 것이다.

메모: ‘기업용’과 ‘B2B’ 용어 정의에서 약간의 차이가 있긴 하다. 하지만 오늘날의 소프트웨어 환경에서 이러한 차이점은 중요하지 않으며, 이 글의 목적에 따라 둘을 동일한 의미를 가집니다.

B2B 프로덕트 디자인은 B2C 프로덕트를 디자인하는 것과 어떻게 다를까?

B2B 프로덕트 디자인은 생각만큼 많이 다르지는 않다. 모든 좋은 디자인을 위한 원칙이 동일하게 적용된다. 하지만 B2C 프로덕트를 디자인하는 것과 B2B 프로덕트를 디자인 하는 것에 약간의 다름이 있다.

시장에 내놓을 자동차를 만드는 것과 상업용 비행정을 만드는 것을 생각해보자. 둘 다 A에서 B로 사람들을 이동시킬 고도의 엔지니어링 디자인이 접목되지만 사용 방법, 제조에 소요되는 시간, 테스팅 & 안전 기준, 사용자들의 기대, 구매 & 소유와 같이 디자인과 프로세스에 영향을 주는 모든것에 명확한 차이가 있다.

마찬가지로 B2B 앱의 경우 앱이 목표로 하는 고유한 문제와 그 접근 방식에 항상 차이가 있습니다.

직면하게 되는 문제:

알림: 이런 문제 중 몇몇은 어떤 종류의 소프트웨어를 디자인하든 동일하게 직면하는 문제들도 있지만, B2B 프로덕트 디자인에서는 훨씬 차별적으로 나타납니다.

1. 기능적 복잡도 😓

B2B 앱은 여러 데이터 상태, 시각화 옵션, 관리 작업, 여러 사용자의 협업, 다른 소프트웨어와 연동과 같이 셀 수 없는 요소가 있기 때문에 복잡도 규모는 보통 B2C 앱보다 더 크다. 하나의 요구사항을 만족시키기 위한 모든 디자인 의사결정이 다른 여러 요구사항에 영향을 미치고, 종종 어떤 임팩트가 있을지 예상하기까지 어렵다. 겉보기에 간단해 보이는 기능을 추가하는데 온갖 종류의 엣지 케이스를 확인해야 하는 과정을 거쳐야만 한다.

💪 해결하는 방법:

복잡성을 해결하는 방법은 뭘까? — 답은 당연히 단순성이다. 인터페이스의 단순성을 최근(*2018년) 유행하는 미니멀 UI와 혼동하지 말라. 여기서 말하는 단순성은 적절한 계획과 프로세스를 통해 구현된 것을 말한다. 프로덕트 사이클이 얼마나 타이트하든 ‘디자인씽킹’하는 것과 디자인을 시작하기 전에 우리가 수집한 일련의 요구사항과 기능 명세들을 정리하는데 시간을 투자하는 것이 중요하다. 사실 이 과정은 디자인의 대부분이라고 할 수 있다.

당신이 떠올린 해결책이 확실하다고 생각할 때면 곧바로 스케치, 피그마, 포토샵을 켜고 싶은 것은 아주 자연스러운 경향이지만 실은 너무 이른 경우가 대부분이다. 전체적인 컨텍스트와 발견 점을 정리하고 내가 어떤 것을 디자인할지에 대해 정리할 수 있는 시간을 갖는것이 중요하다. 리서치와 계획하는 단계를 거치고, 모든 가능성을 발견하고 모든 엣지 케이스를 다뤄야 한다. 마침내 준비되었을 때 인터페이스를 다듬기 시작하자.

"나에게 만약 나무를 자를 6시간이 주어진다면, 나는 첫 4시간을 도끼를 날카롭게 가는데 쓰겠다."
— 격언

적절한 계획과 작업 과정을 거치게 되면 장기적으로 보상받을 것이며, 결국 논리적이고 버그 없는 프로덕트 경험을 이끌어낼 것이다.

1. 근로자(실사용자) 마인드셋을 위해 디자인하기 💼

B2B 프로덕트 사용자의 마인드셋과 행동 양식은 일상적인 B2C 사용자와 매우 다르다. 기업 사용자들은 일반적으로 그들의 일을 효율적으로 완료하는 것 이외에도 그들의 커리어 성장, 배움, 조직에서의 성공과 같은 다른 목표가 있다. 프로페셔널 근로자들을 위해 디자인 하는 것은 그들의 업무 컨텍스트, 워크플로우, 환경, 소명, 문제와 그들이 사용하고 있는 현재 솔루션에 대해 잘 이해하는 것이 필요하다.

✌️ 최고로 잘 할 수 있는 방법:

B2B 프로덕트는 프로덕트 자체에 대한 사용자의 니즈를 넘어 그들의 직업과 커리어에 대한 이해가 아주 중요하다. 최종 사용자와 직접 대화하고, 그들의 도메인을 조사하고 그들의 현재 방식을 체험해보는 것은 사용자에 대한 공감을 발전시키는 데 유용하다.

또한 사용자들은 종종 현재 워크플로우와 루틴에 익숙해져 있어서 그들이 진짜로 원하는 것이 무엇인지 상상하기 힘들어한다. 그들이 말하는 기능과 옵션들은 프로덕트 혁신으로 향하는 길을 밝혀줄 수 없는 것을 말하는 것일 수도 있다.

B2B 프로덕트 팀을 위한 가이드 원칙은 고객들이 현재 어떤 부분에서 난관을 겪고 있는지 알고, 이 이슈들을 해결하는데 미래에 프로덕트가 무엇을 해야 할지 길을 그리는 것이다. 사용자의 장기적인 목표를 알고 난 다음 디자이너들이 할 수 있는 일이 많아진다.

사람들은 더 나은 자신이 되기 위해 프로덕트를 구매한다 — JTBD (https://jtbd.info/)
(*Jobs To Be Done)

사용자들이 자신이 원하는 것이 뭔지 말하는 것에 집중하지 말고, 그들이 어떻게 행동하는지에 집중하고 그 포인트에서 혁신을 끌어내야 한다. 아이디어를 린하게 프로토타입으로 만들어 사용자에게 테스트 해야 한다.

3. 높은 전환 비용을 인지하기 😟

종종 기업 사용자들은 지금 가지고 있는 워크플로우에 너무 익숙하고 만족하고 있어서 다른 프로덕트로 변경해야 할 니즈를 전혀 느끼지 못하기도 한다. 심지어 다른 프로덕트로 변경하고자 할 때도, 여러 사람의 동의와 합의가 필요하기까지 한다. 당연히 현존하는 데이터를 마이그레이션 하는 것은 회사와 근로자 모두에게 불편사항이기도 하다. 일반적인 소비자 앱과는 달리, B2B 프로덕트를 변경하기 위한 전환 비용은 상당히 높다.

😳 관리하는 방법:

기업에게 프로덕트를 변경하라고 설득하는 방법에는 크게 2가지가 있다.

1. 경쟁 프로덕트보다 기능적으로 훨씬 더 나아야 한다
2. 현재 워크플로우를 재정의해서 사용자에게 현재보다 훨씬 더 빠르고/낫고/효율적이고/매력적이게 한다

두 번째 방법에서 디자인이 진가를 발휘할 수 있다. 생산성, 워크플로우, 프로세스는 조직에게 굉장히 중요한 요소이다. 그들의 현재 솔루션을 잘 살펴보고, 어느 부분에서 그들이 난관을 겪고 있는지 확인해보자. 더 빠른 워크플로우, 더 높은 효율성, 더 낮은 비용을 실현할 수 있는 요소를 찾아보자. 이런 면들에서 혁신이 있다면 기업들이 점프하도록 설득할 수 있는 해결책으로 이어질 수 있다.

사람의 행동을 변화시키는 것만이 혁신을 측정하기 위한 가장 최고, 유일, 진정하고 직접적인 방법이다.
— Stewart Butterfield, Slack의 공동창업자

현재 접근방식을 더 효율적으로 바꿀 기회를 항상 찾아야 한다.

4. 새로운 기능과 가능성을 만드는 것을 우선순위로 두기 😤

B2B 프로덕트는 기존 사용자 경험을 강화하는 것 보다 새로운 기능을 만드는 것이 거의 모든 순간에서 우선한다. 프로덕트가 첫선을 보이는 시기엔 디자인 스프린트를 열성적으로 가져가는 것이 일반적이지만, 프로덕트가 출시된 후에는 기능을 계속해서 추가해야만 한다. 유료 고객들은 새로운 가능성과 추가 기능을 계속해서 요구할 것이다. 프로덕트 팀은 앞에 놓여있는 바쁜 로드맵을 미리 계획합니다. 이 시점에서는 디자이너가 업무 관계자들에게 UX와 디자인을 개선하는데 시간을 투자하자고 설득하는 것이 특히 더 힘들 수 있다.

😳 해결하는 방법:

주어진 상황을 업무 관계자들의 입장에서 그려보라. 그들은 어느 스프린트, 어느 주나 어느 월에서든 새로운 기능을 개발하거나 가능성을 추가하지 않는 것은 잠재적인 수익을 어느 정도 잃는 것과 같다고 생각한다. 따라서 사람들에게 UX나 디자인 개선이 가지는 힘이나, 개선했을 때 기능을 추가함으로써 가져올 수 있는 수익보다 더 큰 임팩트를 줄 수 있음을 이해시키는 게 중요하다. 성공 사례를 이야기하고, 상위 의사결정자에게 직접 이야기해서 그들의 마음을 이끌어내라. 개선사항을 디자인 하는 것은 항상 페인 포인트를 주의 깊게 분석하고, 아이디어를 실험해야 하므로 시간과 혁신이 필요할 것이다.

또, 현존하는 프로덕트를 개선하는 것은 성장하는 회사에 아주 중요하기 때문에 훈련 삼아 한 번씩 자신의 프로덕트나 경쟁 프로덕트가 없다고 생각하고 완전 처음부터 솔루션을 브레인스토밍 하는 것을 추천한다. 이렇게 한다면 즐거운 놀라움을 경험하게 될 것이다.

"전구는 촛불의 지속적인 개선에서 나온 것이 아니다."
— Oren Harari

회사를 설득한 다음엔 시간을 정한 스프린트에서 작은 성공을 경험하는 것으로 시작하고, 그 성공의 임팩트를 항상 측정하자. 회사가 디자인에 믿음을 서서히 가지도록 만들어서 점점 더 큰 개선과 실험으로 나아가라.

프로덕트 팀과 엔지니어링 팀이 좋은 UX를 구현할 수 있도록 헌신해달라고 부탁하고, 이게 디자인 팀만의 일이 아님을 알려주자.

5. UX 일관성을 유지하기 😊

최근(*2018년) 3,000개 이상 기업의 디자이너를 대상으로 한 설문조사에서 디자인 팀이 가장 직면하고 있는 가장 큰 문제는 UX 일관성이었다. 일반적인 소비자용 프로덕트와 다르게, B2B 프로덕트는 더 긴 프로덕트 사이클을 가지고 있고 여러 팀으로 나누어져서 병렬적으로 실행되는 경우가 많다.

모든 디자이너들은 다른 팀들과 똑같이 프로덕트의 컴포넌트, 디자인 패턴, 심지어 컬러와 같은 디테일을 변경할 때 일관성을 유지하지 못하는 문제에 직면하고 있다. 이런 문제점은 팀 사이즈가 크거나 프로덕트가 확장하게 될 때 곱절이 되어버린다.

💪 해결하는 방법:

많은 회사가 장기적인 일관성과 확장성을 위해 디자인 시스템을 만들게 된다. 디자인 시스템은 명확한 기준으로 가이드 된 재사용 가능한 컴포넌트의 집합이고, 조합을 통해 여러 종류의 애플리케이션을 만들 수 있다. 디자인 시스템은 보통 다음을 포함한다:

1. 가이드라인 (디자인 원칙, 코드 컨벤션, 편집 가이드라인 등)
2. 비주얼 애셋 (컬러 팔레트, 타이포그래피 스케일, 아이콘 등)
3. UI 패턴 (폼, 버튼 스타일, 페이지 패턴 등)
4. 사용과 유지보수를 위한 포인트들

B2B 프로덕트 팀들에게 디자인 시스템이 있는지 물어보았을 때, 55% 정도는 가지고 있거나 만들고 있는 중이라고 답변했다(*2018년 기준!). 이것은 긍정적인 신호이다. 한 가지 알아두어야 할 점은 디자인 시스템을 100% 끝내는 순간은 없다는 것이다. 장기적으로 만들어나가야 하는 것이고, 시간이 지나면서 진화해 나가는 것이다.

"각 요소의 디자인은 제작하기 쉬워야 하고, 고치기도 쉬워야 한다."
— Leo Fender

디자인 시스템은 일관성 있는 UX를 만들기 위한 큰 발걸음이다.

영감을 얻을 수 있는 B2B 프로덕트 디자인 시스템의 예시: Salesforce의 Lightning Design System, Intuit의 Quickbooks(구 Harmony Design System)

*역자 주. 역자가 추천하는 공개된 디자인 시스템의 예시도 추가합니다:

Segment의 Evergreen, Atlassian의 Design System, Elastic Search의 Elastic UI, IBM의 Design Language, Google의 Material Design, SendGrid의 StyleGuide, Zendesk의 Garden, Microsoft의 Fluent, Mixpanel의 Design System

6. 모든 디자이너가 B2B 프로덕트를 좋아하진 않는다 😢

B2B 프로덕트를 위해 일해본 디자이너 중 이 일이 지루하다고 생각하는 사람이 많다. 에이전시나 B2C 백그라운드를 가진 사람들은 B2B에서 일하는 것이 다양성이 부족하고 흥분되지 않는다고 생각하기도 한다. 우리가 dribbble에서 침 흘리며 보는 멋진 마이크로 인터랙션 비주얼과 애니메이션을 만들 기회는 잘 오지 않는다. 이런 경우 업무는 늘어지게 되고 디자이너들은 뭔가가 빠진 것처럼 동기부여가 되지 않게 된다

😳 방지하는 방법:

B2B 프로덕트 디자인은 고객들의 과업을 해결해주어 그들이 직장에서 더 나은 삶을 살 수 있도록 돕는 데 있다. (위험하지만 않다면) 사용자를 홀릴 수 있는 UI를 만드는 것은 언제나 우선순위 리스트 중 가장 하단에 있을 것이다. 보는 즉시 직관적으로 어떻게 작동할지 알 수 있는 표준화되고, 예측 가능한 사용자 인터페이스가 타겟 고객들에게 가장 좋은 UI이다.

우리의 목표는 사용자들에게서 “와우!” 를 받는것이지만 — 프로덕트가 그들의 일을 얼마나 효율적으로 돕는지로부터 와야 하지, 아름다운 UI로부터 와야 하는것이 아니다

B2B 디자인 팀을 구성할 때 목표와 동기가 일치하는 디자이너를 선택하는 것은 중요하다. 동기라 함은 복잡한 문제를 풀고, 자신의 디자인이 사용자의 일을 완료하는데 어떻게 도움이 되는지 보는 것에서 와야 한다.

따라서, 팀에 들어올 모든 디자이너들에게 이후 일어날 일들을 예상하게 하고 올바른 기대치를 설정하는 것이 중요하다.

B2B 디자인에 입문할 때 필요한 일반적인 조언 몇 가지

B2B는 진화하고 있다. B2B 프로덕트는 더이상 삐걱거리고 지겨운 것이 아니다. 오늘날 사용자들은 일반적인 B2C 앱에서 경험한 퍼포먼스와 경험을 원한다. 그들은 아름다운 UI를 즐기며, 첫 시작 전에 문서를 읽어야만 하는 것을 싫어한다. 차세대 기술인 VR, AI와 음성 인터페이스는 이미 우리의 일상 생활에 들어왔으며, 얼마 지나지 않아 우리의 업무 생활에도 들어올 것이다. B2B 프로덕트에게는 흥분되는 시기이며 디자이너들이 할 수 있는 일은 끝없이 있다.

당신에게 도움이 될 3가지 가이드:

1. 유연함과 모듈화를 받아들여라. 디자인할 모든 것이 진화하고 성장할 것으로 생각해야 한다. 현재의 니즈에 딱 알맞은 컴포넌트를 만들려고 하지 말고 미래의 니즈도 반영할 수 있도록 유연하고 확장성 있게 만드는데 중점을 두어야한다.
2. 규칙과 프로세스를 정립하라. 훌륭한 협업, 탄탄한 사용자 리서치, 액션 가능한 문제 정의, 집중된 디자인 이터레이션들은 한 번씩 달성할 순 있지만 매번 모든 것을 달성하기란 어려운 일이다. 효율적인 방법은 반복 가능한 프로세스를 만들고 매 사이클마다 조금씩 개선해나가는 것이다.
3. 전체를 생각하라. 당신의 디자인과 추가되는 기능들이 프로덕트 전반과 회사의 비전에 어떤 영향을 주는지에 대해 항상 인지하고 있어야 한다. 당신이 만들고, 추가하고, 개선하는 모든 것에 전체적인 관점으로 접근한다면 결국 논리적이고 일관된 프로덕트 경험으로 이어지게 될 것이다.

B2B 디자이너들의 모임 소개

B2B 프로덕트를 만들고있는 B2B 디자이너들은 B2C 디자이너보다 더 어려운 문제를 풀고 있는 경우가 많은데 비해 자료, 지식, 피드백을 찾는데도 어려움을 겪고 있습니다.

더 많은 B2B 프로덕트 디자이너들이 한 자리에서 어려운 점, 배운 점을 공유하고 서로 도움이 되기 위해 커뮤니티를 운영중입니다.

🔗 B2B 디자이너들의 모임 노션 바로가기

🔗 이 글은 Claudia Delago가 본인의 미디엄 블로그에 올린 아티클을 번역, 요약한 글입니다.

프로덕트 관리를 위해 프로덕트 선행 지표는 반드시 필요합니다. 이 때 프로덕트 지표는 모든 것을 측정하려 해서는 안되고, 프로덕트를 더 나은 방향으로 만들기 위한 의사결정이나 액션을 할 수 있는 지표 중에서 선택해야 합니다.

AARRR, HEART, 북극성 지표 세 종류를 적절히 혼합해 프로덕트 지표의 예시를 만들고 이에 대해 설명 합니다. 아래는 사용자의 각 단계 별 성공을 측정하기 위해 만든 프로덕트 지표의 예시입니다.

본인의 프로덕트에 맞는 지표를 설정하는 것은 정해져 있는것이 아니라 항상 변화해야 합니다. 아래 예시에서도 본인의 프로덕트와 잘 맞는 부분은 프로덕트 별로 다 다를 것입니다. 프로덕트 지표를 선택하는 것은 가장 임팩트가 큰 것부터 집중하되, 필요하다면 각 단계를 더 심층적으로 들어가 살필 수도 있습니다. 프로덕트 지표를 선정하는 것은 프로덕트가 사용자의 어떤 단계와 상호작용 하는지, 프로덕트의 비즈니스 목표가 어떤지, 처음 수집하고 있던 데이터 셋에서 더 변화해나갈 부분은 있는지 등을 고려해서 계속해서 반복 개선해야 합니다.

• 획득(Acquisition)
  • 획득률 (Acqusition Rate)
  • 소스 별 획득률 (Acquisition by Source)
• 활성화/참여 (Activation/Adoption)
  • 활성화 비율 (Activation Rate)
  • 사용률 (Adoption Rate)
  • 최초 사용률 (First Time Rate)
  • 최초 사용까지 소요된 시간 (Time to First Action)
• 참여 (Engagement)
  • 활성 사용자 (Active User)
  • 행동 다 사용자 수 (Users per Action)
  • 사용자 별 행동 수 (Actions per User)
  • 행동 간 걸린 시간 (Time Between Actions)
• 작업 완료 (Task Success)
  • 성공률 (Success Rate)
  • 행동에 걸린 시간 (Time on Action)
  • 낭비 (Lostness)
• 행복감 (Hapiness)
  • 추천율 (Referral Rate)
  • 만족률 (Satisfaction Rate)
  • 만족 점수 (Satisfaction Score)
• 리텐션 (Retention)
  • 리텐션율 (Retention Rate)
    • 리텐션율을 볼 수도 있고, 반대 개념인 이탈율을 볼 수도 있다
  • 사용 시간 (Retained Time)
  • 업그레이드율 (Upgrade Rate)
• 수익
  • 사용자 당 수익 (Revenue per User)

Intro

‘지표’가 들어오고 나서부터 프로덕트 관리는 근본적으로 바뀌어버렸다.

프로덕트 지표가 있기 이전에는 우린 눈을 가린채로 사격하고 있는것과 다름 없었다. 우리는 그저 경기가 끝나고 사격 결과가 어떤지 정도만 이해했을 뿐이다. 피드백과 학습의 루프는 너무나도 오래 걸렸다.

최초 우리는 비즈니스 지표에 주로 의존하고 있었다. 예를 들어 ‘수익’ 이라는 지표를 생각 해보자. 수익은 후행 지표이다. 사용자 인게이지먼트의 감소가 수익에 반영되어 수익이 줄어들기 까지는 몇 달이 걸릴 수도 있다. 하지만 수익은 우리의 유일한 가시적인 지표였기 때문에 우리는 수익이 줄어든 후에나 반응할 수 밖에 없었다.

그 후로, 연결된 디바이스들은 전례없이 많은 데이터들을 쏟아내기 시작했고, 분석 툴에도 가시적인 개선이 있었다. 그 결과로 프로덕트 지표가 빠르게 확립되었다. 이제 우리는 거시적인 관점에서 사용자 행동을 이해할 수 있고 사용자 인게이지먼트가 감소하기 수 개월 전에 미리 대응할 수도 있다. 이제 우리는 사격의 결과를 바로 알 수 있게 되어서 즉시 그 결과에 적응할 수 있게 되었다.

프로덕트 지표는 프로덕트의 진행률을 측정하고 결과 지향적인 방식으로 얼라인을 맞출 수 있게 한다. 프로덕트 지표는 우리가 Data Informed, Data Inspired 되도록 하였고 실험을 하고자 하는 의욕을 고취시켰다. 이제 프로덕트 지표를 쓰지 않는다면 뒤쳐지게 되었다. 프로덕트 지표를 쓰지 않으면 사용자에 대해 이해도 덜 할 것이고, 불필요한 리스크도 지게 될 것이고, 똑똑하게 보단 열심히 일하게 될 것이고, 우리가 한 일이 발생시킬 효과에 대해서도 이해하기 힘들어질 것이다.

이제는 프로덕트 지표 없이는 살 수 없는 몸이 되었다..

무엇을 측정할 것인가?

이제 우리는 이벤트(우리 프로덕트에서 수행한 행동)를 트래킹 하고 프로퍼티(이벤트나 사용자에 관한 추가적인 정보)를 수집함으로써 우리의 사용자가 어떤 행동을 하는지 너무나도 쉽게 알 수 있게 되었다. 이 상황에서 드는 첫 번째 생각은 모든 것을 측정하자! 일 것이다. 이를 위해 아마 대시보드도 만들 것이고, 대시보드에는 숫자가 반짝이고 있을 것이다. 우리는 해냈고, 이정도로 밀도 있는 데이터를 다루고 있는 것에 나는 굉장히 중요한 일을 하고 있다고 생각하게 될 것이다.

하지만, 우리가 할 일은 모든 것을 측정하는게 아니다. 우리가 해야할 일은 우리의 프로덕트를 더 나은 방향으로 만드는 것이다. 비즈니스적으로 실행 가능한 방식으로 우리 고객들에게 어떤 가치를 창출하는 것이다. 모든 프로덕트 지표 대시보드는 이를 실행하게 할 내부 도구일 뿐이다. 우리는 우리와, 우리와 함께 일하는 모든 사람들이 더 쉽고 더 가치있는 방식으로 이용할 수 있도록 만들어야 한다. 만약 우리가 모든 것에 대해 보고하기 시작하면, 모든 것이 노이즈가 될 뿐이다.

이 때문에 우리는 KPI(Key Performance Indicators), KEI(Key Experience Indicators)와 같이 주요 지표를 정의할 필요가 있다. 이 숫자들은 허영심이 만들어낸 숫자가 아니라, 우리가 의사결정하고 액션하는데 도움을 주는 작은 데이터 셋이다.

측정해야 하는 주요 항목들이 어떤 것들이 있는지 알려주는 여러 프레임워크들이 있다. 그 중에서 내가 가장 좋아하는 것들을 요약해보았다.

☠️ 해적 지표 혹은 해적 언어로는 AARRR. 이 프레임워크는 제품 단계를 각 사용자 라이프사이클에 따라 측정하는 방식을 제안한다.

❤️ HEART. 이 프레임워크는 사용자가 프로덕트와 어떻게 상호작용 하고 얼마나 만족하는지를 알아보기 위해 만들어졌다.

⭐️ 북극성 지표. 이 프레임워크는 좀 더 급진적이고, 모든 프로덕트 노이즈를 가장 중요한 지표를 위해 제거해야 한다고 본다. 이 때 가장 중요한 지표는 장기적인 비즈니스 결과와 사용자에게 제공되는 핵심 가치의 관계를 가장 잘 나타내는 선행 지표를 말한다. 하지만 이 프레임워크도 북극성 지표에 가장 직접적인 영향을 주는 3에서 5개 보완적 지표를 포함하고 있다.

측정해야 하는 주요 항목은 프로덕트에 따라 다르다. 그럼에도 불구하고, 우리는 이 세가지 프레임워크나 다른 적절하다고 생각되는 프레임워크에서 발견한 인사이트를 사용할 수 있다(그리고 사용 해야한다).

더 자세히 보기

더 자세히 보기 위해, 나는 일반적인 프로덕트가 가질법 한 표준 지표를 몇 가지 작성해보았다. ☠️ 해적 지표와 ❤️ HEART 지표가 말하는 영역을 늘어놓고, 여기서 주요한 항목들을 ⭐️ 북극성과 같이 트리 구조에 배치해보았다. 여기서 어떤 지표들은 다른 지표들보다 더 잘 발견될 수 있는데, 좋은 현상이다. 분석 대시보드는 가장 임팩트가 큰 것부터 집중하되, 필요할 때는 더 심층적으로 들어갈 수 있다.

그럼 각 지표들을 더 심층적으로 살펴보도록 하자.

Acquisition (획득)

획득 단계가 성공적인지 트래킹하기 위해 우리는 새로운 사용자들이 누구인지와 그들이 어떻게 프로덕트를 발견했는지에 대한 지표가 필요하다. 프로덕트 관리 관점에서 획득 지표는 우리가 마케팅 팀과 얼마나 잘 커뮤니케이션 하는지와 우리의 프로덕트가 타겟 사용자들에게 설득력 있는지를 알려준다.

• 획득률은 신규 사용자가 기존 사용자 대비한 양을 의미한다
• 소스 별 획득은 신규 사용자 유치를 위한 각 소스 별 마케팅 전략의 효과를 측정한다

Activation / Adoption (활성화 / 사용)

활성화와 사용 단계가 성공적인지 트래킹하기 위해 우리는 사용자가 프로덕트나 특정 기능과 얼마나 빨리 상호작용을 시작하는지 알려주는 지표가 필요하다. 여기에서는 신규 사용자에만 집중해야 한다(참여(Engagement) 단계와 반대).

이러한 지표들은 우리가 만든 것이 성공할 수 있을지를 파악하는데 많은 도움이 된다. 사람들이 처음 시도해보는 어떤 것을 빠르게 시도해 본다는 것은 그것이 해결하려고 하는 문제에 대해 신경쓰고 있다는 의미인 것이다.

• 활성화 비율은 가입한 사용자 중 얼마나 많은 사용자가 상호작용을 시작했는지를 측정하고 이를 활성 사용자로 변환해서 측정할 수 있다.
  ⚠️ 이 때 우리는 상호작용을 시작한다는 것이 어떤 것인지를 정의해야 한다. 이 경우, 핵심 행동을 처음으로 시작하는 때 혹은 어떤 여러 행동을 연속적으로 수행할 때를 의미한다. 하지만 프로덕트의 성질에 맞게 각자가 정의해야 하는 부분이다.
• 사용률은 얼마나 많은 사용자가 특정 행동을 하거나 어떤 기능과 상호작용 하는지를 측정한다.
• 최초 사용률은 얼마나 많은 사용자가 처음으로 특정 행동을 하거나 어떤 기능과 상호작용을 하는지 이해하는 것이다.
• 최초 사용까지 소요된 시간은 사용자들이 얼마나 빠른 시간 내에 특정 행동을 하거나 어떤 기능과 상호작용을 하는지를 아는 것이다.

Engagmenet(참여)

참여 단계가 성공적인지 트래킹 하기 위해 우리는 사용자가 프로덕트나 어떤 기능과 얼마나 자주 상호작용 하는지를 알려주는 지표가 필요하다. 이런 지표는 편파적이지 않아야 하고 사용자의 행동에 관한 내용이어야 하며 따라서 믿을 수 있고, 유효해야 한다.

참여 단계에서는 전체를 아우르는 것을 측정하는 것 보다 구체적인 것을 측정하는 것이 필요하다. 또 모든 것을 측정할 수 없으므로, 중요한 것 부터 측정해야 한다. 특정 경험을 선택할 때, 우리는 핵심이 무엇인지를 생각해야 한다. 사용자가 우리 프로덕트를 왜 사용하는지, 그리고 어떤 사용자의 행동이 우리 프로덕트를 사용하는 핵심 행동이라고 할 수 있는지 생각해야 한다. 아마존의 경우 구매 행동이, 에어비엔비의 경우 예약 행동이, 왓츠앱의 경우 메세지를 보내는 행동이 핵심 행동이다.

⭐ 사용자가 핵심 행동에 참여하는것은 비즈니스적으로 매우 중요하기 때문에 대부분의 프로덕트 관리 팀에서 북극성 지표와 연관관계를 찾는다. 사용자가 프로덕트와 더 많이 상호작용 할 수록, 그들이 리텐션될 확률이 높고, 이는 곧 수익을 낼 확률이 더 높은 것으로 이어진다. 모든 게임에서 선행 지표이다. 사용자들이 행동하지 않으면 모든 것이 무너지기 마련이다.

• 활성 사용자(Active Users)는 프로덕트 내에서 얼마나 많은 사용자가 활성 상태였는지를 의미한다. ⚠️ 이 때 우리는 활성 상태가 어떤 것인지를 정의해야 한다. 이 경우, 핵심 행동을 한번 이상 수행한 것을 의미한다. 하지만 프로덕트의 성질에 맞게 각자가 정의해야 하는 부분이다.
• 행동 당 사용자 수(Users per Action)는 얼마나 많은 사용자가 특정 기능을 사용하거나 특정 행동을 수행하는지를 의미한다.
  ℹ️ 위에서 핵심 행동을 수행한 활성 사용자 수를 활성 사용자라고 가정했기 때문에, 핵심 행동 당 사용자 수는 프로덕트 전체의 활성 사용자 수와 동일할 것이다.
• 사용자 별 행동 수(Actions per User)와 행동 간 걸린 시간(Time Between Actions)은 사용자가 어떤 행동을 얼마나 자주 하는지와 그 사용 행동에 걸리는 시간을 측정하는 것이다.

Task Success(작업 완료)

작업 혹은 행동이 성공적인지 트래킹 하기 위해, 우리는 사용자가 해당 행동을 하기가 얼마나 용이한지를 알 수 있는 지표가 필요하다. 바로 사용성이다.

• 성공률(Success Rate)은 의도한 최종 상태에 도달하기까지 걸린 행동의 수를 측정한다. 이를 통해 효과를 측정할 수 있다.
• 행동에 걸린 시간(Time on Action)과 낭비(Lostness)는 행동을 얼마나 빠르게 수행할 수 있는지를 알고, 사용자가 행동을 수행하다 길을 잃었는지에 대해 이해할 수 있다. 이를 통해 효율을 측정할 수 있다.
  ⚠️ 사용자가 어떤 행동을 할 때 우리는 그들이 어떤 생각으로 행동하는지 알 수 없기 때문에 이런 지표들의 숫자만으로는 인사이트를 얻기 힘들다. 예를 들어 행동에 걸린 시간이 길었을 때, 사용자는 화장실에 다녀왔거나 전화를 하고 왔을수도 있다. 그럼에도 불구하고 우리는 이 수치들이 갑자기 나빠졌을 때는 문제를 파악해야 할 타이밍임을 알 수 있고, 이 수치들이 좋아졌을 때 개선 사항들이 효과가 있었는지를 알 수 있다.
  💡 좀 더 정확성을 확보하기 위해, 우리가 사용자에게 과제를 제공해 동기를 유도할 수 있는 환경을 만들어볼 수 있다. 이를 통해 우리는 사용자가 어떤 동기로 행동하는지 미리 알 수 있다.

Happiness(행복감)

사용자들의 행복감을 측정하려면, 우리는 추천(Referral)과 만족도(Satisfaction)을 확인할 수 있다. 추천을 트래킹 하기 위해서는 사용자가 프로덕트를 얼마나 자주 추천하는지 알려주는 지표가 필요하다. 만족도를 측정하기 위해서는 사용자가 얼마나 만족하는지(ㅋㅋㅋ) 알려주는 지표가 필요하다.

이런 지표들은 측정하기 흥미로우면서도 까다로운 지표이다. 이 지표들은 사용자가 스스로 알릴 수 밖에 없으며, 감정과 편견이 끼어들 수 있다. 하지만 행동 지표와 결합한다면 유의미한 인사이트를 제공할 수 있다.

• 추천율(Referral Rate)은 사용자가 프로덕트를 추천할만큼 만족하는지를 알 수 있다. ⚠️ NPS(순 추천 고객 지수, Net Promoter Score)는 추천율을 측정하는 가장 잘 알려진 지표이다. “친구나 동료에게 이 프로덕트를 추천할 의향이 있습니까? 1-10 중에서 답변해주세요” 라고 물어보는 것인데, 이는 실제 행동을 측정하는게 아니라 의향을 측정하는것이기 때문에 이 지표를 사용하는 사람들은 많지 않다.
  💡 사용자와 의사소통하는 규칙 중 하나는 그들의 경험에 대해 물어보는 것이다. 우리는 NPS 질문 대신에 이렇게 물어볼 수 있다. “최근 2주 간 이 프로덕트를 누군가에게 추천한 적이 있습니까?” 이렇게. 더 나은 방법으로는 사용자에게 누군가에게 추천할 수 있는 아주 쉬운 방법을 제시하고, 얼마나 많은 사람들이 추천 행동을 수행하는지 트래킹 하는 방법이 있다.
• 만족률(Satisfaction Rate) 및 만족 점수(Satisfaction Score)는 얼마나 많은 사용자가 만족스럽다고 표현할 만큼 만족했는지와 대다수 사용자가 만족한 정도를 측정한다.
  ⚠️ 만족도를 측정할 때는 맥락을 고려해야 한다. 실험을 진행한 1주 이후에 설문을 수행한다면 사용자들의 인지가 이미 변질되었을 것이기 때문에 사용자들의 답변을 신뢰하기가 어려울 것이다.
  💡 화상 전화 서비스에서 품질에 대한 평가를 제공하는 것 같이 어떤 행동의 마지막 단계에 간단한 평가 시스템을 제공할 수도 있다.

Retention(리텐션)

리텐션 단계의 성공을 측정하기 위해, 프로덕트나 특정 기능을 사용자가 얼마나 오래 사용하는지에 대한 지표가 필요하다. 이 지표로 우리는 사용자들이 어떤 것을 중시하는지, 왜 사용자들이 떠나는지를 파악할 수 있다. 사용자의 리텐션은 매우 중요하다. 새로운 사용자를 유치하는 것 보다 기존 사용자를 유지시키는 것이 훨씬 더 쉽기 때문이다.

• 리텐션율(Retention Rate)은 얼마나 많은 사용자가 계속 프로덕트를 사용하는지를 측정한다. ⚠️ 프로덕트를 사용하는것이 어떤 의미인지 먼저 정의해야 한다. 예를 들어 로그인 하는것, 핵심 행동을 수행하는 것, 구독 상태를 유지하는 것 등이 있다. 하지만 프로덕트의 성질에 맞게 각자가 정의해야 하는 부분이다.
• 사용 시간(Retained Time)은 사용자가 우리 프로덕트를 얼마나 오래 사용하는지에 대한 시간이다. 우리는 이 시간을 늘리기 위해 노력해야 할 것이다.
• 업그레이드율(Upgrade Rate)은 프로덕트의 사용 티어가 나뉘어져 있을 때, 사용자가 언제 업그레이드를 결심하는지 그 시기를 파악하는 것이다.

ℹ️ 일부 팀은 리텐션(Retention) 대신에 이탈(Churn)을 측정한다. 최종적인 목표는 같지만 절반이 찬 물잔을 바라보는 관점과도 같다. 나의 경우는 물이 반 차있다고 보는 사람이다.

Revenue(수익)

수익은 사용자가 얼마나 지불하고 있는지, 혹은 우리 프로덕트로 얼마나 돈을 벌고 있는지를 나타낸다. 따라서 비즈니스가 지속 가능하고 건전한 상태를 유지하면서 기존 고객으로부터 수익을 증대시킬 수 있는 다양한 가격 전략을 테스트 해보는 것이 중요하다.

• 사용자 당 수익(Revenue per User)이 이것을 측정할 수 있는 방법이다. 이외에도 다른 지표들이 있지만, 비즈니스의 형태에 따라서 달라질 수 있다.

프로덕트 지표를 선택하는 것은 방향에 관한 것이 아니라, 여정이다. 프로덕트 지표는 프로덕트와 마찬가지로 반복적으로 변경되어야 한다. 우리는 작은 데이터 셋으로부터 시작해 우리가 측정해야 할 결과에 따라 조정해나가야 한다.

이 같은 프로덕트 지표가 없으면 우리는 결과 지향적일 수 없게 된다. 결과 지향적이지 못한다면, 우리는 진정한 의미에서 애자일할 수 없다. 마지막으로, 우리가 결과 지향적이지 못하고 애자일 하지 않는다면, 우리는 우리 프로덕트를 효율적이고 현대적인 방식으로 관리할 수 없게 된다.

프로덕트 관리는 프로덕트 지표가 들어오면서 영원히 바뀌어버렸고, 다시 돌아갈 방법은 없다.

긴 글을 여기까지 읽어줘서 고맙습니다. 만약 이 글이 좋았다면, 다음 (Cláudia Delgado의!) 글들도 읽어볼 만 할겁니다. 이 글보단 더 짧으니까 읽어보세요! 👉

How to Navigate the Abstract World of Outcomes

Learn to Earn: An Experimentation Guide

🔗 이 글은 Robert Turner가 본인의 미디엄 블로그에 올린 아티클을 번역, 요약한 글입니다.

⚡️ 요약

사용성을 정량적으로 평가하려고 하면 큰 결함이나 딜 브레이커가 되는 핵심 이유를 알려주긴 하지만, 정성적인 조사 방법으로는 제품 사용성에 대한 정성적인 지표로서 역할은 하지만 개선에 대한 방향은 알기 어렵다. 제품 개발자들에게 사용성에 대한 유의미한 인사이트를 위해서는 추가적인 컨텍스트가 필요하다.

사용성을 구성하는 5가지 차원은 다음과 같다.
- 학습 용이성
- 효율성
- 기억 용이성
- 오류 대처
- 만족도

디자인 휴리스틱(직관적 발견법)으로는 유명한 닐슨의 10가지 기준이 있다. 1. 시스템 상태의 가시성
2. 시스템과 실제 세계의 일치
3. 사용자 통제감과 자유도
4. 일관성과 표준화
5. 오류 방지
6. 회상보다는 인지
7. 사용 유연성과 효율성
8. 미적이며 미니멀한 디자인
9. 사용자가 오류를 인지하고, 진단하고, 복구할 수 있도록 지원
10. 도움말과 문서화

제품 사용성을 위해서는 ‘사용성을 구성하는 5가지 각 차원에 대해 10가지 디자인 휴리스틱이 잘 지켜지는지’를 제품 개발 초기 디자인부터 신경 쓰고, 자주 평가해야 한다.
평가는 정량적, 정성적인 방법을 모두 사용해 각 방법의 장단점을 취합해야 한다.
연구 결과에 대해서는 핵심 내용과 제안사항, 액션 아이템을 정리하는 것을 프로세스 화 하여 리서치 결과가 유의미하게 남을 수 있도록 해야 한다.

Intro

우리는 소비자로서 우리가 구매하려는 제품(예를 들어 자동차, 가전제품, 모바일 디바이스, 앱 등)이 궁극적으로 우리를 위해 어떻게 동작할지에 대한 기본적인 기대를 빠르고 명확하게 형성합니다. 보통 브랜드 평판, 고객 리뷰, 제품 데모 등 “유사 상호작용”을 통해 얻은 데이터를 기반으로 하는 기대는 우리의 쇼핑 행태부터 최종적인 구매 결정에까지 모든 것에 영향을 줍니다. 이러한 기대 중 가장 중요한 것은 그 제품이 어떤 것인지 충분히 알기 쉽고, 사용하기에 번거롭지 않다는 것입니다.

우리가 새로운 제품 사용을 시작하면, 그 디자인에 내재한 어떤 특징이 우리가 제품과 제조업체 모두에 대한 태도를 형성할 뿐만 아니라 제품을 계속 사용하는 정도나 방식을 결정합니다. 우리는 모두 직관적이지 않거나 반 직관적인 제품을 경험해봤고 이에 대해 비난한 적이 있을 것입니다. 하지만 제품을 사용하고 실제로 사용자 친화적으로 만드는 근본적인 특성에 대한 피드백(제품 개발자들에게는 필수적인 정보)을 표현하는 것은 조금 더 복잡합니다. 사용성 피드백과 제품 평가는 종종 ‘딜 브레이커’의 핵심 이유나 사용성의 큰 결함에 대한 개별 증상을 밝혀준다. 반대로, 전체적인 사용성 평가(예를 들어, ‘이 제품의 사용성에 대해 전반적으로 얼마나 만족하셨습니까?’와 같은 질문)는 제품의 전반적인 사용성에 대한 훌륭한 정성적인 지표를 제공하지만 섬세하게 진단하기엔 정보를 거의 제공하지 않습니다. 그 말인즉슨, 어떤 사람은 제품이 사용자 친화적이지 않다고 생각은 하지만, 그 이유나 어떻게 개선할 수 있는지는 전혀 모른다는 의미입니다. 검증되고 표준화된 평가 도구일지라도 개발자들에게 사용성에 대한 유의미한 인사이트를 제공하기 위해서는 추가적인 컨텍스트가 필요합니다.

다차원 구조인 사용성

우리는 일반적으로 제품의 사용성이 절대적인 지표라고 생각하지 않습니다. 어떤 제품도 100% 친화적이거나 100% 친화적이지 않습니다. 오히려 대부분의 제품은 사용성 스펙트럼에서 대체로 중-저 구간인 “meh” 정도에 위치한다. 이것은 사용성이 정량적으로 평가가 가능하고 측정가능하지만 1차원적인 구조가 아니기 때문입니다. 따라서 우리는 사용성을 하나로 취급하거나 측정해서는 안 됩니다. 연구진들은 사용성이 서로 다르지만 연관된 5가지 요소로 구성되어있다고 결론 내렸습니다.

• 학습 용이성: 사용자가 처음 제품을 사용할 때 기본적인 태스크(예: 보안 설정 변경하기)를 얼마나 쉽게 성공적으로 수행할 수 있는가?
• 효율성: 사용자가 제품이 어떻게 동작하는지 학습한 다음, 일상적인 작업을 얼마나 빠르게 수행할 수 있는가?
• 기억 용이성: 사용자가 제품을 사용하지 않다가 다시 돌아왔을 때 이전에 멈췄던 부분으로 쉽게 돌아올 수 있는가? 중단이나 일시적인 방해로 사용자가 처음부터 다시 시작해야 하는가?
• 오류 대처: 사용자가 얼마나 자주 실수를 하고, 그 실수는 얼마나 심각하고, 사용자가 얼마나 쉽게 그 실수를 정정하거나 복구할 수 있는가?
• 만족도: 사용자에게 제품이 전반적으로 얼마나 매력적이고 즐거움을 주는가?

이러한 요소들은 초기에 그리고 자주 고려되어야 하며, 과학적 자료와 표준에 맞게 제품에 의도적으로 디자인 되어야 하고, 효과를 보장하기 위해 제품 개발 전반에 걸쳐 엄격하게 테스트 되어야 합니다. 즉, 이러한 중요한 요인 중 하나를 무시하면 부적절한 제품 사용성이 초래됩니다. 만약 여러 요소를 무시한다면 제품 사용성은 더욱 악화할 것입니다. 반복적인 디자인 접근 방법으로 테스트를 일상적으로 수행하는 것이 최종 디자인에 들어가 결정돼버리기 전에 사용성 결함을 식별하고 수정할 수 있는 핵심 방법입니다.

디자인 휴리스틱 (직관적 발견법)

만약 인간과 시스템의 상호 작용에 대한 역학관계를 특정하는 과학적인 자료가 사람과 시스템의 인터페이스를 설계하고 검증하기 위한 진정한 “사용자 매뉴얼”을 구성한다면, Jakob Nielsen이 1994년에 발표한 디자인 휴리스틱은 시행착오를 거친 믿을만한 “퀵 가이드”를 대표합니다. 닐슨의 연구는 제품 개발자가 유저 인터페이스를 디자인할 때 고려해야 할 10가지 중요한 규칙으로 요약됩니다.

1. 시스템 상태의 가시성: 시스템은 사용자와 의사소통 하여 현재 시스템이 어떤 모드, 상황, 상태인지 계속해서 알려주어야 합니다. 눈에 띄는 지연이나 버벅임 없이 사용자의 인풋과 명령을 확인하고 이에 응답해야 합니다.

2. 시스템과 실제 세계의 일치: 시스템은 사용자가 친숙하게 생각하는 단어, 표현, 개념으로 대화해야 합니다. 실재하는 규칙을 적용하고, 실제 세계에서 나타나는 대로 일관된 방식으로 디지털 정보와 표현을 표시해야 합니다.

3. 사용자 통제감과 자유도: 사용자는 종종 의도하지 않은 기능이나 옵션을 선택하곤 하며, 이런 원하지 않는 시스템 상태에서 긴 다이얼로그나 프로세스 없이 즉각 “비상 탈출”할 수 있는 명확한 표시가 필요합니다. 되돌리기와 다시 실행을 지원해야 합니다.

4. 일관성과 표준화: 사용자는 인터페이스에 나타나는 다른 단어, 코드, 상황이나 액션이 동일한 의미인지 궁금해할 필요가 없어야 합니다. 적절한 네이밍 규칙을 정하고 준수해야 합니다.

5. 오류 방지: 어떤 좋은 에러 경고나 메세지보다도 에러가 나지 않도록 하는 디자인이 더 사려 깊은 디자인입니다. 에러를 발생시키기 쉬운 조건을 제거하거나 사용자가 액션을 수행하기 전에 직접 확인할 수 있는 옵션을 제공해야 합니다.

6. 회상보다는 인지: 오브젝트, 액션, 워크플로우를 잘 보이게 표시하여 사용자가 기억에 의존할 필요 없이도 다음 단계가 무엇인지 인지할 수 있도록 해야 합니다. 사용자들은 인터페이스의 한 부분에서 다른 부분으로 이동할 때나, 트레이닝이나 문서에서 뭔가를 기억할 필요가 없습니다. 핵심적인 정보(지침, 주의, 경고와 알림을 포함)는 확인될 때까지 표시되어야 하며 적절할 때마다 쉽게 찾을 수 있어야 합니다.

7. 사용 유연성과 효율성: 초보 사용자가 확인할 수 없는 단축키와 같은 가속 장치를 통해 숙련된 사용자의 인터랙션 속도를 높일 수 있어 시스템이 숙련 사용자와 비숙련 사용자 모두를 만족시킬 수 있습니다. 하지만, 이런 가속 장치가 모든 사용자에게 항시적으로 제공되는 경우 인터페이스를 복잡하게 하고 성능이 저하될 수 있습니다.

8. 미적이며 미니멀한 디자인: 인터페이스에는 연관 없거나 거의 불필요한 정보는 포함되어서는 안 됩니다. 모든 부차적인 정보들은 유의미한 정보와 경쟁하게 되어 가시성을 저해합니다.

9. 사용자가 오류를 인지하고, 진단하고, 복구할 수 있도록 지원: 오류 메세지는 일반적인 언어로 표현되어야 합니다 (코드나 사용자에게 익숙하지 않은 용어를 사용하지 않고). 문제의 성격을 명확하게 설명하고 건설적인 해결책에 관해 설명해야 합니다.

10. 도움말과 문서화: 이런 것들 없이도 시스템을 사용할 수 있는 것이 더 바람직하지만, 온보딩 지원이나 문서를 제공할 필요가 있을 수 있습니다. 이런 정보들은 찾기 쉽고 이동하기 쉬워야 하며, 사용자의 작업에 초점을 맞춰 수행할 단계들을 명확하게 제시해야 하며, 지나치게 방대해서는 안 됩니다.

그래서… 제품을 사용자 친화적으로 만드는 것은 (요약)

1. 사용성을 염두에 두고 디자인하라. 사용성은 이분법적이지 않고 다차원적이고 역동적인 구조로 되어 있다는 것을 인지해야 합니다. 전략적인 관점에서, 핵심 사용성 차원(학습 용이성, 효율성, 기억 용이성, 오류 대처, 만족도)에 주의를 기울여 제품 디자인의 처음부터 신중하게 통합되도록 해야 합니다. 전술적으로는 앞서 설명했던 각 차원에 대해 사용성 휴리스틱(오류 방지, 회상보단 인지 등)을 끌어올려 점진적으로 그리고 장기적으로 성공할 수 있도록 하세요. 자주 평가하고 필요에 따라 조정하세요.

2. 사용성을 염두에 두고 평가하라. ”사용성 측면에서 이 제품에 전반적으로 얼마나 만족하셨나요?”나 이와 같은 질문만으로 제품의 사용성을 판단하면 안 됩니다. 각 핵심 차원에서 제품이 얼마나 잘하고 있는지를 평가해 만약 부족한 부분이 발견된다면 해당 문제에 날카롭게 다듬을 수 있도록 하세요. 수많은 표준화되고 검증된 평가 방법(예: 시스템 사용성 척도 System Usability Scale, 사용자 인터페이스 만족도 설문 Questionnaire for User Interface Satisfaction, IBM 사후 시나리오 및 연구 후 시스템 사용성 질문 IBM After-Scenario and Post-Study System Usability Questionnaires 등)이 있습니다. 내가 뭘, 그리고 왜 하고 있는지 정확히 알지 못한다면 바퀴를 재발명하고 있을 필요가 없습니다.

3. 표준화된 사용성 질문을 넘어서라. 위에서 언급된 표준화된 기법들은 제품 사용성 전반 평가에 상당한 개선 진단을 제공할 수 있지만, 디자이너나 개발자가 실행 가능한 컨텍스트를 제공하는 데는 여전히 부족합니다. 만약 이런 기법들이 디지털로 이루어진다면, 낮게 평가된 부분의 원인에 대해 더 잘 이해하기 위해 하나 이상의 개방형 후속 질문(예: 설문 조사 플랫폼의 질문 로직 기능을 이용하는 등)을 활용하세요. 만약 기법을 직접 수행한다면, 참가자들의 답변을 함께 검토하거나 연구 내용을 알려주는 동안 낮은 평가를 받은 항목에 대해 임시 인터뷰를 빠르게 진행할 수 있도록 계획하세요.

4. 피드백을 디자이너나 개발자가 사용할 수 있도록 정제하라. 데이터 분석은 부담스럽고, 압도되고, 시간이 많이 소요될 수 있습니다. 의도한 대상에게 전달할 땐 항상 로우 데이터에서 핵심 정보, 피드백, 테마, 트렌드, 포인트와 제안사항을 뽑아 관리 가능한 수의 명확한 작업 아이템으로 간결하게 패키지화하세요. 이를 통해 중요한 리서치 결과가 무시되거나 사라질 가능성을 크게 줄일 수 있지만, 이 규칙은 사용성 엔지니어링 작업에서 가장 간과되고 지켜지지 않는 요소 중 하나입니다.

🔗 이 글은 Sandhya Hegde가 Amplitude Blog에 올린 아티클을 번역, 요약한 글입니다.

⚡️요약

• 북극성 지표는 프로덕트 팀이 목표로하는 고객의 문제와 비즈니스가 목표로하는 수익을 연결한다
• 북극성 지표는 회사 내 조직들의 목표와 전략을 하나로 일치시키는 역할을 한다
• 북극성 지표는 고객의 가치를 대변하는 프로덕트의 비전 과 고객의 가치를 측정할 수 있는 프로덕트 전략에 대한 선행 지표 로 나뉜다
• 북극성 지표는 트리로 만들 수 있는데,
  1. 북극성 지표를 넓이, 깊이, 빈도, 효율성 4가지 차원으로 구성하고
  2. 각각의 차원을 개선할 수 있는 KPI를 설정하고
  3. 각 KPI를 만족할 수 있는 전략을 구성하여 만들 수 있다
• 또 각 회사는 Attention, Transaction, Productivity 게임 중 하나에서 플레이하는데, 각 게임 종류와 프로덕트의 비즈니스 구조에 따라 가져야 할 북극성 지표를 어느정도 방향을 잡을 수 있다

Intro

프로덕트 북극성 지표는 오늘날 가장 강력하면서 사람들이 잘못 이해하고 있는 프로덕트 전략 프레임워크이다. 많은 프로덕트 팀이 북극성 지표를 수립하지 않거나 잘못 수립해 의도하지 않은 결과를 맞이하고 있다.

이 아티클은 북극성 지표에 대해 파고드는 시리즈 중 첫 번째다. 이 아티클이 프로덕트 리드와 매니저에게 이 지표가 왜 중요한지, 어떻게 정의하고 프로덕트 전략과 성장을 위해 어떻게 사용하는지 가이드가 되길 바란다. 이 아티클에서 다음에 대해 이야기한다:

• 북극성 지표는 무엇이며 왜 중요한가?
• 질문 1: 좋은 북극성 지표의 좋은 예
• 질문 2: 회사에서 북극성 지표는 하나만 가져야 하는가?
• 질문 3: 좋은 북극성 지표를 선택하는 방법
• 프로덕트 전략 운영에 북극성 지표를 사용하는 방법

북극성 지표는 무엇이며 왜 중요한가?

북극성 지표는 프로덕트 팀의 성공을 측정하는 지표이다. 북극성 지표는 프로덕트 팀이 풀고자 하는 고객의 문제와 비즈니스가 목표로하는 수익의 관계를 정의한다.

따라서 어떤 회사든 세 가지 중요한 목적을 가진다.

• 프로덕트 팀이 어떤 것에 최적화 하거나 무엇을 트레이드 오프할 지 명확하게(clarity)하고 조직 내에서 일치(alignment)시킨다
• 프로덕트 조직의 임팩트와 진행 과정을 회사의 다른 조직에 전달하여 프로덕트 전략 계획을 가속하고 더 많은 지원을 받을 수 있도록 한다
• 가장 중요한 것은, 프로덕트의 결과에 대해 책임을 질 수 있다는 것이다

많은 회사에서 프로덕트 팀은 비즈니스에서 얼마나 임팩트를 주고 있냐가 아닌, 그들이 얼마나 결과물을 전달하는지에 따라 평가받는다. 프로덕트에 임팩트 중심적인 문화가 없다면, 당신은 비즈니스의 운명에 영향을 줄 수 없다. 즉 북극성 지표가 없다면, 프로덕트 중심 회사가 될 수 없다는 말이다.

책임 없이는 리더십도 없다

다음은 프로덕트 전략이나 실행에 책임이 있는 사람이 프로덕트 북극성 지표에 대해 대답해야 할 세 질문이다.

질문 1: 좋은 북극성 지표의 좋은 예

북극성 지표는 두 가지 파트로 나뉘어져 있다.

1. 프로덕트의 비전에 대한 정의
2. 현재 프로덕트 전략을 측정할 수 있는 주요 지표

우리가 끌어내고 싶은 고객 가치는 "무엇이 행동을 이끌어 내는지 더 쉽게 답변하고, 더 나은 고객 경험을 제공하는 것"이다.

우리는 현재 빠른 성장 단계에 있기 때문에, 우리의 Weekly Quering Users (WQUs) 지표 - 예를 들어 최소 주 1회 이상 데이터를 조회한 고객 수 - 는 ‘넓이(breadth)’를 반영한다. 이 지표는 시간이 지남에 따라 사용자가 다시 방문하게 하고(Retain) 사용자를 확장할 수 있는 선행 지표이다.

좋은 북극성 지표는 가치와 일치한다

당신의 북극성 지표는 고객이 인지하는 가치를 제공하는 행동이 무엇인지에 대한 이해로부터 나와야 한다. 임팩트에 가장 가까워질 수 있도록 해야 한다. 이것은 “일간 활성 사용자 수 (Daily Active USers, DAU)”나 “등록 사용자 수 (Registered Users)”가 좋은 KPI가 아니라는 뜻이다. 만약 이 지표가 프로덕트의 KPI라면 팀에 명확성을 제공할 큰 기회를 날리고 있는 것이다.

팀이 고객 가치를 북극성 지표와 연결하지 못한다면, 비즈니스를 잘못된 길로 이끌게될 수 있다.

LinkedIn의 북극성 지표 예시

LinkedIn의 데이터 사이언티스트는 “추천(endorsements)” 기능에 대한 그들의 북극성 지표를 개선하는 것이 더 나은 프로덕트 경험을 제공하지 않았다는 멋진 케이스 스터디를 공유하였다. 그들의 지표 정의는 추천이 만들어지고/받아들여진 액션에 관한 것 이었고, 채용 담당자는 이러한 지지가 잘못된 정보를 제공하고 있을지 우려한다는 고객이 인지하는 가치를 대변하지 못해 LinkedIn의 비즈니스를 실제로 개선하지 못했다.

Reforge 또한 최근 프로덕트 지표를 제대로 설정하지 않았을 경우 일반적으로 발생하는 위험에 대한 훌륭한 아티클을 개제하였다.

좋은 북극성 지표는 성공에 대한 선행 지표이다

프로덕트 북극성 지표는 프로덕트와 고객 가치가 무엇인지에 대해 상세해야 한다

이 지표의 중요한 부분은 미래 성공에 대한 선행 지표가 되어야 한다는 것이다. 월간 매출이나 ARPU(사용자 별 평균 매출, Average Revenue Per User)와 같은 후행 지표는 프로덕트 임팩트의 신호를 빠르게 줄 수 없다. 이러한 지표는 미래 수익에 대한 예측을 제공하는 것이 아니라 과거에 발생한 일에 대해 말해줄 뿐이다. 미래에 발생할 수익과 시장 가치가 더 늘어나도록 지표를 가져갈 수 있다면, 임팩트 또한 더 많이 가져갈 수 있다.

eCommerce 산업의 북극성 지표 예시

Amplitude의 고객 중 하나인 Fourtune 100 리테일러는 회사의 미래에 모바일 커머스 비즈니스가 전략적으로 우선순위가 높다는 것을 발견해 이를 성장시키려고 하고 있다.

그 팀의 북극성 지표는 아마 “모바일 주문이 배송 완료된 수” 일 것이다. 이 지표는 배송이 지불, 물류 문제, 반송 문제 없이 완료 되었다는 것이기 때문에 그들의 모바일 앱에서 주문하는 사람을 포착하고 (현재 전략이 집중하는 바), 좋은 경험을 한 사람(가치를 얻는 고객)을 포착한다.

프로덕트의 세계에서, 이것은 종종 “고객의 아하 모먼트”를 찾는 것으로 비유되곤 한다. 고객이 다시 돌아오는(리텐션) 초기 행동을 찾을 수 있다면, 강한 선행 지표가 되는 효과적인 북극성 지표를 가지게 되는 것이다.

북극성 지표는 미래 비즈니스 결과에 대한 선행 지표여야 한다

Facebook 북극성 지표 예시

최근 Facebook은 “첫 10일 동안 7명의 친구를 등록한 사용자 수”를 주요 지표로 선정하고 있다는 것이 잘 알려져 있다. 이러한 주요 액션을 어떻게 발견하는지 궁금하다면 다음 가이드 👉를 확인해볼 수 있다.

B2B의 북극성 지표 예시

만약 SaaS 회사가 Dropbox나 Hubspot과 같은 셀프 서브 비즈니스 모델을 가지고 있다면, 그들의 지표는 아마 “첫 주에 활성 사용자가 3명인 트라이얼 계정” 일 수 있다. 이 지표는 가치를 발견하고 있는 모든 신규 무료 계정을 포착하고, 트라이얼 전환과 구독으로 인한 매출이 발생할 것이라는 프로덕트 팀이 예측하고 활성화 할 수 있는 신호를 제공해준다.

Docusign의 전 프로덕트 리더이자 Social Capital의 파트너인 Ashley Carroll은 자신의 웨비나에서 더 나은 프로덕트를 만드는데 “non-revenue” 프로덕트 북극성 지표의 중요성을 이야기했다.

비슷하게, Instacart와 같이 빠르게 성장하는 회사들은 그들 프로덕트 북극성 지표를 종종 “주 별 첫 주문을 완료하는 사용자”와 같은 새로운 사용자 활성화(New user activation) 지표에 집중하기도 한다. 한 번 활성화 된 사용자가 유지된다는 것을 알기 때문에, 회사가 미래 수익에 대한 선행 지표에 집중할 수 있도록 해준다.

요약하자면, 좋은 북극성 지표는 다음 세 가지 특징을 가진다:

1. 고객이 당신의 프로덕트에서 가치를 발견하는 순간을 측정한다
2. 현재 프로덕트 전략의 핵심을 대변한다
3. 회사가 중요하게 여기는 미래 비즈니스 결과물에 대한 선행(후행이 아닌) 지표이다

질문 2: 회사에서 북극성 지표는 하나만 가져야 하는가?

꼭 그런것은 아니다. “하나의 핵심 지표”라는 생각은 비즈니스 저변에서 커뮤니케이션을 단순화하는데 용이하지만 보통 충분하지 않다. 보통 규모가 큰 회사들은 복잡한 생태계를 가지고 있고 1-3개의 핵심 프로덕트 지표에서 최적의 균형을 찾기 위해 노력한다. 핵심 지표가 하나라면 무엇이 더 중요한지 알 수 없고, 중요한 트레이드 오프를 눈치채지 못할 수 있다.

거기에 더해, 지표는 각 프로덕트 팀의 목표와 지표를 도출하는데도 사용된다. 모든 팀은 프로덕트 조직의 북극성 지표를 발전시키는 그들만의 구체적인 목표를 만들어야 한다.

북극성 없는 KPI들은 그냥 지표 국밥이 되기 마련이다

예를 들어, Amplitude에서 우리의 프로덕트 북극성 지표는 주 별 Amplitude에서 한 번 이상 쿼리를 치는 사용자의 수이다. 우리는 이것을 주별 쿼리하는 사용자(Weekly Querying Users, WQUs) 라고 부른다. 거기에 더해, 우리는 이전에 백엔드 엔지니어링 팀이 가지고 있던 인프라의 퍼포먼스에 대한 지표도 가지고 있다.

모든 북극성 지표는 4가지 차원 - 넓이, 깊이, 빈도, 효율성 - 으로 쪼갤 수 있다. Amplitude의 핵심 지표는, 이 중 세 가지 차원을 높은 우선순위를 부여해 프로덕트 팀이 발전하는 데 쓰고 있다.

아래는 식료품 주문과 배달 앱에 대한 북극성 지표 트리 예시이다. 트리는 12개의 프로덕트 개선 계획을 북극성 지표의 각의 차원을 발전시킬 수 있는 하나의 프레임워크로 묶은 것이다.

질문 3: 좋은 북극성 지표를 선택하는 방법

이 아티클이 그 방법을 배우기에 딱 알맞은 곳입니다! 조직과 프로덕트 분야에 적합한 북극성 지표를 선택하는 데 가장 중요한 것은 당신이 어떤 게임을 하고 있는지 아는 것이다.이 게임은 핵심 고객 관여 모델에 대한 것이다. 11,000개가 넘는 회사와 3조가 넘는 사용자 액션을 분석한 결과, 모든 디지털 제품은 다음 세 종류 중 하나에 대한 게임을 하고 있다는 것을 알게 되었다.

1. 관심 게임(Attention) : 프로덕트가 사용자의 시간을 얼마나 가져갈 수 있는가
2. 트랜잭션 게임(Transaction) : 플랫폼 안에서 사용자가 상업적 트랜잭션을 얼마나 만드는가
3. 생산성 게임(Productivity) : 프로덕트 내에서 사용자가 얼마나 고가치 디지털 업무를 수행할 수 있는가

Facebook과 Netflix는 둘 다 관심 게임을 하고 있지만, 비즈니스 모델은 근본에서 부터 다르다. Facebook의 수익은 광고 수익을 창출하기 위한 피드 관여도와 비례한다.

반면 Netflix는 구독 모델을 가지고 있고 콘텐츠의 양이 정해져 있다(점점 많아지고 있지만). 이는 그들의 북극성 지표는 콘텐츠를 시청하는 시간이 아니라 구독자들의 수를 극대화 하는데 있어야 한다는 것을 의미한다.

유사하게 Amazon Retail과 Walmart는 동일한 트랜잭션 게임을 수행하지만 다른 북극성 지표를 가질 수 있다. Amazon은 그들의 구독 모델이 충성도와 LTV에 대한 가시성을 제공하기 때문에 아마존 프라임 구독자들의 수와 그들이 만들어 내는 가치를 최적화 하는데 있을 것이다. Walmart는 반대로 비용 우위를 가지기 때문에 고객이 방문할 때 마다 고객의 지갑 점유율에 집중할 것이다.

Salesforce는 B2B 회사들에게 고객 정보에 대한 Source of Truth 중심지 역할을 하고자 한다. 그들의 새로운 전략은 세일즈 시 의사결정을 위한 AI 와 관련되어 있다. 이것은 그들의 북극성 지표는 사용자 확보 보다는 그들 계정에 고객 데이터가 얼마나 저장되는가에 더 집중하고 있다는 것을 의미한다. 이런 모델과는 다르게, Adobe Creative Cloud는 개별 구독자와 그들이 구독을 유지하도록 충분한 인게이지먼트를 제공하는 것에 집중할 것이다.

프로덕트 전략 운영에 북극성 지표를 사용하는 방법

프로덕트 전략을 수행하는데 북극성 지표 프레임워크를 사용하는 것은 임팩트 중심 조직에게 필수적인 투자이다. 또 이것은 프로덕트 주도형 기업으로 가는 길이다.

이 시리즈에서 이후 이어지는 아티클들은 다음 질문들에 대한 답을 찾아볼 것이다.

• 북극성 지표를 도입하려면 어떤 인프라와 문화가 필요한가?
• 프로덕트 생애 주기에 북극성 지표를 어떻게 최적화 하는가?
• 북극성 지표 트리를 고객 여정에 어떻게 매핑할 것인가?
• PM, 엔지니어링, 디자인과 같은 다른 프로덕트 조직에 위해 신뢰도와 오너십을 어떻게 제공하는가?

만약 사용자의 행동을 어떻게 분석하고 북극성 지표를 수행하는 방법을 더 배우고 싶다면 이를 시작하기 위한 리소스들도 있습니다!

🔗 이 글은 Annina Koskinen이 Spotify.design에 올린 아티클을 번역, 요약한 글입니다.

⚡️요약

이 글은 디자인 프로세스에 대해 공부한 사람이라면 모두 알고 있는 Empathy - Design - Prototype - Test - Iteration 단계를 Spotify만의 언어로 다시 쓴 내용이라고 볼 수 있다. 이 때 중요한 점은 데이터를 바탕으로 해야 한다는 점이다. 팀은 비즈니스 목표를 달성하기 위한 역할을 하며, 디자인이 설정된 목표를 증명할 수 있는 지표를 움직이는 것을 확인해야 한다. 이 프레임워크는 다음과 같은 단계로 이루어진다.

1단계: 목표 정하기. 이 때 목표는 비즈니스 목표일 수 도 있고, 작은 단위의 개선 프로젝트일 수 도 있다.
2단계: 목표와 관련한 데이터와 인사이트를 모으기. 목표와 관련된 사용자의 컨텍스트, 사용 행태, 멘탈 모델 등 다양하고 구체적인 데이터와 인사이트를 모은다.
3단계: 수집된 데이터와 인사이트에서 기회나 문제¹ 발견하기. 각 인사이트에서는 다양한 방식으로 기회나 문제가 정의될 수 있다.
4단계: 각 포착한 기회나 문제를 해결할 수 있는 가설 세우기. 이 역시 하나의 기회나 문제를 여러 가설로 해결을 꾀할 수 있다. 만약 목표가 너무 커 발견한 기회나 문제도 크다면 집중하고자 하는 기회나 문제를 위한 또 하나의 Toughtful Execution Framework를 만들면 된다.
5단계: 각 가설을 증명하거나 반박하기 위한 디자인 솔루션 만들기. 한 가설은 여러 디자인 솔루션으로 증명이나 반박이 가능하고, 각 솔루션을 임팩트와 실현 가능성으로 평가하여 테스트할 솔루션을 결정한다. 이 때 테스트할 솔루션은 MVP수준으로 만들어 테스트한다.
6단계: 위에서 선정한 디자인 솔루션 테스트하기. 테스트한 결과는 가설을 증명할수도, 증명하지 못할수도 있다. 만약 결과가 가설을 긍정적으로 증명한다면, 더 많은 긍정적인 신호를 끌어내고 사용자의 만족도를 끌어올릴 수 있도록 MVP를 더 Iteration해야 한다. 반대로 결과가 가설을 증명하지 못한다면 다른 디자인 솔루션이나 다른 가정으로 넘어가 다시 단계를 진행한다.
7단계: 테스트한 결과로부터 배우게 된 점을 정리해 팀이 앞으로 나아가는데 밑거름이 되도록 하기.

Intro

직감은 창의적인 프로세스에 중요한 역할을 한다. 하지만 전략적인 결정을 하는 데 단독으로 사용되거나 한 가정에 대해 여러 해결책을 생각해보는 것을 막게 되어선 안된다.

Annina Koskinen은 Spotify의 그로쓰 임무를 수행하는 팀이 목표를 달성하고 영향력을 행사할 수 있는 리소스가 되어준 Thoughtful Execution Framework을 제시한다.

Thoughtful Execution Framework은 여러 문제나 기회를 식별하는 방식으로 데이터와 직감을 활용할 수 있도록 하고, 하나의 해결책으로 수렴하기 전에 가설 수립과 발산을 광범위 하게 진행할 수 있도록 한다.

📕 PDF 가이드나 Figma 템플릿, Mural 템플릿을 활용하여 이 프레임워크를 사용할 수 있다.

우리는 우리의 마음과 감정의 목소리를 맹목적으로 신뢰해서는 안된다. 우리의 마음은 항상 감정과 과거 경험을 바탕으로 주관적인 표현만을 제공하기 때문이다. 하지만 우리의 의견과 선택은 항상 어느정도 직감에 의거하기 때문에 이 주관적인 마음을 완전히 배재할 순 없다. 이건 잘못된 것이 아니라 다양성을 만들어주는 아름다운 것이다. 서로 다른 관점과 경험을 가진 사람들이 무엇이 더 합리적인 판단인지 알아내려 하는 것이 전략적인 비즈니스 결정이기 때문에 우리는 이 주관성에 대해 더 잘 알고 있어야 한다.

약 5년 전 Spotify가 새로운 Tribe를 만들려고 하던 때, 성공적인 팀을 가장 잘 구성하는 3가지 방법을 세워볼 수 있었다.

첫째, 조직의 모든 팀이 통찰력과 회사의 전략을 바탕으로 한 명확한 목표를 가지고 있다.
둘째, 이러한 목표는 측정할 수 있어 우리의 업무가 비즈니스에 미치는 영향을 추적할 수 있어야 한다.
마지막으로, 팀들은 그들의 목표를 달성하기 위한 세심하게 세운 계획을 가지고 있어야 한다.

팀에게는 보통 다음과 같은 일이 많았기 때문에 여기에서 개선의 기회를 발견하였다.

비즈니스 목표가 세워진 다음, 팀은 보통 곧바로 그 목표를 달성할 아이디어를 생각하는데 몰두하곤 했다. 그리곤 한 반짝이는 아이디어를 발견해 이 아이디어가 원하는 효과를 제공하는지 얼른 A/B 테스트를 하려 했다. 하지만 우리는 곧 목표에 한 솔루션만으로 곧바로 달려가고, 그 솔루션이 원하는 결과를 주지 못하면 되돌아서서 그 이유를 찾는게 굉장히 힘들다는 것을 배우게 되었다. 솔루션을 잘못 디자인 한건지? 아니면 가정이 옳지 못했던건지? 그것도 아니라면 진짜 문제를 해결하고 있던게 맞긴 한건지?

팀들이 이런 막막한 상황에 놓이는 것을 막기 위해 이런 마인드셋을 가질 수 있는 방법을 생각해보기로 했다.

The Thoughtful Execution tree

한 솔루션으로 곧바로 달려들게 하는 생각을 바꾸기 위해, 프로덕트 개발 프로세스에 필수적인 스텝을 밟도록 하였다. 이런 스텝은 트리 구조로 보여줘 팀들이 이 스텝을 순서대로 밟는 것을 도왔다. 우리는 팀이 문제 발견, 가설 수립, 아이디어 발산 과정을 넓게 먼저 본 후 하나의 솔루션으로 수렴할 수 있도록 하고자 했다.

It all starts with data and insights

만약 친구가 당신에게 다른 나라로 이민간 뒤 외롭다고 불평하면, 아마 이런 말을 하고싶은 생각이 들 것이다. “원래 책 읽는거 좋아했으니까 독서모임 같은델 들어가는건 어때?”. 아마 다른 사람은 동료들이랑 더 많은 시간을 보내라고 말 할 수도 있을 것이다. 하지만 그 친구의 행동을 세심하게 분석해야 그녀가 외롭다고 하는 진짜 이유를 알아낼 수 있을 것이다. 그녀가 일이 너무 많아 친구를 만날 시간이 없을 수도 있고, 아직 언어가 유창하지 못해 사회적인 교류를 못할 수 있을 수도 있다. 진짜 문제를 제대로 이해해야 유의미한 조언을 해줄 수 있을 것이다.

비즈니스 세계에서도 이와 비슷하게, 목표가 세워졌다면 해결해야 할 잠재적인 문제와 기회가 무엇인지 정확하게 알기 위해 데이터와 인사이트를 모으는데 충분한 시간을 들여야 한다. Spotify에서는 이것을 산(mountains)이라고 부른다. 마치 산처럼 이 문제와 기회들은 높이도 다르고, 달성할 수 있는 난이도도 달라 각각에 맞는 고유한 전략이 필요하다.

브라질에 있는 팀에서 사용자가 음악을 들으러 계속 Spotify로 돌아올 수 있는 방법에 대해 고민하고 있었다. 물론 브라질 사람들이 더 앱에 자주 들어올 수 있도록 하는 많은 아이디어를 떠올릴 수도 있었겠지만, 데이터와 인사이트를 충분히 모아보니, 제대로된 솔루션이 있다면 더 많은 사람들이 활성 사용자(active user)로 남을 수 있는 아주 색다른 문제와 기화를 발견할 수 있었다. 해결하고자 하는 한 영역은 로컬 브라질리언 음악 카탈로그를 새로운 사용자에게 더 효율적으로 제공하는 쪽이었고, 다른 한 영역은 느린 네트워크 속도에 맞춰 어플리케이션 퍼포먼스를 최적화 하는 것이었다. 이런 아주 다른 두 문제와 기회는 아주 다른 솔루션으로 해결해야 할 것이며 데이터와 인사이트를 통해 올바른 방향을 바라보는 것이 중요하다는 것을 알 수 있다.

해결할 서로 다른 문제와 기회를 발견한 뒤 다음으로 할 일은 이를 해결했을 때 가장 임팩트가 큰 곳이 어딘지 아는 것이다. 가능하다면 데이터 사인티스트 친구에게 빠른 조사나 실험을 해서 어떤 기회의 “산”이 가장 높은지 알아봐 달라고 할 수 있다. 프로젝트의 범위에 따라 목표의 지표를 움직이기에 가장 적합한 방법으로 하나의 문제나 기회에 집중하는 것으로 결정할 수도 있고, 여러 개를 한 번에 해결하려 할 수도 있다.

하나의 문제나 기회에 집중하기로 했다면, 그 문제나 기회에 대한 또 하나의, 더 자세한 Toughtful Execution tree를 만드는 것이 좋다. 예를 들어, 한 팀이 Spotify 모바일 가입 경험을 최적화 하려고 할 때, 그들의 최초 목표는 가입에 성공하는 수를 늘리는 것 이었을 것이다. Funnel은 어느 프로덕트를 보아도 어느정도 비슷하다. 100%의 사람들이 funnel에 들어와서, 계속 남아있을 동기에 따라 다른 수가 다른 순서에서 이탈하게 될 것이다.

많은 앱들은 서비스를 사용하기 위해 계정을 만들어야 한다. 그리고 많은 회사가 이 경험을 최대한 부드럽게 만들어 서비스를 사용하기 위해 동기로 가득차지 않은 사람들까지도 “한 쪽 끝에 있는 문”을 통과시키기 위해 최적화에 힘을 쓴다. 우리 가입 팀이 데이터와 인사이트를 보기 시작했을 때, funnel에서 더 최적화할 수 있는 키 포인트를 발견할 수 있었다.

1. 몇몇 사람들은 Spotify 앱을 다운 받았지만, 가입 폼 화면까지 오지 않았다.
2. 몇몇 사람들은 가입 폼 화면으로 들어왔지만, 폼을 완성하지 않았다.
3. 몇몇 사람들은 가입 폼 화면으로 들어오고, 폼을 완성했지만 어떤 오류때문에 가입에 실패했다.

이 세 목표는 모두 그들의 목표하는 지표를 개선할 수 있었을 것이지만, 팀은 세 번째 기회를 먼저 집중하기로 했다. 세 번째 기회에 있는 사람들은 가입에 대한 동기를 분명히 보였지만 가입 하기에 실패했기 때문이다. 이제 팀은 또 다른 Toughtful Exeucution Tree를 만들었고, 이번엔 목표를 더 구체적으로 잡았다.

가입 화면의 데이터를 수집하고 경험에 대한 양적인 테스트를 수행해 가입 폼에 대한 가설을 세울 수 있는 더 구체적인 문제와 기회를 발견할 수 있었다.

From opportunities to multiple hypotheses and solutions

모든 문제와 기회는 여러 다른 결과에 도달할 수 있는 여러 다른 방식으로 설명될 수 있다. 이 때문에 우리가 가장 원하는 결과로 도달할 수 있는 방법이 무엇인지 확인할 수 있도록 각 기회마다 여러 가설을 세우는 것이 중요하다. 세워진 각 가설은 또 여러 솔루션을 가질 수 있으므로, 하나의 디자인 솔루션을 실행해 보는 것으로는 가설을 증명하거나 반박할 수 없다.

우리가 왜 어떤 플레이리스트가 각 사용자에게 추천 되었는지 더 잘 설명할 수 있는 기회를 탐색하고 있을 때, 우리는 여러 가설을 세웠고 그 중 일부가 아래 트리에 표현되어 있다. 또 트리는 하나의 가설이 여러 방법으로 디자인될 수 있다는 점도 보여준다. 그리고 각 방법은 서로 다른 방식으로 효과를 보였을 것이다.

From solutions to learnings

솔루션 디자인 단계에서, 테스트 할 MVP(Minimum Viable Product)로 스콥을 줄여나가기 전에 일단 과감하고 자유롭게 생각해야 한다. 점진적인 개선을 할 수 있는 단기적인 방식과 더 큰 변화가 필요한 장기적인 방향성 모두를 생각해야 한다. 위 예시들은 대체로 점진적인 개선이 들어있긴 하지만, Toughtful Execution은 이미 존재하는 것을 변화시키는 것 뿐만 아니라 완전히 새로운 것을 생각할 때도 잘 작동한다. 당신의 트리는 프로덕트의 가치를 제안하는 첫 단계에서는 좀 더 높은 곳에서 바라보고 있어야 하고, 기초를 정확하게 다진 다음엔 최적화가 나와야 한다. 프로덕트가 성숙하지 못한 상태라면, 지표의 임팩트를 측정하기 위해 더 큰 도약이 필요할 것이다.

당신이 솔루션을 디자인 했다면, 원하는 임팩트를 만들어 내는데 가장 효과적일 것이라고 생각되는 것을 테스트 할 차례다. 아이디어를 만족도와 실현 가능성으로 분석해보자. 예상되는 임팩트와 실행할 수 있는 속도도 염두에 두자. 가장 많은 것을 배울 수 있는 아이디어와 가장 만들기 쉬운 아이디어가 무엇인지 각각 평가해보자.

양적인 테스트는 A/B 테스트에 적합한 사항에 대한 많은 정보를 제공할 수 있다. 테스트를 해보고 실험을 하는 과정에서 또 다른 솔루션을 떠올리게 될 것이고 더 많이 배우면서 트리도 함께 업데이트 할 수 있을 것이다. 우리의 목표는 솔루션이 목표의 지표를 움직이는지를 확인해 가설을 증명하거나 반박하는 것이다. 목표하는 지표가 움직이지 않는 여러 솔루션을 실험했다면, 트리의 다른 가지로 옮겨갈 시간이 됐다는 의미이다. 반대로 MVP가 성공적인 결과를 내었다면, 솔루션을 더 반복 수정한다면 더 긍정적인 효과를 볼 수도 있을 것이니 다른 기회로 넘어가기 전에 반복 수정하는 것이 중요하다.

The power of Thoughtful Execution

우리가 팀에 우리의 프레임워크를 소개해줬을 때, 우리는 그들이 탐색하고 있는 가설의 질이 올라가고 비즈니스 지표가 긍정적인 트렌드를 그리는 것을 명확하게 확인할 수 있었다. Spotify의 문화는 자율성이 강조되기 때문에, Toughtful Execution을 공식적인 프로세스로 소개되는 것을 원하지 않았다. 우리는 팀에게 Toughtful Execution tree를 문서화 할 수 있는 한, 그들이 트리의 각 스텝을 어떤 도구를 사용해 수행할 지에 대한 자율성을 제공했다. 이 프레임워크는 팀이 작업을 구조화 하고 업무를 목표에 맞춰 조정하고, 팀 외부에 작업 중인 내용과 그 이유, 이후 어떤 영역에 초점을 맞출 지를 전달하는데 유용한 도구가 되어주었다.

Your turn

우리는 Toughtful Execution을 그로쓰 팀에서 5년 동안 사용 해오며 이 프레임워크를 외부에 알릴 때가 되었다고 생각했다. 그 과정에서 배운 팁들을 남겨둔다.

1. Don’t get paralyzed by not having enough data

달려 들 문제와 기회를 정의하는 데 최대한 많은 데이터와 인사이트를 동원해야 하는 것이 중요하긴 하지만, 일을 진행하기 전에 모든 것을 안다는 것은 비현실 적인 일이다. 여러 회사의 여러 팀은 데이터와 리서치에 다른 수준을 가지고 있으며, 충분한 인사이트를 가지지 못하는 상황은 일반적인 일이다. 빠른 인사이트를 얻을 수 있는 다른 방법을 생각해보라. 유사한 프로덕트를 벤치마크 해보거나, 당신의 프로덕트에 대한 전문가 평가를 수행해보라. 가능하다면 당신의 프로덕트에 대한 학습 실험을 수행해 추가적인 인사이트를 얻을 수도 있다. 기회를 발견하고 정의하는데 직감을 사용해도 괜찮다. 하지만 직감은 양심적으로 사용하고, 사용한 가정이 사실인지 확인하자. 중요한 것은 진행하는 것이며 Toughtful Execution tree는 배워가는 과정에서 계속해서 업데이트 할 수 있다.

2. Be mindful of which testing method to use

양적인 실험이 핵심 비즈니스 메트릭이 어떻게 영향을 받았는지 확실한 데이터를 제공하긴 하지만, 질적인 방식에서도 많은 것을 배울 수 있다. 과감한 아이디어를 정성적인 설정으로 테스트 해보는 것은 무언가를 만들기 위해 시간과 리소스를 투자하기 전 빠르고 저렴하게 테스트 해볼 수 있는 방식이다. 예를 들어, Spotify의 핵심 네비게이션을 리디자인 할 때, 우리는 card sorting 기법을 사용해 Spotify의 다른 콘텐츠 세트와 기능을 각 카드에 담아 기존 유저와 신규 유저에게 그룹핑 하고 구조화 하는 실험을 하였다. 이 리서치에는 하루만 소요되었고, 프로토타입을 만드는데 무언가를 투자하지도 않았지만 사람들이 우리의 프로덕트를 어떻게 멘탈 구조로 바라보고 있는지 알 수 있었다.

3. Holistic changes tend to move metrics

리텐션과 같은 큰 비즈니스 지표를 움직이는 것은 어려운 일이니 당신의 실험이 중립적인 결과를 보이더라도 실망하지 말라. 우리가 무료 티어 고객에게 제공 할 온보딩 기능을 탐색하고 있을 때, 프로덕트 교육의 한 부분이 질적인 실험에서는 긍정적인 결과를 보였지만 양적인 지표를 움직이지는 못한 경우를 종종 발견하였다. 하지만 우리가 한 번에 여러 변경한 실험을 진행했을 때는 리텐션이 상승하는 것을 확인할 수 있었다.

4. MVP only gets you basecamp

당신의 실험이 목표하는 지표를 긍정적인 방향으로 움직이는데 성공했다면, 이 실험을 확장하고 다음 기회로 넘어가고자 하는 생각이 들 것이다. MVP는 기회의 산에 있는 “베이스캠프”까지만 데려다 줄 뿐, 경험을 더 개선한다면 더 많은 임팩트를 가져갈 수 있을 것이다. MVP는 보통 경험을 위한 꼭 필요한 기능을 넣기 위해 프로덕트 만족도에 큰 임팩트를 줄 수 있는 만족도를 위한 요소가 제거된 경우가 많다. 따라서 MVP를 프로덕트 전반에서 높은 퀄리티를 낼 수 있도록 최적화 하는 과정이 중요하다.

🔗 이 글은 Jason Fox가 UX Collective에 올린 미디엄 글을 번역, 요약한 글입니다.

⚡️요약

1. Constant Component에 제공되어야 할 정보를 작성하기
2. Dynamic Component에서 오류 상황의 컨텍스트를 더 잘 이해시킬 수 있도록 보강하기
   • 최소 요구 조건은 Constant Component이다. 잘 작성된 Constant Component만 있어도 유저의 오류 상황을 명확히 인지시키고 해결할 수 있다.
   • Constant Component는 사용자가 취할 수 있는 액션 경로와 무엇이 왜 발생했는지 명시
   • Dynamic Component는 오류 상황에 대한

오류 메세지 작성을 위한 건축 블록

디지털 프로덕트를 만드는 과정에서 오류 메세지는 끊임없이 작성되어야 한다. 오류 메세지 작성의 핵심 건축 블록으로 오류 상황에서 제공되어야 할 정보를 경제적이고 사용자 중심적으로 디자인할 수 있다.

모든 오류 메세지는 두 가지 종류의 핵심 컴포넌트로 구분할 수 있다.

1. Constant Components

Constant Component는 필수 요소이다. 여기엔 사용자에게 어떤 일이 일어났고, 왜 일어났고, 어떻게 진행할 수 있는지에 대한 정보를 제공한다.

이 컴포넌트는 다음 정보를 포함할 수 있을 것이다:

• 사용자가 취할 수 있는 액션 경로 (Action path)
• 무엇/왜 를 설명하는 문장 (What/why statements)

2. Dynamic Components

이 컴포넌트는 오류 상황의 심각성, 원인, 다른 요소 등에 의해 조절될 오류 메세지의 톤을 조정하는 역할을 한다.

이 컴포넌트는 다음 정보를 포함할 수 있을 것이다:

• 초래된 결과 (Impact statements)
• 상황 확인/사과 (Acknowledgements/apologies)
• 다른 해결 방안 (Alternate resolution paths)
• 의례 어구 (Politeness markers)
• 담화 어구 (Discourse markers)

오류 메세지 문장이 잘못된 경우

오류 메세지가 기본 구성에서 벗어나 있다면 사용자들은 오류 상황을 명확하게 인지하지 못하게 될 것이고, 그 오류 메세지는 곧 SNS에서 까이게 될 것이다.

이 문장을 활용하는 방법

• 오류 메세지를 작성할 때 Constant Component를 작성하는 것을 목표로 하기
• 오류 발생한 컨텍스트의 살을 붙이기 위해 Dynamic Component를 작성하기
• 어떤 종류의 오류 메세지들은 왜 제구실을 하지 못하는지에 대한 가설을 생각해보기
• 작성한 오류 메세지를 한 번 더 검수하기
• 깊게 파고들 수 없는 작은 프로젝트이더라도 매번 유용한 오류 메세지를 작성하는 패턴을 만들기

🔗 이 글은 Raluca Budiu가 Nielsen Norman Group에 올린 아티클을 번역, 요약한 글입니다.

⚡️요약

사용자 리서치에서 크게 두 가지 방법이 있고, 두 방법의 특징을 알고 더 좋은 방법을 선택해야 한다

• 반복 측정 설계는 참가자 간 차이를 상쇄할 수 있지만, 학습 효과를 방지하기 위해 랜덤화를 사용해야 하고
• 독립 집단 설계에서는 조건 간 학습 효과를 상쇄할 수 있지만, 참가자 간 차이를 상쇄할 수는 없음

용어 정리

Between-Subjects Study Design: 독립 집단 설계
Within-Subject Study Design: 반복 측정 설계

한 조사에서 여러 사용자 인터페이스를 비교하려 할 때, 다음과 같은 조건들로 실험 참가자에게 태스크를 부여할 수 있다.

• 독립 집단 설계: 각 실험 조건에 각기 다른 사람이 참여함. 한 사람은 한 인터페이스에만 노출될 수 있도록 함
• 반복 측정 설계: 동일한 사람이 모든 실험 조건에 노출되도록 함

정량적 조사에서 실험 디자인

주로 정량적 사용성 조사는 비교하는데 핵심 목표를 둔다. 예를 들어 경쟁사의 웹사이트, 다른 두가지 버전의 디자인, 사용자 그룹의 두 종류(experts vs. novices) 간 비교가 있다. 이 때 정량적 분석에서는 두 가지 변수가 있다.

독립 변수(Independent variables): 리서처에 의해 직접적으로 조정되는 것
종속 변수(Dependent variables): 측정되는 것 (그리고 독립 변수의 조정에 따라 결과가 달라질 것으로 예상되는 것)

만약 조사가 통계적으로 유의미한 결과를 만든다고 했을 때,
독립 변수의 조정이 종속 변수의 변화를 야기했다고 할 수 있다.

자동차 렌트 사이트의 예시로 돌아가보자.

두 렌탈 사이트중 자동차를 렌트하는데 더 나은쪽이 어디인지 알고 싶다면, 사이트를 독립 변수로, 태스크를 수행하는데 걸리는 시간과 정확도를 종속 변수로 둘 수 있다. 이 때 조사의 결과는 종속 변수인 시간과 정확도가 사이트를 다르게 할 때 달라지거나 동일하게 유지되는 것으로 나올 수 있을 것이다(만약 동일하게 유지된다면, 두 사이트 중 더 나은 곳은 없다는 의미)

이 때 조사를 위한 실험 방법을 선택하는 것은 데이터를 통계적으로 분석하는 방법에 영향을 준다.

실험 방법은 독립 집단 설계이면서 반복 측정 설계일 수 있다.
30살 미만 사용자와 그렇지 않은 참가자 간 비교를 하고 싶을 때, 독립 변수는 두가지가 된다

1. 나이 - 2가지 타입: 30살 미만, 30살 이상
2. 사이트 - 2가지 타입: A, B

예를 들어, 각 연령 그룹에 동일한 숫자의 참가자를 모집하고 각 참가자를 A와 B 사이트 모두에서 자동차 렌탈을 수행한다고 하자.

그렇다면 이 조사는 독립 변수 사이트에 대해서는 반복 측정 설계이고(각 참가자는 두가지 사이트 모두를 보게 되니까),
독립 변수 나이에 대해서는 독립 집단 설계가 된다(각 참가자는 30살 미만이거나 30살 이상이며, 둘 다일 수 없음).

30살 미만의 참가자를 30살 이상이될 때 까지 기다렸다가 다시 조사를 한다면 반복 측정 설계가 될 수 있겠지만, 현실적으로 말이 되지 않음

일부 독립 변수의 종류는 디자인 방법에 영향을 준다.
예를 들면 위와 같이 나이, 전문성, 사용자 타입 (business traveler, leisure traveler), 성별 (한 사람이 한 성별만 가지고 있다고 가정하면)과 같은 변수가 그렇다.

사용성 뿐 만 아니라 약물 실험과 같은 경우도 독립 집단 설계일 수 밖에 없다. 각 참가자는 두 가지 모든 약에 노출되지 못하고, 한 종류의 약물에만 노출되어야 한다.

또 변수의 조작 자체가 참가자에게 영향을 줄 수도 있다. 읽기에 더 도움되는 교수법을 확인하고 싶을 때, 한 사용자는 이전의 교수법에서 읽기 능력이 향상되었을 수 있으므로 두 가지 방법을 모두 사용할 수 없다.

독립 집단 설계 vs 반복 측정 설계 어느 것이 더 나을까

답은 언제나 그렇듯 “때에 따라서 다르다” 이다.

• 독립 집단 설계는 학습 효과와 조건 간 방해 효과를 최소화 할 수 있다
  한 사이트에서 자동차를 빌려 본 참가자는 자동차 렌탈 과정에 대해 더 잘 알게될 것이다. 이러한 지식은 두 번째 사이트에서 더 효율적으로 태스크를 수행할 수 있도록 할 것이다.
• 독립 집단 설계는 반복 측정 설계보다 더 짧은 세션 시간이 소요된다
  두 번 측정하는 것 보다 짧은 시간이 소요되는 것이 덜 지치고 덜 지루할 것이다. 또 원격 조사나 연구자가 함께하지 않는 조사에서 더 유용할 수 있다.
• 독립 집단 설계는 더 많은 독립 변수가 있을 때 더 설계하기 쉽다
  설계 순서에 따른 노이즈를 최소화 하기 위해 랜덤화를 사용해야 한다. 모든 사용자에게 사이트 A 다음 사이트 B를 수행하도록 하지 않아야 할 것이다. 두 개 사이트에 대한 실험은 설계하기 쉽지만, 독립 변수가 많거나 한 변수의 레벨이 다양해지는 경우 현존하는 정량적 조사 플랫폼에서 랜덤화를 도입하기 어려울 것이다.
• 반복 측정 설계는 더 적은 참가자로 더 저렴하게 수행할 수 있다
  정량적 조사 방법에서는 보통 각 조건 별로 30개 이상의 데이터 포인트를 가져야 통계적 유의성을 확보할 수 있다. 독립 집단 설계에서는 두 사이트 모두에서 30명의 참가자가 필요하지만, 반복 측정 설계에서는 두 사이트를 합쳐 30명의 참가자만 있으면 된다. 두 배나 저렴하다
• 반복 측정 설계는 랜덤 노이즈를 최소화 한다
  💎이것은 반복 측정 설계의 가장 큰 장점이다.
  모든 참가자들은 각자 자신의 백그라운드, 컨텍스트, 상황을 가지고 있을 것이다. 동일한 참가자가 변수의 모든 레벨과 상호작용 하면, 전체에 대해 모두 동일하게 영향을 주고받게될 것이다.
  독립 집단 설계일 경우 만약 행복한 사람과 피곤한 사람이 실험에 참여했을 경우 결과가 원하는대로 나오지 않을 수 있다. 독립 집단 설계에서 각 집단 참가자들을 다른 집단 참가자들과 성향, 백그라운드, 컨텍스트, 상황을 일치시키는게 좋지만, 이 모든것을 예측해서 참가자를 구하기란 불가능하다.

랜덤화는 두 방법 모두에서 필요

반복 측정 설계에서 랜덤화가 필요한 이유는 실험의 순서에서 오는 학습 효과와 조건 간 전이 효과를 반감시키기 위한 것이다.

독립 집단 설계에서 랜덤화는, 참가자가 각 조건에 랜덤하게 배정되어야 한다는 의미이다. 리서처가 좋아하는 사람들을 사이트 A에 배정하고 그 결과가 B보다 좋았다고 하면 안된다는 것이다.

결론

사용자 조사는 독립 집단 설계일 수 도 있고, 반복 측정 설계일 수도 있다. 둘 다 일 수도 있고. 각각의 조사 방법은 장단점이 있으니 이를 잘 고려해 방법을 선택해야 할 것이다.

요약하자면, 다음과 같다

• 반복 측정 설계
  • 더 적은 참가자
  • 더 싼 실험 가격
  • 조건 간 진짜 차이를 알 수 있음
• 독립 집단 설계
  • 조건 간 학습 효과의 최소화
  • 더 짧은 세션 시간
  • 더 쉬운 설계와 더 쉬운 분석

덧, 이 아티클의 내용을 읽으니 📕 원인과 결과의 경제학 책이 연상되었다 👇

이 아티클과 원인과 결과의 경제학은 독립 변수를 조정하여 실험한 결과에서 종속 변수가 변화 했을 때, 독립 변수가 정말로 종속 변수의 변화를 야기 했는지 통계적 유의미성을 확보하기 위한 방법에 대해 말하고 있는 점이 유사했다. 이 아티클에서는 조사 방법론 측면에서 두 방법과 각 방법의 유의점을 소개했고, 원인과 결과의 경제학에서는 통계적으로 유의미성을 증명할 수 있는 방법에 대한 소개가 담겨있다.

이상적으로는 반복 측정 설계 + 랜덤화를 사용하는 것이겠지만, 독립 변수의 개수가 많아진다거나, 조사 설계와 분석 방법에서 걸림돌이 있을 수 있겠다. 통계학에 대한 궁금증이 늘어간다.