제품팀이란?
제품을 만들기 위해서 다양한 사람들이 모인 조직
최소 포함 직무
-최소 1명의 제품 관리자 PO,PM
-최소 1명의 디자이너
-최소 2명의 엔지니어
추가로 데이터 애널리스트, 마케터, 비즈니스 오퍼레이터등이 있다.
디자이너는 목적조직과 기능조직이 교차하는 매트릭스 조직 팀으로 구성되기도 한다.
목적조직과 기능조직
목적조직 - 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀
세부 분류별로 담당하는 팀이 있다. (EX. 대출팀, 카드팀 등등)
각 팀에는 기획, 디자인, 개발등을 담당하는 사람들이 있다.
빠르고 효율적으로 제품을 만들어 낼 수 있다.
기능조직 - 같은 직무의 사람들끼리 모인 팀
비슷한 일을 하기때문에 전문 분야를 논의하면서 전문성을 높일 수 있다.
매트릭스 조직 - 목적조직과 기능 조직이 크로스된 조직 (한 사람이 두가지 팀에 속한다.)
속도를 빠르게 가져가는 목적조직의 장점과 전문성을 높이는 기능조직의 장점을 가져갈 수 있다.
제품팀이 일하는 방식
1. 린스타트업 - 빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식
학습 - 만들기 - 측정
적게 투자 적게 제품을 만들어 빠르게 시장에 내보고 사용자의 반응을 확인해 본다.
좋은 제품을 만들기 위한 방법들을 많이 학습해야한다
-사용자에게 물어보는 것 (많이,자주)
- 에자일
빠르게 제품을 배포해서 사용자의 피드백을 받고 그것을 바탕으로 제품을 더 잘 만들어보자는 목적
에자일 - 날렵함, 민첩함
제품을 만드는 기간을 1~4주 정도로 잡고 계속 반복해 나감
유연하게 반응할 수 있다.
빠르게 사용자들의 반응을 검증할 수 있다.
에자일의 반대 방식 폭포수 방식
폭포수 방식 - 폭포가 떨어지는 것처럼 수직적으로 각 단계를 거친다.
요구사항 - 디자인 - 개발 - 테스트 - 배포
수직적이고 독립적인 방식
규모가 큰 대기업에 적합한 방식
속도가 느리고 유연하게 대처하기가 어렵다.
스프린트 - 제품을 개발하는 1~4주 정도의 짧은 기간
스크럼 - 스프린트 안에서 빠르게 개발하는 애자일 방법론
이터레이션 - 스프린트를 반복하는 것
UX/UI 실무 프로세스
기획
1.문제정의
-우선순위가 높은 문제르 정함
2.아이데이션
솔루션 스케치 - 아이디를 와이어프레임 형태로 그려 이를 기반으로 이야기를 나눔
3.프로덕트 스펙 문서작성 = PRD(Product Requirements Document, 제품 요구사항 정의서)
-디자인에 들어가기 전 솔루션에 대해 상세하게 글로 작성
-디자인이 나오지 않아도 엔지니아가 솔루션을 미리 상상하고 준비할 수 있다.
-팀원 모두가 같은 생각을 가지고 있는지 확인 할 수 있는 가이드 역할 문서
-기획배경과 솔루션, 기능 요구사항, 실험 계획 등이 포함되어 있어야함
-하나의 문서로 작성하는 것이 좋다
프로덕트 스펙 문서에 들어가는 내용
1. 기획배경&문제정의 - 문제발견과정, 문제로 정의한 이유, 문제 원인
-
솔루현 설명 - (디자이너의 역할이 가장 중요) 페르소나, 사용자 시나리오, 기능별 주요 특징, 요구사항, 에외 상황 및 엣지 케이스 정의, 최종시안
-
실험설계 - 문제정의 -> 솔루션 -> 실험계획 (디자이너가 작성하는 경우는 거의 없음)
-
예상일정
한번 작성하고 끝이 아니라 계속 업데이트 해줘야함
디자인
1.초안디자인
-디자인 디테일보다 전체적인 버드아이 뷰로 바라보기
2.피드백
-논의한 내용대로 디자인이 잘 되었는지 공유하고 피드백을 받는다.
-프로토타이입도 공유하기도 한다.
3.최종디자인 확정 및 핸드오프
-확정된 최종디자인을 엔지니어에게 공유하는 것을 핸드오프라고 한다
핸드오프
디자인한 것을 개발할 수 있도록 엔지니어에게 공유하는 것
엔지니어에게 같이 공유하면 좋은 것
1. 유저 플로우
2. 유즈 케이스 - 상황에 따라 달라지는 화면 정의
3. 반응형 레이아웃 - 다양한 디바이스에 적용이 되야함
개발
1. 디자인QA
-디자인대로 정확하게 개발되었는지 확인
-최대한 사용자와 비슷한 환경으로 테스트
디자인을 공유하고 피드백 받기
좋은 피드백을 받으려면 기획 배경과 맥락을 잘 이해해야한다.
피드백을 주는 사람이 전체적인 내용과 충분한 정보를 알 수 있도록 전달해야한다.
- 배경
- 솔루션의 의도
- 필수 리뷰어 - 불특정 다수에게 받을 수 없음
- 참고 문서
- 피드백 기한 - 업무 가시성 확보
[실무 프로세스 1] 협업하기
협업이란?
협업의 질이 제품의 질을 만든다
각 직무의 리소스가 낭비없이 좋은 솔루션을 만드는데 집중하는 것
PO,PM
PM- Product Manager 약자
제품의 전략을 세우고 우선순의를 결정
전략을 수립하고 디자이너와 함께 아이디어를 구체적으로 솔루션을 만들어 낸다.
PO- Product Owner 약자
PM보다 더 많은 역할과 책임이 주어짐
제품팀을 이끌고 제품이 시장에 잘 전달될 수 있도록 관리
제품을 잘 만들 수 있는 환경을 만듬
이해 관계자들과 논의
권한과 세부적인 역할의 차이가 있다.
PM - 실행위주
실무를 중심으로 프로젝트를 관리
구체적으로 솔루션을 만들 수 있도록 요구사항을 분석하고 전략을 설계하고 지표를 관리
PO - 관리 위주
전체 로드맵을 그리고 제품을 관리
버드아이뷰로 로드맵을 그리고 전략을 설계하고 지표 관리 및 분석 등의 세부업무를 함
회사에따라 조금 씩 다를 수 있음
엔지니어
디자이너가 그린 화면을 실제 동작하게 하는 사람이 엔지니어이기 때문에 소통과 이해가 중요하다.
프론트엔드 엔지니어
눈에 보이는 부분(UI)을 영역을 구현하는 사람
백엔드 엔지니어 = 서버엔지니어
제품에 필요한 정보를 프로세싱하는 업무를 담당
제품에 필요한 정보를 저장하거나 관리하는 사람
QA 엔지니어
배포전 제품의 퀄리티를 테스트를 수행하는 사람
데이터 애널리스트
데이터를 수집하고 분석해서 좋은 인사이트로 좋은 제품을 만들 수 있게 제공해 주는 사람
보기 좋은 형태로 가공하고 시각화하여 제공해줌
UX/UI 직무
BX 디자이너
브랜드 경험과 관련된 전반적인 디자인을 하는 사람
로고, 심볼, 제품에 들어가는 그래픽 등
브랜드 제품의 모든것에 기여
UX writer
제품 내에 문구를 담당하는 사람
어떠한 톤&매너, 이미지를 가지고 있는지 문구로 전달하는 사람
[실무 프로세스 2] 실험 문화
실험
제품의 개선이 실제로 사용자에게 더 나은 경험을 만들었는지 검증하는 것(데이터로 확인)
본인의 주관이 반영되기 쉬움 (공급자가 만들고 싶은 제품이 아니라 사용자가 원하는 제품을 만들어야함)
객관적으로 의사결정을 할 수 있음
A/B테스트
A안 = 대조군 = 원안
B안 = 실험군 = 개선안
변화가 좋은 역할을 했는 효과를 본다.
제품의 개선이 실제로 사용자에게 더 나은 경험으로 만들었는지 검증하기 위해 테스트하는 변수는 1개로 제안한다.
A/B테스트를 하는 이유
제품에 변화를 주면 그 개선이 사용자에게 어떠한 행동을 만들었는지 정보를 얻기위해
변화를 주었을 때 행동이 달라졌다면 상관관계와 인과관계를 알 수 있다.
사용자를 알게 되면 같은 시간에 더 나은 의사결정을 할 수 있다.
앰플리튜드
제품 안에서 일어나는 특정 행동에 이벤트를 심어 해당 행동이 일어났을때 기록을 한다.
그 기록을 데이터로 쌓아 우리에게 보여준다.
이벤트별 분석, 화면별 퍼널 분석, 리텐션 그래프, 유저 구성 등의 기능이 있어 제품에 관한 다양한 데이터를 보고 분석할 수 있다.
구글 애널리틱스
구글에서 제공하는 무료 분석 도구
앰플리튜드
가격이 높아 조직 규모로 사용
제품에서 일어나는 행동을 트레킹
제품팀을 위한 솔루션에 가까움
구글 애널리틱스
일부분은 유료지만 대부분 무료
마케팅 플랫폼이랑 연계성이 좋음
[실무 프로세스 3] 디자인 QA
QA (Quality Assurance)
제품이 출시되기전 기능을 테스트 하는 것
기능을 만든 담당자라면 대부분 직접 QA를 진행한다.
사용자가 제품을 이용할 수 없을 만큼의 치명적인 결함은 업는지 배포전 확인
기대하는 수준의 품질을 갖추었는지 확인
프로덕트 스펙 문서에 작성했던 대로 잘 구현됐는지 확인
특수한 상황에서 예상치 못한 오류는 없는지 확인
전반적인 ux가 사용하기 편한지 확인
QA문서
1. 체크리스트
-예/아니오, Pass/Fail로 답변할 수 있는 성격의 내용을 확인하는 목록
-기능이나 개선 범위가 크지 않을 때 사용
- 테스트 시나리오(TS)
기획한 기능이 모두 동작하는지 사용자의 입장에서 작성하는 문서
사용자가 제품을 경험하게 되는 과정을 이야기의 형태로 상세하게 작성 - 테스트 케이스(TC)
QA가 정교하면 정교할 수록 제품의 품질이 좋다,
원하는 대로 동작하는지 요구사항을 충족하는지 확인하기 위해서 모든 케이스를 작성한 문서
특정 조건 아래 모든 환경을 테스트 할 수 있도록 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 자세하게 적어야 한다.
디자인 QA
디자인과 다른 부분을 발견했다면 팀원들과 내용을 공유하고 수정을 요청한다.
디자인한 화면과 엔지니어가 구현한 화면을 비교하면서 수정할 부분을 전달한다.
잘못 개발된 화면과 원래 디자인 화면과 기획의도를 함께 전달한다.
발견한 이슈를 업무티켓 형태로 전달하는 것을 추천
테스트케이스 작성 + 디자인 QA로 발견한 이슈 공유하기
뱅크샐러드의 회원가입/로그인 과정에서 휴대폰 본인인증 화면에 대한 QA를 한다고 가정
1.테스트케이스 작성하기
2.디자인QA로 발견한 이슈 공유하기
3.추가로 사내 메신저를 통해 엔지니어에게 발견한 이슈를 공유하는 글을 작성해 보세요.
@엔지니어
안녕하세요.
테스트케이스 작성중 이슈를 발견해 수정 요청드립니다.
회원가입 화면에서 이름을 길게 작성할 경우 텍스트가 텍스트 필드를 벗어납니다.
텍스트가 텍스트 필드를 벗어나지 않게 수정부탁드립니다.
참고 문서
-프로덕트 스펙
-피그마파일
-이슈 공유 텍스트케이스
MEDIUM
- 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제
- 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것
- 사용자가 상황을 제대로 이해하기에 어려움이 있는 것
(예시: 네트워크 오류로 팝업이 떠야 하는 상황에서 알 수 없는 오류 팝업이 뜨는 이슈) - 시각적으로 오류가 난 것처럼 보이는 것
이번주 금요일까지 수정 부탁드립니다.
