Chapter 17-01. 고객 경험을 만드는 PM 전략

1️⃣ 프로덕트를 만드는 사람들

서비스 기획자/PM/PO	개발자	디자이너
CEO, 개발자, 디자이너 사이에서 프로덕트를 기획하는 업무를 수행. UX(사용성, 적합성), Business(시장성), Tech(구현 가능성)의 이해가 필요. 서비스 기획자는 보통 waterfall 방식 기획. PM, PO는 agile 방식으로 기획. 비즈니스 기획자 보다 사용자를 조사하고 고객 경험을 설계.	프로덕트 구현. 골자를 잘 구현해야 함. 데이버베이스 서버, 이미지 서버가 나눠져 있음. 안드로이드, ios 개발자는 따로 나눠져있는 것이 좋음.	레이아웃 디자인을 설계. 디자인을 완료 후 프론트엔드에게 산출물 전달.

🔷  서비스 기획자 / PO,PM

	서비스 기획자	PO	PM
문제의 본질을 이해하고 사용자들에게 전달할 서비스의 가치를 만들어나가는 역할
방식	waterfall	agile 색으로 각 스프린트를 나눈다 스프린트에서 공유 문서 1. 개발 완료. 2. 완료하지 못한 개발. 3. 기술적 이슈/버그. 4. 회고. 5. OKR 달성 상황. 6. 이번 스프린트에 개발할 사항.
필요 역량	커뮤니케이션 스킬 UX/UI 디자인, 리서치, 논리적 사고 기술 이해 및 다양한 학문의 이해	고객을 대변하며 사업 가티를 창출할 수 있는 역량. 가설을 설정, 검증, 요구사항 정의. 데이터분석. 인사이트 발굴. 업무할당, 백로그 관리.	개발 조직과 협의 일정 정의. 구체적인 개발 티켓 생성 관리. 협업 시 테스트 진행. 테스트 진행. 사용 설명서 작성 배표. 문의 사항 답변.
결과물	UX Design 전략수립 프로덕트 설계 .IA 기능정의 wireframe workflow

 

---

2️⃣ 프로덕트 목표와 지표 설정하기

🔷 OKR(목표 핵심 결과)

• 분기단위로 목적을 설정
• 측정 가능한 지표로 key result를 설정
• 무엇을 어떻게 할것인가를 담고 있어야 함.
• 공식적이고 투명함.
• 상향식 혹을 수평식.
• 보상과 무관한 공격적이며 도전적인 목표.
• 마무리 객관적인 점수로 평가와 분석이 필수.

목표 정의	핵심 결과	핵심지표를 이루를 3가지 요소
명확한 목적 공격적인 달성 목표 주기 마다 설정(팀, 1면마다) 집중을 위해 한개만 설정 매주~2주 단위로 측정	측정가능한 정량적인 지표로 설정 비교가능 하도록 기준점 수치를 기록 달성을 위한 구체적 계획이 있어야 함.	달성 기간 행동 지표 정량적 수치

🔷 Key result 설정 지표

• AARRR 지표
  • 유입, 활성화, 유지, 추천, 매출 5단계에 맞는 특정 지표를 기준으로 서비스 상태를 가늠할 수 있는 효율적인 지표.
  • 유입 - 유입 경로, DAU, MAU, New user
  • 활성화 - 채류기간, 이탈률, 사용자 흐름.
  • 유지 - 재방문률, 전환율.
  • 추천 - 공유채널별 공유 비율.
  • 매출 - 매출, 전환율을 높이는 목표.
• PV : 페이지 뷰, 페이지가 사용자에게 노출되는 지표.
• UV : 데이터 수집 기간 동안 페이지에 방문한 전체 사용자(중복은 제외)
  • UV와 PV 특정 기간의 증감 추게가 큰 날을 찾아 인사이트를 발견.
• 전환율 : 방문한 사용자 중 특정 행위를 한 방문자의 비율 지표.
• 이탈율 : 페이지와 상호작용하지 않고 사이트를 떠난 단인페이지 세션의 비율 지표.
• 종료율 : 방문한 모든 페이지 대상을로 1개 이상의 페이지를 보고 화면을 종료한 방문 행동 비율 지표.

🔷 데이터 분석 목적

• 분석 시 조직의 이슈 기반으로 생각.
• 패턴에서 발견되는 변화/추세로 인한 인사이트 발견이 중요.
• 문제 개선을 위한 가설을 수립하고, 조직에 공유하고 공감대 형성.
• 데이터 분석하여 비즈니스 기여에 성과를 창출할 수 있는지 고민하고 우선순위 설정.

---

3️⃣ 프로덕트 관리 및 산출물

현황 분석	포지셔닝	기획 및 디자인	구현 및 검증
시장 분석 경쟁사 분석 자사 분석 고객 분석	고객 세그먼트 타겟 고객 선정 사이트 포지셔닝	서비스 컨셉 및 전략 IA 설계 화면 설계 콘텐츠 제작 디자인 테스트	서버 개발 UI 개발 프론트 개발

1. 프로젝트 기간 수립
   • 개발 담당자와 협의하여 목표 일정을 수립
   • 초기 단계임으로 변경 가능 함.
2. 일정 관리
   • WBS : 업무 일정 확인용.
   • 요즘 jira로 실시간으로 할당/상황 파악.
3. 프로덕트 배포
   • 개발 조직이 정한 일정이나 절차 확인.
   • 배포 일정과 변경 사항을 협업팀에 공유.
   • 저녁 늦게 또는 금요일에 배포 금지.(앱스토어는 마감이 보통 목요일!)
   • 사용률이나 매출이 급증하는 기간에는 배포 지양.
   • 플렛폼 일정을 고려 (특정 기관의 검토/승인, ios 안드로이드 가이드라인, 플렛폼 배포 순서와 일정을 다르게 진행)
4. 배포 주기를 정해서 배포
   • 여러 팀이 동시에 배포를 시도하면 기술적 문제 발생가능성이 높음.
   • 버젼 관리의 어려움.
   • 자주 업데이트 하는 것은 고객 경험의 일관적 유지가 어려움.

🔷 산출물

• RFP(request for proposal) : 제안 요청서, 의뢰업체가 위탁업체를 선정하기 위해 작성.
  • 요청 제한서 제출 일자.
  • 선정 기준을 위한 가이드라인(의도, 방향성).
  • 프로젝트 소개, 목표, 일정(F/U기간 명시), 제안서 가이드라인, 평가 기준, 결과발표 기간 명시.
• 메뉴 구조도 : main struture를 파악할 수 있는 메뉴 구조도.
• IA : 정보 구조 설계, 어떤 기능을 하는 화면들이 어떤 뎁스, 기준 문서
• wireframe : 화면 단위 구조를 설계하는 작업
  • 이해 관계자 들과 레이아웃, 기능, 콘텐츠들을 협의하기 위해 설계
  • 페이지 목적에 집중.
  • 요소만 정의.
  • 텍스트는 속성으로 작성하거나 예시로 작성.
• user flow : 실 사용자들이 구체적으로 이용하는 순서에 따라 화면들이 전개되는지 정의
  • 화면 간 흐름 제공
  • 일관된 사용자 경험을 제공
  • 복잡한 흐름을 쉽게 파악
  • case 와 error 체크

🔷  small test 

-> 처음 접하는 기능을 또는 디자인을 어떻게 사용하는지 small test 가능.

2차 시안 완성 후 최종안에 가까운 디자인 UT로 진행

🔸 준비

• 조건을 명확하게 정의한 후, 테스트 대상 섭외.
• 테스트 도중 검중 사항을 미리 정해 놓음.
• 참여자는 5명 이상.(5명만 테스트해도 85% 문제를 발견할 수 있다 - 제이콥 닐슨)

🔸 장점

• 고객의 의견을 빠르게 확인 할 수 있음.
• 제작자 입장에서 간과한 사실들을 확인.
• 사용자의 불편함, 예상치 못한 행동을 확인.

 

---

4️⃣  Usability 휴리스틱

제이콥 닐슬이 만들 사용성을 평가하기 위한 척도로 사용되는 10가지 기준.

신규 서비스를 출시 하기 전 체크 리스트

NO
1	시스템 상태의 시각화	기기의 상태(와이파이), 로딩 중일 때, 비어있는지 등 어떻게 시각적으로 표현 할지. 연결이 끊어졌어요, 로딩 중입니다, 장바구니가 비어있어요..
2	시스템과 실제 세계의 일치(metaphor)	사람들은 본인의 경험을 기반으로 새로운 시스템의 동작을 히애함. 실제 세계와 일치하는 모델을 차용하면 사용자의 인지에 도움. 카드 일렬번호 입력 시 카드모양..
3	사용자 제어와 자유	사용자들이 무의식중으로 기능을 수행하거나 의도하지 않앗던 경로로 이동하는 경우가 있음. 그 상황을 취소하거나 빠져나올 수 있는 기능 제공.
4	일관성과 표준	디자인 표준을 준수하고 일관성을 유지하면 빠르게 예측 가능, 학습에 도움. 다른 어플리케이션에서도 따르고 있는 익숙한 플랫폼 가이드라인을 따르면 사용자들이 새로운 서비스일지라도 길을 잃지 않도록 친숙한 기능 제공. 아이콘, 비슷한 앱에서 사용되는 디자인, 우리만의 디자인..
5	에러 방지	사용자가 에러를 발생할 수 있는 상황을 미연에 방지. 액션 버튼 활성화, 유효성 체크 방식, 알림창..
6	에러 인식, 진단, 복구	에러를 사용자들이 인식하고 복구 할 수 있도록 디자인. 에러를 명확하게 보여주고 대안을 찾을 수 있어야 함.
7
8
9
10

---

5️⃣ 개발 플랫폼 특징

Web	App
기준 해상도 정의	표준 OS 설정
브라우저 호환성 강함	브라우저 호완성 약함
마우스 키보드 인터페이스	터치 인터페이스
넓은 레이아웃 안의 정보 우선순위에 대한 배치	제한된 레이아웃 안의 정보 우선순위대한 노출 순서
웹 접근선 준수	앱 접슨성 준수
웹 표준 준수 (HTML css javascript)	앱 표준 가이드라인

 

🔷 개발 플랫폼 정의 기준

1.  서비스 목적
2. OS에서 제공하는 기능 활용도
3. 콘텐츠 변경 주기

🔸 먼저 어느것 부터 출시할까?

국내 OS(operating system) 점유율은 Statcounter에서 확인 가능.
edit -> operating system -> mobile

현재 한국에선 안드로이드가 68%로 높기때문에 안드로이드가 우세하여 한국에선 안드로이드를 먼져 출시하는 것이 유리.

타겟 유저들에 따라 달라질 수 있기때문에 연령층도 확인.

 

🔷 App

🔸 Native app

해당 앱스토어에서 다운로드 가능하고 해당 OS에서 실행 가능

장점	단점
다양한 기능, UI를 모두 이용 가능 (카메라, 마이크..)	해당 OS에서만 다운로드/실행 가능.
빠르고 안전적, 반응이 빠른 환경	수정 사항 발생 시 앱을 업데이트 배포.
	언어에 제약이 있음
- 필수로 사용되어야 하는 플랫폼이 있는 경우 사용. - 앱기능이 많고 복잡한데 성능이 뒷받침이 되어야하는 경우 사용.

 

🔸  Moblie Web

브라우저에 URL만 입력하면 어떤 디바이드에서도 동일한 내용 확인

장점	단점
어떤 플랫폼이든 동일한 콘텐츠	OS에서 제공하는 모든 기능을 활용하기 힘듬.
개발 시 적은 시간과 비용	네이티브, 하이브리드 보다 검색, URL 접근 실행이 까다로움.
삐르게 업데이트
- 다중 플랫폼 지원이 필요한 경우, 많은 사용자들이 다양한 채널을 통해 동시 접속 때 동일한 서비스를 제공하는 목적 시 사용. - 콘텐츠가 빈번하게 변경될 때 사용.

 

🔸  Hybrid App

Native app +  Moblie Web,  Native app에 웹 뷰를 띄워 실행

면세점 등

장점	단점
네이티브 API와 브라우저 API를 이용한 다양한 개발 가능. app과 유사한 UI, 스마트폰 제어 기능.	복작한 navigation 동선 문제 발생.
크로스 플랫폼 대응 가능, 상대적 유지보수 쉬움.	네이디브 기능에 접근하기 위해 해당 개발 지식이 필요.
- 다중 플랫폼 지원이 필요한 경우, 많은 사용자들이 다양한 채널을 통해 동시 접속 시 동일한 서비스를 제공하는 목적 시 사용. - 콘텐츠가 빈번하게 변경될 경우 사용.

 

🔷 Web

🔸 적응형 웹

데스크탑 버전, 모바일 버전의 사이트를 각각 제장해 운영

수정 시 작업을 중복하여 비효율적

 

🔸 반응형

하나의 소스코드로 모든 스크린에 최적화된 웹 사이트를 구축할 수 있는 방법.

브라우저의 가로 넓이에 반응하여 구성요소가 변경하는 기능.

초기 시간은 많이 들지만, 유연하에 반응하여 유지보수 시 편함.