[ch3] 실무 프로세스

 

디자인 프로세스

• 기획

문제 정의 : PO/PM과 함께 제품 목표에 따라 우선순위 높은 문제 정함. 회사에 따라 문제 정의 단계는 디자이너 참여 여부가 다르다.

아이데이션 : 앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그중에 적절한 골루션을 고른다.
-솔루션 스케치 : 아이데이션에서 그리는 스케치. 보통 기획과 아이디어가 잘 보이도록 와이어프레임의 형태로 그린다.

프로덕트 스펙 문서 : 디자인에 들어가기 전, 문서에 솔루션에 대해 상세 내용을 글로 먼저 적어보는 것. 디자인이 나오지 않아도 엔지니어가 솔루견을 미리 상상하고 준비할 수 있다는 장점이 있다.

• 디자인

초안 디자인 : 피그마 등의 디자인 툴로 솔루션을 디자인. 디자인 디테일보다는 전반적인 사용자 여정과 UX에 집중해 보면서 프로덕트 스펙 문서에서 놓친 부분이 없는지 살피는 부분이다.

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

최종 디자인 및 핸드오프 : 피드백을 초안에 반영하여 최종 디자인을 확정. 확정안과 필요에 따라선 작성한 가이드를 엔지니어에게 공유하여 개발이 원활히 진행될 수 있도록 돕는다.

핸드오프 : 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것. 디자이너의 의도를 엔지니어가 잘 이해할 수 있도록 아래의 내용을 포함해서 전달.
-유저 플로우 : 처음 시작하는 화면은 어디이고 어떻게 연결되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성.
-유즈 케이스 : 상활에 따른 정의
-반응형 레이아웃 : 대부분의 회사에서는 스크린 크기를 하나 정해 디자인을 하고 반응형으로 대응하기에, 디자인이 어떻게 표현되어야 하는지 가이드가 필요하다.

• 개발

디자인 QA : 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA를 의미하며, 최대한 사용자와 비슷한 환경으로 테스트.

 

프로덕트 스펙 : 제품 요구사항 정의서PRD라고도 부른다.

• 제품을 만들거나 개선할 때 사용하도록 기능 사양을 정의한 가이드 문서.
• 팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드하는 역할.
• 기획 배경과 솔루션, 기능 요구사항, 실험 계획 등을 담고 있으며, 최대한 기획, 디자인, 개발에 필요한 내용을 모두 적고자 한다.

기획 배경과 문제 정의 : 아래의 내용을 포함하여 기획하게 된 배경을 짧게 설명하고 사용자의 문제를 정의한다.
·문제 발견 과정
·문제 정의한 이유
·문제 원인
·문제 영향을 받는 주체

솔루션 설명 : 만들고자 하는 솔루션에 대해 UX/UI 관점에서 아래의 내용을 포함해서 자세하게 설명한다.
·페르소나
·사용자 시나리오
·기능별 주요 특징 & 요구사항
·예외 상황 및 Edge case 정의
·최종 시안

실험 설계 : 솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결 과를 분석할 것인지에 대한 계획을 작성한 것.
·실험 가설 : 문제 해결을 통해 만들고자 하는 결과.
·실험 방식 
·결과 평가 : 문제가 해결되었는지 판단할 수 있는 방법
·실험 기간

예상 일정 : 작업에 필요한 시간을 추정하고 예상 일정을 잘 산정하는 것은 리소스를 효율적으로 쓰기 위한 시작점이기 때문에 프로덕트 스펙에는 꼭 포함되어야 하는매우 중요한 부분이다.

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

 

디자인 공유하고 피드백 받기

• 디자이너의 업무의 대부분은 디자인과 피드백, 거듭되는 수정으로 이루어진다. 
• 기획 배경과 맥락을 잘 이해해야 좋은 피드백이 나올 수 있어, 피드백을 주는 사람이 전체적인 내용을 알 수 있도록 충분한 정보를 함께 전달할 필요가 있다.
• 디자인 피드백을 요청시 고려해야 할 것.
  ·배경 : 구체적인 데이터와 가설 등을 더하여 해당 프로젝트를 기획하게 된 배경을 설명.
  ·솔루션 : 시각적으로 강조하고 싶었던 부분이나 중요하게 생각한 부분 같이 가설에서 어떠한 방향성을 잡고 디자인했는지 설명.
  ·필수 리뷰어 : 다수에게 디자인을 공유할 땐 꼭 피드백을 받고 싶은 사람을 지정하여 참조한다.
  ·참고 문서 : 프로덕트 스펙 문서 같이 전반적인 프로젝트 이해하는 데 도움이 되는 문서들.
  ·피드백 기한 : 제품 개발, 배포 일정에 영향을 주지 않도록 피드백을 받을 수 있는 충분한 여유를 둬야한다.

PM과 PO

• PM : 프로덕트 매니저. 제품의 전략을 세우고, 우선순위를 결정해 실행하는 사람으로, 제품의 전략을 수립하고 아이디어의 우선순위를 정해 디자이너와 함께 솔루션을 설계하는 실제 프로젝트를 수행하는 실무의 성격이 강하다.
• PO : 프로덕트 오너. 제품에 대한 오너십을 갖고 제품이 시장에 잘 전달될 수 있도록 관리하는 사람으로, 제품 팀을 이끌며 제품이 시장에 잘 전달될 수 있도록 관리하며, 이해관계자들과 논의하고, 팀원들이 제품을 잘 만들 수 있는 환경을 만드는 데에도 힘 쓰기에 반적으로 PM보다 더 많은 역할과 책임이 주어진다.
• 둘의 차이 

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

 

엔지니어

• 프론트엔드 엔지니어 : UI 같이 제품과 사용자가 만나는 시각적인 영역의 기능을 코드로 구현하는 사람.
  단순히 그래픽을 구현하는 것을 넘어서 화면 간 이동, 컴포넌트의 모션 등을 코드로 구현하기 때문에 사용자의 경험을 만드는 UX와도 깊게 관련이 되어있다.
• 백엔드 엔지니어 : 서버 엔지니어.
  정보를 저장, 전송하는 것뿐만 아니라 제품 전체를 효율적으로 운영할 수 있도록 구조 구현을 고민한다.
• QA 엔지니어 : 기능이 개발되면 배포하기 전에 테스트를 위해서 QA 테스트를 계획하고 테스트를 진행하여 제품 모니터링을 통해 서비스의 안정성과 전반적인 품질을 높이는 역할. 
• 데이터 애널리스트 : 데이터를 추출해서 수집하고 분석해서 인사이트를 제공한다. 
  데이터를 보기 좋은 형태로 가공하고 시각화하여 제품팀이 의사결정을 올바르게 할 수 있도록 돕는다.
• BX 디자이너 : Brand eXperience. 브랜드 경험과 관련된 전반적인 디자인을 하는 사람.
• UX writer : 제품 내의 문구를 담당하며, 브랜드의 보이스앤톤을 문구로 전달하고, 명확한 메시지를 통해 제품의 사용성을 높이는 일을 한다.

실험

• 사람은 편향적이기 때문에 만드는 사람의 주관이 제품에 반영되기 쉬우며, 이때  데이터로 사용자의 데이터를 확인하여, 객관적으로 의사결정을 할 수 있다.
• 전후 비교 테스트 : 실험 기간 전후로 지표가 어떻게 달라졌는지를 비교해 보는 방법. 보통 A/B 테스트로 진행할 수 없는 상황에서 사용.
• A/B 테스트 : 두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험. 임의의 대조군과 실험군 두 집단으로 나누고 서로 다른 안을 보여주고 어느 집단이 더 좋은 지표를 보이는지를 측정하고 평가한다. 이때, 효과를 정확히 파악하기 위해 변수는 가능한 1개로 제한하는 것이 좋다.

디자인 QA : 제품이 출시되기 전에 기능을 테스트하는 것

• 제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준이 충족되었는지를 확인하는 과정.
• 디자인 QA의 목적

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

• QA 문서
  ·체크리스트 : 예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록으로, 기능이나 개선 범위가 넓지 않을 때 사용한다.
  ·테스트 시나리오 :기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서로, 사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 작성한다.
  ·테스트 케이스 : 특정 조건 아래에서 요구 사항 충족 여부를 확인하기 위한 환경 테스트를 위해 요구 사항을 상세하게 작성한 문서.
  
  
• 디자인 QA  : 디자인이 정확하게 개발되었는지 확인하는 절차.
  
• 이슈의 중요도 정의.
  

Highest	· 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우
High	· 사용자가 행동을 완수할 수 없는 이슈 ·기능상 사용성에 치명적인 문제가 될 수 있는 것
Medium	· 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제 · 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것 · 사용자가 상황을 제대로 이해하기에 어려움이 있는 것 · 시각적으로 오류가 난 것처럼 보이는 것
Low	· 기능상 문제가 없는 것 · 예상 안과는 다르지만, 맥락상 과정을 이해하기에 어려움이 없는 것 · 오픈 후 수정되어도 문제없는 디테일한 부분
Lowest	· 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈