brunch

라이킷 21 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 우잉 Jul 03. 2023

Chapter.3 사용성 테스트, 어서 오고

프로덕트 디자이너가 요약한 <사용자를 생각하게 하지마!> 마지막 장

3장으로 바로 오셨다면 1장, 2장 내용을 먼저 읽어보시는 것을 추천드려요!
사용성의 정의와 개념, 이를 위해 필요한 요소들을 배울 수 있을 거예요 :)

▷ Chapter.1 <사용성, 누구냐 너!> : https://brunch.co.kr/@shc9500/20

▷ Chapter.2 <여긴 어디? 나는 누구?> : https://brunch.co.kr/@shc9500/21

▶︎ Chapter.3 <사용성 테스트, 어서 오고> : https://brunch.co.kr/@shc9500/22

앞선 두 번째 챕터에서 우리는 사용자를 목적지로 잘 안내할 수 있는 방법에 대해 배웠습니다. 다음으로 세 번째 챕터에서는 비효율적인 사용성 토론에서 벗어나 사용성 테스트를 하는 방법에 대해 배울 차례입니다. 더 나은 제품을 만들기 위해 꼭 필요한 사용성 테스트는 어떻게 하는 게 좋을까요? 계속해서 즐겨주세요! :)

- 목차 -

1. 사용성 테스트와 포커스 그룹 테스트의 차이

2. 누구나 따라 할 수 있는 DIY 사용성 테스트 가이드

3. 사용성 테스트 허가를 받아내는 방법

4. 디테일한 사용성 챙기기

5. 사용성 그리고 접근성

1. 사용성 테스트와 포커스 그룹 테스트의 차이

본격적으로 사용성 테스트를 설명하기 전 IT 종사자들이 사용성 테스트와 포커스 그룹 테스트를 헷갈려한다는 점을 짚고 넘어가고자 합니다. 사용성 테스트는 한 명의 참가자가 수행하는 과제를 지켜보는 방식으로 과제 수행 과정에서 참가자가 혼란스럽거나 답답함을 느낀 지점을 찾아 개선하는 게 평가의 주된 목표입니다. 반면 포커스 그룹 테스트는 5~10명 정도의 참가자가 특정 서비스에 대한 개인의 경험, 새로운 의견 등을 자유롭게 말하는 방식으로 참가자의 감정이나 의견 표본을 추출하는 게 평가의 주된 목표입니다.

두 평가 방식은 무엇이 다를까요? 두 평가의 본질적인 차이점은 사용자가 실제 서비스를 사용하는 모습을 지켜보는 것에 있습니다. 포커스 그룹 테스트는 서비스의 개선 방향을 알려주지 못하며 테스트의 인사이트는 화면 설계 이전에 인지하고 있어야 하는 내용이 대부분입니다. 따라서 기획 단계에서 수행해야 가장 유용한 결과를 얻을 수 있습니다. 반면 사용성 테스트는 서비스의 설계 및 개발 프로세스 전반에 걸쳐 유용하게 사용할 수 있습니다. 따라서 사용성 테스트가 서비스를 만드는 과정에 있어서 포커스 그룹 테스트보다 효과적입니다. 조금 더 구체적으로 사용성 테스트가 필요한 이유는 다음과 같습니다.

1) 서비스 제작에 참여한 사람은 객관적인 시각을 갖기 어렵다

서비스 제작에 참여한 사람은 주관적인 시각을 가지고 있기 때문에 실제 기획한 내용이 잘 작동하는지 확인하기 위해서는 일반인을 대상으로 관찰하는 게 좋습니다.

2) 평가는 어떠한 내용이라도 도움이 된다

모수가 적더라도(심지어 평가자가 1명이라도) 사용성 테스트를 하는 게 하지 않은 것보다 백번 낫습니다. 서비스의 부족한 점을 아는 것과 모르는 것은 개선 퀄리티에 큰 차이점을 가져옵니다.

3) 프로젝트 초반에 실수를 바로잡을 수 있다

프로젝트 초반에 진행한 평가가 후반에 진행한 평가보다 수정이 용이합니다. 초반에 바로잡은 실수 하나가 이후에 발생할 수 있는 크리티컬한 문제 여러 개를 방지할 수 있습니다.

그러나 대부분의 회사는 사용성 테스트를 진행하기 위한 인력이 부족하거나, 평가를 위한 공간이 없는 등 여러 한계가 존재합니다. 이 모든 한계를 극복할 수 있는 방법으로 Do It Yourself 사용성 테스트가 있습니다.(줄여서 DIY 사용성 테스트라고 합니다) DIY 사용성 테스트는 어떠한 규모의 조직도 시행할 수 있는 평가 방법으로 최소한의 비용으로 최대한의 효과를 불러일으킬 수 있습니다. 그렇다면 DIY 사용성 테스트는 어떻게 하는 걸까요?

2. 누구나 따라 할 수 있는 DIY 사용성 테스트 가이드

DIY 사용성 테스트를 진행하는 방법은 다음과 같습니다.

1) 전체 프로세스

한 달에 한 번 오전에 시간을 내어 평가를 진행하고 결과를 브리핑 한 뒤 개선할 부분을 결정합니다.

2) 테스트 목적

서비스의 가장 시급한 문제를 파악하고 다음 평가가 진행되기 전에 개선할 수 있도록 담당자를 배정합니다.

3) 테스트 시기

서비스 구축 및 개발 프로세스 전반에 걸쳐 꾸준히 진행합니다.

4) 테스트 횟수

한 달에 한 번 오전 시간에 진행합니다.

Q. 왜 한 달에 한 번 정해진 시간에 진행해야 하나요?
A. 다수의 팀원이 약속한 시간을 지키려면 단순한 시간이 좋기 때문입니다. 일정을 고정해 놓으면 매번 평가 날짜를 고르는 수고를 하지 않아도 되며 고정된 일정이기에 이해관계자들의 참석률이 높아집니다. 또한 반나절의 테스트만으로 충분한 양의 업무가 생기기에 일정을 길게 잡을 필요가 없습니다.

5) 테스트 참가자 수

적정 참가자 수는 3명입니다.

Q. 왜 적정 참가자 수가 3명인가요?
A. DIY 사용성 테스트는 가설을 검증하는 방식이 아니기 때문에 정성적인 결과물을 활용합니다. 따라서 서비스 사용성의 핵심 문제를 찾는 것이 더욱 중요합니다. 이는 3명 정도의 참가자로부터 충분히 발견할 수 있습니다.

6) 참가자 선택 방법

타겟 사용자(실제 서비스 사용자) 보다 일반 사용자를 대상으로 자주 평가하도록 합니다.

Q. 왜 타겟 사용자(실제 서비스 사용자)가 아니어도 괜찮은 건가요?
A. 서비스는 범용성을 가져야 합니다. 전문가만 사용할 수 있는 서비스라 해도 전문가가 될 수 있는 일반인도 사용할 수 있어야 합니다. 타켓 사용자로 테스트를 진행한다 해도 콘텐츠에 대한 이해도만 높을 뿐 사용하는 방식은 일반 사용자와 비슷합니다. 또한 타겟 사용자는 서비스를 일반인이 사용하기 쉬운 수준으로 만들었다 해서 모욕감을 느끼지 않습니다.

7) 테스트 장소

빈 사무실 두 개면 충분합니다. 한 개의 사무실에서는 화면 공유 소프트웨어를 사용해 평가를 진행하고, 다른 사무실에서 공유되는 평가를 관찰하도록 합니다.

8) 테스트를 관찰하는 사람

최대한 많은 수의 이해관계자가 관찰하도록 합니다.

9) 테스트 구성(1시간 기준)

인사 및 평가 과정 설명(5분) : 참가자와 인사를 나눈 뒤 전반적인 테스트 과정을 설명합니다.

서비스 배경 지식 질문(5분) : 참가자에게 서비스와 관련된 아이스 브레이킹 질문을 합니다.

서비스 둘러보기(5분) : 참가자에게 서비스에서 무엇을 할 수 있을 것 같은지 질문을 합니다.

평가 과제(35분) : 참가자에게 일련의 과제를 부여하고 수행하는 내용을 소리 내어 말하게 합니다. 만약 말하고 있지 않다면 그들의 생각을 소리 내어 말하도록 유도합니다. 이때 유도신문이나 힌트를 주어선 안됩니다.(만약 도움을 요청한다면 “제가 없었다면 어떻게 하셨을 것 같나요?”로 대답합니다)

심층 질문(5분) : 참가자에게 테스트와 관련해 궁금한 점을 물어보게 합니다.

마무리 인사(5분) : 참가자에게 감사 인사와 함께 수고비를 전달하고 나가는 문을 안내합니다.

10) 결과 보고

테스트를 관찰한 사람들끼리 브리핑을 진행합니다. 그다음 브리핑에서 결정한 사항을 A4 1~2페이지로 요약합니다. 이때 가장 중요한 문제를 고치는데 집중하도록 합니다.

Q. 가장 중요한 문제를 어떻게 구별하나요?
A.
- 관찰자들에게 본인이 관찰한 문제 중 가장 심각하다고 생각한 문제 3개를 기록하도록 합니다.
- 관찰자들이 기록한 모든 문제를 줄 세운 다음 투표를 통해 총 10개의 문제를 선택합니다.
- 10개 문제의 우선순위를 세운 다음 적절한 담당자를 배치하고 필요한 자원을 파악합니다.

11) 주의할 점

새로운 문제를 만들어내는 행위는 자제하도록 합니다. 테스트에서 나온 문제를 해결하는데 최대한 집중하도록 합니다.

쉽게 고칠 수 있는 문제는 별도의 목록으로 제작합니다. 이는 윗선의 허가를 받지 않고 담당자가 한 시간 이내 해결할 수 있는 문제여야 합니다.

참가자의 기능 추가 피드백은 가려듣도록 합니다. 정말 훌륭한 아이디어가 아니라면 기능을 추가해도 대부분 사용하지 않을 가능성이 높습니다.

참가자가 일시적으로 헷갈린 문제에 대해 과도한 집착은 지양하도록 합니다. 보다 거시적인 관점에서 사용성의 핵심 문제를 찾는데 집중하도록 합니다.

참가자에게 기능의 호감도를 확인하는 질문은 지양하도록 합니다. 듣기 불편하더라도 있는 그대로의 평가를 들을 수 있도록 합니다.

3. 사용성 테스트 허가를 받아내는 방법

이러한 사용성 테스트의 가장 큰 효용은 테스트를 관찰한 모든 이들이 기존에 사용자를 대하던 관점이 변한다는 점에 있습니다. 진행하는 혹은 진행된 사용성 테스트가 본인이 예상한 바와 매우 다르기 때문에 나와 사용자가 다른 존재라는 사실을 명확히 인식하기 때문입니다. 그러나 사용성 테스트를 하고 싶지만 다양한 이유(정치적 이슈 혹은 재정적 이슈)로 우선순위에서 밀려나 불가피하게 회사 혹은 팀의 지원을 받지 못하는 경우가 있습니다. 이럴 때 사용성 증진 업무를 물심양면으로 지원해 주십사 내부 구성원 및 경영진을 설득할 수 있는 방법을 소개합니다.

1) ROI(Return On Investment : 투자 대비 수익률)를 보여준다

사용성에 변화를 주어 추가된 수익이나 절감한 비용을 증명할 수 있는 데이터를 제시합니다. 예를 들어 버튼의 형태나 라벨링을 변경한 후에 수익이 0.25% 증가했다는 증거를 제시하는 방법이 있습니다.

2) 경영진이 흥미를 가질만한 이야기를 한다

사용성 증진 업무가 사용자에게 유용한 것 이상으로 회사가 앓고 있는 문제에 기여한다는 증거를 제시합니다. 예를 들어 사용자의 페인 포인트를 개선함으로써 CSI(Customer Satisfaction Index : 고객만족도) 지표가 상향하고, 이는 CX팀의 KPI(Key Performance Indicators : 핵심성과지표)에 매우 밀접한 영향을 줄 수 있음을 설득합니다.

위 두 가지 방법은 철저한 검증이 필요합니다. 만약 제대로 검증된 수치가 아니라면 해당 데이터는 다른 누군가로부터 반박될 가능성이 높습니다. 이런 상황에 닥친다면 효과적인 설득이 어렵습니다. 만약 데이터나 구체적인 수치를 제시하지 못하는 상황이라면 마지막 방법을 사용하도록 합니다.

3) 이해 관계자, 내부 구성원, 경영진이 사용성 테스트를 직접 보도록 한다

업무 관계자 혹은 고위 관리자가 단 1분만이라도 사용성 테스트를 직접 관찰하게 합니다. 특히나 경영진 같은 높은 책임자에게 사용성 테스트를 진행할 예정이니 팀의 사기를 위해 잠시 얼굴을 비쳐달라고 부탁합니다. 이들은 일반 사용자가 본인의 서비스를 어떻게 사용하는지 지켜본 적이 거의 없기에 예정된 시간보다 오래 머무르며 평가에 몰입할 가능성이 높습니다. 여기서 가장 중요한 점은 직접 보게 하는 것입니다.

9시 뉴스에서 스포츠 경기의 하이라이트를 보는 것은 기억에 오래 남지 않지만, 해당 경기를 실시간으로 직접 관람한 것은 기억에 오래 남습니다. 만약 직접 오는 게 불가능하다면 사용성 테스트를 촬영한 영상을 핵심만 간추려 3분 이내의 짧은 영상으로 제공하도록 합니다.

4. 디테일한 사용성 챙기기

서비스가 보편적인 사용성을 갖췄다면 우리는 한 걸음 더 나아가 사용자에 대한 배려심을 갖출 필요가 있습니다. "우리 서비스가 직관적으로 이해하기 쉬운가?"라는 질문뿐 아니라 "우리 서비스가 사용자를 진심으로 배려하고 있는가?"라는 질문도 해야 합니다. 배려를 갖춘 설계는 사용자의 무의식에 큰 흔적을 남겨 서비스에 재방문할 확률을 높여주기 때문입니다.

서비스의 호감을 키우는 사용성을 알아보기 전, 먼저 서비스의 호감이 줄어드는 대표적인 요인을 살펴보겠습니다.

1) 사용자가 원하는 정보 숨겨두기

예를 들어 상품 가격, 배송비, 고객센터 번호를 일부러 노출하지 않는 경우가 있습니다. 고객센터 번호의 경우 전화가 올 때마다 비용이 들기 때문에 숨겨 놓는 것이며, 상품 가격, 배송비 등의 정보는 사용자를 가능한 깊은 뎁스로 유인하기 위해 숨겨놓는 것입니다. 이는 전화 영업 방식과 유사한 전략으로 시간을 더 쓴 사용자일수록 설득될 확률이 높다고 판단한 구시대적 결과물입니다.

2) 사용자를 귀찮게 하기

예를 들어 신용카드 번호, 핸드폰 번호, 주민등록 번호 입력 시 공백이나 하이픈을 직접 입력해야 하는 경우가 있습니다. 개발자가 코드 몇 줄 쓰는 게 귀찮아 수천, 수만 명의 사용자가 번거로운 작업을 떠맡은 상황인 것입니다. 디자이너와 개발자는 사용자의 귀찮은 일을 대신해 주는 사람임을 잊어서는 안 됩니다.

3) 필요하지 않은 개인 정보 물어보기

예를 들어 서비스에서 활용되지 않음에도 불구하고 성별, 직업 정보를 강제로 입력해야 하는 경우가 있습니다. 보통 단순한 데이터 수집 목적으로 이와 같은 정보를 받습니다. 만약 서비스를 이용하는 데 있어 꼭 필요하지 않은 정보라면 사용자가 의아함을 느끼지 않도록 정보 수집 목적의 당위성을 설득할 필요가 있습니다.

4) 가식적인 표현 사용하기

예를 들어 명백한 사용성 문제가 있지만 이를 UX 라이팅으로 해결하려는 경우가 있습니다. 사용자는 서비스가 진정성이 있는지 없는지 매우 쉽게 알아챈다는 점을 명심해야 합니다.

물론 예외도 있습니다. 팝업창을 띄우는 게 대표적인 예로 팝업창은 사용자에게 항상 번거로운 존재입니다. 하지만 통계적으로 팝업창을 띄웠을 때 수익이 10% 증가한다면 비즈니스 관점에서 사용자를 귀찮게 하더라도 사용할 수 있습니다. 다만, 득과 실을 꼼꼼히 따져보고 최대한 적합한 방식으로 사용자에게 제공해야 함을 잊어서는 안 됩니다.

이제 앞선 예시와 반대로 서비스의 호감을 키우는 대표적인 요인을 살펴보겠습니다.

1) 사용자가 원하는 정보 보여주기

예를 들어 주차 비용, 환불 비용, 이용 가능 시간 등 숨기고 싶은 정보를 가장 앞에 노출하도록 합니다. 이 같은 설계로 무의미한 뎁스 이동을 줄여 사용자가 편리함을 느끼도록 합니다.

2) 사용자의 수고 덜어주기

예를 들어 구매한 상품의 택배 송장 번호를 클릭 or 탭 했을 경우 택배사 사이트에서 배송 상황이 바로 조회될 수 있도록 합니다. 이처럼 사용자의 입력 비용을 줄일 수 있는 설계가 있다면 적극적으로 도입하도록 합니다.

3) 사용자가 궁금해하는 내용 제공하기

예를 들어 FAQ 목록이나 기술 지원 목록이 있습니다. 이러한 정보는 항상 최신 상태를 유지해 CS 리소스와 불필요한 커뮤니케이션 코스트를 줄이도록 합니다.

4) 오류나 문제가 발생했을 경우 쉽게 회복되도록 하기

예를 들어 결제 오류 상황에서 알 수 없는 에러코드를 노출하는 것보다 명확한 상황 설명이 담긴 팝업과 함께 선택지를 제공하도록 합니다. 오류나 문제를 애초에 방지하는 게 가장 좋지만 예기치 못한 상황은 언제나 발생할 수 있습니다. 따라서 진실성 있는 대응과 함께 원래 상태로 쉽게 돌아올 수 있는 방법을 제공하도록 합니다.

5. 사용성 그리고 접근성

디테일한 사용성을 챙기는 배려는 장애인에게도 동일하게 적용돼야 합니다. 만약 당신의 서비스가 장애인은 우리 서비스의 대상이 아님을 전면 선언할게 아니라면 접근성을 함께 고려하도록 합니다. 특히나 탐색 경험에 있어 가장 취약한 위치인 시각 장애인을 고려한 설계가 중요합니다. 이들을 고려한 설계는 다음과 같습니다.

1) 모든 페이지에 적절한 대체 텍스트(Alt Text)를 추가한다

시각 장애인은 비장애인과 마찬가지로 원하는 정보를 쉽고 빠르게 찾고 싶어 합니다. 비장애인들이 콘텐츠를 읽지 않고 훑어보는 것처럼 시각 장애인들도 링크 맨 앞부분의 단어 몇 개만 듣고 본인이 찾는 정보와 관련이 없다면 곧장 다음 링크로 넘어갑니다. 따라서 이들을 위해 링크 맨 앞이나 텍스트 첫 줄에 핵심 키워드를 대체 텍스트로 추가하도록 합니다.(이미지에는 도움이 될 만한 설명을 꼭 넣도록 합니다)

2) 키보드로 모든 콘텐츠에 접근이 가능하도록 한다

시각 장애인은 서비스의 주 탐색 도구가 마우스나 손가락이 아닌 키보드입니다. 따라서 스크린 리더를 사용하는 시각 장애인들을 위해 콘텐츠를 쉽게 탐색할 수 있도록 올바른 HTML 헤딩 구조를 사용하도록 합니다. 예를 들어 메인 콘텐츠에는 <h1>을, 주요 섹션에는 <h2>를, 부제목에는 <h3>를 사용해 각 단계를 논리적으로 조직할 수 있도록 합니다.(텍스트 필드에는 무엇을 입력하면 되는지 알 수 있도록 헬퍼 텍스트를 꼭 연결하도록 합니다)

3) 각 페이지를 시작할 때 '메인 콘텐츠로 넘어가는 링크'를 삽입한다

스크린 리더를 사용하는 시각 장애인들은 평균 10초에서 20초를 내비게이션 텍스트를 듣는 데 사용해야 합니다. 이는 콘텐츠를 탐색하는 시간이 비약적으로 늘어나는 요소이기에 메인 콘텐츠로 바로 넘어갈 수 있는 링크를 제공하도록 합니다.

[맺음말] 요약을 마무리하며...

우선, 긴 글을 끝까지 읽어주신 여러분께 진심으로 감사의 말씀 전합니다. 각 챕터의 내용은 어떠셨나요? 사용성에 대해 명확히 알아가는 계기가 되셨나요? 저 또한 <사용자를 생각하게 하지마!> 책을 읽으며 평소 구체적으로 생각해 본 적이 없었던 사용성에 대해 깊이 생각해 보는 계기가 되었습니다. 더불어 프로덕트 디자이너로서 기본적인 사용성을 놓치고 있지 않은지 제가 설계한 화면들을 돌아볼 수 있었습니다.

개인적으로 책을 요약하며 느낀 아쉬운 점은 책이 오래되었다는 점도 있었지만 책의 모든 내용이 저자의 경험에 기반하여 작성되었다는 점입니다. 저자의 10년 이상 경력에서 오는 인사이트와 통찰을 무시하는 게 아닙니다. 다만, 구체적인 연구나 수치화된 데이터 없이 오로지 인용과 경험에 기반하여 주장 및 설득하고 있는 점에서 근거의 힘이 부족하다는 생각이 들었습니다. 그럼에도 불구하고 다양한 예시와 구체적인 상황 묘사는 서비스를 만드는 한 사람으로서 큰 공감을 불러일으켰고 책의 내용에 깊게 몰입할 수 있었습니다.

여러분은 좋은 사용성을 갖춘 서비스가 어떤 서비스라고 생각하시나요? 저는 어려운 기술을 일반인들이 쉽게 사용할 수 있도록 만든 서비스가 좋은 사용성을 갖춘 서비스라고 생각합니다. 대표적으로 오픈 AI 사의 Chat GPT 서비스를 예로 들 수 있을 것 같습니다. 1950년대부터 존재한 자연어 처리 기술(NLP)을 구글, MS, 아마존과 같은 글로벌 기업들이 2000년대 들어 본격적으로 발전시켜 왔지만 사용자들에게 익숙한 채팅 UX를 기반으로 '대중화'를 이륙한 건 오픈 AI 사의 Chat GPT이기 때문입니다. 성별, 나이, 인종에 관계없이 고도의 기술을 쉽게 사용할 수 있도록 만들었기 때문에 저는 좋은 사용성을 갖춘 서비스라고 생각합니다. 여러분이 생각하는 좋은 사용성을 갖춘 서비스는 어떤 서비스인가요? 이제부터는 사용성에 관한 여러분의 생각을 담은 답변이 충분히 가능하시리라 믿습니다.

사용성에 관해 깊은 배움이 되셨길 바라며 이만 글을 줄이도록 하겠습니다. 저는 다음 글로 찾아뵙도록 할게요! 그럼 좋은 하루 보내세요 :)