제품팀
제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀.
보통 1명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어로 구성하는 것이 최소 조건.
그 외에도 회사에 따라 제품팀에 데이터 애널리스트, 마케터, BO(Business Operator) 등이 포함될 수 있음.
※ 디자이너는 제품팀에만 속할까?
-> 스타트업에서는 목적조직과 기능조직이 교차하는 매트릭스 조직으로 팀을 구성하기도 함. (하기 설명 참고)
1) 목적조직
특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀.
예를 들어, 핀테크 회사라면 도메인별로 대출팀, 카드팀, 예/적금팀으로 나뉠 수 있음.
일반적으로 제품팀은 이 목적조직을 의미함.
주로 스쿼드나 사일로라고 부름.
제품의 목표를 달성하기 위해 다양한 직무의 사람이 모여있는 팀이기 때문에 속도가 빠르고 효율적이다.
2) 기능조직
유사한 직무끼리 구성된 팀.
예를 들어, 기획팀, 디자인팀, 개발팀 등.
주로 챕터라고 부름.
비슷한 일을 하는 사람들끼리 모여있기 때문에 전문 분야에 대해 깊게 논의하고 서로의 발전을 도울 수 있다.
3) 매트릭스 조직
구성원이 기능조직과 목적조직이 교차된 형태로 소속된 구성.
예를 들어, 프로덕트 디자이너는 기능조직인 디자인팀에 속하면서 동시에 목적조직인 스쿼드에 속할 수 있음.
일반적으로 많은 스타트업이 이 방식으로 일함.
팀의 규모는 회사마다 다를 수 있지만 아마존의 창업자 제프 베조스는 최대 16명을 넘지 않는 것을 추천.
제품팀이 일하는 방식
- 린스타트업
빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영방식.
불확실성이 높은 스타트업에서 제품을 효과적으로 개발하기 위해 고안된 전략.
핵심은 낭비를 줄이는 것으로, 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법.
‘만들기 → 측정 → 학습’을 반복하면서 피드백을 받고 사용자 중심으로 제품을 만드는 것. - 애자일
일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해 나가는 과정을 반복.
린스타트업과 큰 틀은 유사.
애자일은 '날렵한, 민첩한'이라는 뜻.
애자일한 제품팀은 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해 나가는 과정을 반복.
▲ 애자일 방식 용어 정리
스프린트 : 집중해서 여러 태스크를 완료하는 1~4주 정도의 짧은 기간
스크럼 : 1~4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방식. 스프린트에서 설정한 목표에 따라 요구사항 설계 → 디자인 → 개발 → 테스트 → 배포의 과정으로 제품을 개발하는 애자일 방법론의 하나.
이터레이션 : 짧은 주기로 스프린트를 이어 나가는 것. - 애자일 방식의 반대는 폭포수 방식.
UX/UI 실무 프로세스
1. 디자인 프로세스
1) 기획
- 문제 정의 : PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정한다. 회사에 따라 문제 정의 단계에서 디자이너가 참여하기도 하고, 참여하지 않고 따로 PO/PM이 문제를 선정해 공유하기도 한다.
- 아이데이션 : 앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그중에서 적절한 솔루션을 선택. 필요에 따라 러프한 솔루션 스케치를 진행하기도 한다.
- 프로덕트 스펙 문서 작성 : 디자인에 들어가기 전, 문서에 솔루션에 대한 상세 내용을 글로 먼저 적어보기. 디자인이 나오지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다는 장점이 있음. 회사에 따라 생략되거나 PO/PM 직군이 맡아서 하기도 함.
2) 디자인
- 초안 디자인 : 피그마나, 스케치 등의 디자인 툴로 솔루션을 디자인. 디자인 디테일보다는 전반적인 사용자의 여정과 UX에 집중해 보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스는 없는지 살핌.
- 피드백 : 기획 단계에서 논의한 대로 잘 디자인되었는지 팀원들에게 공유하고 피드백을 받는다. 솔루션의 성격에 따라 피그마 프로토타이핑이나 프로토파이 같은 프로토타입 툴을 사용하기도 한다.
- 최종 디자인 확정 및 핸드오프 : 피드백을 초안에 반영하여 최종 디자인을 확정. 확정한 최종 디자인을 엔지니어에게 공유하고 개발이 원활히 진행될 수 있도록 도움. 필요에 따라 가이드를 함께 작성해 전달하기도 함.
디자인 핸드오프에서 지켜야 할 3가지
3) 개발
- 디자인 QA : 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA한다. 최대한 사용자와 비슷한 환경으로 테스트하기. 앱이라면 적어도 안드로이드, iOS 두 환경을 모두 확인하는 것이 좋다.
프로덕트 스펙 문서
제품을 만들거나 개선할 때 사용하는 문서로 기능의 사양을 정의한 가이드
회사에 따라서 PRD(Product Requirements Document, 제품 요구사항 정의서)라고 부르기도 함.
1) 기획 배경 & 문제 정의
기획하게 된 배경을 짧게 설명하고 사용자의 문제를 정의.
<문제 발견 과정, 문제로 정의한 이유, 문제의 원인, 누가 이 문제에 영향을 받는지>이 포함되어야 함.
2) 솔루션 설명
만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세하게 설명.
<페르소나, 사용자 시나리오, 기능별 주요 특징 & 요구사항, 예외 상황 및 Edge Case 정의, 최종 시안>이 포함되어야 함.
3) 실험 설계
솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것인지에 대한 계획.
<실험 가설 - 문제 해결을 통해 만들어 내고자 하는 결과, 실험 방식, 결과 평가 - 문제가 해결되었는지 판단할 수 있는 방법, 실험 기간>이 포함되어야 함.
4) 예상 일정
프로덕트 스펙에 꼭 포함되어야 하는 내용임.
작업에 필요한 시간을 추정하는 예상 일정을 잘 산정하는 것은 리소스를 효율적으로 쓰기 위한 시작점이기 때문에 매우 중요.**
<프로덕트 스펙 초안 작성 완료 예상 일정, UI/UX 디자인 최종 시안 제작 완료 예상 일정, 개발 분야별 예상 일정 - 프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성, 배포 목표 일정>이 포함되어야 함.
Google의 템플릿 참고
디자인 공유하고 피드백 받기
좋은 피드백을 받기 위해선 디자인을 잘 공유하는 것이 중요
<배경, 솔루션의 의도, 필수 리뷰어, 참고 문서, 피드백 기한, 예시> 가 포함되면 좋음.
- 디자인 피드백 요청 예시
[실무 프로세스 1] 협업하기
협업의 질은 곧 제품의 질
협업이란 각 직무의 리소스가 낭비 없이 좋은 솔루션을 만드는 데 집중적으로 쓰이는 것을 의미.
- PM(프로덕트 매니저)
제품의 전략을 세우고, 우선순위를 결정해 실행하는 사람.
제품의 전략을 수립하고 아이디어의 우선순위를 정해 디자이너와 함께 솔루션을 설계하고, 실제 프로젝트를 수행하는 실무의 성격이 강하다. - PO
제품에 대한 오너십을 갖고 제품이 시장에 잘 전달될 수 있도록 관리하는 사람.
PM보다 더 많은 역할과 책임이 주어짐.
이해관계자들과 논의하고, 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경을 만드는 데에도 힘쓴다.
- 엔지니어
1) 프론트엔드 엔지니어
사용자가 만나는 지점, 특히 눈에 보이는 영역의 기능을 구현하는 사람.
앱/웹의 페이지, 화면 안의 각종 컴포넌트 즉, UI를 코드로 구현.
단순히 그래픽을 구현하는 것을 넘어서 화면 간의 이동, 컴포넌트의 모션, 사용자의 인풋에 따른 반응까지 구현하기 때문에 사용자의 경험을 만드는 UX와도 깊게 관련.
2) 백엔드 엔지니어 (= 서버 엔지니어)
제품에 필요한 정보를 저장하거나 전송하고, 관리하는 영역을 담당하는 사람.
정보를 저장, 전송하는 것뿐만 아니라 제품 전체를 효율적으로 운영할 수 있도록 구조를 고민하는 역할도 함.
상대적으로 프론트엔드 엔지니어보다는 디자이너와 접점이 적지만 제품을 만들다 보면 백엔드 엔지니어와도 이야기를 나눌 일이 종종 있음. 예를 들어, 제품에서 특정 정보를 가져와 사용자에게 보여주는 기능이 있다면 저장된 정보를 가져오는 것이기 때문에 백엔드 엔지니어의 의견이 중요.
3) QA 엔지니어
QA 테스트를 계획, 진행하고 제품 전반적인 품질을 높이는 역할을 하는 사람.
기능이 개발되면 배포하기 전에 테스트함.
지속해서 제품을 모니터링하면서 서비스의 안정성과 품질을 지키기 위해 노력함.
4) 데이터 애널리스트
수집하고 분석해서 인사이트를 제공하는 사람.
데이터베이스에서 SQL 같은 언어를 사용해 필요한 데이터를 추출하고, 파이썬 등을 활용해 여러 방면으로 분석하는 일을 함.
데이터를 보기 좋은 형태로 가공하고 시각화하여 제품팀이 의사결정을 올바르게 할 수 있도록 돕는다. - UX/UI 직무
하나의 화면이 완성되기 위해선 UX/UI 디자이너 말고도 다양한 직무의 힘이 필요.
1) BX 디자이너
브랜드 경험과 관련된 전반적인 디자인을 하는 사람.
로고나 심볼처럼 아주 기본적인 것부터 앱/웹에 들어가는 그래픽, 대외에 노출되는 이미지, 각종 인쇄물 등 브랜드를 나타내는 모든 부분을 담당.
2) UX writer
제품 내의 문구를 담당하는 사람.
순히 글을 잘 쓰는 사람이 아니고, 브랜드의 보이스앤톤을 문구로 전달하고, 명확한 메시지를 통해 제품의 사용성을 높인다.
규모가 작은 회사에서는 UX 라이터 직무를 별도로 두지 않고 디자이너가 그 역할을 대신하기도 함.
[실무 프로세스 2] 실험 문화
제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것.
사람은 편향적이기 때문에 만드는 사람의 주관이 제품에 반영되기 쉽다. 데이터로 사용자의 데이터를 확인하면, 객관적으로 의사결정을 할 수 있음. 호불호가 데이터로 증명되기 때문이다.
참고 문서
- 실험은 대부분 A/B 테스트로 진행됨. 이 테스트가 불가능한 경우 전후 비교 테스트를 하기도 한다.
1) 전후 비교 테스트
실험 기간 전후로 지표가 어떻게 달라졌는지를 비교해 보는 방법.
2) A/B 테스트
두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험.
사용자를 임의로 대조군(Control)과 실험군(Treatment), 두 집단으로 나누고 서로 다른 안을 보여준 다음 어느 집단이 더 좋은 지표를 보이는지 측정하여 평가.
디자인 QA
Quality Assurance의 약자로, 제품이 출시되기 전에 기능을 테스트하는 것.
제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준이 충족되었는지를 확인하는 과정이다.
- QA를 할 때 준비해야 할 문서
1) 체크리스트(CL)
예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록.
기능이나 개선 범위가 넓지 않을 때 사용.
2) 테스트 시나리오(TS)
기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서.
사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 적는다.
3) 테스트 케이스(TC)
특정 조건에서 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서.
특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 상세하게 적어야 한다.
