3주차 강의
01. 제품팀이란?
1) 제품팀이란?
- 목적조직 (스쿼드/사일로) : 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀 ex) 핀테크 : 대출팀, 카드팀, 예/적금팀
- 기능조직 (챕터) : 유사한 직무끼리 구성된 팀 ex) 기획팀, 디자인팀, 개발팀
- 매트릭스 조직 : 기능조직과 목적조직이 교차된 형태로 소속된 구성. 일반적으로 스타트업에서 이 방식을 사용. 팀 최대 16명. ex) 한 핀테크 프로덕트 디자이너의 소속 : 디자인팀(기능) + 대출팀(목적)
2) 제품팀이 일하는 방식
- 린스타트업
- 애자일
- 폭포수
02. UX/UI 실무 프로세스
디자인 프로세스
기획 📝 ‣ 디자인 🎨 ‣ 개발 🤖
기획
1. 문제정의 ‣ 2. 아이데이션 ‣ 3. 프로젝트 스펙 문서 작성
📑 프로덱트 스펙 문서
프로덱트 스펙 문서 / PRD (Product Requirements Document, 제품 요구사항 정의서)
: 제품을 만들거나 개선할 때 사용하는 문서로 기능의 사양을 정의한 가이드.
🔔 필요한 이유: 팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드 하는 역활.
✅ 필요 내용 : 기획 배경&솔루션, 기능 요구사항, 실험 계획, 예상 일정
디자인✱
4. 초안디자인 ‣ 5. 피드백 ‣ 6. 최종 디자인 확정 및 핸드오프
🗯 디자인 공유하고 피드백 받기
🔔 디자이너의 업무 대부분은 디자인과 피드백, 거듭되는 수정으로 이루어진다. 그렇기에 좋은 피드백을 받기 위해선 디자인을 잘 공유하는 것이 중요합니다.
✅ 디자인 피드백을 요청할 때 포함하면 좋을 것
: 배경, 솔루션의 의도, 필수 리뷰어, 참고 문서, 피드백 기한
📄 핸드오프란?
: 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것을 의미.
✅ 포함되면 좋은 내용
1. 유저 플로우
2. 유즈 케이스 : 상황에 따른 화면 정의
ex) 회원가입 화면 - 정상 입력, 입력값 오류, 입력 가능 시간 초과 등
3. 반응형 레이아웃
개발
6. 디자인 QA
- 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA를 진행.
- 최대한 사용자와 비슷한 환경으로 테스트하세요.
- 앱이라면 적어도 안드로이드, iOS 두 환경을 모두 확인하는 것이 좋습니다.
03. [실무 프로세스 1] 협업하기
1) 협업이란?
🔔 각 직무의 리소스가 낭비 없이 좋은 솔루션을 만드는 데 집중적으로 쓰이는 것을 의미.
2) PO/PM 이해하기
PM
제품의 전략을 세우고, 우선순의를 결정해 실행하는 사람
PO
통칭 미니CEO, 제품에 대한 오너쉽을 갖고 제품이 시장에 잘 전달될 수 있도록 관리하는 사람. 이해관계자들과 논의하고, 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경을 조성.
PM과 PO, 어떻게 다를까요?
PM은 실무 중심, PO는 제품 전반 관리 및 관망
*조직마다 역할이 겹치거나 다를수도 있다.
3) 엔지니어 이해하기
프론트엔드 엔지니어
: 사용자가 만나는 지점을 개발 ui 구현 디자이너와 가장 자주 소통
백엔드
: 서버 엔지니어, 접점은 조금 적음 하지만 이야기 나눌때가 종종 있다. 화면에서 테이터를 보여주고 싶을대 뒤(서버)에서 데이터를 가져오기 때문에 백앤드가 중요.
큐에이 엔지니어
: QA 테스트를 수행하는 사람, 퀄리티 관리 조직에 따라 유무가 다르다.
데이터 애널리스트
: 데이터를 수집하고 분석해서 인사이트를 제공하는 사람.
데이터베이스에서 SQL 같은 언어를 사용해 필요한 데이터를 추출하고, 파이썬 등을 황요해 여러 방면으로 분석하는 일.
데이터를 가공 및 시각화해 제품팀이 의사결정을 올바르게 할 수 있도록 돕습니다.
4) UX/UI 직무 이해하기
BX디자이너
브랜드 브랜드에 영향을 끼치는 모든 부분을 디자인.
UX writer
톤앤메너를 고민하고 어떻게 전달할지 고민한다. 브랜드 메세지를 담당.
04 [실무 프로세스 2] 실험 문화
1) 실험이란?
돈이나 시간, 사람에 대한 리소스 부족으로 빠르게 제작 및 검증이 필수, 사용자들에 나은 경험을 주었는지 데이터로 검증하는 것
✅ 실험의 이유
- 사람은 주관적이고 편향적이다. 사용자가 원하는 제품이 아니라 공급자가 원하는 제품을 만들 수 있다.
- 데이터로 사용자의 정보 확인 시 객관적으로 의사결정 할 수 있다.
- 호불호가 데이터로 증명 된다.
2) 실험 환경 이해하기
∙ A/B 테스트 : 대부분의 실험에서 사용됨
- a안 대조군(원안)에서 변화를 준 개선안 b안은 실험군이 좋은 경험을 주는 지 확인
- 변수는 1개로 제한 : 정확한 인과관계와 상관관계를 알 수 있다.
✔️ A/B 테스트를 하는 이유
제품에 변화를 줬을 때 사용자가 어떻게 반응하고 행동하는 지 정보를 얻기 위해서입니다.
✔️ 실험을 위한 제품 분석 도구
-
🔗앱플리튜드
: 제품 안에서 일어나는 특정 행동에 이벤트를 심어두면 해당 행동이 일어났을 때를 기록해 데이터를 쌓고 보여줌.
이벤트별 분석, 화면별 퍼널 분석, 리텐션 그래프, 유저 구성 등의 기능이 있어서 제품에 관한 다양한 데이터를 얻고 분석할 수 있다. -
🔗구글 애널리틱스 (ga4)
: 무료 분석툴, 구번전이 구글 애널리틱스에서 GA4(Google analytics 4)로 버전이 변경됨 - 구분을 잘해야 한다.
GA4 : 이벤트 중심으로 데이터 수집하고 특정 페이지 조회, 링크나 버튼 클릭, 스크롤 내리기 등 사용자 상호작용을 기록한다. -
두 사이트의 차이 :
- 가격
- 앰플리튜드는 제품팀을 위한 플랫폼/구글은 마케팅 업무와 잘맞음
- 이벤트 기반 분석이 대세 - 둘 다 서비스 제공 중
∙ 전후 비교 테스트 : A/B 테스트 설계를 할 수 없을 경우나 특정한 상황에서 사용됨.
- 실험 기간 전후로 지표가 어떻게 달라졌는지를 비교해 보는 방법.
05. [실무 프로세스 3] 디자인QA
1)QA란?
Quality Assurancce, 제품이 출시되기 전에 기능을 테스트하는 것을 말한다.
출시 전 마지막 테스트
QA의 목적
- 사용자가 제품을 이용할 수 없을 만큼의 치명적인 결함은 없는지 확인
- 조직 전체에서 기대하는 수준의 품질이 갖춰졌는지 확인
- Product Spec 문서에서 작성했던 명세대로 잘 구현되었는지 확인
- 특수한 상황에서 예상하지 못한 대로 동작하지는 않는지 확인
- 전반적인 UX가 사용하기 편리한지 확인
2) QA 문서
체크리스트(CL)
: 가장 간단한 버전 문서, 에/아니요로 대답. 작은 요소를 확인하기 위한 용도
ex) 가벼운 질문으로도 확인할 수 있는 작은 배포 때 유용
- 버튼을 눌렀을 때 색상이 변하나요?
- 버튼을 눌렀을 때 A 페이지로 이동하나요?
테스트 시나리오(TS)
: 사용자 입장에서 작성하는 문서, 이야기 형식, 사용자가 기능을 경험하는 과정을 상세하고 자세하게 적어야 한다.
ex) 회원가입 flow를 테스트하는 상황
- 회원가입은 카카오톡, 네이버, 일반 회원가입 3가지가 있다.
- 일반 회원가입의 경우 이메일, 비밀번호, 이름을 입력한다.
- 올바르지 않은 정보를 입력할 경우 텍스트 필드 아래에 얼럿 메시지가 노출된다.
- CTA 버튼을 누르면 회원가입 요청을 보낸다.
테스트케이스(TC)
: 실무에서 매우 많이 사용됨, 특정 조건에서 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서
ex) 회원가입 flow를 테스트하는 상황
| 화면 | 조건 | 테스트 케이스 | 입력 값 | 기댓값 | 테스트 환경 |
|---|---|---|---|---|---|
| 일반 회원가입 | 정상 | 모든 텍스트 필드에 정상 값 입력 | email: ‘test@gmail.com’ name: ‘김르탄’ password: ’test123’ | 회원가입 완료 화면으로 이동 | iOS/Android/Web |
| 일반 회원가입 | 에러 | 형식에 맞지 않은 이메일 입력 | email: ‘testgmail.com’ | 텍스트 필드 아래에 얼럿 메시지가 노출 | iOS/Android/Web |
3) 디자인 QA
QA는 원래 기능 QA/디자인QA로 나뉜다
디자인 QA는 디자인이 정확하게 개발되었는지 확인하는 절차
디자인 QA에서 발견한 이슈 공유하기
- 개발화면과 피그마 화면을 함께 보면서 수정사항 확인.
- 엔지니어가 잘 이해하도록 작성되어야 한다.
- 조직에 따라 다르지만 지라나 트렐로를 사용한다. 업무 티켓형태로 전달하는 것이 효율적이다.
- 티켓에 첨부된 이미지에 요구한 부분을 강조하고 피그마 이미지에 의도를 작성해 놓으면 개발자가 이해하기 더욱 쉽다.
이슈 중요도 정의(옵션)
🔔 qa일정이 촉박할때도 많음, 중요도가 정해져있어야지 일처리를 빠르게 할 수 있음.
HIGHEST
- 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우
HIGH
- 사용자가 행동을 완수할 수 없는 이슈
- 기능상 사용성에 치명적인 문제가 될 수 있는 것
MEDIUM
- 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제
- 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것
- 사용자가 상황을 제대로 이해하기에 어려움이 있는 것
(예시: 네트워크 오류로 팝업이 떠야 하는 상황에서 알 수 없는 오류 팝업이 뜨는 이슈) - 시각적으로 오류가 난 것처럼 보이는 것
LOW
- 기능상 문제가 없는 것
- 피그마 화면과는 다르지만, 맥락상 과정을 이해하기에 어려움이 없는 것
- 오픈 후 수정되어도 문제없는 디테일한 부분
LOWEST
- 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈
인사이트
강의를 다 듣고 정리를 했지만 몇몇부분은 아직 익숙하지 않아 좀 더 살펴봐야 될 것 같다. 3주차는 실무에 필요한 내용들이 많아 좋았다.
디자이너는 디자인만 잘하는 것이 아닌 원할한 소통이 기반인 협업을 해야한다는 생각이 들었다.
