[UX, UI 디자인 입문 3주차]학습일지

ㆍ제품팀이란?
- 제품을 만들기 위해 각자 다른 전문적인 능력을 가진 사람들이 모인 팀
- 1명의 제품관리자(PO 또는 PM), 1명의 디자이너, 2명의 엔지니어가 제품팀을 구성하는데에 있어 최소한의 구성과 조건
- 제품을 만들기 위해서는 기획-디자인-개발순
- 그 외에도 회사에 따라 제품팀에 데이터 애널리스트, 마케터, 사업적으로 비즈니스가 잘 운영될 수 있게 지원해주는 BO(Business Operator)등이 포함 될 수 있다.

ㆍ린스타트업이란?
- 빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식
- 아이디어, 만들기, 제품, 측정, 데이터, 학습중에서 만들기, 측정, 학습부분을 강화
- 군더더기 없이 낭비를 줄이는 것이 중요 포인트

ㆍ애자일이란?
- 사전적으로 날렵한, 민첩한 이라는 의미를 가지고 있다.
- 애자일한 제품팀은 1~4주 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해나가는 과정을 반복
 
ㆍ폭포수(Waterfall) 방식
- 폭포가 떨어지는 것처럼 수직적으로 각 단계를 하나씩 진행하는 것을 의미한다.
- 각 단계가 완벽하게 완성되었을 때에만 다음 단계로 넘어가고 이전 단계으로는 돌아가지 않는다.
- 요구사항 설계부터 디자인, 개발이 순서대로 독립적으로 진행
- 단계별로 업무 분담이 명확하고 진행 상황파악이 쉽다.
- 하지만 속도가 느리고 변화하는 상황에 유연하게 대처하기 어렵다.

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

========================================================

UX/UI 실무 프로세스 

1)디자인 프로세스

문제정의 - 아이데이션 - 프로덕트 스펙 문서 작성 - 초안 디자인 - 피드백 - 최종 디자인 확정 - 디자인  QA
└                                       [기획]                            ┛     └                        [디자인]                       ┛   └ [개발]  ┛      

========================================================
▶기획
1. 문제 정의
ㆍPO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정한다.

2. 아이데이션
ㆍ앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그 중에서 적절한 솔루션을 선택
ㆍ필요에 따라 러프한 솔루션 스케치 진행

3. 프로덕트 스펙 문서 작성
ㆍ디자인에 들어가기 전에 문서에 솔루션에 대한 상세 내용을 글로 먼저 작성
ㆍ디자인이 나오지 않아도 엔지니어가  솔루션을 미리 상상하고 준비할 수 있다는것이 장점
========================================================
▶디자인
1. 초안 디자인
ㆍ 피그마나, 스케치 등의 디자인 툴로 솔루션을 디자인
ㆍ디자인 디테일보다는 전반적인 사용자의 여정과 UX에 집중

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

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

ㆍ핸드오프란? 
- 공유한 내용을 바탕으로 피드백을 받은것을 초안에 반영하여 최종디자인으로 확정한 디자인을 엔지니어에게 공유하는 것
(디자인을 개발할 수 있도록 엔지니어에게 전달하는 것)
========================================================
☞디자인을 공유할 때 아래의 내용을 포함해 함께 전달하는 것이 좋다.

1.유저 플로우
- 처음 시작하는 화면이 어디이고 어떻게 연결되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성
2. 유즈 케이스
- 상황에 따른 화면을 정의
예시)회원가입 과정에서 일어날 수 있는 정상케이스와 에러 케이스, 타임아웃 케이스 등 다양한 상황이 생길 수 있기에 모든 케이스에서 달라지는 화면을 놓치지 않고 정의해주어야 한다.
3. 반응형 레이아웃
- 스크린 크기 하나를 기준으로 디자인을 하고 반응형으로 대응
- 아주 작은 스크린 크기나 특별한 스크린 크기에 디자인이 어떻게 표현되어야 하는지(엔지니어에게) 가이드를 주는것이 좋다.
========================================================
▶개발
1. 디자인QA
- 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인
- 최대한 사용자와 비슷한 환경으로 테스트
- iOS, AOS 운영체제 둘 다 대응하는 앱이라면 둘 다 확인해보는 것이 좋다.
=========================================================
2. 프로덕트 스펙 문서
- 프로덕트 스펙은 제품을 만들거나 개선할 때 사용하는 문서로 기능의 사양을 정의한 가이드
- 회사에 따라 PRD:제품 요구사항 정의서라고도 함

ㆍ프로덕트 스펙이 왜 필요한가?
- 팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드하는 역할

ㆍ어떤 내용이 들어가는가?
- 기획 배경과 솔루션, 기능, 요구사항, 실험 계획 등을 담고 있다.
- 가능한 한가지의 기획, 디자인, 개발에 필요한 모든 내용을 적는 것이 좋다.
- 문서가 여러 개로 파편화 되어 있다면 한가지의 URL을 첨부해 한 곳에서 볼 수 있도록 하는 것이 좋다.
========================================================

1) 기획 배경 & 문제 정의
- 기획을 하게 된 배경을 짧게 설명하고 사용자의 문제를 정의
문제 정의 시에는 문제 발견 과정, 문제로 정의한 이유, 문제의 원인, 누가 이 문제에 영향을 받는지에 대한 내용이 포함되어 있어야 함

2) 솔루션 설명 (★디자이너의 역할★)
- 만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세하게 설명해야 한다.
- 솔루션 설명에는 페르소나, 사용자 시나리오, 기능별 주요 특징 & 요구사항, 예외 상황 및 Edge case(얘기치 못한 상황) 정의, 최종 시안(URL 첨부)의 내용이 포함되어 있어야 함 

3) 실험 설계(데이터 애널리스트, PM, PO의 역할)
- 실험 가설
- 실험 방식
- 결과 평가
- 실험 기간

4)예상 일정
☞프로덕트 스펙에는 예상 일정을 꼭 포함해야 한다. 작업에 필요한 시간을 추정하고 예상 일정을 잘 산정하는 것은 리소스를 효율적으로 쓰기 위한 시작점이기 때문에 매우 중요함
- 프로덕트 스펙초안 작성 완료 예상 일정
- UX/UI 디자인 최종 시안 제작 완료 예상 일정
- 개발 분야별 예상 일정(프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성 되어야 한다.
- 배포 목표 일정

※프로덕트 스펙 문서는 계속해서 업데이트 되어야 한다.
기획 초기에 만들기 시작해 기능이 배포되고 실험이 종료될 때까지 끊임없이 업데이트하고 관리 되어야 한다.
 
========================================================
협업이란?
- 각 직무의 리소스가 낭비없이 좋은 솔루션을 만드는데 집중적으로 쓰이는 것

PM/PO 이해하기
PM : 프로덕트 매니저는 제품의 전략을 세우고 우선순위를 결정해 실행하는 사람(실무 중심으로 프로젝트를 관리)
PO : 프로덕트 오너는 제품에 대한 오너십을 갖고 제품이 시장에 잘 전달될 수 있도록 관리하는 사람 
(미니 CEO라고도 불리며 제품 전반의 로드맵 및 제품 관리 및 분석하면서 동시에 제품팀의 조직 관리에도 힘씀)

#엔지니어 이해하기
ㆍ왜 엔지니어를 이해해야 할까?
- 디자이너가 그린 화면을 실제 동작하는 화면으로 만들어주는 사람
1.프론트 엔지니어 : 사용자가 만나는 지점, 특히 눈에 보이는 영역의 기능을 구현하는 사람
2.백엔드 엔지니어 : 제품에 필요한 정보를 저장하거나 전송하고, 관리하는 영역을 담당하는 사람
QA엔지니어 : QA테스트를 계획, 진행하고 제품 전반적인 품질을 높이는 역할을 하는 사람
데이터 애널리스트 : 수집하고 분석해서 인사이트를 제공하는 사람

*UX/UI 직무 이해하기
UX/UI 디자이너 말고도 BX 디자이너, UX 라이터의 도움을 받아 협력하여 디자인 제작
========================================================
ㆍ실험 문화란?
- 제품에 대해 개선점을 적용하여 사용자가 좋아하는지 안좋아하는지 검증하는 것
왜 실험해야 할까?
- 사람은 편향적이기 때문에 만드는 사람의 주관이 제품에 반영되기 쉽기 때문에 사용자가 좋아하는 제품을 만들기위해 실험하는 것
- 데이터로 사용자의 데이터를 확인하면 객관적으로 의사결정을 할 수 있다.
- 호불호가 데이터로 증명되기 때문에

ㆍA/B 테스트
-기존 원안(대조군)과 개선안(실험군) 두가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험

ㆍ변수를 1개로 제한해야 하는 이유
- 실험을 하는 목적이 제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터롤 검증하기 위해서이지만 만일 한 번에 여러가지 변수를 놓고 테스트를 한다면 여러가지 변수에서
어떤요소가 어떤 효과를 일으켰는지 정확히 알 수 없기 때문이다.

ㆍA/B 테스트를 하는 이유
- 제품을 어떤 변화(개선안)을 줬을 때 사용자가 어떻게 반응하고 행동하는지 정보를 얻기 위해서
- 변화를 주었을 때 행동이 달라졌다면, 그 안에서 상관관계와 인과관게를 찾아낼 수 있다.
- 거듭된 실험을 통해 제품팀은 사용자에 대한 이해도가 높아지고 더 나은 의사결정을 할 수 있다.

ㆍ실험을 위한 제품 분석 도구
#앰플리튜드
- 제품 안에서 일어나는 특정 행동에 이벤트를 심어두면 해당 행동이 일어났을 때를 기록해 데이터를 쌓고 보여준다. 
- 이벤트별 분석, 화면별 퍼널 분석, 리텐션 그래프, 유저 구성 등의 기능이 있어서 제품에 관한 데이터를 얻고 분석할 수 있다.

#구글 애널리틱스 (GA4)
- 구글에서 제공하는 무료 분석툴로, 대중적인 인지도가 높고 많이들 사용한다
- GA4는 이벤트 중심으로 데이터를 수집하고 특정 페이지 조회, 링크나 버튼 클릭, 스크롤 내리기 등 사용자 상호작용을 기록

 
#앰플리튜드와 구글 애널리틱스의 차이
- 앰플리튜드는 이벤트 기반 분석이면서 제품 팀을 위한 솔루션에 가깝다.(유료)
- 구글 애널리스틱은 일부 기능만 유료이며 마케팅 팀을 위한 솔루션에 가깝다.

#디자인QA
- Quality Ausserance의 약자로 제품이 출시되기 전에 기능을 테스트하는 것

#QA의 목적
- 사용자가 제품을 이용할 수 없을만큼 치명적인 결함은 없는지 배포전에 확인하는 과정
- 조직 전체에서 기대하는 수준의 품질이 갖춰졌는지 확인
- 프로덕트 스펙 문서에서 작성했던 명세대로 잘 구현되었는지 확인
- 특수한 상황에서 예상하지 못한게 작동하지 않았는지 확인
- 전반적인 UX가 사용하기 편리한지 확인

#QA문서 
- 체크 리스트 (CL) : 예/아니오 혹시 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록, 기능이나 개선 범위가 크지 않을 때 사용
- 테스트 시나리오 (TS) : 기획한 기능이 모두 제대로 동작하는지 확인하기 위해 사용자의 기준에서 작성하는 문서, 사용자가 기능을 사용하면서 겸험하게 되는 과정을 상세하게 적는다.
- 테스트 케이스 (TC) : 특정조건에서 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서, 특정조건의 환경에서 테스트 하는것이기 때문에 특정조건, 테스트 범위, 케이스 기대값 테스트 환경 등을 상세하게 적야 한다.

#디자인QA에서 발견한 이슈 공유하기
- 디자인한 화면과 엔지니어가 개발한 화면을 띄워놓고 디자인과 다른 부분을 발견했다면 팀원을과 내용을 공유하고 수정을 담당 엔지니어에게 요청
- 어디가 잘못되었는지 엔지니어가 정확하게 알 수 있도록 작성하는것이 중요하다.
- 잘못 개발된 화면과 원래의 디자인 화면을 기획 의도와 함께 전달하기