사용성 테스트 가이드

사용자 친화적인 UI/UX는 어떻게 테스트할 것인가?

"고슴도치도 자기 새끼는 예뻐 보인다."

우리 앱은 정말 대단해!

"우리 앱은 이런저런 다른 앱들과 차별화된 서비스를 제공하며 유저들에게 보다 직관적이고 편리한 UI와 UX를 제공하고 있습니다."라고 주장하는 기업이 있다. 이들이 주장하는 유저들에게 보다 직관적이고 편리한 UI/UX의 기준은 어디서 온 것일까? 과연 이들이 주장하는 대로 유저들은 이 앱을 사용할 때 기존에 사용해 오던 다른 앱들보다 직관적으로 정보를 확인하고 편리하게 사용할 수 있을까?

실제로 온라인에서 서비스 중인 많은 웹, 앱들 중에서 UI/UX가 직관적이고 편리한 앱들도 있고 이와 반대로 도대체 어떻게 써야 하는지 감이 오지 않는 UI/UX를 가진 서비스들도 많다. 분명 이 서비스를 만들어낸 담당자들은 자신들이 원하는 방향이나 규칙대로 유저들이 사용할 것이라고 생각하겠지만 실제로는 그들만에 착각에서 끝나는 경우가 많다. 그러면서 유저들이 요청하는 개선사항들에 대해서 이해하지 못하고 자신들이 의도한 대로 사용하지 않는 유저들이 문제라고 얘기하며 문제를 덮어두는 경우도 있다.

사용성 테스트를 해야 하는 이유?

서비스를 개발할 때 많은 사람들은 자신이 가진 지식을 기반으로 설계하고 디자인한다. 하지만 이렇게 개발된 서비스들이 유저들에게 좋은 평가를 받기 위해선 기능적인 측면도 중요하지만 UI적인 측면과 UX적인 측면도 고려되어야 한다. 누가 봐도 기발하고 유용한 기능을 탑재하고 있다고 하더라도 유저가 이를 인식하지 못하거나 플로우가 복잡하여 사용하기 어렵다면 유저들은 우리가 제공하려고 했던 양질의 서비스를 제대로 경험해보지도 못하고 떠나가게 된다. 그렇기 때문에 서비스를 개발할 때 무작정 우리가 원하는 기능을 욱여넣기보단 어떻게 하면 유저들이 우리가 원하는 방향에서 크게 벗어나지 않고 올바른 플랫폼 규칙 안에서 사용할 수 있게 만들지 고민을 해야 한다.

이 같은 고민은 요구사항을 작성할 때 어느 정도 고려되긴 하지만 요구사항에서 사용성까지 고려하기엔 너무 많은 고민과 리소스가 낭비될 수 있기 때문에 유저의 사용성에 대해서는 디자인과 기능 정책에 대한 구체화 작업단계에서 고려하는 것이 좋다.

결과적으로 사용성 테스트를 해야 하는 이유는 다음과 같다.

데이터만으로는 알 수 없는 유저의 행동 이유를 정성적으로 파악하기 위해

VOC로 인입되는 문제들을 실제 유저가 어떤 상황에서 겪는지 관찰하기 위해

문제를 개선하기 위한 UX의 가설을 검증하기 위해

사용성 테스트 방법에는 여러 가지가 있지만 대중적으로 많이 알려진 “Heuristic Evaluation(발견적 평가방법)”을 주로 참고한다.

Heuristic Evaluation(발견적 평가방법)

제이콥 닐슨이 주창한 사용성 공학의 방법론 중 하나이다. 지속적인 디자인 개발과정(Interatice design process)을 거치는 컴퓨터 프로그램이나 웹사이트 등 복잡한 시스템을 위한 사용자 인터페이스 디자인 개발에서 사용성 문제를 조기에 발견해 내기 위한 방법이다.

이 방법을 적용하기 위해서는 사용성 원리를 잘 알고 있는 소규모 테스트 전문가들이 인터페이스 디자인을 평가하게 된다. 이때 어느 한 사람 만으로는 디자인된 인터페이스의 문제점을 발견해 내는 것이 어려운 일이기 때문에 소규모 테스트 전문가들에 의해 효율적으로 문제점을 찾아내는 방법이다.

이때 발견적 평가방법의 10가지 원리를 통해 디자인된 인터페이스를 테스트한다.

1. 시스템의 상태에 대한 가시성을 유지할 것 (Visibility of system status)
시스템은 항상 적절한 시간 내에 적절한 피드백을 통해 사용자에게 시스템의 현재 상황을 알려야 한다.

2. 현실 세계와 시스템이 일치할 것 (Match between system and the real world)
시스템은 시스템 중심의 용어가 아닌 사용자에게 익숙한 단어나 문구, 개념을 사용하여 사용자의 언어를 사용해야 하며 정보가 자연스럽고 논리적인 순서로 표시되도록 현실 세계의 규칙을 따라야 한다.

3. 사용자에게 컨트롤과 자유성을 부여할 것 (User control and freedom)
사용자는 실수로 시스템 기능을 선택하는 경우가 많으므로 긴 대화를 거치지 않고 원치 않는 상태에서 벗어나게 할 수 있는 명확하게 표시된 해결 방법을 제공해야 한다. (예: 실행 취소 및 다시 실행 등)

4. 일관성과 표준을 지킬 것 (Consistency and standards)
사용자는 서로 다른 단어, 상황 또는 행동이 같은 의미인지 궁금해하거나 추측해야 할 필요가 없어야 하며 플랫폼의 규칙(예: 이용 약관, 이용 정책 등)을 따라야 한다.

5. 사용자의 오류를 방지할 것 (Consistency and standards)
좋은 오류 메시지보다 더 좋은 것은 애초에 문제가 발생하지 않도록 세심하게 설계하는 것이다. 오류가 발생하기 쉬운 조건을 제거하거나 사용자가 작업을 실행하기 전에 오류를 확인할 수 있도록 옵션을 제시해야 한다.

6. 기억보다는 인식하게 할 것 (Recognition rather than recall)
개체, 작업 및 옵션을 표시하여 사용자가 대화의 한 부분에서 다른 부분으로 넘어가는 정보를 기억할 필요가 없어야 한다. 시스템 사용 지침은 필요할 때마다 눈에 보이거나 쉽게 검색할 수 있어야 한다.

7. 시스템 사용에 대한 효율성과 유연성을 가질 것 (Flexibility and efficiency of use)
초보 사용자에게는 보이지 않는 액셀러레이터는 종종 숙련된 사용자의 상호 작용 속도를 높여 시스템이 경험이 없는 사용자와 숙련된 사용자 모두를 만족시킬 수 있도록 하거나 사용자가 자주 사용하는 작업을 커스터마이징 할 수 있어야 한다.
사용성 테스트에서 “액셀레이터(accelerator)”는 사용자가 인터페이스를 빠르게 조작하고 상호 작용할 수 있도록 돕는 기능이나 요소를 가리키며 일반적으로 키보드 단축키, 제스처, 즐겨찾기 등이 있다.

8. 심미적이고 최소한의 디자인을 할 것 (Aesthetic and minimalist design)
다이얼로그에는 관련성이 없거나 거의 필요하지 않은 정보가 포함되어서는 안 된다. 다이얼로그에 추가되는 모든 정보는 다이얼로그와 직접적으로 관련 정보와 경쟁하며 상대적인 가시성을 떨어뜨린다.

9. 실수로부터 회복이 가능할 것 (Help users recognize, diagnose, and recover from errors)
오류 메시지는 시스템 코드 없이 사용자가 이해할 수 있는 일반 언어로 표현하고 문제를 정확하게 나타내며 건설적인 해결책을 제시해야 한다.

10. 도움을 줄 수 있는 문서를 제공할 것 (Help and documentation)
시스템 사용 시 마주할 수 있는 문제를 해결하기 위한 도움말과 문서를 제공해야 할 수 있다.

이러한 정보는 다음과 같은 사항이 요구된다.

- 검색하기 쉬워야 함

- 사용자의 작업에 초점을 맞춰야 함

- 수행해야 할 단계를 구체적으로 나열해야 함

- 각 단계에 대한 정보의 양이 너무 크지 않아야 함

발견적 평가방법의 장단점

장점: 테스터들이 참고하는 기준 항목이 매우 상세하기 때문에 프로세스가 매우 세밀하고 개선할 수 있는 부분에 대한 좋은 피드백을 제공한다.

단점: 특정 기준이 정해져 있기 때문에 테스트하는 사람에 따라 평가가 달라질 수 있다.

전문적인 테스트 집단이 사용성에 대한 평가를 하는 것은 전체적인 디자인에 대한 피드백과 가이드를 제공해 줄 수는 있지만 실제 환경에서 유저들이 느끼는 사용성과는 거리가 멀 수도 있다. 우리의 서비스를 이용하는 유저들의 대다수는 이러한 전문지식보다는 타 서비스들과의 사용성을 비교하기 때문이다. 그 서비스의 사용성이 전문적인 시각에서 좋지 않을지라도 이미 대중적으로 보편화된 UI/UX를 갖고 있을 경우 유저들은 그러한 UI/UX가 직관적이고 편리하다고 느끼고 있을 수 있기 때문이다. 그래서 사용성 테스트를 할 때는 전문적인 테스트 집단의 평가보다는 실제 유저들을 대상으로 테스트를 진행하는 것이 시장평가에서 유리할 수 있다.

다만 유저들을 대상으로 테스트를 하더라도 평가 항목(체크리스트)은 위 10가지 원리에 따라 작성하여 진행하는 것이 좋다.

테스트 대상 기능을 선정하고 체크리스트를 생성해 보자!

앞서 설명했듯이 사용성 테스트를 위한 평가 항목(체크리스트)은 위의 10가지 원리에 따라 작성해야 테스트 참여자들의 주관적인 평가의견을 객관적인 데이터로 가공할 수 있다. 때문에 체크리스트를 작성할 때는 테스트할 기능을 정하고 해당 기능을 설계, 디자인한 목적과 이유를 명확히 이해해야 한다.

이를 위해서 테스트 대상이 되는 기능을 선정할 때는 기능에 대한 정책과 디자인을 한 기획자와 디자이너가 함께 테스트 대상의 기능을 살펴보고 테스트를 통해 얻고자 하는 결과를 예상해서 체크리스트를 작성하는 것이 좋다. 예를 들어 평소에 유저로부터 잦은 VOC가 접수되던 기능을 개선한 경우 유저가 원하는 방향대로 제대로 수정이 되었는지를 측정하기 위한 개선 포인트가 체크리스트에 녹아져 있으면 좋다.

다만 체크리스트를 작성할 때 주의해야 할 점은 유저에게 미션에 대한 힌트를 제공하지 않도록 주의해서 작성해야 한다. 체크리스트에 우리가 원하는 흐름대로 행동하도록 유도하는 힌트를 제공할 경우 체크리스트가 매뉴얼 역할을 하게 되어 테스트 결과에 대한 신뢰성이 떨어지게 된다.

체크리스트 작성은 이렇게!

테스트를 위한 체크리스트에는 다음과 같은 항목이 필수로 포함되어 있어야 한다.

- 테스트 대상 기능 정보

- 테스트 대상 기능에서 수행할 태스크(미션)

테스트 대상 기능은 기획자, 디자이너와 함께 선정한 사용성 테스트가 필요한 기능 리스트로 이루어져 있으며, 이 기능들은 새롭게 개발되었거나 다시 디자인된 기능일 수 있으나 모든 기능이 사용성 테스트에 포함되지는 않는다. 테스트 대상으로 선정되는 기능들은 내부적으로 사용성 테스트가 필요하다고 판단되는 기능들만 진행하는 것이 좋다. 테스트 참여자에 따라 장시간 모든 기능을 테스트하는 것이 불가능할 수 있고 테스트해야 할 기능이 많을수록 옵저버나 테스트 참여자의 집중도가 낮아지기 때문에 후반부에 테스트되는 기능의 결과에 대한 신뢰도가 낮아질 수 있기 때문이다.

테스트 대상 기능을 선정했다면 해당 기능에서 테스트 참여자가 수행해야 할 태스크(미션)를 작성하는데 이때 사용해야 할 태스크의 유형은 다음과 같다.

- 자주 수행되는 태스크 또는 중요한 기능과 관련된 태스크

- 유저가 어려움을 겪을 것으로 예상되는 태스크

- 최종 목적지(기대결과)는 하나이지만 도달하기 위한 루트가 여러 개이거나 숏컷이 있는 태스크

- 재 디자인된 기능을 사용하는 태스크

- 새롭게 개발된 기능을 사용하는 태스크

사용해야 할 태스크의 유형을 파악했다면 다음은 태스크를 작성할 때 어떤 기준으로 태스크를 작성할 것인지 고민해야 한다. 태스크는 다음과 같은 기준으로 작성할 수 있다.

- Direct tasks or Scenario tasks (다이렉트 태스크 또는 시나리오 태스크)

- Open-ended or Closed task (열린 태스크 또는 닫힌 태스크)

Direct tasks or Scenario tasks (다이렉트 태스크 또는 시나리오 태스크)

다이렉트 태스크는 테스트 참여자가 수행해야 할 미션의 최종 목적지(기대결과)에 도달하기 위한 지시만을 전달하고 옵저버는 테스트 참여자가 미션을 완료할 때까지의 과정을 기록한다. 다이렉트 태스크의 경우 목적성이 명확하고 루트가 다양한 기능인 경우 유저들이 가장 많이 사용하는 루트가 어디인지 파악하기 위한 용도로 사용할 때 유리하다. 예를 들어

과외방에 교재 자료를 업로드하십시오.

반면 시나리오 태스크는 미니 유저 스토리와 흡사하다. 목표 달성에 필요한 필수 세부 사항을 포함하여 테스트 참여자가 실제 상황을 모방해 미션에 대한 공감과 사용성 테스트의 인위성(부자연스러움)을 상당 부분 완화시킬 수 있다. 시나리오 태스크의 경우 범용성이 높은 기능이나 사용 방법(조건)이 다양한 기능인 경우 유저가 어떤 방식으로 사용하는지 파악하기에 유리한 방식이다. 예를 들어

여러분은 영어 과외 수업을 결제하려고 하는데 메인카드 설정이 되어 있지 않은 상태입니다. 메인카드부터 설정한 후 과외 수업을 결제해 보세요.

Open-ended or Closed task (열린 태스크 또는 닫힌 태스크)

열린 태스크는 최소한의 정보를 제공해서 유저가 하길 바라는 행동에 대해 제약을 두지 않는다. 이는 유저가 시스템을 자유롭게 이용하면서 지속적으로 인터랙트 하는 영역이 어디인지, 또는 유저에게 문제가 되는 것이 무엇인지 찾고자 할 때 유용하다.

여러분은 북스 사이트에서 다양한 교재들을 구입할 수 있다고 들었습니다. 여기에 관심이 생겨 북스 사이트가 무엇이고 어떤 교재들이 있는지 확인해보고 싶어 졌습니다.

닫힌 태스크는 유저가 해야 하는 행동을 명확하게 지시한다. 이런 유형의 태스크는 하나의 정답만을 가진 기능을 유저가 해결할 수 있는지 해결하는데 어느 정도의 시간이 소요되었는지(예상되는 시간 내에 해결을 하였는지?) 해결하지 못했다면 어떤 문제 때문인지 파악하기 위한 가장 흔하게 사용되는 구성 방식이다.

여러분은 이번 회차의 과외시간에 참석할 수 없는 상황에 빠졌습니다. 과외 일정을 변경하기 위해 과외 일지에 접근하여 과외 일정을 변경하십시오.

열린 태스크를 사용할 때는 다음과 같은 제약 사항들을 고려해야 한다.

테스트 참여자는 자신이 태스크를 완료하였는지? 언제 완료하였는지 인지하지 못할 수도 있다. 또한 태스크를 끝내는 것에만 집중해서 우리가 원하는 탐색의 행위에 노력하지 않을 수 있다.

열린 태스크는 성공률을 측정할 수 없기 때문에 퍼포먼스 측정이 필요한 경우에는 적합하지 않다.

이런 이유로 인해 열린 태스크를 사용할 때는 닫힌 태스크와 적절히 조합하여 원하는 측정 결과를 얻을 수 있는 체크리스트로 구성해야 한다. 또한 태스크를 작성할 때는 다음과 같은 사항들을 주의해야 한다.

1) 유저에게 정답을 유추하거나 유도하는 단서가 되는 단어나 문장은 피해야 한다.

태스크를 만들 때 주어진 미션을 해결하는 데 사용되는 단어나 시스템에서 사용되는 용어가 들어가지 않도록 주의해야 한다. 참여자에 따라 특정 단어를 통해 정답을 유추해서 태스크를 수행할 수 있는데 이럴 경우 테스트의 목적과는 다른 결과가 나올 수 있다. 예를 들어, "당신은 주로 사용하는 교재를 '즐겨찾기' 하고 싶습니다. 원하는 교재를 '즐겨찾기' 해보십시오"라는 태스크 대신 "당신은 수업이 있을 때마다 사용하는 교재를 매번 찾는데 번거로움을 느끼고 있습니다. 수업을 진행할 때 매번 교재를 찾는 것보다 편리하게 사용하는 방법이 있지는 않을지 살펴보십시오"라는 형식으로 다소 장황할 수 있으나 상황만을 정확히 인지 시키면서 정답을 유추하는 단어를 피해서 작성하는 것이 좋다.

2) 현실적이게 작성하고 애매모호한 지시는 피해야 한다.

태스크에서 요구하는 미션은 테스트 참여자가 실제 상황에서 수행될 수 있는 미션이어야 하며, 상황에 대한 묘사는 애매모호해선 안된다. 애매모호한 묘사로 인해 유저가 다른 플로우로 태스크를 수행하게 된다면 미션을 달성하기에 까지 예상보다 많은 시간이 소요될 수 있고 이로 인해 테스트 결과 자체가 정확하지 않게 된다.

3) 적절한 수준의 디테일한 정보를 제공해야 한다.

테스트 참여자가 자신이 무엇을 해야 하는지 알 수 있는 정도의 충분한 정보를 제공하면서도 참여자들이 미션을 달성하기 위해 탐색하고 행동하는 것에 방해되지 않아야 한다. 따라서 상황에 대한 묘사는 길지 않아야 하며 태스크에서 달성해야 하는 미션의 요구사항에 대한 명확한 정보를 제공해야 한다. 예를 들어, "당신은 영어 스마트 콘텐츠를 학생에게 전달하려고 합니다."와 "당신은 영어 스마트 콘텐츠의 동영상 콘텐츠를 학생에게 전달하려고 합니다."라는 태스크에서 미션은 학생에게 스마트 콘텐츠를 전달하는 게 목적이지만 전자는 스마트 콘텐츠 안에서 아무 콘텐츠나 보내면 되기 때문에 행동자체가 단순해질 수는 반면 후자는 스마트 콘텐츠 안에서 동영상 콘텐츠와 일반 콘텐츠가 있다는 정보를 제공해 주기 때문에 스마트 콘텐츠 안에 어떤 분류가 있고 동영상 콘텐츠를 찾아야 한다는 생각과 행동을 하게 된다 이때 여기서 내비게이션이나 카테고리, 검색과 같은 기능이 제공될 경우 이에 대한 사용성 테스트를 할 수 있게 된다.

사용성 테스트를 위해 준비해야 할 것들!

"발견적 평가방법"은 정량적 데이터를 수집하는 것이 아닌 유저들의 정성적인 리뷰들을 취합하는 평가 방식이기 때문에 테스트를 하기에 앞서서 어떤 방식으로 진행할지 테스트에 어떤 역할이 필요한지 사전에 준비를 철저히 하지 않을 경우 유의미한 테스트 결과를 도출하지 못할 수도 있다. 때문에 테스트를 진행하기 위한 역할을 분배하고 각 담당자들이 참고해야 할 가이드를 작성해서 리허설을 진행하는 것이 좋다.

1. 역할 분담

- 모더레이터 : 사용성 테스트의 전체 진행

- 옵저버 : 테스트 참여자의 행동과 테스트 결과를 기록, 모더레이터 서포팅

- 코디네이터 : 참여자 모집과 스케줄관리, 참여자 커뮤니케이션 채널 운영 관리

2. 인터뷰 대상자 모집

3. 사용성 테스트 대상의 프로토타입 제작

4. 인터뷰 설문지 작성

- 참여자의 정보

- 진행 순서

- 아이스 브레이킹용 대본

- 테스트 체크리스트

- 마무리 대본

철저한 준비는 성공의 지름길!

테스트 준비가 되었다면 다음은 테스트를 진행할 옵저버들에 대한 사전 가이드와 리허설이 필요하다.

모더레이터의 경우 하고자 하는 사용성 테스트의 목적을 이해하고 있는 상태가 대부분이지만 지원된 옵저버의 경우 사용성 테스트를 진행하거나 서포팅해 본 경험이 없는 경우가 있을 수 있기 때문이다.

따라서 모더레이터는 옵저버와 코디네이터를 대상으로 리허설을 진행하여 진행 방식을 가이드하고 대본이나 체크리스트에서 빠진 부분이 있는지 체크하고 참여자들의 돌발행동이나 질문에 대해 미리 대비해야 한다.

테스트 환경을 구성하자!

사용성 테스트를 진행하는 환경(공간)은 참여자가 테스트 대상에 집중할 수 있도록 외부와 차단된 공간이 유리하며 옵저버와 참여자의 비율은 1:1로 테스트에 참여하는 것이 좋다. 진행자나 옵저버를 모집하는데 어려움이 있다면 참여자들의 스캐쥴을 분산하여 테스트를 진행해야 하며, 이때 테스트를 마친 참여자들과 테스트 예정인 참여자들 간에 소통을 차단하여 테스트를 완료한 참여자의 주관적인 견해가 테스트 예정인 참여자에게 주입되지 않도록 환경을 분리해야 한다. 환경 분리가 어렵다면 참여자들에게 테스트가 끝날 때까지 테스트 대상에 대한 의견을 나누지 않을 것을 사전에 당부해 두는 것이 좋다.

사용성 테스트 시 주의 사항

리허설과 환경 구성까지 마쳤다면 이제 본격적으로 사용성 테스트를 시작해 보자. 코디네이터와 함께 스캐쥴에 맞춰서 테스트를 진행하는데 이때 몇 가지 사항들을 주의해야 한다.

1) 참여자의 서비스 이해도 및 배경 파악하기

사용성 테스트 참여자의 서비스 이해도와 배경은 사용성 테스트의 결과에 결정적인 영향을 미치는 만큼 우리가 테스트하려고 하는 목적이 어떤 것이냐에 따라 참여자의 서비스 이해도와 배경지식을 고려해서 참여자를 모집해야 한다. 서비스 이해도가 높은 참여자는 기존 서비스에서 UI/UX 변화가 많을 경우 기존 버전과 비교해서 사용성을 테스트할 때 유리하고 서비스 이해도가 낮은 참여자는 우리 서비스의 UI/UX가 서비스 이해도가 낮아도 이해하기 쉬운 직관적인 UI/UX를 가졌는지 테스트할 때 유리하다.

테스트 참여자의 배경은 참여자를 모집할 때 참여자가 유사 서비스조차 이용해 본 적이 없어도 테스트를 할 수 있는 주관적인 기준이나 지식이 있는지 판단할 수 있는 척도로 사용할 수 있다. 서비스가 특정 유저들을 대상으로 개발된 경우 서비스의 이해도 보다는 배경을 보고 판단하는 것이 유리할 수도 있다.

2) 참여자의 행동에 관여하지 않고 끝까지 관찰하고 기록하기

참여자가 태스크를 수행하고 있을 때 모더레이터나 옵저버는 참여자가 하는 행위에 대해서 평가하는 언행이나 도움을 주는 행동을 하지 말아야 한다. 이러한 행동은 참여자가 태스크에 집중하지 못하게 하고 정확한 테스트를 방해한다.

3) 참여자의 질문에 대답하지 않기

참여자의 경우 태스크를 수행하면서 기능이 이해되지 않거나 찾고자 하는 오브젝트가 보이지 않을 경우 의도치 않게 질문을 내뱉는 경우가 있을 수 있다. 이때 모더레이터나 옵저버가 질문에 대답을 해주게 되면 결과적으로 미션에 달성하기 위한 힌트를 제공하는 것과 마찬가지이기 때문에 참여자의 질문에는 대답하지 않아야 한다. 단, 참여자가 질문에 대한 답변을 듣지 못했다고 기분 나빠하지 않도록 "태스크를 수행함에 있어서 질문은 금지되며 진행자들은 답변하지 않는다"는 것을 사전에 고지해야 한다.

4) 기획 의도와 디자인 배경을 설명하지 않기

테스트를 진행함에 앞서 테스트 대상에 대한 기본적인 설명과 테스트 방식에 대해서 사전에 고지를 해야 한다. 다만 이 테스트 대상에 대한 기획의도와 디자인 배경에 대해서는 설명하지 않아야 한다. 기획 의도와 디자인 배경을 듣게 될 경우 참여자들은 무의식적으로 기획 의도와 디자인 배경을 생각하면서 그에 걸맞는 행위로 태스크를 수행할 확률이 높기 때문이다. 이렇게 되면 사용성 테스트가 아니라 요구사항 검증이 된다.

5) 프로덕트에 대한 사용 의향, 선호도에 대한 의견 취합하지 않기

테스트가 끝난 직후 참여자로부터 테스트 대상에 대한 사용의향이나 선호도를 물어봐서는 안된다. 테스트 대상을 개발한 당사자들 앞에서 참여자들이 본인들의 사용 의향이나 선호도를 있는 그대로 냉철하게 평가해서 대답해 줄 리가 없다. 여기서 들을 수 있는 대답은 단순히 예의 바른 평가일 뿐이기 때문에 쓸데없이 시간낭비 하지 말자. 그럼에도 불구하고 사용 의향이나, 선호도에 대한 의견이 필요하다면 테스트가 모두 끝난 후 참여자들을 대상으로 익명 설문조사를 진행하거나 기존 유저들을 대상으로 익명 설문조사를 진행하는 것이 좋다.

테스트 결과를 받아들이자!

테스트가 끝난 후 정말 사용성에 문제가 있는 영역이나 화면, 기능이라면 참여자들로부터 공통적인 평가 의견들이 나오게 된다. "버튼이 작아서 잘 안 보여요.", "디자인 마무리가 덜 된 것 같아요.", "기능이 너무 복잡해요.", "동작 반응이 너무 느려요.", "기존 다른 서비스들과 달라서 이해하기 힘들어요.", "기능이 왜 이렇게 동작해야 하는지 이해가 안 돼요." 등등 테스트 참여자들로부터 공통적으로 부정적인 의견이 나온다면 이는 사용성에 심각한 문제가 있다고 의심해봐야 한다. 우리는 서비스를 만들 때 좋은 기능이고 유저들에게 도움이 되는 기능일 거라고 생각하며 만들었겠지만 실제로 유저들이 원하는 기능인지 VOC로 많이 접수되던 기능인지 사전에 요구사항에 대한 검증이 되지 않은 기능이라면 극단적으로 봤을 때 '없어도 되는 기능'을 만들었을 수도 있다. 테스트가 결과가 그렇다면 마음이 아프더라도 그 기능에 대한 내부 평가는 다시 생각해봐야 한다. 고슴도치가 자기 새끼를 바라보는 시선으로 우리 기능을 평가하고 있었던 게 아닌지 곰곰이 다시 생각해 보자.

모든 평가 의견은 피가 되고 살이 된다.

테스트가 끝나면 모든 테스트 결과와 평가 의견들을 분석하여 문제점이나 좋은 점들을 키워드 단위로 정리하여 카테고리화하여 전체적으로 문제가 되는 디자인이나 사용성에서 어떤 것들을 먼저 해결해야 하는지 분석할 필요가 있다. 이때 문제점들을 해결하자면서 이미 좋게 평가받은 부분들을 없애버리는 불상사가 발생하지 않도록 좋은 평가의견들도 카테고리화하여 문제점을 개선하기 위한 의견을 나눌 때 무분별한 수정을 하지 않도록 기준으로 삼아야 한다. 결과적으로 좋은 평가 의견은 우리 서비스의 장점이라고 볼 수 있고 나쁜 평가 의견은 유저가 원하는 사용성과 기능의 힌트가 된다. 이를 종합하여 우리 서비스의 장점에 개선된 UI/UX를 더하면 정말 유저들이 원했던 기능과 우리가 원했던 혁신과 편리함을 제공해 줄 수 있는 서비스로 만들 수 있게 된다.

참고자료

이 페이지는 아래의 자료들을 참고하여 작성되었습니다.

https://ubuntu.com/blog/usability-testing-how-do-we-design-effective-tasks

Usability testing: how do we design effective tasks | Ubuntu

https://en.wikipedia.org/wiki/Heuristic_evaluation

Heuristic evaluation - Wikipedia