1227_UX/UI (+디자인씽킹, 실무 프로세스)
01. 디자인씽킹이란?
논리적으로 제품을 만들 수 있도록 도와주는 프레임워크 중 하나
-> 사용자에 대한 이해를 기반으로 문제를 찾고 제품을 만들어 검증하는 프로세스
디자인씽킹 5단계
1. 공감하기-Empathy
: 인터뷰나 관찰 등의 다양한 방법으로 사용자와 공감대를 맞추고,
그들의 경험을 완전히 이해하기 위해 노력하는 단계
2. 문제 정의하기- Define
: 공감으로 얻은 정보를 해석해 사용자가 불편함을 느끼는 지점을 발견하는 단계
3. 아이디어 발산하기 - Ideate
: 다양한 아이디어를 내고, 그중에서 가장 적합한 아이디어를 선택하는 단계
4. 프로토타입 만들기 - Prototype
: 사용자가 아이디어를 경험할 수 있도록 구체적인 제품이나 서비스로 개발하는 단계
5. 테스트하기 - Test
: 프로토타입을 사용자가 직접 사용해 보게 하고 피드백을 받는 단계
디자인은 아이디어를 눈에 보이는 것으로 만드는 일
회사에서 일을 1) 빠른 시간에 2) 논리적, 현실적으로 일해야한다.
디자인씽킹은 이를 도와준다.
02. Data-Drive과 디자인씽킹
데이터드리븐이란?
데이터는 곧 사용자에 대한 이해
온라인 기반의 생활 양식으로 사용자의 행동 대부분이 데이터로 쌓이고, 점점 더 데이터를 많이 활용할 수 있게 됨.
03. [디자인씽킹 1단계] 공감하기 Empathy
1) 디자인씽킹에서 가장 중요한 단계
- 회사의 매출은 사용자한테서 나오기 때문에 사용자를 정확히 아는 것이 중요
-회사는 매출을 내고 이익을 남겨야 함. 그리고 그 매출은 제품, 정확히는 그 제품을 쓰는 사용자한테서 나옴
- 제품을 쓰면서 회사에 돈을 벌어다 줄 사람이 사용자이기 때문에 UX/UI 디자이너는 끈질기게 사용자를 조사하고, 분석해서 더 많은 사용자가 제품을 잘 쓸 수 있도록 디자인해야 함.
2) 공감하기란?
- 사용자를 완벽히 이해해야 함
- 인터뷰나 관찰 등의 다양한 방법으로 사용자와 공감대를 맞추고, 그들의 경험을 완전히 이해하기 위한 노력
- 공감대 형성한 후 사용자의 충족되지 않은 욕구(Needs)와 불편한 점(Pain Point)들을 파악하며 진짜 문제에 다가갈 수 있게 된다.
[공감하기 단계에서 활용할 수 있는 방법]
- 1) A-E-I-O-U 관찰법
정보를 체계적으로 수집할 수 있도록 5가지의 분류로 수집하는 관찰법
언제?
인터뷰나 현장 조사에서 사용자를 관찰할 일이 있을 때 활용
어떻게?
활동 Activities, 환경 Environments, 상호작용 Interactions, 사물 Objects, 사용자 Useers의 5가지 주제가 적힌 종이 혹은 시트를 준비한다. 그리고 대상을 관찰하며 발견한 내용을 해당하는 주제에 맞춰 적기.
-2) 공감지도(Empathy Map)
6개의 도표를 채우며, 사용자가 숨겨진 어려움과 욕구를
언제?
사용자를 관찰할 일이 있을 때 활용
어떻게?
우리의 대표 사용자가 누구인지 떠올려보고, 가장 인물의 입장이 되어 생각과 느낌, 말과 행동, 보는 것, 듣는 것을 정리하고 사용자가 겪을 어려움과 욕구를 유추
-3) 인터뷰
사용자 파악하는 가장 대표적인 방법으로 사용자를 직접 만나 다양한 질문을 던지고 대답을 들으며, 정보르 얻는 것을 의미.
언제?
제품 개발 전 과정에서
어떻게?
인터뷰를 통해 얻고자 하는 목적을 분명하게 정함.
가장 적절한 사용자 그룹 생각해봄
그룹의 특성에 따라 대상자 모집
인터뷰 대상은 5명이면 충분
예, 아니오로 대답할 수 있는 질문보다는 다양한 대답을 들을 수 있는 개방형 질문을 하는 것이 좋음.
4) AEIOU로 사용자 이해하기
사용자 관찰하거나 해석할 때 사용할 수 있는 5가지의 정보 분류 체계
- 활동
관찰하는 대상이 어떻게 움직이는지 살펴보세요.
사용자의 모든 행동을 눈여겨보는 것이 좋습니다.
활동에는 이런 것들이 있어요.
이야기를 나누는 중에 먹거나 보인 행동
특별한 움직임이나 반응, 제스쳐
목적을 이루기 위해 선택한 방법
환경
📕 3주차 📕
01. 제품팀이란?
1) 제품팀이란?
제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀.
보통 1명의 제품 관리자(PO나 PM), 1명의 디자이너, 2명의 엔지니어가 제품팀을 구성하는 최소 조건.
그외에도 데이터 애널리스트, 마케터, BO등이 포함.
<목적조직>
특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀
e.g. 핀테크 회사 : 도메인별로 -> 대출팀, 카드팀, 예/적금팀
제품팀이라고 하면 보통 목적조직을 의미
목적조직은 주로 스쿼드나 사일로라고 부름
목적조직은 제품의 목표를 달성하기위해 다양한 직무의 사람이 모여있는 팀이기 때문에 속도가 빠르고 효율적이라는 장점.
<기능 조직>
유사한 직무끼리 구성된 팀
e.g. 기획팀, 디자인팀, 개발팀
기능조직은 주로 챕터
기능조직은 비슷한 일을 하는 사람들끼리 모여있기 때문에
전문 분야에 대해 깊게 논의하고 서로의 발전을 도울 수 있다는 장점.
<매트릭스 조직>
구성원이 기능조직과 목적조직이 교차된 형태로 소속된 구성
e.g. 프로덕트 디자이너는 기능조직인 디자인팀에 속하면서 동시에 목적조직인 스쿼드에 속함.
많은 스타트업에서 이 방식으로 일함
팀의 규모는 회사마다 다를 수 있지만, 16명을 넘지 않는 것을 추천.
2) 제품팀이 일하는 방식
<린스타트업>
린스타트업은 빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식.
- 린스타트업은 불확실성이 높은 스타트업에서 제품을 효과적으로 개발하기 위해 고안된 전략
- 핵심은 낭비를 줄이는 것, 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법
- 린스타트업에서는 '만들기 -> 측정 -> 학습'을 반복하면서 피드백을 받고 사용자 중심으로 제품을 만드는 것을 중요하게 생각
<애자일>
애자일은 제품을 만드는 방법론 중 하나.
일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해 나가는 과정을 반복
- 애자일은 사전적으로 날렵한, 민첩한이라는 뜻이 있음
- 애자일한 제품팀은 1-4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해나가는 과정을 반복
<폭포수 vs 애자일>
폭포수 방식
- 폭포가 떨어지는 것처럼 수직적으로 각 단계를 하나씩 진행
- 각 단계가 완벽하게 완성되었을 때만 다음 단계로 넘어가고 이전 단계로는 돌아가지 않음
- 요구사항 설계부터 디자인, 개발이 순서대로, 독립적으로 진행
- 단계별로 업무 분담이 명확하고 진행 상황 파악이 쉬움
- 속도가 느리고, 변화하는 상황에 유연하게 대처하기 어려움.
애자일 방식
- 1-4주의 스프린트 단위로 제품을 개발, 테스트 하고 피드백을 받아 개선해 나가는 과정을 반복
- 수평적으로 일하면서, 불필요한 의사결정을 줄이고 즉각적으로 계획과 실행으로 피드백을 빠르게 반영
- 빠르게 변화하는 환경에 맞추어 기민하고 유연하게 대응할 수 있다는 것이 장점
<스프린트>
- 짧은 거리를 전속력으로 달리는 것
- 집중해서 여러 태스크를 완료하는 1-4주 정도의 짧은 기간
- 스타트업에서는 스프린트를 여러 번 반복하며 밀도 있게 일합니다.
<스크럼>
- 1-4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방식
- 스프린트에서 설정한 목표에 따라 요구사항 설계 -> 디자인 -> 개발 -> 테스트 -> 배포의 과정으로 제품을 개발하는 애자일 방법론의 하나
<이터레이션>
- 짧은 주기로 스프린트를 이어 나가는 것을 이터레이션이라고 표현
02. UX/UI 실무
1) 디자인 프로세스
📖 기획
< 문제 정의>
- PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정함
- 회사에 따라 문제 정의 단계에서 디자이너가 참여하기도 하고, 참여하지 않고 따로 PO/PM이 문제를 선정해 공유하기도 함
<아이데이션>
- 앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그 중에서 적절한 솔루션을 선택
- 필요에 따라 러프한 솔루션 스케치를 진행
* 솔루션 스케치: 보통 아이데이션 단계에서 그리는 솔루션 스케치는 기획과 아이디어가 잘 보이도록 와이어프레임 형태로 그림
<프로덕트 스펙 문서 작성>
- 디자인에 들어가기 전, 문서에 솔루션에 대한 상세 내용을 글로 먼저 적어본다.
- 디자인이 나오지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다는 장점이 있다.
- 회사에 따라 생략되거나 PO/PM 직군이 맡아서 하기도 한다.
🎨 디자인
<초안 디자인>
- 피그마나 스케치 등의 디자인 툴로 솔루션을 디자인
- 디자인 디테일보다는 전반적인 사용자의 여정과 UX에 집중해 보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스는 없는지 살핍니다.
<피드백>
- 기획 단계에서 논의한 대로 잘 디자인되었는지 팀원들에게 공유하고 피드백을 받습니다.
- 솔루션의 성격에 따라 피그마 프로토타이핑이나 프로토파이 같은 프로토타입 툴을 사용하기도 합니다.
<최종 디자인 확정 및 핸드오프>
- 피드백을 초안에 반영하여 최종 디자인을 확정
- 확정한 최종 디자인을 엔지니어에게 공유하고 개발이 원활히 진행될 수 있도록 돕습니다.
- 필요에 따라 가이드를 함께 작성해 전달하기도 한다.
*핸드오프 : 핸드오프는 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것.
- 핸드오프는 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것을 의미
- 디자이너의 의도를 엔지니어가 잘 이해해야 제품이 잘 구현
- 디자인을 공유할 때 다음의 내용을 포함할 것,
1. 유저 플로우
- 처음 시작하는 화면은 어디이고 어떻게 연결되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성
2. 유즈 케이스
- 상황에 따른 화면 정의
- e.g. 회원가입 화면에서는 정상 입력, 입력값 오류, 입력 가능 시간 초과 등의 다양한 상황이 생길 수 있음
모든 케이스에 달라지는 화면을 놓치지 않고 정의해주어야 한다.
3. 반응형 레이아웃
- 대부분의 회사에서는 스크린 크기를 하나 정해 디자인을 하고 반응형으로 대응
- 아주 작은 스크린 크기나 특별한 스크린 크기에 디자인이 어떻게 표현되어야 하는지 가이드를 주는 것이 좋다.
(가이드 예시)
💻 개발
<디자인 QA>
- 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA를 한다.
- 최대한 사용자와 비슷한 환경으로 테스트
- 앱이라면 적어도 안드로이드, iOS 두 환경을 모두 확인하는 것이 좋음
<프로덕트 스펙 문서>
*프로덕트 스펙은 제품을 만들거나 개선할 때 사용하는 문서로 '기능의 사양을 정의한 가이드'
회사에 따라서 PRD(Product Requirements Document, 제품 요구사항 정의서)라고 부르기도 함.
- 기획 배경과 솔루션, 기능 요구사항, 실험 계획 등을 담고 있다.
- 가능한 한 기획, 디자인, 개발에 필요한 모든 내용을 적는 것이 좋다.
문서가 여러 개로 파편화되어 있다면 url을 첨부해서 한 곳에서 볼 수 있도록
🗃포함 내용
1) 기획 배경 & 문제 정의
: 기획하게 된 배경을 짧게 설명하고 사용자의 문제를 정의한다.
- 문제 발견 과정
- 문제로 정의한 이유
- 문제의 원인
- 누가 이 문제에 영향을 받는지
2) 솔루션 설명
: 만들고자 하는 솔루션에 대해 UX/UI 관점에 대해 자세히 설명
- 페르소나
-사용자 시나리오
-기능별 주요 특징 & 요구사항
- 예외사항 및 Edge Case 정의
- 최종시안
3) 실험 설계
: 솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것인지
- 실험 가설 / 문제 해결을 통해 만들어 내고자 하는 결과
- 실험 방식
- 결과 평가 / 문제가 해결되었는지 판단할 수 있는 방법
- 실험 기간
4) 예상 일정
- 프로덕트 스펙 초안 작성 완료 예상 일정
- UI/UX 디자인 최종 시안 제작 완료 예상 일정
- 개발 분야별 예상 일정 / 프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성
- 배포 목표 일정
Google의 템플릿 참고하기
<디자인 공유하고 피드백 받기>
- 디자이너의 업무의 대부분은 디자인과 피드백, 거듭되는 수정으로 이루어짐
- 기획 배경과 맥락을 잘 이해해야 좋은 피드백
- 피드백을 주는 사람이 전체적인 내용을 알 수 있도록 충분한 정보를 함께 전달
🗃 디자인 피드백 요청할 때 포함하면 좋을 것
1) 배경
- 프로젝트 기획하게 된 배경을 설명
- 구체적인 데이터와 가설을 더함
2) 솔루션의 의도
- 가설에서 어떠한 방향성을 잡고 디자인했는지 설명
- 시각적으로 강조하고 싶었던 부분이나 중요하게 생각한 부분이 있다면 함께 적는다.
3) 필수 리뷰어
- 다수에게 공유할 땐 꼭 피드백을 받고 싶은 사람 지정
- 디자인한 화면으로 영향을 받는 곳과 연관된 사람이 있다면 참조
4) 참고 문서
- 프로덕트 스펙 문서를 함께 첨부하면 전반적인 프로젝트를 이해하는 데에 도움
- 디자인 파일도 함께 공유하면 다른 디자이너들의 도움을 받을 수 있다.
- 이해를 돕기 위해 프로토타입을 함께 공유하는 것도 좋다.
5) 피드백 기한
- 제품 개발, 배포 일정에 영향을 주지 않도록 피드백을 받을 수 있는 충분한 여유를 가지세요.
- 일정이 촉박하다면 피드백을 받고 싶은 기한을 함께 표시하는 것이 좋다.
디자인 피드백 요청 예시
03. [실무 프로세스 1] 협업하기
협업하는 방법과 함께 일하게 될 동료들에 대해 이해해봅시다.
1) 협업이란?
- 앞서 제품팀은 각자 다른 전문적인 능력을 갖춘 사람들이 모인 것.
- 제품팀은 함께 모여 어려운 문제를 해결하기 위해 긴 시간 함께 노력한다.
- 협업이란 각 직무의 리서스가 낭비 없이 좋은 솔루션을 만드는 데 집중적으로 쓰이는 것.
- 서로가 좋은 퍼포먼스를 낼 수 있도록 돕고 시너지를 낼 수 있도록 하는 것이 좋음
04. [실무 프로세스 2] 실험 문화
1) 실험이란?
제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는 데이터로 검증하는 것.
왜 실험을 해야 하나요?
- 사람은 편향적이기 때문에 만드는 사람의 주관이 제품에 반영되기 쉽습니다.
- 데이터로 사용자의 데이터를 확인하면, 객관적으로 의사결정을 할 수 있습니다.
- 호불호가 데이터로 증명되기 때문
2) 실험 환경 이해하기
실험은 대부분 A/B 테스트로 진행됩니다.
A/B 테스트 설계를 할 수 없을 때, 특정한 상황에서는 전후 비교 테스트를 하기도 합니다.
전후 비교 테스트
- 실험 기간 전후로 지표가 어떻게 달라졌는지 비교해 보는 방법입니다.
커머스에서 상품 리스트 페이지를 개선하고 상품 구매율의 변화를 보는 상황
12월 1일에 실험이 시작되어 3주간 진행. 12월 1일 이전 3주의 데이터와 이후 3주의 데이터를 추출하여 상품 구매율이 달라졌는지를 보는 거죠.
A/B 테스트
- 기존 화면은 대조군으로 정합니다. 효과 검즈을 위한 비교 대상입니다.
- 테스트하고 싶은 안을 실험군으로 정합니다.
-A/B 테스트의 효과를 정확히 파악하기 위해 테스트하는 변수는 가능한 1개로 제한하는 것이 좋습니다.