퍼소나부터 사용성 테스트까지

01. 퍼소나 알아보기

우리의 제품이나 서비스를 사용하는 고객군을 대표하기 위해 가상으로 만든 인물

앨런 쿠퍼의 저서 '정신병원을 뛰쳐나온 디자인'에서 소개된 방법론

서비스 기획, 제품 개발, 디자인 등 많은 분야에서 사용자 연구 및 마케팅 전략을 위해 주로 활용

 

누군가는 퍼소나의 유용성에 대해 의심한다

- 애자일로의 변화

- 퍼소나의 남용

- 마케팅 분야에서의 활용

 

문제 기술 3요소

1. 서비스의 현재 <목표>

2. 서비스에 대해 사업의 이해관계자가 다루고자 하는 <문제>

3. 서비스의 구체적인 솔루션이 아닌 <개선을 위한 명확한 요구사항>

 

비즈니스 가정 -> 현재 고객에 대해 예상해보고 이런 니즈가 있을 것이다를 예측

1. 우리 고객들은 ()하려는 니즈가 있다.

2. 이러한 니즈는 ()으로 해결될 수 있다.

3. 우리의 초기 고객은 ()이다. (일 것이다)

4. 고객들이 우리 서비스에서 얻어내려는 가장 큰 가치는 ()이다.

5. 고객들은 부가적인 이득으로 ()또한 얻을 수 있다.

6. 우리는 ()를 통해 주 고객층을 확보할 수 있을 것이다.

7. 우리는 앞으로 ()으로 돈을 벌 수 있을 것이다.

8. 시장에서 우리의 주 경쟁자는 ()이 될것 이다.

9. 우리는 ()으로 그들을 이길 것이다.

10. 우리의 가장 큰 제품 위험은 ()이다.

11. 우리는 ()을 통해 이 문제를 해결할 것이다.

 

사용자 가정

1. 사용자는 누구인가?

2. 그들의 일이나 삶에 있어서 우리 제품이 적합한 곳이 어디인가?

3. 우리 제품이 풀어야 할 문제는 무엇인가?

4. 언제 그리고 어떻게 우리 제품이 활용되는가?

5. 어떤 기능이 중요한가?

6. 우리 제품은 어떻게 보이고 활용되어야 하는가?

 

프토포 퍼소나 만드는 과정

- 항상 그렇듯, 먼저 가설을 설정하고 이후 실제 리서치를 통해 입증하는 과정을 거친다

- 가정 단계에서 프로토 퍼소나를 정의. 이후 다듬어 완성한 것이 타겟 퍼소나

- 누가? 왜? 우리 제품을 사용하는지/할지에 대해 할 수 있는 최선의 추정

- 팀원 모두 종이 위에 가볍게 프로토 퍼소나를 그려본다

- 계속되는 사용자 조사를 통해 가정을 입증하면서 수정

- 충분히 조정될 여지가 있고, 버릴 수도 있다

 

 

2. 퍼소나 실습

준비물 : A4, 펜, 포스트잇, 회의실, 함께 진행해줄 동료들

퍼소나를 만들기 위해 앞서 설정한 목표 및 문제 정의 대한 공통된 이해

너무 진지하지 않은 적당히 가벼운 마음

 

프로토 퍼소나 만들기

사용자 유형, 간단한 스케치 ,이름 등

실제 사용자의 행동이나 예측되는 행동 -> 사용자는 제품을 통해 어떻게 행동하는가? 어떤 행동이 예측되는가?

ex.사용자는 강의를 수강 중이다. 강의를 통해 직무에 활용하고자 한다 등

페인포인트&니즈 -> 제품을 통해 무엇을 하고 싶어하는가? 불만은 무엇인가?

ex. 강사의 목소리가 졸리다. 강의 시간대 별로 책갈피를 하고 싶다.

해결방안 -> 사용자의 페인포인트나 니즈에 대한 예상되는 해결책은 무엇인가?

ex. 강사가 재밌는 이야기를 들려줘야한다. 책갈피 기능을 추가한다.

 

타겟 퍼소나 만들기

1. 브레인 스토밍

- 팀 구성원이 모여서 문제 정의, 데스크 리서치 등에서 얻은 자료를 논의

- 앞서 만든 프로토 퍼소나를 함께 보면서 메인 타겟이 될 퍼소나는 어떤 것인지, 퍼소나 설정으로 인해 어떤 결과가 예상되는지 등을 논의

 

2. 타겟 퍼소나 템플릿 만들기

- A4 용지를 한 장씩 나누어 가지고 가로세로 2번 접어 4등분한다

- 각각 해당되는 항목을 작성한다. 여러장을 만들어도 된다.

 

3. 타겟 퍼소나 선정

- 각자 작성한 프로토 퍼소나를 소개하고 가장 타겟이라고 생각되는 3~4개 퍼소나 유형으로 추린다

 

퍼소나를 지속해서 개선하기

- 꾸미는 것에 시간 들이지 말라 -> 그 시간에 사용자와 이야기를 더 해라

- 인터뷰나 사용성 테스트 등을 통해 실제 고객의 의견 수집, 업데이트

- 영원히 사용하는 것이 아님 -> 반복적으로 시간이 지나면서 변화할 수 있음, 매번 리서치 진행 지속적으로 업데이트 필요

 

 

3. 사용성 테스트 알아보기

사용자에게 특정 과업을 수행하도록 과제를 부여한뒤 그 일을 진행하는 과정(행동)을 관찰하는 방법

- 의도한 서비스 시나리오대로 행동하는지 관찰

- 필수적인 컨트롤 요소를 인지/이해/예측/실행하는지 알 수 있음

- 이외의 다양한 컨트롤 요소를 인지/이해/예측/실행하는지 알 수 있음

 

사용성 테스트 (Usability Test) 와 유저 테스트 (User Test)는 다르다.

 우리의 제품을 평가하는 것이다.

사용자가 (기능)을 통해 (다음 단계 진행)을 할 수 있는가? 문제점은 무엇인가?

 

인지 : 사용자가 눈으로 확인/발견하였는가?

이해 : 사용자가 무엇이라고 또는 어떤 의미로 이해하였는가?

예측 : 무엇을 하는 기능인지? 또는 다음 화면을 어떻게 예상했는가?

실행 : 예측과 일치하는 부분 or 일치하지 않는 부분

 

회사에서의 리서치 진행 프로세스

프로젝트 발의 -> 기획 의도 공감 (프로젝트 목적/의미/목표 등) -> 사전 분석 (레퍼런스 및 벤치마킹) -> 컨설팅 (리서치 요건 협의, 리서치 방법론 설정) -> 리서치 진행 (pain point, hurdle, barrier 등 사용성 이슈 도출) -> 결과 분석 (정량/정성 분석) -> 인사이트 도출 (개선방향 및 방안 수립) -> 리서치 결과 트래킹 -> 다시 프로젝트 발의

 

사용성 테스트의 일반적 과정

1. 참여자 모집

2. 서비스 사용

3. 진행자(모데레이터)는 참여자가 길을 잃지 않도록 안내

4. 참관자들은 고객의 행동 관찰

5. UT가 끝나면 도출된 이슈에 대해 브리핑

6. 빠르게 개선

7. 반복

 

꼭 정석적인 사용성 테스트를 할 필요는 없다

- UT는 정성적 테스트, 무언가를 증명하는 것이 아니다

- 애자일 테스트에서는 인사이트를 얻기 위해 절차의 변경이 가능

- 기본적으로 진행자는 참여자의 생각을 말로 표현하도록 유도

 

사용성 테스트는 누구나 해도 된다

- 모든 프로덕트에는 문제가 있고, 심각한 문제는 쉽게 발견됨

- 다만 사용성 문제는 프로덕트를 만드는 사람들은 스스로 발견하기 어려움 (이미 어떻게 작동하는지 알기 때문에)

- 우리의 프로덕트와 관련 없는 사람들을 대상으로 사용성 테스트를 해야함

 

그런데 왜 안하는가?

- 대부분의 사람들이 사용성 테스트 경험이 없음, 중요성을 모름

- 시간이 부족하다, 만들어놓고 나중에 수정하자, 완성되지 않은 결과물이라 보여주기 꺼려한다거나 한다

- 분명 잘못된 것

 

큰 규모의 프로젝트와 애자일 프로젝트의 사용성 테스트 비교

 

사용성 테스트 참여자는 몇 명을 모집해야할까?

3명이면 충분해요.3 -> 3명만 해도 왠만한 심각한 문제는 잡는다.

사람수보다는 여러번의 테스트를 자주하자.

 

온라인 UT VS 오프라인 UT

오프라인 UT

기존의 리서치는 대면으로 진행

- 장점 : 참여자의 표정과 행동을 직접 관찰

- 단점 : 참여자 리크루팅 소요시간이 길고, 오프라인 특성상 비용이 크다

온라인 UT

비대면 형태로 진행 가능

사용자가 편한 장소에서 진행 -> 부담이 덜하고 실제 목소리가 나올 수 있음

 

스티브 크룩의 사용성 원칙 TOP3

제 1법칙 사용자를 고민에 빠뜨리지 마라!

모든 페이지는 쉽고 분명해야 함

사용자는 작동방식까지 이해하려 하지 않음. 적당히 임기응변

제 2법칙 고민 없는 명쾌한 클릭이라면 클릭 수는 중요하지 않다.

고민 없는 세 번의 클릭이 심사숙고해야하는 한 번의 클릭보다 낫다

사용자는 최선의 선택을 하지 않음. 최소 조건만 충족되면 만족함

제 3법칙 불필요한 단어는 삭제하라

쓸데없는 말은 줄이고 본론부터 얘기하라

사용자는 페이지를 읽지 않고 훑어본다

 

 

4. 사용성 테스트 수행하기 1

문제 정의는 가장 중요한 부분

무엇에 대해 테스트 할지, 누구에게 어떻게 질문할지 등을 고려하는 단계

 

초보자가 문제 정의 단계에서 자주 하는 실수

- 데이터를 반복해서 수집

- 깊은 분석 없이 일반적이고 피상적인 분석이나 단순한 설문을 진행

- 질문을 작성할때 깊이 고민하지 않음

- 이미 다들 알고 있는 내용을 정리할 뿐

 

좀 더 명확한 문제 정의를 위해서는?

- 내가 해결하고자 하는 문제에 직접 연관된 사람(고객)을 만나서 인터뷰

- 문제의 구조를 분해해보자

- 구체적으로 어떤 데이터를 살펴봐야할지 고민

- 문제를 분석하기 앞서 현 상황에서 고객의 상황을 시뮬레이션 해보자

- 고객 행동에 대한 가설을 세워보자

실습을 위한 팁 : 개선하고자하는 프로덕트/서비스를 하나 선택하여 그에 대한 문제 정의를 해보고 리서치 계획을 세워보자

 

데스크 리서치

서비스와 관련된 외부 상황 (트렌드, 시장환경 변화)부터 내부 상황 (조직, 협업 구조, 서비스 시스템)까지 다방면으로 서비스가 놓여있는 상황을 파악하기 위한 방법론

다른 사람이 리서치한 것을 찾고 검토하는 것

내가 개선하고자하는 서비스에 대한 통계 분석, 트렌드 분석, 벤치마킹, 사용성 평가, VOC 분석 등을 수행.

회사에서 직접 데이터를 얻을 수 없다면 논문, 기사, 리포트 자료 등 여러 방면으로 찾아보기

 

최상의 리서치 -> 사용자/사용자의 환경/서비스의 목표 3가지 관점이 겹치는 지점

1. 서비스를 이용하는 사용자는 누구인지 파악

2. 그 사용자가 서비스를 사용하는 환경과 맥락은 무엇인지 파악

3. 서비스가 목표로 하는 것은 무엇인지 파악

* 실습을 위한 팁 : 내가 개선하고자하는 프로덕트/서비스에 대한 문제 정의가 어느 정도 되었다면 현황을 파악하기 위한 데스크 리서치를 수행해보자

 

사용성 테스트를 위한 이해 관계자 인터뷰

회사에서 일하다보면..

- 타 부서로부터 요청받은 리서치를 단순히 설계하거나

- 피상적인 사용성 테스트를 하는 것에서 그치거나

- 가끔은 높으신 분들이 정한대로 진행되기도 함

 

하지만 리서처는 회사의 이해관계자들이 이야기하는 것이 정답이라고 생각하지 말고 항상 의심하기

- 대부분의 이해관계자는 솔루션 도출을 하고 싶어하고 빠르고 쉬운 해결책을 얻고 싶어함

- 그들은 아직 문제가 무엇인지 잘 알지 못할 수 있기 떄문에 관점을 바꾸어보자

 

 

이해관계자 인터뷰

- 이해관계자에게 이슈 또는 테스크 목록 작성을 요청

- 이슈 논의는 항상 함께 공유되어야함

- 주요한 이슈를 추리고 그 중에서 가장 중요한 것을 함께 논의

- 기분을 나쁘게 하는 커뮤니케이션은 자제

- 어떤 내용에 대해 이야기할 것 인지 미리 주제 전달

*실습을 위한 팁 : 내가 개선하고자하는 프로덕트/서비스를 직접 만들고 있는 사람을 찾기 어렵다면, 내가 이 서비스를 기획하는 사람이라고 가정하여 이슈 목록을 작성하고 그 중 서비스의 목표에 부합하는 우선순위 이슈를 찾아보자

 

테스크 작성하기

- 각 화면 세부영역 별로 사용자가 할 수 있어야 하는 Task를 작성해보자

- 문제 정의와 데스크 리서치 등에서 수집한 정보를 바탕으로 현재 해결해야 할 문제에 집중

- Task 작성은 처음에는 브레인 스토밍을 통하여 아이디어를 수집하고 우선순위 작업을 통해 먼저 확인할 내용을 정리함

 

5. 사용성 테스트 수행하기 2

 리서치 대상자 선별

아무나X 내가 해결하고자하는 문제에 집중된 사용자를 찾아야 함

인구통계학적 정보나 고객의 행동데이터르르 통해 선별하는 것이 가장 좋지만, 힘든 경우는 직접 사용자 그룹을 구분하는 작업을 하자

 

리서치 대상 그룹을 4가지 축으로 구분하여 리서치 대상 선별의 우선순위를 살펴보자

X축 : 고객을 찾기 쉬운 정도

Y축 : 얻을 수 있는 정보의 양

 

여기에서 대상 고객은 앞서 문제 정의/데스크리서치/이해관계자 인터뷰 등의 과정에서 발견한 정보를 기반으로 선정해야 함

*실습을 위한 팁 : 앞서 수집한 정보들을 기반으로 리서치 대상에 적합한 고객들의 특성을 정의해보자 (연령대, 서비스 이용 패턴, 고객의 니즈 등)

 

리서치 참여자 사전동의

- 사용성 테스트 시 화면 녹화, 녹음에 대한 동의

- 비밀 유지에 대한 동의

- 개인정보 수집 및 이용에 대한 동의

 

참여 동의 과정의 효과

- 참여자가 걱정하는 부분을 안심시켜 긴장을 완화

- 리서치 과정을 설명하고 목적을 분명히 함으로서 공감대를 높힐 수 있음

무신사 앱 내의 무신사 리서치 페이지를 통해 참여 신청을 받음 -> 사전 동의 확인해보기

 

리서치 참여자 모집하기

- 참여여부/리서치일정/리워드 등 안내

- 필요한 준비를 미리 안내 (앱 설치 또는 원격 연결 등)

- 이어폰 준비

- 조용한 장소에서 진행하도록 요청, 이동중 운전중에는 진행이 불가함을 안내

- 대면으로 진행할 경우에는 조용한 회의실에서 소음에 방해받지 않도록 진행

 

실제 회사에서는 자체적으로 유저의 pool을 관리하거나 리크루팅 업체에게 맡기기도 함.

 

원격 진행 경우 모니터 화면을 녹화하는 프로그램을 미리 설치

참여자의 반응을 자세히 살피기 위해 녹화 장비 등 미리 준비

작성된 테스크를 바탕으로 수행하고 별도의 인터뷰를 섞어 진행할 수 있음

 

진행자가 저지르는 실수

- 말을 너무 하지 말라

- 디자인을 설명하지 말라

- 참여자의 질문에 답변하지 말라

- 자꾸 인터뷰를 하려고 하지 말고 사용성 테스트를 하라

- 대답을 유도하거나 선호도로를 묻지 말라

 

결과 정리 및 리뷰

- 애자일한 사용성 테스트는 발견한 이슈에 대해 짧게 요약

- 테스트에 참관한 사람들에게 브리핑함

- 빠르게 다음 테스트를 준비할건지 아니면 깊은 분석을 할건지 의사결정 진행

- 결과를 분석하여 Action Item 도출

- 별도의 리뷰 세션을 통해 결과를 도출하고 다음 스텝으로

 

리서치 이후에 해야할 것들

- 다음 리서치 스텝 고려

- 리서치 결과 아카이브

- 참여자 리워드 제공

- 리서치 녹화 및 녹음 자료 등 적재

- 유관 부서 이외에도 리서치 결과 공유

- 팀 내 리서치 진행내용 회고

 

6. UX 리서처의 포트폴리오 팁

소프트스킬과 하드스킬 필요

커뮤니케이션 스킬이 가장 중요하다. -> 사람을 상대하기 때문에 기본적으로 공감이 잘 되어야 하고 소통 잘 되어야 함

 

리서처로 첫 시작을 하고자하는 분에게

- 신입 또는 주니어의 경우 실무에서 실제 고객을 대상으로 리서치를 한 경험이 적다는 것을 안다

- 학교 과제나 사이드 프로젝트 등에서 실제 리서치를 설계진행분석 해본 경험이 중요

- 혼자서 프로젝트의 리서치 과정을 다 진행해본 경험은 정말 좋다

- 스스로 과제를 만들거나 재능 기부 같은 것들의 기회를 활용해볼 수 있음 (자선 단체, 비영리단체)

- 꼭 대학원을 가지 않아도 된다

 

리서처의 포트폴리오는 결과보다 과정이 중요

- 진행한 프로젝트의 결과를 보여주기 보다 과정이 어떻게 수행되었는지가 더 중요

- 문제 정의가 어떤 과정을 거쳐 도출되었는지 보여져야 함

- 프로젝트에 사용했던 리서치 방법론을 고른 이유가 명확하고 근거 있어야 한다.

- 단순히 표면적인 리서치 결과로 끝나는게 아니라 Action Item으로 연결되어야 한다

- 구체적인 사례를 통해 설명하는 것이 좋다

- 포트폴리오를 보는 사람을 사용자라고 생각하고 작성하라

 

보여지는 것에만 집중하지 마라

- 시각적 인터페이스를 강조해서 보여주려 하지마라

-> 리서처는 화면을 디자인하는 것이 아니라 경험을 디자인하는 것

-> 도출된 디자인은 리서치 결과가 어떻게 적용되었는지 보여져야 한다

- 커뮤니케이션 스킬이 좋은 것이 좀 더 중요

-> 면접 대답이 맥락에 맞는가, 팀플레이에 유용한 사람인가

- 포트폴리오에서 사용하는 단어와 문맥, 오타 하나까지 신경쓰는 사람도 있다