UT(사용성 테스트)로 고객과 가까워지기

얼마 전 과거에 진행했던 사이드 프로젝트를 크게 개선할 기회가 생겼다. 그 프로젝트는 말 그대로 사이드 프로젝트였기 때문에 순수 JavaScript로 React와 비슷한 UI 라이브러리를 직접 만들어 웹사이트를 구축하는 취지로 진행했다. 당시에는 꽤 잘 만들었다는 평가도 받았지만… 현대 웹 라이브러리와 프레임워크들이 얼마나 뛰어난지를 체감할 수 있는 소중한 기회가 되었다.

 

문제는 그 사이드 프로젝트가 꽤나 사용자가 있어서 늘어나 유지보수가 필요해졌다는 점이었다. 그래서 이전처럼 순수 JavaScript 형태로는 더 이상 운영이 어렵다고 판단했고, 이번 기회에 Next.js 14로 마이그레이션 하기로 결정을 내렸다.

 

그러다 위기는 곧 기회라고, 이번에 새롭게 개편하면서 기술뿐만 아니라 사용자 경험 측면에서도 크게 개선해보기로 했다. 나 역시 그 당시 내렸던 몇 가지 설계 결정에 아쉬움이 있었고, 서비스 운영 중에 부족하다고 느낀 부분도 있었기에 이번 기회를 사용자 경험을 대폭 개선할 수 있는 기회로 삼고자 했다.

이러한 계기로 사용성 테스트를 진행하게 되었다

 

가설과 검증 사이

사용자 경험을 개선하려면 무엇을 해야 할까? 솔직히 말해서, 과거의 나는 평소에 내가 문제라고 '직감'했던 것들을 수정하고 사용자 경험이 개선했다고 말했을 것이다. 사실, 이 말이 완전히 틀린 것은 아니다. 이 서비스를 직접 만든 개발자만큼 이 서비스를 잘 아는 사람은 없을 것이고, 그 개발자가 불편하다고 직감한 부분은 문제가 있을 가능성이 높다.

 

하지만 너무 많이 아는 것이 오히려 독이 될 수 있다. 이 서비스를 처음 접하는 사용자와 개발 과정에서 수천 번을 본 개발자의 시각은 분명히 다르다. 또한, 개발자가 서비스의 문제점을 지적하는 것은 자신이 만든 것을 비판하는 것이기 때문에 인지부조화에 빠질 수 있다. 따라서 개발자의 관점은 매우 편향되어 있을 가능성이 높다.

 

따라서 비단 개발자뿐만 아니라 내부 조직 구성원들의 직감도 단순히 '가설'에 불과하다. 더 명확한 개선을 위해서는 이 가설을 검증하는 방법이 필요하다. 그리고 사실 과거에 사용자에게 서비스를 이용해 보도록 요청하고 관찰했을 때, 사용자가 내가 의도한 것과 완전히 파괴적으로 다르게 사용하는 모습을 여러 번 목격한 경험이 있다. 따라서 이번에는 단순히 '가설'을 실행하는 것이 아니라, '가설'을 테스트하고 검증한 후에 실제로 사용자가 문제라고 느끼는 부분을 개선해보고 싶었다.

 

 

왜 사용성 테스트(UT)인가?

따라서 우리 팀은 사용성 테스트(UT)를 통해 사용자가 실제로 어려움을 겪는 부분을 파악하기로 했다. 사용성 테스트는 사용자에게 과제(task)를 주고 사용자가 주어진 과제를 해결하는 모습을 관찰하여, 이후 질문을 통해 사용자의 행동 이유를 분석하는 UX 리서치 기법이다.

 

사용성 테스트를 선택한 이유는 가장 방해 요소 없이 사용자의 순수한 행동을 파악할 수 있는 기법이라고 판단했기 때문이다. 인터뷰나 설문 조사는 잘 진행되면 유용한 자료가 될 수 있지만, 질문에서 우리의 의도나 선호가 드러날 위험이 있다. 따라서 현재 우리의 자원 상황을 고려했을 때 적합하지 않았다.

 

또 다른 이유는 사용자와 더 가까이 소통할 수 있는 기법이라는 점이다. 데이터 수집이나 화면 분석 및 관찰의 경우 일방적인 소통이기 때문에 사용자의 의도를 정확히 알기 어렵다. 반면, 사용성 테스트는 방해 요소 없이 관찰을 진행한 후 인터뷰를 통해 행동의 의도를 물어볼 수 있어 고객을 더 잘 이해하고 이를 토대로 더 나은 개선 방향을 도출할 수 있다고 판단했다.

 

 

사용성 테스트 진행하기

 

1. 과제 시나리오 작성하기

사용성 테스트를 효과적으로 진행하려면 사용자에게 부여할 과제(task) 시나리오를 잘 준비하는 것이 중요하다. 시나리오를 작성할 때 필자는 “사용자의 언어”를 사용하는 데 가장 주의했다. 예를 들어, “졸업 결과 조회 페이지로 가서 남은 학점을 확인하세요”와 같은 기능적인 용어 대신, “졸업 사정 결과를 확인해 주세요. 졸업하려면 앞으로 몇 학점이 필요하나요?”와 같이 사용자가 우리 서비스를 이용하는 ‘의도’를 반영한 과제를 만들기 위해 노력했다. 시나리오 작성 방법에 대해서는 필자가 UX 전문가가 아니기 때문에, 인터넷에서 더 좋은 자료를 찾아보는 것이 좋을 듯하다.

시나리오 예시

시나리오 예시 2

UT는 물리적인 제약이 있기 때문에, 각 사용자에 대해 15~20분 정도 테스트를 진행할 계획이었다. 이에 따라, 8~10개의 테스트 시나리오를 준비했다.

 

시나리오를 준비할 때는 단순히 과제를 준비하는 것에 그치지 않고, 시작 지점, 의도한 정상적인 경로, 각 과제별 필수 질문, 특정 상황 발생 시 추가 질문, 기록할 때 주의할 점 등을 모두 고려하여 작성했다.

 

2. 사전 준비하기

UT를 원활하게 진행하기 위해서는 사전에 몇 가지 준비가 필요하다. 먼저, 사용자가 과제를 수행할 물리적인 공간이 필요하다. 우리는 학교 회의실 공간을 활용했다. 또한, UT를 진행하는 역할을 나눠야 한다. 우리는 크게 진행자와 관찰 및 기록자로 역할을 나누었다. 진행자는 과제를 테스터에게 설명하고, 테스터의 질문에 응답하거나 돌발 상황에 대응하는 역할을 맡는다. 관찰 및 기록자는 테스터의 과제 수행을 촬영하고, 관찰하면서 주목해야 할 점을 기록하는 역할을 맡았다. 물론 이러한 역할은 환경과 상황에 따라 팀마다 조정할 수 있다.

 

또한, 무엇보다 중요한 것은 사전에 테스터를 섭외하는 것이다. 우리는 우리 서비스를 사용해본 적이 없으면서도 서비스 활용도가 높은 3학년 이상의 학생들을 선정하기로 했다. 테스터의 숫자는 많을수록 좋지만, 물리적 제약으로 인해 약 5명 정도를 선정해 놨다.

 

서비스 상황에 맞춰 테스트 계정을 생성하거나 테스트 환경을 구축하는 등, 사전에 필요한 조건을 리스트업 하고 빠짐없이 준비하여 테스트 당일에 문제가 발생하지 않도록 하자!

 

3. 테스트 진행하기

어느덧 사용성 테스트를 진행하기로 한 당일이 되었고, 테스터 분들에게 정해진 시간에 정해진 장소로 오도록 하여 테스트를 진행했다.

사용성 테스트 녹화 화면

갈 곳 잃은 테스터의 손

 

 

사용성 테스트 결과

팀원들의 노력 덕분에 테스트를 무사히 마칠 수 있었다. 테스트를 진행하며 사용자가 과제를 수행하는 과정을 관찰하면서 느낀 점은, 사용자는 정말로 우리의 의도대로 움직이지 않는다는 것이다! 우리가 문제라고 생각했던 부분이 실제로 문제로 드러난 경우도 있었지만, 전혀 문제라고 생각하지 못했던 부분에서도 사용자가 어려움을 겪는다는 사실을 많이 발견했다. 이는 매우 큰 수확이었다. 정말 UT를 진행하기 잘했다는 생각이 들었다.

 

이러한 내용들을 영상으로 다시 확인하면서 정리하는 과정이 필요했는데, 감사하게도 팀원 중 한 분이 아주 잘 정리해 주셨다.

사용성 테스트(UT) 결과

사용성 테스트(UT)를 진행한 전후로 팀원 모두의 시각이 크게 변화했다. 그 이유로는, 이후 진행된 개선 회의에서 서로 주고받는 의견들이 전과는 완전히 달라졌기 때문이다. 우리는 사용자를 더욱 깊이 이해하게 되었고, 직감이 아닌 근거를 바탕으로 그들이 불편해하는 점과 이를 어떻게 개선할지를 논의하게 되었다. “이게 불편하지 않을까요?”라는 막연한 질문 대신, “여기서 어려움을 느끼고 있으니, 이렇게 바꿔봅시다!”라는 구체적인 제안으로 변하게 된 것이다. 회의는 더 열정적이고 주도적이며, 생산적인 분위기 속에서 진행되었다.

 

 

사용성 테스트 진행 후기

무슨 일이든 직접 해보기 전에는 어떤 결과가 나올지 알 수 없는 것 같다. 솔직히 UT를 하기 전에는 "이게 과연 의미가 있을까?"라는 생각도 들었다. 결국 내가 문제라고 생각했던 부분이 그대로 드러나지 않을까 싶었다. 그런데 테스트를 진행해 보니 내 예상과는 완전히 다른 결과가 나왔다. 내가 문제라고 생각한 부분도 있었지만, 예상치 못한 부분에서도 사용자가 어려움을 겪는다는 것을 알게 되었다. 실제로 테스트를 해보니 전과는 완전히 다른 시각으로 우리 서비스를 바라볼 수 있게 되었다.

 

고객에게 다가가고 이해하는 것은 말처럼 쉽지 않다. 스튜디오 안에서 개발을 계속하다 보면, 알게 모르게 고객과 점점 더 멀어지는 서비스를 만들게 된다. 이번 일을 통해 나는 정말로 사용자를 위한 서비스를 만들고 있는지 반성하게 되었다. 사용자와 가까워지고, 진정으로 사용자를 위한 제품을 만들기 위해서는 말이나 슬로건을 뛰어넘는 실천이 필요하다.

 

그런 의미에서 사용성 테스트(UT)는 경험상 전문 UX 디자이너가 없어도 적용할 수 있으며, 사용자와 가까워질 수 있는 유용한 방법이라고 생각한다. 모든 역할이 명확하게 분리된 환경이라면 모르겠지만, 항상 그런 환경에서 프로젝트를 진행할 수는 없다. UX 디자이너가 없을 때 사용자 경험(UX)이 좋은 제품을 만들어야 하는 책임은 누구에게 있을까? 나는 프론트엔드 개발자라고 생각한다. UX 디자이너가 없다고 해서 형편없는 제품을 만들 것인가? 그럴 바에는 차라리 잠을 더 자는 것이 낫다.

 

따라서 프론트엔드 개발자도 고객과 더 가까워지기 위한 방법을 알고 노력해야 하며, 특정 상황에서는 주도적으로 행동할 수 있어야 한다고 생각한다. 그래야 UX 디자이너가 있더라도 원활한 커뮤니케이션이 가능하지 않을까?