제품팀이란~

제품을 만들기 위해 전문적인 능력을 갖춘 사람들이 모인 팀

• 1명의 제품 관리자(PO/PM)
• 1명의 디자이너 (뭐야 3명은 있어야될듯? 막이러시구..)
• 2명의 엔지니어
  ⁕ 데이터 애널리스트, 마케터, BO등이 포함될 수 있다.
  
  

목적조직 (스쿼드/사일로)

• 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀.
• 일반적으로 제품팀이라고 하면 목적 조직을 의미한다.
• 속도가 빠르고 효율적이라는 장점이 있다.

기능조직 (챕터)

• 유사한 직무끼리 구성된 팀 (기획팀, 디자인팀, 개발팀)
• 비슷한 일을 하는 사람들끼리 모여있기 때문에 전문 분야에 대해 깊게 논의하고 전문성으로 높일 수 있다.

매트릭스 조직 (스타트업 방식)

• 기능조직과 목적조직이 교차된 형태
• 아마존 창업자 ⓙⓔⓕⓕ는 최대 16명을 넘지 않는 것을 추천한다.

  피자 두 판의 법칙

  신속하고 효율적으로 운용할 수 있도록 팀원을 피자 두판으로 식사를 해결할 수 있는 수 이내로 유지하라는 원칙
  제가 피자한판 드리겠습니다 허리 피자~ 어깨 피자~ 다리 피자~ 가슴 피자~ 얼굴 피자~ 웃음 피자~ 팔자 피자~ 인생 피자~
  파하하하하하하

제품팀이 일하는 방식

린 스타트업

• 제품을 빠르게 테스트하고 그 결과를 제품에 반영하는 방식
• 불확실성이 높은 스타트업에서 제품을 효과적으로 개발하기 위해 고안된 전략
• 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법
• 만들기 → 측정 →학습 을 반복하면서 사용자 중심으로 제품을 만든다.

애자일 (Agile)

• 일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해가는 과정을 반복한다.
• 제품팀은 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선하는 과정을 반복한다.
• 수평적으로 일하면서 불필요한 의사결정을 줄이고 즉각적인 계획과 실행으로 피드백을 빠르게 반영한다.
• 빠르게 변화하는 환경에 맞추어 기민하고 유연하게 대응할 수 있다는 것이 장점

폭포수방식(Waterfall)

• 수직적으로 각 단계를 하나씩 단계를 진행한다.
• 각 단계가 완벽하게 완성되었을 때만 다음 단계로 넘어가고 이전 단계로는 돌아가지 않는다.
• 요구사항 설계부터 디자인, 개발이 순서대로, 그리고 독립적으로 진행된다.
• 단계별로 업무 분담이 명확하고 진행 상황 파악이 쉽다.

용어
스프린트 : 집중해서 여러 태스크를 완료하는 1~4주 정도의 짧은 기간
                 스타트업에서는 스프린트를 여러 번 반복하며 밀도 있게 일한다.

스크럼 : 1~4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방식
              요구사항 설계 → 디자인 → 개발 → 테스트 → 배포의 과정

이터레이션 : 짧은 주기로 스프린트를 이어 나가는 것

---

UXUI 실무 프로세스

디자인 프로세스

기획

       1. 문제정의

• PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정한다.

  2. 아이데이션

• 문제를 해결할 다양한 아이디어를 내고, 그 중에서 적절한 솔루션을 선택한다.
• 필요에 따라 러프한 솔루션 스케치를 진행하기도 한다.
  솔루션 스케치란 기획과 아이디어가 잘 보이도록 와이어 프레임의 형태로 그린 것

  3. 프로덕트 스펙 문서 작성

• 디자인에 들어가기 전, 솔루션에 대한 상세 내용을 글로 먼저 적는다.
• 디자인이 준비되지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다.

디자인

          1. 초안 디자인

• 피그마, 스케치 등의 디자인 툴로 디자인 한다.
• 디테일보다는 전반적인 UX에 집중하면서 프로덕트 스펙 문서에서 놓친 엣지케이스는 없는지 살핀다.

          2. 피드백

• 기획 단계에서 논의한 대로 잘 디자인되었는지 팀원들에게 공유하고 피드백을 받는다.
• 솔루션의 성격에 따라 피그마 프로토타이핑/프로토파이같은 프로토타입 툴을 사용하기도 한다.

          3. 최종 디자인 확정 및 핸드오프

• 피드백을 초안에 반영하여 최종 디자인을 확정한다.
• 최종 디자인을 엔지니어에게 공유하고 개발이 원활히 진행될 수 있도록 한다.

  핸드오프란

  디자인을 개발할 수 있도로 엔지니어에게 전달하는 것
  
  - 유저 플로우 : 사용자가 특정 목표를 달성하기 위해 서비스나 제품 내에서 거치는 모든 단계를 시각적으로 표현한 흐름도
  - 유즈 케이스 : 상황에 따른 화면 정의. 사용자가 시스템을 통해 특정 목표를 달성하는 방법을 사용자 관점에서 설명한 것
  - 반응형 레이아웃 : 다양한 기기의 화면 크기에 맞춰 자동으로 최적화되어 보이는 디자인 방식.
                                 대부분의 회사에서는 스크린 크기를 하나 정해 디자인을 하고 반응형으로 대응한다.

  개발

          디자인 QA

• 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 과정
• 최대한 사용자와 비슷한 환경으로 테스트한다.
• if) 앱, 안드로이드,ios 모두 확인하기!

프로덕트 스펙문서

제품을 만들거나 개선할 때 사용하는 문서로 기능의 사양을 정의한 가이드
기획 배경과 솔루션, 기능 요구사항, 실험 계획 등을 담고 있다.

1) 기획배경 & 문제정의

기획하게 된 배경을 짧게 설명하고 사용자의 문제를 정의한다. 아래의 내용이 포함되어야 한다.

• 문제 발견 과정
• 문제로 정의한 이유
• 문제의 원인
• 누가 이 문제에 영향을 받는지

2) 솔루션 설명

만들고자 하는 솔루션에 대해 UX/UI 관점에서 설명한다. 아래의 내용이 포함되어야 한다.

• 페르소나
• 사용자 시나리오
• 기능별 주요 특징 & 요구사항
• 예외 상황 및 Edge Case 정의
• 최종 시안

3) 실험 설계

솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것인지에 대한 계획

• 실험 가설
  • 문제 해결을 통해 만들어 내고자 하는 결과
• 실험 방식
• 결과 평가
  • 문제가 해결되었는지 판단할 수 있는 방법
• 실험 기간

4) 예상 일정

작업에 필요한 시간을 추정하고 예상 일정을 잘 산정하는 것은
리소스를 효율적으로 쓰기 위한 시작점이기 때문에 매우 중요

• 프로덕트 스펙 초안 작성 완료 예상 일정
• UX/UI 디자인 최종 시안 제작 완료 예상 일정
• 개발 분야별 예상 일정
  • 프론트엔드, 서버, 이벤트 설계, QA 가 각각 세부적으로 작성되어야 한다.
• 배포 목표 일정

디자인 공유 / 피드백

• 피드백을 주는 사람이 전체적인 내용을 알 수 있도록 충분한 정보를 함께 전달한다.

  디자인 피드백을 요청할 때 포함하면 좋은 것

  항목	설명
  배경	디자인 기획의 출발점과 구체적인 가설을 명확히 제시한다.
  솔루션 의도	디자인이 어떤 방향으로 문제를 해결하려 했는지 설명한다. 시각적으로 강조하고 싶었던 부분/ 중요하게 생각한 부분도 적는다.
  필수 리뷰어	피드백을 꼭 받고 싶은 대상을 지정하여 효율을 높인다.
  참고 문서	프로젝트 이해를 돕는 관련 프로덕트 스펙 문서나 프로토타입을 첨부한다.
  피드백 기한	피드백 제출 마감일을 명시하여 일정 관리에 도움이 된다.

[실무 프로세스 1] 협업하기

협업이란~

• 각 직무의 리소스가 낭비 없이 좋은 솔루션을 만드는 데 집중적으로 쓰이는 것
• 더 좋은 퍼포먼스를 낼 수 있도록 돕고 시너지를 낼 수 있도록 하는 것이 좋은 협업이다.

PO/PM

PM (Project Manager)

• 제품의 전략을 수립하고 아이디어의 우선순위를 정해 디자이너와 함께 솔루션을 설계한다.

PO (Project Owner)

• 제품팀을 이끌며 제품이 시장에 잘 전달될 수 있도록 관리한다.

PO vs PM

PM	PO
• 실무 중심으로 프로젝트를 관리한다.	• 제품 전반의 로드맵을 그리고 제품을 관리한다.
• 요구사항 분석, 전략 설계, 지표 관리 및 분석 등의 업무를 수행한다.	• 로드맵과 전략 설계, 지표 관리 및 분석 등의 업무를 하며 동시에 제품팀의 조직 관리에도 관여한다.

엔지니어

디자이너가 그린 화면을 실제 동작하는 화면으로 만들어 주는 사람들

프론트 엔드 엔지니어

사용자가 만나는 지점, 눈에 보이는 영역의 기능을 구현하는 사람

• 앱/웹의 페이지, 화면 안의 각종 컴포넌트 즉, UI를 코드로 구현한다.
• 그래픽 구현을 넘어 화면간의 이동, 컴포넌트의 모션, 사용자의 인풋에 따른 반응도 구현한다.

백엔드 엔지니어 (서버 엔지니어)

제품에 필요한 정보를 저장하거나 전송하고, 관리하는 영역을 담당하는 사람

• 정보를 저장, 전송하는 것 뿐만 아니라 제품 전체를 효율적으로 운영할 수 있도록 구조를 고민한다.

QA 엔지니어

QA테스트를 계획, 진행하고 제품 전반적인 품질을 높이는 역할을 한다.

• QA엔지니어는 기능이 개발되면 배포하기 전에 테스트를 한다.
• 지속해서 제품을 모니터링하면서 서비스의 안정성과 품질을 지키기 위해 노력한다.

데이터 애널리스트

수집하고 분석해서 인사이트를 제공하는 사람

• 데이터베이스에서 SQL 같은 언어를 사용해 필요한 데이터를 추출하고, 파이썬 등을 활용해 여러 방면으로 분석하는 일을 한다.
• 데이터를 보기 좋은 형태로 가공하고 시각화하여 제품팀이 의사결정을 올바르게 할 수 있도록 돕는다.

UX/UI 직무

BX (Brand eXperience) 디자이너

브랜드 경험과 관련된 전반적인 디자인을 한다.

• 로고나 심볼처럼 아주 기본적인 것부터 앱/웹에 들어가는 그래픽, 이미지, 각종 인쇄물 등 브랜드를 나타내는 모든 부분을 담당한다.

UX writter

제품 내의 문구를 담당하는 사람

• 브랜드의 보이스앤톤을 문구로 전달하고 명확한 메시지를 통해 제품의 사용성을 높이는 일

[실무 프로세스 2] 실험 문화

실험이란~

제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것

• 실험은 대부분 A/B 테스트로 진행된다.

  A/B 테스트

  두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험

• 사용자를 임의로 대조군(Control)과 실험군(Treatment), 두 집단으로 나누고 서로 다른 안을 보여준 다음 어느 집단이 더 좋은 지표를 보이는지 측정하여 평가

• A/B 테스트의 효과를 정확히 파악하기 위해 테스트하는 변수는 가능한 1개로 제한하는 것이 좋다.

  실험을 위한 제품 분석 도구

  앰플리 튜드

  구글 애널리틱스 (GA4)

[실무 프로세스 3] 디자인 QA

QA란~~ (Quality Assurance)

제품이 처음 기획한 대로 구현 되었는지, 회사에서 생각하는 품질 기준이 충족되었는지를 확인하는 과정

목적

• 조직에서 기대하는 수준의 품질이 갖춰졌는지 확인한다.
• 프로덕트 스펙 문서에서 작성했던 대로 구현되었는지 확인한다.
• 사용자가 제품을 이용할 수 없을 만큼의 치명적인 결함이 없는지 확인한다.
• 특수한 상황에서 예상하지 못한 대로 동작하지 않는지 확인한다.
• 전반적인 UX가 사용하기 편리한지 확인한다.

QA 문서

체크리스트 (CL)

• 예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록
• 기능이나 개선 범위가 넓지 않을 때 사용한다.

  테스트 시나리오 (TS)

• 기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서
• 사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 적는다.

  테스트 케이스 (TC)

• 특정 조건에서 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서
• 특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 상세하게 적어야 한다.

디자인 QA

디자인이 정확하게 개발되었는지 확인하는 과정

디자인QA에서 발견한 이슈 공유하기~

• 어디가 잘못되었는지 엔지니어가 정확하게 알 수 있도록 작성하는 것이 좋다.

• 잘못 개발된 화면과 원래의 디자인 화면을 기획 의도와 함께 전달한다.

  이슈 중요도 정의하기

  HIGHEST
  

• 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우
  
  HIGH
  

• 사용자가 행동을 완수할 수 없는 이슈

• 기능상 사용성에 치명적인 문제가 될 수 있는 것
  
  MEDIUM

• 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제

• 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것

• 사용자가 상황을 제대로 이해하기에 어려움이 있는 것
  (예시: 네트워크 오류로 팝업이 떠야 하는 상황에서 알 수 없는 오류 팝업이 뜨는 이슈)

• 시각적으로 오류가 난 것처럼 보이는 것
  
  LOW

• 기능상 문제가 없는 것

• 피그마 화면과는 다르지만, 맥락상 과정을 이해하기에 어려움이 없는 것

• 오픈 후 수정되어도 문제없는 디테일한 부분

  
  LOWEST

• 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈

  ---

너무 부러워.