UX디자인 - 사용자테스트

어떻게 해야 하는가?

- 사용자는 제품의 최종 심사위원이지만, 그들의 행동을 사전에 예측하기란 매우 어려운 일, 무엇을 원하는지 그들에게 묻더라도 그들이 말하는 내용이 정말로 필요한 것인지는 확신할 수 없다.

- 아이디어가 실제로 어떻게 작동하는지를 제대로 이해하기 위해서는 제품을 어떻게 사용하는지를 관찰할 필요가 있고, 의견이 아니라 반응에 집중해야한다.

- 솔루션이 사용자에게 얼마나 효과적으로 작동하는지를 더 빨리 확인할수록 유리하고, 사용자에게 아이디어를 테스트하는 것은 디자인 프로세스에서 매우 중요한 단계

이를 위해서, (1) 테스트 프로세스의 목적을 이해하고, (2) 간섭이나 방해를 차단할 수 있는 테스트 절차 계획, (3) 적절한 결론을 추출하기 위해 사용자의 행동을 관찰하는 방법을 학습해야 함

---

😎{사용성 테스트의 역할 이해하기} - 여기부터!

일반적인 원칙을 담은 사용성 가이드라인이 존재하지만, 제품을 독특하게 만드는 특정 컨텍스트에서의 모든 고려사항을 포함할 수는 없기에 아이디어가 특정 컨텍스트에서 기능하는지를 확인하기 위해 해당 컨텍스트에서 테스트할 필요가 있다.

사용성 테스트는 제품의 사용성에서 가장 의미가 큰 이슈를 확인하기 위해 사용되는 프로세스, 사용자가 어려움을 왜 겪는지, 이러한 문제점이 해당 컨텍스트에서 사용자의 목표 달성을 얼마나 방해하는지를 이해하는 데 도움을 줌

{사용성 테스트의 일반적인 절차는 다음과 같다.}

1. 무엇을 테스트할지 그리고 이를 위한 적절한 접근법 결정하기

2. 사용자에게 컨텍스트를 제공할 계획과 적절한 질문 정의하기

3. 참가자가 제품과 어떻게 인터랙션하는지 관찰하기

4. 발견점 확인하고 요약하기

 

{사용성 테스트의 역할 이해하기 - 테스트 대상 결정하기}

아이디어를 테스트하기 위해서는 테스트할 대상을 준비해야한다.

기존 제품 : 

제품의 이전 버전 혹은 경쟁사의 유사 제품을 테스트할 수 있고, 제품이 이미 존재하기 때문에 저렴한 비용으로 사용자에 대해 더 많이 배우고, 기존의 아이디어가 어떻게 작동했는지를 더 잘 이해할 수 있는 기회

 

초기 디자인 :

스케치와 목업만으로는 디자인하는 경험에 사용자를 몰입시키기 어렵지만 사용자의 멘탈 모델과 기대 사항을 파악하는 데에는 도움을 줄 수 있고, 사용자에게 친숙한 용어와 컨셉을 이해하기 위해 스케치의 아이디어를 그들이 재해석하도록 요청할 수 있다.

- 목업은 사용자에게 제품과 상호작용을 한다면 예상되는 결과를 나타내어 그들의 기대사항을 확인하는데 사용 가능하다.

 

기본 인터랙션 컨셉 : 

기초적인 프로토타입을 사용하여 앱의 전반적인 컨셉이나 특정한 워크플로우에 대한 접근법을 테스트할 수 있고, 컨셉에 대한 확신 수준에 따라서 단일 컨셉에 대한 테스트에 초점을 맞추거나, 가장 효과적인 방향을 찾기 위해 몇 개의 선택 가능한 접근법을 비교할 수 있다.

 

상세 인터랙션 : 

정교한 프로토타입을 사용하여 특정 활동을 더 효과적으로 평가할 수 있고, 더 정돈된 프로토타입으로 최종 제품에서의 인터랙션에 매우 근접한 인터랙션을 재현 가능하며 이를 통해, 검색 용이성, 모션 속도, 사용자에게 제공되는 피드백과 같은 인터랙션에서의 특정 측면이 예상처럼 잘 작동하는지를 확인할 수 있다.

 

제품의 개발 버전 :

제품을 개발하면서 중간버전을 사용하여 사용자의 피드백을 얻을 수 있고, 이는 목표로 하는 디자인과 실제 구현과의 격차를 확인하는 데에 유용하다. 또한, 사용자 경험을 가장 크게 개선 가능한 측면을 다듬기 위해 우선순위를 매기는 것도 도움이 된다.

{사용성 테스트의 역할 이해하기 - 적절한 방법 사용하기}

사용자의 모든 정보를 알아낼 수 있는 완벽한 방법은 존재하지 않지만, 가능한 노이즈를 줄이기 위해서 다양한 각도에서 파악할 수 있는 여러 가지 방법을 개발해왔는데 이 기법은 크게 발상적 리서치와 평가적 리서치 2가지 군으로 구분할 수 있다.

발상적 리서치 :

- 사용자 리서치를 파악하고, 이러한 관찰점을 그들의 문제점을 해결하는 방법에 대한 아이디어로 전환시키는 것을 목적을 두고 있다. 

- 맥락적 연구, 인터뷰, 설문조사는 발상적 리서치에서 사용되는 몇 가지 기법, 이 기법은 프로젝트의 최초 반복에 적용이 가능하다.

 

평가적 리서치 :

- 솔루션이 얼마나 효과적인지 확인하는데 초점을 맞추고, 아이디어가 떠오르면 아이디어가 사용자에게 얼마나 적합한지를 확인, 즉 평가하기를 원할 것이다. 기법 중 일부는 사용자의 태도에 기반을 두며, 다른 일부는 실제 사용자의 행동에 집중한다.

 

{ 평가적 리서치 - 행동 vs 태도 }

행동적 기법은 개입을 최소한으로 하면서 사용자의 행동을 이해하려는 반면, 태도기반의 기법에서는 사용자가 직접 정보를 제공한다.

- 관찰을 위해 사용자를 경험에 몰입하게 만들고 그들의 행동을 해석하는 노력이 들어가지만, 사용자가 말하는 것보다 그들의 실제 행동이 훨씬 믿을만 하다는 사실을 확인할 수 있다.

 

{평가적 리서치 - 정성적 vs 정량적 }

정성적 기법은 직접관찰을 기초로 하며, 정량적기법은 설문조사 혹은 서버로그 등을 통해 수집된 데이터를 측정하고 종합하는 것을 기반으로 한다.

- 숫자를 통해서 무엇인 발생했는지를 이해할 수 있지만, 정성적 기법에서 사용된 관찰은 행동의 이유를 설명해 준다. ex) 사용자가 당신의 앱에서 보낸 시간을 측정한다면 사용자가 콘텐츠에 더 몰입하여 더 긴 시간을 보낸 것인지, 아니면 원하는 정보를 찾기 힘들어서 더 긴 시간이 걸린 것인지를 측정치가 말해줄 수 는 없다.

 

다양한 행동적, 정성적 기법 중에서 사용성 테스트에 집중하고, 사용성 테스트는 사용자 행동 관찰에 기초한 리서치 기법으로 이 기법을 통해서 문제가 되는 사용성 패턴을 확인할 수 있으며, 디자인이 사용자의 목표 달성에 도움을 주지 못하는 이유를 파악할 수 있다.

사용성 테스트에서 사용자의 의견이 아니라 그들의 반응을 살펴야 하기에 최대한 제품이 사용되는 실제 컨텍스트와 유사한 상황을 재현하고, 일부 참가자가 그런 경험을 거치게 하면서 솔루션이 사용자 니즈를 얼마나 잘 충족시키는지를 관찰해야 한다.

 

진행자가 있는 사용성 테스트 :

테스트 진행자가 참가자와 1대1로 상호작요을 하여 진행자가 직접 혹은 원격으로 개입할 수 있으며, 테스트 목적에 대한 컨텍스트 정보를 제공한다.

참가자는 목표 달성을 위해 태스크에 대한 생각을 말하면서 제품이나 프로토타입을 사용하게 되고, 그 동안 진행자는 다양한 사용성 문제점을 알아내기 위하여 참가자의 상호작용을 관차라혹, 이슈의 원인과 사용자의 멘탈 모델을 더 자세히 확인하기 위해 후속 질문을 던진다.

 

진행자가 없는 사용성 테스트 : 

테스트 진행자는 사전에 스크립트를 준비하며, 참가자는 추가 개입 없이 이를 따르고 스크립트가 동시에 많은 사람에게 배포될 수 있으므로 이러한 방식은 프로세스 자동화에 도움이 되고, 다양한 온라인 서비스를 통하여 프로세스 자동화가 가능

But, 진행자 부재는 예상치 못한 상황에 대한 더 깊은 이해를 방해하거나, 사용자가 궤도를 벗어났을 때 도움을 제공할 수 없다. 이 때문에, 스크립트는 정교해야 하고,  모든 가능한 일탈을 고려하고, 일부 태스크에는 시간 제한을 설정해야하며 프로토타입은 집중력을 잃지 않을 만큼 충분히 세련되게 구현돼야 한다.

 

사용성 벤치마크 :

다양한 제품 혹은 제품의 버전이 특정 태스크를 얼마나 지원하는지를 비교하는 것이 목표

- 참가자는 제품 혹은 프로토타입으로 태스크 세트를 완료하고 일반적인 측정값은 태스크 소요 시간, 태스크 수행 성공 여부, 발견된 에러 개수 이고 사용자의 학습 효과를 확인하기 위해서 주요 태스크를 반복 측정하기를 원할 수도 있음

 

종적 연구 :

일부 제품은 사용자의 장기간 활동과 관련된 목표를 가짐 ex) 사용자의 운동을 권장하는 활동 추적 제품은 몇 개월에 걸쳐 이어지는 장기경험 사용자를 포함한다.

이 때문에, 긴 기간 동안의 사용자 인터랙션을 지속적으로 관찰할 수 있다.

 

시선 추적 :

사용자가 무엇을 보는지를 캡처하는 것은 사용성 연구에서 유용한 데이터 포인트가 될 수 있다. 시선 추적 HW/SW를 사용하여 참가자가 어디에 시선을 두고 있는지를 확인할 수 있으며, 이는 사용성 테스트에서 매우 유용하다.

시선 추적은 사용자 행동과 그들의 시선에 대한 컨텍스트에서 고려해야하는 또 다른 데이터 포인트를 제공한다.

😎여기까지!

---

테스트 계획하기

최고의 결과를 얻기 위해서는 테스트에 앞서 몇 가지 사전 계획이 필요하는데 테스트 계획하기 절차는 아래와 같다

- 목표 정의하기

- 시나리오와 태스크

- 스크립트 정의하기

- 환경설정하기

테스트 계획하기 - 목표 정의하기

평가에서 관심을 가질 측면은 다음과 같다.

1. 시각적 계층 구조 : 제공되는 다양한 정보 간의 관계를 사용자가 이해하는가?

2. 내비게이션 : 애플리케이션의 여러 부분 사이로 사용자가 원활하게 이동하는가?

3. 워크플로 : 사용자가 활동을 매끄럽게 완수할 수 있는가?

4. 2가지 서로 다른 접근법 비교 : 어떤 측면 때문에 하나의 대안이 다른 하나보다 더 선호되는가?

> 확인하려는 목표를 정리하고 나면, 답을 얻기 위해 사용자에게 경험하게 할 컨텍스트에 맞는 시나리오를 정의할 수 있다.

 

테스트 계획하기 - 시나리오와 태스크

시나리오를 아래의 형태 중 하나로 조정하여 제공할 수 있다.

1. 일반적인 시나리오 : 사용자가 본 제품에 대한 첫인상을 묻고 사용자가 제품에 대해 기대한 바는 무엇인지, 사용자의 멘탈 모델에 얼마나 부합하는지를 확인하는 데에 도움을 준다.

2. 짐카나 : 참가자에게 달성 해야 하는 목표를 명확히 제시하고 이를 찾도록 한다. ex) 휴가 목적지에 방문하는 가장 저렴한 방법을 찾게 한다.

3. 리버스 짐카나 : 결과값의 예제를 참가자에게 제공한다. ex) 파리를 방문하는 프로모션 패키지의 이미지를 보여주고, 참가자에게 이를 찾는 방법을 알아내도록 한다.

4. 사용자가 정의한 태스크 : 참가자의 일반적인 활동을 묻는 초기 질문을 기초로 활동을 제안할 수 있다. 이러한 접근은 사용자에게 밀접하고 친숙한 컨텍스트를 더 자세히 이해하는 데 도움을 주지만, 테스트 제품이 이 같은 컨텍스트를 지원해야만 한다.

5. 예상 밖의 태스크 : 즉흥적이거나 오류가 발생한 상황을 테스트할 때에는 사용자 행동을 예측하기가 어렵다. ex) 메시지 알림 or 수신 전화에 사용자가 어떻게 반응하는지를 테스트하려면 사용자에게 부차적인 태스크를 먼저 요청하고 사용자가 부차적인 태스크를 마치고 나면 주요 태스크가 등장하도록 준비해야 한다.

6. 불가능한 태스크 : 달성 불가능한 태스크를 제시하는 것도 일부 경우에서는 유용할 수 있다. ex) 폰 주소록에 저장되지 않은 누군가에게 전화를 걸어보라는 요청은 전달된 정보가 존재하지 않는다는 사실이 얼마나 명확하게 인식 되는지를 판단하는 데 도움이 된다. 사용자의 목표를 확인하고 이를 시나리오에 명확하게 제시하는 것은 제품의 솔루션을 디자인하는 데 유용하다.

테스트 계획하기 - 스크립트 정의하기

테스트 스크립트 작성을 통하여 당신이 원하는 바를 직접 말하지 않고도 사용자가 수행하게 만드는 최고의 전략을 생각해낼 수 있고 테스트를 순조롭게 진행할 수 있는 가이드를 얻을 수 있다.

스크립트는 최초의 가이들이 뿐이기에 예측하지 않았던 부분에 대한 여지를 가져야 하고, 진행자가 없는 테스트에는 더 정교한 스크립트를 정의해야 한다.

- 테스트하려는 시나리오별로 테스트 스크립트는 일반적으로 다음과 같은 측면으로 구성된다.

1. 소개 : 참가자에게 시나리오를 전달하는 방법을 설명한다.
2. 질문 : 테스트 이전, 진행 중, 이후에 참가자에게 하는 질문을 통하여 참가자를 더 자세히 이해할 수 있다. 초기 질문은 문제점과 고객의 기대 사항에 대한 더 깊은 이해, 진행 중에는 특정 태스크에 대한 사용자의 실행 요청, 테스트 끝에서는 전반적인 느낌에 대한 수집이 이루어진다.
3. 예상되는 결과 : 태스크별로 사용자가 지나갈 것으로 예상되는 단계를 서술하려고 할 것이다. 이는 성공적인 경로에서 벗어나는 편차를 확인하는 데 도움이 된다. 또한 사용자 인터랙션을 관찰할 때 집중해서 관찰해야 하는 중요한 측면을 언급할 수도 있다.
4. 시나리오 변형 : 예상 결과를 바탕으로 일부 대안적인 액션 경로를 예측할 수도 있다. 경우에 따라서는 시나리오에 변형을 주는 방법도 고려할 수 있다.

 

- 사용자가 달성하려는 목표에 집중하고, 왜 그것을 달성하길 원하는지를 사용자가 이해하기에 충분한 컨텍스트를 제공하고, 사용자가 특정 단계를 거칠도록 유도해야 한다. 

- 용어 사용에도 주의해야 하는데, 특정 액션이 아닌 최종 활동이라는 점에 유의해야 하고 실제 사용자와 함께 프로세스를 시작하기에 앞서 파일럿 테스트를 실시하는 것이 편리하다.

- 파일럿 테스트의 목적은 스크립트 자체의 이슈를 찾는 것, 스크립트가 명확하고 사용자가 자신이 무엇을 해야 하는지를 쉽게 이해할 수 있는지를 검증하는 것

- 사실적인 사용자의 행동을 관찰하기 위해서 실제 사용자 환경에 최대한 가까이 다가길 원할 것이고, 사용자의 인터랙션을 상세하게 관찰하고 분석을 위해 기록을 보관하고, 관련 결과를 요약할 때 그 행동을 사용하길 원한다. 사용자가 일반적으로 사용하는 것과 유사한 기기를 쓰거나 사용자 자신의 기기를 쓸 수 있게 허용한다면 도움이 될 것이다.

사용성 테스트 실행하기

계획이 준비되면 사람을 찾고, 당신의 아이디어를 그들의 손에 올려놓고 그들을 관찰할 수 있다. 사용성 테스트 실행 절차는 아래와 같다.

1. 참가자 모집하기

2. 프로세스 소개하기

3. 사용자 행동 관찰하기

4. 주요요소 확인하고 결과 요약하기

사용성 테스트 실행하기 - 참가자 모집하기

문제점을 찾기 위해서 많은 사용자에게 테스트를 진행할 필요 없이 3명에서 5명의 사용자에게 제품을 테스트하는 정도로도 중대한 사용성 이슈의 대부분을 찾을 수 있다. 소수의 사람들을 테스트하면 되지만, 그 사람들이 당신의 목표 고객을 대표할 수 있어야 하는 것이 중요하다.

- 목표 고객을 정의하고, 그들의 특징을 페르소나 문서에 담고 이를 스크리닝 기준으로 사용하여 테스트 후보자를 선별할 수 있다.

사용성 테스트 실행하기 - 프로세스 소개하기

사용자가 편안함을 느끼게 하는 것은 그들이 평상시처럼 행동하게 만드는 데 도움을 준다.

1. 먼저, 참가자를 반갑게 맞이하고, 시간을 내준 데에 감사를 표하며 테스트 프로세스를 간결하게 설명하는 과정은 압박감을 줄이는 데 도움이 된다.
2. 테스트의 목적을 설명하고, 프로토타입으로 구현한 아이디러르 테스트하는 것이라는 점을 명확히 한다. 테스트 대상은 참가자가 아니라 제품이라는 점을 강조하며 목적은 이슈를 찾아내는 것이기에 참가자가 프로토타입을 사용하는 데 어려움을 겪는 것은 지극히 당연하다.
3. 사람들의 호의적이거나 부정적인 의견을 꺼내놓고 말하지 않으려는 경향을 방지하고 싶기에, 테스트를 진행하는 제품은 초기 프로토타입에 해당하며, 당신과 관련이 없는 팀에서 개발한 제품이라고 강조해서 말할 수 있다. 실제로 사실이 아니더라도, 사용자에게 어느 정도의 안전 거리를 확보해주면 그들의 생각을 솔직하게 말하는 데 도움이 된다.
4. 참가자가 소리 내 생각하도록 격려한다. 참가자가 프로토타입과 인터랙션하면서 그들이 무엇을 하는지, 무엇을 보는지, 어떤 점이 놀라운지, 어떤 점이 기대에 부합하는지를 말해주도록 만들어야 한다. 참가자가 소리내 말하게 만드는 것은 무엇 때문에 이슈가 생겼는지를 정확히 이해하기 위해서 그들의 생각을 읽을 수 있는 최고의 방법
5. 세션을 레코딩한다면 참가자에게 그 목적을 명확하게 전달한다. 레코딩은 제품 개선 목적으로 팀에서만 사용한다는 점을 설명하고, 세션 전체나 일부분에 대한 레코딩 공개를 고려한다면, 배포에 앞서 리뷰하고 승인할 기회를 제공한다는 점을 사용자에게 알릴 수 있다. 이를 통하여 사용자는 자신에게 통제권이 있다고 느끼며, 레코딩이 인터넷상에서 인기 비디오가 될지도 모른다는 걱정을 덜 수 있다.
6. 참가자에게 프로세스에 대한 어떤 질문이든 할 수 있는 기회를 제공하고 나면, 테스트 스크립트를 시작할 준비가 됨

사용성 테스트 실행하기 - 사용자 행동 관찰하기

테스트 진행 중에 앞서 정의한 스크립트에 따라 참가자에게 질문을 하게 되는데, 참가자가 어려움을 겪게 되면, 사용자의 행동이나 말을 문자 그대로 해석하지 않고 이슈를 유발한 근본적인 문제점을 찾아야 한다. 

테스트 세션 도중에 사용자가 이슈를 경험할 때마다 그들에게 도움을 제공하고 싶은 유혹에 빠질지도 모른다. 하지만 테스트 목표는 사용자가 성공하는 것이 아니라 어떤 부분에서 실패하고, 그 이유가 무엇인지를 당신이 알아내는 것이라는 점이다. 사용자가 잠시 동안 아무것도 하지 못할 때에도 이를 이용해서 왜 그들이 멈췄는지를 이해하고, 그들이 다른 경로를 찾도록 만들어야 한다.

사용성 테스트 실행하기 - 주요요소확인, 결과요약

테스트를 하다보면 동일한 이슈가 반복되는 패턴을 확인하게 된다. 사용자의 태스크 완수를 방해하거나 그들의 경험에 불편함을 만들어 내는 큰 이슈에 집중해야 한다. 모든 이슈를 해결할 리소스가 넉넉할지라도 우선순위에 대한 명확한 기준을 가져가는 것이 유용하다.

사용성 연구의 결과는 가급적 간략하고 흥미롭게 만들어야 하고, 결론을 간단명료하게 담아내야 한다. 주요 포인트를 강조하기 위해 스크린샷을 포함하고, 짧은 비디오 영상을 편집할 수 있다.

 

---

실용적으로 진행하기

사용자의 실제행동을 기초로 피드백을 받는 것은 디자인 프로세스에서 가장 중요한 부분 중 하나이다.  사용자가 제품을 어떻게 사용할지에 대해 과도한 자신감을 가진 일부 팀에서는 자기보고식 피드백에 의존하거나, 테스트 프로세스를 지나치게 복잡한 과정이라고 인식할 수 있다.

준비하는 데 시간이 필요하지만, 테스트가 실제로는 시간을 절약하는 방법이라는 점을 팀원들이 이해하도록 만들어야 한다. 더 빨리 문제점을 찾을수록 문제점을 더 쉽게 고칠 수 있다.

 

팀원들을 리서치 세션에 참관 시키기 :

리서치 세션을 직접 보는 것은 많은 팀에게 눈이 뜨이는 경험이 된다. 그들이 예상하기에는 매우 쉬운 기본 태스크를 완료하기 위해 사용자가 고생하는 모습을 목격하고 나면, 전체 디자인 프로세스의 목적을 더 수월하게 이해할 수 있다.

 

학습이 검증보다 훨씬 중요하다. :

사용성 테스트에 있어 최악의 설정 중 하나는 팀에서 이미 제품 방향을 정해놓고 이 결정을 확정하기 위한 의도로 사용성 테스트를 하는 것이다. 이를 피하기 위해서는 팀에서 제품의 구체적인 방향성을 결정하기 전, 이른 시점에 사용성 테스트를 진행하도록 밀어붙여야 한다.

 

리서치 질문에 대답을 하는지를 확인하라. :

리서치 질문을 명백하게 밝히는 것은 프로세스 시작뿐만 아니라 마지막에서도 목표를 명확화 하는 데 유용하다. 모든 경우에 대한 답변을 채울 수 없다면 다가오는 연구에서 무엇을 개선해야 하는지를 과거로 거슬러 올라가서 찾아낼 수 있을 것이다. 이는 리서치 질문을 더 명확하게 만들거나 더 좋은 답변을 얻을 수 있도록 프로세스를 향상시켜 다음 프로세스를 개선하는 데 유용하다.

 

리서치 숫자와 결합시키기 :

정성적 접근과 정량적 접근을 결합시키는 것은 당신에게 더 넓은 시각을 제공할 수 있다. 정량적 방법은 많은 수의 사용자에게 도달하고, 그들의 일반적인 행동에 대한 데이터 수집을 지원한다.

A/B 테스트를 사용하여 더 많은 사람에게 접근법을 비교할 수 있고, 테스트하려는 일부 변경이 반영된 소프트웨어의 변형안을 일부 제품 사용자에게 보여주는 것으로 구성된다.

 

리서치 숫자와 결합시키기 :

A/B 테스트 소프트웨어는 버튼 클릭률을 바탕으로 어떤 변형안이 더 좋은 결과를 얻었는지를 알려줄 것이다. 유용한 수치를 정의하기 위해서는 앞서 정의한 디자인 목표를 고려하고, 이러한 목표의 달성 여부를 표시할 수 있는 지표를 찾아내야 한다.