UXUI 디자인 입문 3주차 - 강의 복습

제품팀

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

보통 1명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어가 제품팀을 구성하는 최소 조건임.

그 외에도 회사에 따라 제품팀에 데이터 애널리스트, 마케터, BO(Business Operator) 등이 포함될 수 있음 

 

목적조직

특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀 

i.e) 핀테크 회사 내 대출팀, 카드팀, 예/적금팀 

목적조직은 주로 스쿼드나 사일로라고 불림 

 

기능조직 

유사한 직무끼리 구성된 팀 

i.e) 기획팀, 디자인팀, 개발팀 

기능조직은 주로 챕터라고 불림 

 

매트릭스 조직 

구성원이 기능조직과 목적조직이 교차된 형태로 소속된 구성을 의미함 

즉, 한 명이 두 팀에 소속되어 있는 형태. 

 

제품팀이 일하는 방식

1) 린스타트업

빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식

만들기 -> 측정 -> 학습을 반복하면서 피드백을 받고 사용자 중심으로 제품을 만드는 것을 중요하게 생각함 

 

2) 애자일 

제품을 만드는 방법론 중 하나 

일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해 나가는 과정을 반복하는 것 

애자일한 제품팀은 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해 나가는 과정을 반복함. 

 

2-1) 폭포수 방식

수직적으로 각 단계를 하나씩 진행하는 것을 의미함

각 단계가 완벽하게 완성되었을 때만 다음 단계로 넘어가고 이전 단계로는 돌아가지 않음 

요구사항 설계부터 디자인, 개발이 순서대로, 독립적으로 진행됨 

단계별로 업무 분담이 명확하고 진행 상황 파악이 쉽다는 장점이 있으나, 속도가 느리고 변화하는 상황에 유연하게 대처하기 어렵다는 단점이 있음. 

 

2-1) 스프린트 

집중해서 여러 테스크를 완료하는 1~4주 정도의 짧은 기간을 의미함 

 

2-2) 스크럼

1~4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방식

스프린트에서 설정한 목표에 따라 요구사항 설계 -> 디자인 -> 개발 -> 테스트 -> 배포의 과정으로 제품을 개발하는 애자일 방봅론의 하나. 

 

2-3) 이터레이션

짧은 주기로 스프린트를 이어 나가는 것을 의미

 

UX/UI 실무 프로세스

디자인 프로세스

UX/UI 디자이너는 크게 기획 -> 디자인 -> 개발 단계에서 모두 관여를 한다. (뭐?)

 

1) 기획 

1. 문제 정의 

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

- 회사에 따라 참여안하기도 하는데, 튜터님 왈 참여하기를 강력하게 권장한다고 함 

- 딱봐도 하기 싫어보이는 일인걸 보니 사회에서 수요가 정말 많은 일인 것으로 보임 

 

2. 아이데이션 

- 앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그중에서 적절한 솔루션을 선택함

- 필요에 따라 러프한 솔루션 스케치를 진행하기도 함.

 

2-1. 솔루션 스케치

- 곧바로 개발로 들어가면 돈 많이 드니까 기획과 아이디어가 잘 보이도록 대충 손으로 슥슥 그리는 거

 

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

- 디자인 들어가기 전에 문서에 솔루션에 대한 상세 내용을 먼저 글로 적는 것 

- 디자인 나오기 전에 엔지니어가 솔루션을 미리 상상하고 준비할 수 있고, 계속 사람들이 이거 보면서 동상이몽하는 것이 아니라 생각을 링크시킬 수 있음 

- 회사에 따라 생략되거나 PO/PM 직군이 맡아서 하기도 함 

 

2) 디자인 

1. 초안 디자인 

- 피그마나 스케치 등의 디자인 툴로 솔루션을 디자인함 

- 디자인 디테일보다는 전반적인 사용자의 여정과 UX에 집중하면서, 프로덕트 스펙 문서에서 놓친 엣지 케이스는 없는지 살펴보기 

 

*엣지 케이스란 소프트웨어나 시스템에서 예상치 못한 상황이나 특정 조건에 따라 동작이나 결과가 변하는 경우를 가리킴. 엣지케이스는 일반적인 시나리오와는 다른 동작을 포함하고 있으며, 소프트웨어나 시스템의 안정성과 사용자 경험에 영향을 미칠 수 있음. (https://designbase.co.kr/dictionary/edge-case/)

 

2. 피드백

- 기획 단계에서 논의한 대로 잘 디자인되었는지 팀원들과 공유하고 피드백 받기.

 

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

- 피드백을 초안에 반영하여 최종 디자인을 확정

- 확정한 최종 디자인을 엔지니어에게 공유하고 개발이 원활히 진행될 수 있도록 도움

 

3.1. 핸드오프

디자인을 개발할 수 있도록 엔지니어에게 전달하는 것을 의미함 

디자인을 공유할 때 다음의 내용을 포함해 함께 전달하는 것이 좋음.

 

3.1.1. 유저 플로우

처음 시작하는 화면은 어디고, 어떻게 연결되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성하기

 

3.1.2. 유즈 케이스

상황에 따른 화면 정의를 의미함 

회원가입 화면에서는 정상 입력, 입력값 오류, 입력 가능 시간 초과 등의 다양한 상황이 생길 수 있는데, 이 모든 케이스에 달라지는 화면을 놓치지 않고 정의해주어야 함 

 

3.1.3. 반응형 레이아웃 

대부분의 회사에서는 스크린 크기를 하나 정해 디자인을 하고 반응형으로 대응함 

아주 작은 스크린 크기나 특별한 스크린 크기에 디자인이 어떻게 표현되어야 하는지 가이드를 주는 것이 좋음 

 

3) 개발 

1. 디자인 QA

개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA를 함

ㅚ대한 사용자와 비슷한 환경으로 테스트하고

앱이라면 적어도 안드로이드, iOS 두 환경을 모두 확인하는 것이 좋음 

 

프로덕트 스펙 문서

제품을 만들거나 개선할 때 사용하는 문서로, 기능의 사양을 정의한 가이드. 

PRD라고 부르기도 함. 

 

기획배경과 솔루션, 기능 요구사항, 실험 계획 등을 담고 있음 

가능한 기획, 디자인, 개발에 필요한 모든 내용을 적는 것이 좋음. 

문서가 여러 개로 파편화되어 있다면 URL을 첨부해서 한 곳에서 볼 수 있도록 하기.

 

1) 기획 배경 & 문제 정의

기획하게 된 배경을 짧게 설명하고 사용자의 문제를 정의하기 

문제 정의에는 아래 내용들이 포함되어야 함 

1. 문제 발견 과정

2. 문제로 정의한 이유

3. 문제 원인

4. 누가 이 문제에 영향을 받는지 

 

2) 솔루션 설명

만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세하게 설명하기

솔루션 설명에는 아래 내용들이 포함되어야 함 

1. 페르소나

2. 사용자 시나리오

3. 기능별 주요 특징 & 요구사항

4. 예외 상황 및 Edge Case 정의 

5. 최종 시안 

 

3) 실험 설계 

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

1. 실험 가설: 문제 해결을 통해 만들어 내고자 하는 결과

2. 실험 방식

3. 결과 평가: 문제가 해결되었는지 판단할 수 있는 방법 

4. 실험 기간 

 

4) 예상 일정 

 

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

포함하면 좋을 것 

 

1. 기획 배경 - 구체적인 데이터와 가설을 더하면 좋음 

 

2. 솔루션의 의도 - 가설에서 어떤 방향성을 잡고 디자인했는지를 설명 

 

3. 필수 리뷰어 - 꼭 피드백을 받아야 하는 사람을 지정

 

4. 참고 문서 - 프로덕트 스펙 문서를 함께 첨부하면 도움이 됨. 프로토타입, 디자인 파일도 함께 공유하면 좋음 

 

5. 피드백 기한 

 

*퍼널(Funnel): 사용자가 서비스 접속 후 상품을 구매하기까지의 경로를 가시화하여 전환과 이탈률을 측정함으로써 집중 개선 대상 페이지를 발견할 수 있는 기능임. 개선된 페이지의 성과까지 간단히 추척해나갈 수 있음. 

(https://brunch.co.kr/@beusable/31)

 

실무 프로세스 1: 협업하기

PO/PM 이해하기

PM: 

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

실제 프로젝트를 수행하는 실무의 성격이 강함.

실무 중심으로 프로젝트를 관리함.

요구사항 분석, 전략 설계, 지표 관리 및 분석 등의 업무를 수행함. 

 

PO;

제품에 대한 오너십을 갖고 제품이 시장에 잘 전달될 수 있도록 관리하는 사람

일반적으로 PM보다 더 많은 역할과 책임이 주어지며, 제품팀을 이끌고 제품이 시장에 잘 전달될 수 있도록 관리함.

이해관계자들과 논의하고, 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경을 만드는 데에도 힘을 씀.

제품 전반의 로드맵, 제품을 관리함. 

로드맵과 전략 설계, 지표 관리 및 분석 등의 업무를 수행하며, 제품팀의 조직 관리에도 힘을 씀. 

 

엔지니어 이해하기

프론트엔드 엔지니어: 앱/웹페이지, 화면 안의 각종 컴포넌트, 즉 UI를 코드로 구현함단순히 그래픽 구현을 넘어 화면 간의 이동, 컴포넌트의 모션, 사용자의 인풋에 따른 반응까지 구현하기 때문에 사용자의 경험을 만드는 UX와도 깊게 관련이 되어 있음.

 

벡엔드 엔지니어:

서버 엔지니어라고도 함. 정보를 저장, 전송하는 것뿐만 아니라 제품 전체를 효율적으로 운영할 수 있도록 구조를 고민하는 역할도 함.

 

QA 엔지니어:

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

 

데이터 애널리스트:

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

 

UX/UI 직무 이해하기

BX 디자이너:

Brand eXperience의 줄임말로, 브랜드 경험과 관련된 전반적인 디자인을 하는 사람.로고나 심볼처럼 아주 기본적인 것부터 앱/웹에 들어가는 그래픽, 대외에 노출되는 이미지, 각종 인쇄물 등 브랜드를 나타내는 모든 부분을 담당함.

 

UX writer:

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

단순히 글을 잘 쓰는 사람이 아니라, 브랜드의 보이스앤톤을 문구로 전달하고, 명확한 메시지를 통해 제품의 사용성을 높이는 일을 함. 규모가 작은 회사에는 별도로 없기도 함.

 

실무 프로세스 2: 실험 문화

실험이란?

제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것.실험은 대부분 A/B 테스트로 진행됨

 

A/B 테스트

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

 

기존 화면은 대조군(Control)으로 정하고, 테스트하고 싶은 안을 실험군(Treatment)으로 정함.A/B 테스트의 효과를 정확히 파악하기 위해 테스트하는 변수는 가능한 1개로 제한하는 것이 좋음.

 

변화를 주었을 때 행동이 달라졌다면, 그 안에서 상관관계와 인과관계를 찾을 수 있기 때문에 하는게 좋다. 

 

실험을 위한 제품 분석 도구

1. 앰플리튜드- 기능은 좋다. 근데 비쌈. 유료임- 이벤트 기반 분석- 제품 팀을 위한 솔루션에 가까움. 

 

2. 구글 애널리틱스 (GA4) - 무료다. 근데 일부 기능(GA4 360)은 유료임. 대중적인 인지도도 높고 그만큼 많이 쓰인다.- 이벤트 기반 분석으로 변화함. - 마케팅팀을 위한 솔루션에 가까움.

 

실무 프로세스 3: 디자인 QA 

QA란?

Quality Assurance의 약자. 제품이 출시되기 전에 기능을 테스트하는 것을 의미함. QA 팀이 있더라도 기능을 만든 담당자라면 대부분 직접 QA를 함.

 

QA 문서 

1. 체크리스트2. 테스트 시나리오3. 테스트 케이스 (얘를 가장 많이 씀.)

 

디자인 QA에서 발견한 이슈를 공유하는 업무 티켓 예시.

해당 부분은 노션을 참고하면서 자세하게 더 살펴보는 것이 좋다.