💡디자이너의 조직을 제품팀이라 한다
❓ 제품팀이 일하는 방식은..
❗ 린 스타트업
▶ 아이디어>만들기>제품>측정>데이터
▶ 학습 형식의 사이클로 불확실성이 높은 스타트업에서 효과적으로(낭비⬇, 적은 리소스) 제작을 한다.
❗ 애자일
▶ 요구사항>디자인, 개발>테스트>배포
▶ 1~4주의 스프린트 단위로 위의 단계를 빠르게 반복
▶ 수평적으로 일하며 즉각적인 계획과 실행으로 피드백을 빠르게 반영
▶ 빠르게 변화함으로 기민하고 유연하게 대처 가능한 장점
🔎 UXUI 실무 프로세스_기획 > 디자인 > 개발
1️⃣ 기획
▶ 문제 정의
> PO/PM과 목표에 따라 우선순위가 높은 문제를 정한다
▶ 아이데이션
> 앞서 정의한 문제의 아이디어를 도출하고 솔루션을 와이어프레임 형태로 만든다
▶ 프로덕트 스펙 문서 작성
> 디자인 전, 솔루션에 대한 내용을 글로 작성(엔지니어에 따라, PO/PM이 맡기도 함)
2️⃣ 디자인
▶ 초안 디자인
> 디자인 툴로 솔루션을 제작
> 디자인 디테일 보다 사용자의 여정과 UX에 집중 프로덕트 스펙 문서에서 놓친 엣지 케이스가 있는지 없는지 체크
▶ 피드백
> 기획 단계 내용으로 잘 디자인 했는지 피드백을 받음
> 솔루션 성격에 따라 툴을 사용하기도 함
▶ 최종 디자인 확정 및 핸드오프
> 피드백을 초안에 적용&디자인 확정
> 엔지니어에게 내용을 공유 필요에 따라 가이드 첨부
▶ 가이드에 들어가면 좋은 내용
> 유저 플로우
> 유즈 케이스
> 반응형 레이아웃
3️⃣ 개발
▶ 디자인 QA
> 디자인 그대로 개발 되었는지
> 최대한 사용자와 비슷한 환경으로 테스트(앱이라면 안드로이드, IOS 둘 다)
❗ 프로덕트 스펙문서/PRD(Product Requirements Document, 제품 요구사항 정의서)
※ 팀원 모두가 같은 생각으로 작업하도록 도와주는 가이드
1. 기획 배경 & 문제 정의
▶ 문제 발견 과정, 이유, 원인, 영향을 받는 사람
2. 솔루션
▶ 페르소나, 사용자 시나리오, 기능별 특징&요구사항, 예외상황 및 Edge Case, 최종시안
3. 실험 계획
▶ 실험 가설(만들어 내고자 하는 결과)
▶ 실험 방식, 결과 평가, 기간
4.예상 일정
▶ 프로덕트 스펙 초안 작성 완료 예상 일정
▶ UI/UX 디자인 최종 시안 제작 완료 예상 일정
▶ 개발 분야별 예상 일정 (프론트엔드, 서버, 이벤트 설계, QA 각각 세부적으로)
▶ 배포 목표 일정
▶ 최대한 한 곳에서 확인이 가능하도록
실무 프로세스 1_협업
1. PO/PM 이해
▶ PM_프로덕트 매니저 : 실무 중심 관리, 요구사항 분석, 전략 설계, 지표 관리 및 분석 등
▶ PO_프로덕트 오너 : 제품 전반의 로드맵, 지표관리 및 분석, 조직 관리
2. 엔지니어 이해
▶ 프론트엔드 : 웹/앱의 페이지 UI를 코드 구현
▶ 백엔드 : 서버 엔지니어
▶ QA : 제품 배포 전 퀄리티&모니터링
▶ 데이터 애널리스트 : 데이터베이스에서 정보를 수집, 분석해 인사이트를 제공
3. UXUI 직무 이해
▶ BX 디자이너 : 브랜드 로고, 심볼 등 앱/웹에 들어가는 그래픽을 디자인
▶ UX writer : 브랜드 보이스앤톤을 문구로 전달(디자이너가 하기도 한다)
실무 프로세스 2_실험 문화
1. 실험 환경
▶ A/B 테스트로 진행
> 대조군/실험군 (변수는 1개로 제한한다)
> 전후 비교 테스트를 하기도 한다
> 실험 기간 전후의 지표를 비교
2. 실험을 위한 분석 도구
▶ 앰플리튜드
> 제품 안에서의 행동의 이벤트를 심어두면 행동의 데이터를 쌓아줌
> 다양한 데이터를 얻을 수 있음
> 유료
▶ 구글 애널리틱스(GA4)
> 일부 무료 분석
> 이벤트 기반 분석
> 마케팅팀을 위한 솔루션에 가까움
실무 프로세스 3_디자인 QA
1. QA 목적
▶ 제품의 결함을 체크
▶ 품질을 체크
▶ 프로덕트 스펙 문서 명세에 부합한지 체크
▶ 특수한 상황 동작 체크
▶ UX가 편리한지 체크
2. QA 문서
▶ 체크리스트_CL
> 예/아니오, Pass/Fail 답병
> 개선 범위가 넓지 않을 때
▶ 테스트 시나리오_TS
> 기획 기능이 모두 작동하는지
> 기능을 사용하면서 경험하는 과정
▶ 테스트 케이스_TC
> 특정 조건의 요구사항을 충족하는지 확인하기 위한 케이스를 작성
> 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 상세하게
3. 디자인 QA
▶ 디자인 화면 VS 개발된 화면 비교분석
> 다른 부분은 팀원들에게 기획 의도를 함께 전달
> 지라/트렐로 사용시 업무 티켓 형식으로 전달 추천
※ 이슈 중요도 정의
▶ 효율적으로 일하기 위하여 정하는 일의 순서
HIGHEST
> 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우
HIGH
> 사용자가 행동을 완수할 수 없는 이슈
> 기능상 사용성에 치명적인 문제가 될 수 있는 것
MEDIUM
> 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제
> 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것
> 사용자가 상황을 제대로 이해하기에 어려움이 있는 것
(예시: 네트워크 오류로 팝업이 떠야 하는 상황에서 알 수 없는 오류 팝업이 뜨는 이슈)
> 시각적으로 오류가 난 것처럼 보이는 것
LOW
> 기능상 문제가 없는 것
> 피그마 화면과는 다르지만, 맥락상 과정을 이해하기에 어려움이 없는 것
> 오픈 후 수정되어도 문제없는 디테일한 부분
LOWEST
> 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈
'UXUI 교육내용 정리' 카테고리의 다른 글
| [UXUI 입문 5주차] 디자인 원칙 (6) | 2025.01.27 |
|---|---|
| [UXUI 입문 4주차] 디자인 툴 (2) | 2025.01.24 |
| [UXUI 입문 2주차] 디자인 씽킹 (2) | 2025.01.22 |
| [UXUI 입문 1주차] 디자인 가이드 & 트랜드 (1) | 2025.01.21 |
| [UXUI 사전캠프_2일_#1] 피그마 기초 완전 정복 4~5주차 복습 (0) | 2025.01.21 |