1. 사용자는 누구인가? 2. 그들의 일이나 삶에 있어서 우리 제품이 적합한 곳은 어디인가? 3. 우리 제품이 풀어야 할 문제는 무엇인가? 4. 언제 그리고 어떻게 우리 제품이 활용되는가? 5. 어떤 기능이 중요한가? 6. 우리 제품은 어떻게 보이고 활용되어야 하는가?
< 프로토 퍼소나 만드는 과정 >
- 항상 그렇듯, 먼저 가설을 설정하고 이후 실제 리서치를 통해 입증하는 과정을 거친다. - 가정단계에서 '프로토 퍼소나'를 정의 이후 다듬어 완성한 것이 '타겟 퍼소나 - 프로토퍼소나는 누가? 왜? 우리 제품을 사용하는지/할지에 대해 할 수 있는 최선의 추정 - 팀원 모두 종이 위에 가볍게 프로토퍼소나를 그려본다. - 계속되는 사용자조사를 통해 가정을 입증하면서 프로토퍼소나를 수정 - 프로토퍼소나는 충분히 조정될 여지가 있고, 아니다 싶으면 버릴 수도 있다.
[ 퍼소나 실습 ]
[ 사용성 테스트 알아보기 ]
사용성 테스트 (Usability Test) : 사용자에게 특정 과업을 수행하도록 과제(Task)를 부여한 뒤 그 일을 진행하는 과정(행동)을 관찰하는 방법.
- 의도한 서비스 시나리오대로 유저가 행동하는지 아닌지 알 수 있음 - 필수적인 컨트롤 요소를 인지/이해/예측/실행 하는지 알 수 있음 - 이외의 다양한 컨트롤 요소를 인지/이해/예측/실행 하는지 알 수 있음
< 사용성 평가(Usability Test)와 유저 테스트(User Test)는 다른 개념이다 > : 사용자가 000(기능)을 통해 XXX(다음 단계 진행)을 할 수 있는가?
할 수 없다면 문제점은 무엇인가? 고객(User)이 우리가 제공하고 있는 서비스의 구조와 기능을 의도한 대로 인지 / 이해 / 예측 / 실행 할 수 있는가?
- 인지: 사용자가 눈으로 확인/발견 하였는가 - 예측: 무엇을 하는 기능인지, 또는 다음 화면을 어떻게 예상하였는가 - 이해: 사용자가 무엇이라고, 또는 어떤 의미로 이해하였는가 - 실행: 예측과 일치하지 않는 부분 or 일치하지 않는 부분
< 사용성 테스트의 일반적 과정 > 1. 참여자를 모집한다 2. 우리의 서비스를 사용해 보도록 한다 3. 진행자는 참여자가 길을 잃지 않도록 안내한다 4. 참관자들은 고객의 행동을 관찰한다 5. UT가 끝나면 도출된 이슈에 대해 브리핑 6. 빠르게 개선한다 7. 반복한다
--> 꼭 정석적인 사용성 테스트를 할 필요는 없다
< 스티븐 브룩의 사용성 원칙 Top 3 >
✓ 제 1법칙 사용자를 고민에 빠뜨리지 마라, 모든 페이지는 쉽고 분명해야 한다. 사용자는 작동방식까지 이해하려 하지 않는다. ✓ 제 2법칙 고민없는 명쾌한 클릭이라면 클릭 수는 중요하지 않다. 고민없는 세번의 클릭이 심사숙고 해야하는 한번의 클릭보다 낫다. 사용자는 최선의 선택을 하지 않는다. 최소 조건만 충족되면 만족한다. ✓ 제 3법칙 쓸데없는 말을 줄이고 본론부터 얘기해라 사용자는 페이지를 읽지 않고 훑어본다.
[ 사용성 테스트 수행하기 ]
단계별로 나눈 사용성 테스트
[ 사용성 테스트 문제 정의 ] : 문제 정의는 사용성 테스트에서도 가장 중요한 부분 무엇에 대해 테스트 할지, 누구에게 어떻게 질문할지 등을 고려하는 단계
< 초보자가 문제 정의 단계에서 자주 하는 실수 > - 데이터를 그저 반복해서 수집 - 깊은 분석 없이 일반적이고 피상적인 분석이나 단순한 설문을 진행 - 질문을 작성할 때 깊이 고민하지 않음
좀 더 명확한 문제 정의를 위해서는 - 내가 해결하고자 하는 문제에 직접 연관된 사람(고객)들을 만나서 인터뷰를 해보자 - 해결하고자 하는 문제의 구조를 분해해보자 - 구체적으로 어떤 데이터를 살펴봐야 할지 고민해보자 - 실제 문제를 분석하기에 앞서 현 상황에서 고객의 상황을 시뮬레이션 해보자 - 고객 행동에 대한 가설을 세워보자
*실습을 위한 팁 : 내가 개선하고자 하는 프로덕트/서비스를 하나 선택하여 그에 대한 문제 정의를 해보고 리서치 계획을 세워보자
[ 사용성 테스트를 위한 데스크 리서치 ] - 데스크 리서치는 서비스와 관련된 외부 상황(트렌드, 시장환경 변화)부터 서비스의 내부 상황(조직, 협업 구조, 서비스 시스템)까지 다방면으로 서비스가 놓여있는 상황을 파악하기 위한 방법론 - 문제 정의 단계에서는 내가 해결하고자 하는 문제에 직접 연관된 사람을 만나봤다면, 데스크 리서치에서는 다른 사람이 리서치 한 것을 찾고 검토하는 것 - 내가 개선하고자 하는 서비스에 대한 <통계 분석 / 트렌드 분석 / 벤치마킹 / 사용성 평가 / VOC분석 등>을 수행하는데, 회사에서 직접 데이터를 얻을 수 없다면 <논문, 기사, 리포트 자료 등> 여러 방면으로 찾아보자
[ 사용성 테스트를 위한 데스크 리서치 ] : 최상의 리서치는 <사용자 / 사용자의 환경 / 서비스의 목표> 3가지 관점이 겹치는 지점이다 1. 서비스를 이용하는 사용자는 누구인지 파악해보자 2. 그 사용자가 서비스를 사용하는 환경과 맥락은 무엇인지 파악해보자 3. 서비스가 목표로 하는 것은 무엇인지 파악해보자
*실습을 위한 팁 : 내가 개선하고자 하는 프로덕트/서비스에 대한 문제 정의가 어느정도 되었다면 현황을 파악하기 위한 데스크 리서치를 수행해보자
[ 사용성 테스트를 위한 이해관계자 인터뷰 ] 리서처가 이 단계에서 해야할 일 - 이해관계자에게 issue or task 목록 작성을 요청하자 - 이슈 논의는 항상 함께 공유되어야 한다 - 주요한 이슈를 추리고 그 중에서 가장 중요한 것을 함께 논의해보자 - 이해관계자의 기분을 나쁘게 하는 커뮤니케이션은 자제하자 - 논의 전에는 항상 어떤 내용에 대해 이야기 할 것인지 미리 주제를 전달해주자
*실습을 위한 팁 : 내가 개선하고자 하는 프로덕트/서비스를 직접 만들고 있는 사람을 찾기 어렵다면, 내가 이 서비스를 기획하는 사람이라고 가정하여 이슈 목록을 작성하고 그 중 서비스의 목표에 부합하는 우선순위 이슈를 찾아보자
[ 사용성 테스트 태스크(Task) 작성하기 ] - 각 화면, 세부영역 별로 <사용자가 할 수 있어야 하는> Task를 작성해보자 - 문제 정의와 데스크 리서치 등에서 수집한 정보를 바탕으로 현재 해결해야 할 문제에 집중 - Task 작성은 처음에는 브레인스토밍을 통하여 아이디어를 수집하고 우선순위 작업을 통해 먼저 확인할 내용을 정리한다
< 리서치 대상자 선별 > - 리서치 대상자를 <아무나> 해도 된다고 생각하면 안 되고 해결하고자 하는 문제에 집중된 사용자를 찾아야 한다 - 가장 좋은 것은 고객 데이터를 보유하여 인구통계학적 정보나 고객의 행동데이터를 통해 선별하는 것이지만, 그 작업이 힘든 경우는 직접 사용자 그룹을 구분하는 작업을 해보자
리서치 대상 그룹을 4가지 축으로 구분하여 리서치 대상 선별의 우선순위를 살펴보자
- 여기에서 대상 고객은 앞서 문제 정의/데스크 리서치/이해관계자 인터뷰 등의 과정에서 발견한 정보를 기반으로 선정해야 한다
*실습을 위한 팁 : 앞서 수집한 정보들을 기반으로 리서치 대상에 적합한 고객들의 특성을 정의해보자(연령대, 서비스 이용 패턴, 고객의 니즈 등
< 리서치 참여자 사전동의 > : 리서처는 항상 리서치에 참여하는 고객에 대해 사전 동의를 받아야 한다 - 사용성 테스트 시 화면 녹화, 녹음에 대한 동의 - 비밀 유지에 대한 동의 - 개인정보 수집 및 이용에 대한 동의
< 리서치 참여자 모집하기 > - 참여자 선별 후 대상자에게 참여 여부 / 리서치 일정 / 리워드 등을 안내 - 사용성 테스트 진행 시 필요한 준비를 미리 안내(앱 설치 또는 원격 연결 등) - 화면을 함께 보면서(미러링) 전화로 진행하는 경우 이어폰을 준비하도록 함 - 조용한 장소에서 진행하도록 요청하며, 이동 중 / 운전 중에는 진행이 불가함을 안내 - 대면으로 진행할 경우에는 조용한 회의실 등에서 주변 소음에 방해받지 않도록 진행
< 진행자(모더레이터)로서 저지르는 실수 > - 말을 너무 많이 하지 말라 - 디자인을 설명하지 말라 - 참여자의 질문에 답변하지 마라 - 자꾸 인터뷰를 하려고 하지말고 사용성 테스트를 하라 - 대답을 유도하거나 선호도를 묻지 말라
[ 결과 정리 및 리뷰 ] - 애자일한 사용성 테스트에서는, 각 세션이 끝난 후 발견한 이슈에 대해 짧게 요약을 한다 - 모든 세션이 끝난 후에는 사용성 테스트에 참관한 사람들에게 브리핑을 한다 - 빠르게 다음 사용성 테스트를 준비 할 것인지 아니면 깊은 분석을 할 것인지 의사결정을 진행 - 위 과정이 끝난 이후에는 결과를 분석하여 이후 Action Item을 도출 - 별도의 리뷰 세션을 통해 결과를 리뷰하고 다음 스텝으로 향하자
< 리서치 이후에 해야 할 것들 > - 다음 리서치 스텝 고려 - 리서치 결과 아카이브 - 참여자 리워드 제공 - 리서치 녹화 및 녹음자료 등 적재 - 유관 부서 이외에도 리서치 결과 공유 - 팀 내 리서치 진행내용 회고
* 이 글은 제로베이스 UIUX 디자인 스쿨 주 3일반 강의 자료 일부를 발췌하여 작성되었습니다.
: 사용자가 과업을 수행하는 동안 하는 행동, 느끼는 감정, 그리고 상호작용하는 접점(터치 포인트)을 시간 순서로 정의한 것.
과업을 수행하는 동안 사용자가 보고, 듣는 모든 것과 그 곳의 환경 역시 상호작용하는 접점에 해당한다.
< User Journey Map을 통해 알 수 있는 것 >
1. 사용 동기 (Motivations)
- '커피를 마시고 싶다'가 동기라면 '어느 카페를 갈까? 나 쿠폰 있는데' 라고 살이 붙으면서 목적이 됨.
2. 시작점 (User Approach)
- 커피를 마시고 싶다는 생각을 하고 카페 위치를 찾고 걸어가서 카페에 들어가는 과정부터 시작점이라 볼 수도 있고, 앞의 과정을 생략하고 카페에 들어온 이후부터를 시작점으로 정할 수도 있음.
3. 행동 (Action)
- 스텝 바이 스텝으로 행동을 기록.
4. 감정 (Emotions)
- 스텝마다 사용자가 느끼는 감정도 기록.
5. 도구 (What they use for)
- 핸드폰을 보고 주문을 위해 직원과 대화하고 주문 번호가 뜨는 디스플레이를 보는 등 사용자가 상호작용하는 모든 것들을 맵에 기록.
6. 시간 (Time and Sequence)
- 유저 져니 맵의 핵심을 사용자의 동기가 발생하고부터 목적을 달성하는 것까지의 과정을 담은 것. 가장 중요한 것이 시간.
[ User Journey Map의 활용 ]
1. 팀원 및 이해관계들의 공통된 이해를 도와줌.
2. 디자인 의사결정에 주요 기준이 됨(퍼소나)
3. 기회 요인(Opportunity)과 문제점(Problem)을 도찰할 수 있고 특히 선후관계를 파악할 수 있음.
4. 사용자가 우리 제품을 어떻게 수용하고 있는지 쉽게 파악할 수 있음.
5. 타 부서와의 협업에 매우 유용한 자료가 됨.
< User Journey Map의 중요성 >
= 무엇보다 사용자를 공감하기 위한 중요한 도구가 된다. 깊은 공감을 통해 디자인 의사결정 과정에서 보다 사용자 중심의 방향으로 나아갈 수 있다.
프로젝트 진행 과정에서 우리가 자주 접하는 실수
1. 우리가 누구보다 우리 사용자를 잘 이해하고 있다. (높은 자신감)
2. 우리 사용자는 이렇게 생각할 거야.(나를 기준으로 해석하면서 확증편향에 빠짐)
3. 사용자 조사 결과를 객관적으로 해석하지 못함
User Journey Map의 기본 구조
- Zone A:퍼소나 영역
- Zone B:Experience의 영역.
③: step 사용자가 과업을 수행하는 순서
④: 액션
⑤: 유저의 생각
⑥: 사용자의 감정
유저 저니맵의 목적은 궁극적으로 사용자를 이해하고 Insight를 얻기 위함.
- Zone C: ⑦,⑧번 영역에는 기회요인이나 담장자, 문제점, 떠오른 아이디어 등을 작성함.
[ User Journey Map 만들기 ]
1. 범위 정하기
- 여정 지도를 작성하는 목적과 범위 정하기
- 여정의 범위: 제품 전체 또는 특정 기능 또는 세부 Task가 될 수 있음.
- 여정 지도의 디테일 수준을 정하기
2. 퍼소나 정하기
- 퍼소나가 정의되어 있더라도 제작 목적에 따라 공통 여정 지도만 제작할 수 있음.
- 반대로, 특정 기능에 대해 사용자 별로 다른 사용 행태가 예상되는 경우 각각의 여정 지도를 제작하여 비교 분석할 수 있음.
3. 기준 항목 정의
- 여정 지도에서 단계별로 표시할 정보를 정의한다.
- 기본적으로 사용되는 항목
단계 Phase 감정 Emotion 문제점 Problem
과업 Task 기능 Functions 기회요인 Opportunity
- 필요에 따라 추가할 수 있는 항목
접점 Touch Point 장소 공동 작업자 (사용자가 과업 수행시 상호작용하는 사물이나 사람)
4. 프레임에 정보 채워넣기
- 만들어진 틀 안에 해당하는 정보를 채워넣는다. 이때 시스템 중심이 아닌 사용자 중심으로 한다는 것이 포인트이다. "사용자라면 A를 완료하기 위해 무엇을 의도하고 행동할까"의 관점을 유지한다. 예상되는 사용자의 '다른 선택'이나 '오해' 또는 '실수'로 인해 연이어 발생되는 브랜치 플로우 (Branch Flow)를 정의한다.
5. 리뷰하기
- 프로젝트 참여자들과 함께 작성된 여정 지도 리뷰하기.
[User Journey Map의 활용]
< User Journey Map을 활용하면 장점 >
- 한마음 한 뜻 : 팀원 모두가 일치된 사용자 모델을 이해
- 문제점의 구체화 : 문제점을 다각도로 부석하여 문제의 원인과 해결방안 모색에 도움을 줌
= 유저 리서치 결과와 여정지도를 비교하여 기존에 파악된 문제점의 상세한 원인과 그 해결방안을 모색하는 자료로 활용될 수 있음.
문제점의 구체화
- 문제점의 구체화를 통해 UI적 문제점을 해결할 수 있다.
- 시스템 / UI적으로는 문제 없는 과정 이더라도, UJM을 통해 개선점을 발견
- 기존 문제점의 상세한 원인과 해결 방안을 모색하는 자료
[사용자 여정 지도의 특징]
- 물리적 시간 표현
- 전략적 사고 (기존 프로세스 단축, 효과정 방안 모색)
- 조사결과 -> 원인 파악 -> 개선방안 도출 -> 기대 효과
- 사용자별 특징 포착 (예외 케이스의 중요도가 얼마나 높은가를 판단)
- 리서치 주안점 도출 (POV, point of view) ; 추가 리서치 필요 부분 발견, 추후 리서치에 필요한 POV 함께 정의
Context의 효과적 공유
[ 태스크 플로우 Task Flow ]
- 과업 수행의 흐름(사용자가 Task를 어떻게 수행하는지를 선형적으로 표현한 것)
-UI 설계의 중요 단계
[ 테스크 플로우와 유저 저니맵의 차이점? ]
- 형식적으로는 비슷한 면이 많음.
공통 — 사용자의 행동/목적이 어떤 순서로 어떤 행동을 하며 어떻게 달성하는가를 시간 순서대로 기재
차이 — 저니맵이 더 큰 개념(져니맵에서 유저의 특정 행동 - 속성의 플로우를 표현한 것. 시스템 대응 파악)
= 저니맵에서 특정한 액션을 선택하여 이 액션의 디테일한 과정과 시스템의 움직임을 태스크 플로우로 작성
Task Flow의 구성
Task Flow의 시스템 스텝별 기능
Task Flow 시스템 스텝별 지원 기능 정리
= Task Flow는 유저가 Task를 완료하기 위한 행동의 연속이다.
- 사용자 과업 정의
- 퍼소나에 따라 동일 task가 여러개로 정의 가능
- 시나리오 기반으로 가능한 모든 파생 루트 표시
- 대략적 콘텐츠와 기능 설명 포함 가능 (주요 기능, 필수 입력 항목 등)
- UJM에서 하위 분류 된 플로우
[ Task Flow의 이점 ]
- UI를 빠르고 저렴하게 현실적으로 바라볼 수 있다.
- 시스템 개발 관점과 사용자 관점 포괄 가능 (다양한 포지션의 사람들의 타협점과 모색 시작점 파악)
- 발생 가능한 문제점 미리 발견하고 대응
- 각 단계별 어떤 정보와 기능이 필요한지 확인
- 발생 가능한 모든 경우의 수 확인
[ Task Flow의 3요소 ]
1) Personas : Who ar the users?
2) Goal : What do they want to acomplish?
3) Steps : What are the steps users need to take to archive the goal
Task Flow를 그리기 위한 플로우차트 컴포넌트
[ Task Flow 만들기 ]
1. 목적 Goal
- 신규 개발을 위해
- 기존 ui 분석을 위해 (기반 데이터에 따라 담는 내용이 달라질 수 있다)
2. 시나리오 정의 Scope and Use-case
- 누가, 어떤 목적으로, 언제, 어디서, 무엇으로 사용
3. 디테일 수준 Level of Detail
- 작성 목적에 따라 디테일 수준 결정
4. 작성 방법 Tool
- 작성 / 수정 / 공유가 용이한 방법 고려
STEP 1. Task의 목표
팬케이크를 만드는 과정으로 예시
STEP 2. 사용자의 모든 행동 기술
- 작성할 행동 범위에서 외부적으로 일어나는 인터랙션은 경우에 따라 필수/옵션이 되기도 한다.
STEP 3. 의사결정 요인 추가
- Decision point / 사용자의 의도와 시스템의 목적에 따라 TF가 나눠지는 시점 추가
STEP 4. 의사결정 요인 추가
- Remarkable Point 추가 / Pain Point or Opportunity
STEP 5. 확장: Branch Flow 정의
- What if / 다양한 가능성 검토를 위해, 발생 가능성이 있는 만약을 가정하여 다양한 브랜치 플로우를 작성
[ User Flow ]
: Task 시작점이 반드시 시스템이 아닐 수 있다는 점이 차이가 있다. (시스템 외부, 포털서비스 등)
사용자의 동기 발생 시점부터 시작하는 경우가 많음
주제를 벗어나지 않는 적정한 범위 안에서 User Flow를 작성한다.
[ User Story Map ]
: 사용자 스토리 맵과 Journey Map과 유사할 수 있으나, '왜 스토리맵을 만드는지 어떤 관점으로 사용자를 보고 어느 시점에 어떤 형태로 디자인에 도움을 줄 수 있는가'를 이해해야 한다.
작게 나누어 스토리를 작성해본다.
1. Backbone 만들기
- 사용자에 관련된 우리가 아는 모든 것 (factors)
- 레고로 집을 짓는다고 가정한다면, 레고 조각 하나 하나를 수집한다고 이해
2. 이야기 만들기
3. 관점 나누기 Share view point
- 다른 퍼소나와 관점을 갖고 비교하며 스토리텔링 (사고편향 방지&가능한 풍성한 스토리 생성)
4. 추가 작업
5. Activity(or epic) 기준으로 그룹핑 Group tasks by activity
6. 우선순위 Start Slicing
- 중요도와 사용 횟수 등에 따라 에픽들을 분류한다.
7. 세부 작업
8. 스토리 맵 결과
* 이 글은 제로베이스 UIUX 디자인 스쿨 주 3일반 강의 자료 일부를 발췌하여 작성되었습니다.
: 목적과 환경에 따라 다양한 사용자 조사 방법론을 활용하여 사용자의 드러나는 사용 행태와 비언어적인 요구사항을 도출해내는 조사 (사용자가 어떻게 사용하고 이해하고 어떤 감정을 느끼는지를 통합적으로 조사하는 것)
- 사용자 조사의 필요성
[ 상황 ]
배달 서비스 어플리케이션을 만들 건데, 만들고자 하는 우리도 배달 서비스의 이용자이니까 사용자 조사 없이 바로 만들면 되는 거 아닌가?
= 우리가 사용자도 되기는 하지만 이해관계자 입장이다. 하루 종일 배달 서비스 관련 생각만 하고 이미 깊게 이해한 상태이기 때문에 보는 시각이 다른 일반 사용자들과 다르다. 이렇게 되면 대표성도 없어진다. 배달 서비스의 특성상 사용자 층은 다양한데 우리의 생각으로 모든 사용자들의 입장을 편향하게 되는 것으로 디자인 컨셉에 대한 도출 자체가 어긋난다.
즉, 사용자 조사는 필요하다.
[ 사용자 조사 방법 ]
- Natural: 사용자에게 개입하지 않고 있는 그대로를 조사
- Laboratory: 연구소처럼 사용자를 조건에 두고 조사
1. Ethnography
: 사용자의 생활을 관찰하고 순수한 데이터를 얻는 가장 자연스러운 방법
- Town Waching: 높은 곳에서 관찰하는 조사
(버스 정류장을 관찰하면 어느 시간대에 사람들이 많고 버스를 잡을 때는 어떤 행동을
하게 되는지에 대한 데이터를 얻을 수 있다.)
- Contextual inquiry: 사용자에게 궁금한 점을 인터뷰
(관찰하고자 하는 행동을 하는 사용자를 관찰한 후 궁금한 점을 나중에 따로 인터뷰 함)
- Photo diary: 사용자에게 어떤 행동을 했을 때 사진 데이터(기록 데이터)를 모음
= Town Watching, Photo diary는 불필요한 데이터가 많아 유의미한 데이터가 없을 수 도 있음
2. Usability Studies
: 사용자를 조건에 두고 데이터를 얻는 방법
- Usability Test: 사용성 평가, 사용자에게 Tesk를 주고 사용자 행동에 대한 데이터 분석을 함
(사용자에게 링크를 주고 또 다른 사용자에게 공유하라는 미션을 주었을 때, 어떤 행동을 하는지 등)
- Card sorting: 미리 준비해놓은 자료들을 바탕으로 사용자에게 분류해보도록 함
- A / B Test:2-4개의 디자인을 준비해두고 사용자에게 투표를 받는 형태
= 높은 확률로 원하는 데이터를 얻을 수 있지만 질문하지 않은 데이터는 얻을 수 없어 폭이 좁아질 수 있음.
그리고 Card sorting 과 A / B Test 같은 경우는 선택지를 우리가 주는 상황이기 때문에 우리가 준비한 선택지가 완벽하지 않으면 오히려 더 악영향을 미칠 수 있음.
3. Contextual inquiry
: in Context (사용자가 있는 곳에서) -> do Inquiry (사용자를 연구)
- 사용자를 이해하고 질 높은 데이터를 얻기 위해서 기반 지식을 가지고 있어야 한다. (알지만, 모르는 척)
- 도재와 장인 관계로 접근 (디자이너와 사용자)
사용자가 디자이너에게 아무것도 모르는 척 모두 설명하도록 유도
Contextual Inquiry Process
[ Contextual inquiry 유의사항 ]
1. 사용자가 있는 곳으로 가서 인터뷰하기
- 사용자가 최대한 사용자 주변 환경과 상호작용 하는 것을 활용할 수 있도록 하기 위함
2. 정해진 질문은 최소화, 대신 사용자가 직접 말하도록 유도하기
- 말하는 사람의 역할이 우리가 되지 않도록 유지
3. 전문가는 사용자이며, 우리를 가르쳐 달라고 부탁하기
- 사용자가 생각할 때 너무 당연해서 말 안해도 되는것 까지 얘기해달라고 부탁해야 함
4. 사용자에게 가이드를 주지 않기 (주작 x)
- 중간에 사용하지 않은 기구들을 사용해달라고 한다던지, 사용하지 않는 건지에 대한 질문으로 조사에 어긋날 수 있음
- 관찰 후 나중에 다시 인터뷰로 질문
5. 목적(goal)을 먼저, 그리고 나서 왜(why), 어떻게 하는지(task process) 조사
- 모든 내용 관찰 후 이후에 메일이나 인터뷰를 통해 한번 더 설명해달라고 부탁하기
- 사용자가 행동하는 도중 개입해서 물어보는 것은 사용자가 설명을하기 위해 평소처럼 행동하지 않을 수 있기 때문에 좋지 않음
6. 사용자에게 직접적으로 불만이나 아이디어를 묻는 것 자제
7. 중립적인 자세 유지
8. 그 공간에서 사용자가 어떤 사람/사물과 인터랙션 하는지 관찰
[ 사용자 조사 준비 ]
[ 사용자 조사 설계 프로세스 ]
1. 조사 목적 정의: 어떤 걸 알고 싶은가?
2. 조사 범위 정의: 조사 시간에 대한 낭비가 있을 수도 있으므로 범위를 신중하게 정한다.
3. 조사 방법 정의: 얻고자 하는 데이터가 어떤 것인지 생각해보고 그게 맞는 조사 방법으로 정의한다.
4. 조사 대상자 기준 정의: 대상자에 따라 수집되는 데이터가 달라질 수도 있으므로 신중하게 기준을 정의한다.
5. 조사 대장자 모집
6. 파일럿 테스트
7. 조사 실행
8. 결과분석
- 원격 사용자 조사의 장점은 참여에 대한 부담이 적어 테스트 진행 시간을 길게 할 수도 있고, 화면 녹화를 통해 간편하게 자료를 수집할 수 있다는 것이 있다.
- 사용자 조사는 프로젝트 초반에 해도 되지만 중간에 공백이 생기거나 의문점이 생겼을 때 해도 무관하다.
[ 사용자 조사 계획서 ]
- 조사 계획서는 필수는 아니지만 계획서를 작성하면서 빠진 점을 더블 체크할 수 있고, 이해 관계자와의 커뮤니케이션에 활용하면 좋다.
[ 파일럿 테스트 ]
- 드레스 리허설: 실제와 똑같이 테스트 해보면서 마지막으로 점검
- 시간 확인: 테스트 예상 시간과 다르게 시간이 오버되는 경우가 있으므로 질문을 수정해야 함.
-변수 확인: 테스트 도중 변수를 수정할 수 있음
-기술적 점검: 테스트할 때 오류가 없는지 확인 가능
[ 사용자 조사결과 분석 및 모델링 ]
< 사용자 조사 결과를 통해 얻는 것 >
- 대상 도메인에 대한 더욱 깊은 이해
- 사용자의 내제된 요구사항과 존재하는 불만 요인 파악
- 시퀀스에 따른 사용자의 감정 변화 파악
- 사용자의 심성 모델(Mental model) 파악
- 전반적인 사용 경험 및 학습 수준에 대한 파악
- 사용 동기(motivation)와 작업 과정(task flow, Jobs to be done) 파악
< 사용자 조사 결과 분석을 통해 얻는 것>
- 사용자 행태와 니즈에 대한 명확한 이해: 사용자에 대한 공감
- 시장의 수준과 서비스의 진입 장벽(huddle)
- 디자인 컨셉/가설 평가
- Shed light on users: 모르는지 몰랐던 부분에 대한 이해
[ 분석 및 모델링 ]
1. 분석하기
: 로우 데이터(날것형태) 정형화
- 오디오 녹음 파일
- 비디오 파일 : 화면 녹화 또는 조사 장면 녹화
- 노트 케이커와 관찰자의 노트(*노트테이커를 필수)
- 설문조사 결과
- 정량적 측정 데이터(클릭스트림,페이지뷰 등)
2. 녹취록 만들기
: 녹취록을 만드는 이유
- 모든 사람이 로우데이터를 사용 할 수는 없다.
- 기억은 편향적이다. (본인이 원하는 방향으로 곡해하여 기억할 가능성이 있음)
- 비 언어적인 데이터 수집
- 데이터 정합성을 위한 안정장치 (한사람의 기억과 해석에 의존 사용자의 답변을 해석하면 객관적 데이터를 얻기 어려움)
3. 정보 구조화 하기
: 어피니티 다이어그램
2차 정형화 과정
- 데이터 간 연관성/속성파악
- 핵심 데이터 파악
- 데이터 사용성 향상
Affinity diagram 만들기
[ 아티팩트 모델 (오브젝트모델) ]
- 사용자가 무엇과 인터랙션 하는지 알 수 있다.
- 행동 유발의 계기 및 문제점을 발견 할 수 있다.
- 특정 아키팩트의 사용 전후로 인한 변화를 이해할 수 있다.
- 장애 요인을 파악 할 수 있다. ( 환경적인 부분에서 특히 그렇다.)
강사님이 강의를 준비하는 과정을 그린 그림
* 이 글은 제로베이스 UIUX 디자인 스쿨 주 3일반 강의 자료 일부를 발췌하여 작성되었습니다.
