brunch

You can make anything
by writing

C.S.Lewis

by 직장인 K Mar 15. 2021

사용자 평가를 통해 프로덕트의 사용성을 높이는 방법

사용성 평가 A to Z


서비스를 만들고 기획을 하다 보면, 서비스에 대한 지식을 습득하고 많이 사용해보게 되기 때문에

더 이상 사용자의 입장에서 서비스를 볼 수 없게 되어요.


그래서 제작한 서비스의 기능이 실제 잘 작동하는지 확인하는 유일한 방법은 사용자들이 사용하는 모습을 관찰하는 것인데요, 이를 사용성 평가라고 한답니다.



사용성 평가


우선 사용성이라고 하면 어떤 것일까요?

사용성이란 프로덕트를 통해 사용자가 ‘원하는 목적을 제대로 달성(Useful)’하였는가와 그러한 목적을 ‘가능한 편리하게 수행(Usable)’하였는가 그리고 ‘전반적인 사용 만족도(Satisfiable)’는 어떠하였는가와 같은 측정 요소들을 가지는 복합적인 개념이에요.

[출처: thinkuser]


사용성 평가는 한 사람이 어떤 물건(프로덕트 or 와이어프레임 or 러프 스케치)을 가지고

진행자가 제안하는 일반적인 과제를 수행하는 과정을 지켜보는 것을 말해요. 


조금 더 쉽게 표현하자면 사용자에게 우리의 프로덕트를 써보게 하고 사용하는 과정을 지켜보는 것을 말해요.

때문에 사용자가 프로덕트를 사용하며 혼란스럽거나 답답한 느낌이 드는 지점을 찾아서 화면을 수정해 나갈 수 있어요.



사용성 평가 시작 시점은 프로젝트 초반에 가까울수록 좋고 평가 주기는 짧을수록 좋습니다.

사실 사용성 평가를 하기에 너무 이른 시점은 없어요.


기존 프로덕트의 디자인을 고칠 계획이라면 디자인 작업 시작 전에 평가해보는 것이 좋아요.

문제가 있어서 고쳐야 할 부분과 문제가 없어서 그대로 두어도 될 부분을 구분할 수 있기 때문이에요.


[사용자를 생각하게 하지 마] 책에서는 사용성 평가에 대해서 아래와 같이 강조하고 있답니다.  

훌륭한 사이트를 만들려면 반드시 평가하라

평가 참가자가 한 명뿐이어도 좋다. 그렇게라도 평가를 하는 편이 아예 하지 않는 것보다 100% 났다.

프로젝트 초기에 진행한 평가가 프로젝트 후반에 진행한 평가보다 났다. 설사 초기 평가 대상자가 1명뿐이고 후기 평가 대상자가 50명이 된다고 하더라고 말이다.



사용성 평가 계획하기


사용성 평가의 주기는 어떻게 가져가야 할까요?

한 달에 한 번 오전 시간이 좋아요. 그 이유는 3가지가 있습니다.  

단순하므로 지켜지기가 쉬워요.

그 정도면 필요한 내용을 얻을 수 있답니다. 참가자 3명을 관찰해서 얻은 결과만으로도 다음 달 사용성 평가 전까지 팀원을 바쁘게 할 만한 충분한 양의 업무가 생기게 될 것이에요.

언제 사용성 평가를 할지 결정하는 수고를 덜어주어요. '베타 버전이 완료되면 평가하자'처럼 프로젝트 단계나 결과에 따라서 평가 일정을 정하는 것보다 훨씬 좋습니다.


참가자는 몇 명, 그리고 어떤 사람을 뽑아야 할까요?

한 평가당 3명이 적절해요.

사용자 평가의 목적은 무언가를 증명하는 것이 아니에요.

무언가를 증명하려면 정량적인 평가가 필요하지만 사용자 평가는 정성적인 방법이에요.


대부분의 기업에서는 최대한 메인 유저에 가까운 참가자를 모집하는데 시간을 많이 들여요. 하지만 꼭 그럴 필요는 없답니다. 프로덕트를 사용할 만한 참가자를 대상으로 평가를 진행했을 때 얻는 장점도 분명히 있지만 생각만큼 중요하지는 않아요. 보통은 아무 참가자를 모집해도 문제가 없어요. 특히 사용성 평가를 시작한 초기라면 누구나 발견할 만한 사용성 결함이 많을 것이에요.



사용성 평가 진행하기


사용성 평가 이후에 브리핑을 통해 앱 수정 방향성을 도출하게 됩니다.

사용성 평가는 어떻게 진행해야 할까요? 1시간 정도 진행한다는 가정하에 시간 분배를 해 보았어요.


1. 인사 (2분)


2. 배경 질문 (5분)

참가자에게 프로덕트 관련해서 몇 가지 질문을 던져 보는 것이에요.

참가자의 긴장을 풀어주는 동시에 그들의 서비스나 앱 관련 지식수준이 어느 정도인지 가늠하는데 도움이 될 것이에요.


3. 프로덕트 둘러보기 (3분)

프로덕트에서 무엇을 할 수 있을 거라 생각하는지 참가자에게 물어보아요.

현재 우리의 프로덕트가 사용자가 이해하기 쉬운지, 그리고 해당 분야에 대한 참가자의 지식수준은 어느 정도인지 알 수 있어요.


4. 과제 (45분)

진행자가 제시한 일련의 과제를 참가자가 수행하는 모습을 관찰해보는 것이고 이는 사용성 평가의 핵심 부분이에요.


과제를 제시할 때에는 세부사항 일부를 참가자 스스로 선택하게 했을 때 흥미로운 결과가 많이 도출되는 경향이 있어요.

'2만 원 미만의 요리책을 찾아보세요'라는 과제보다

'구매하고 싶은 책이나 최근에 구매한 책을 찾으세요'라고 하는 과제가 더 좋습니다.

이렇게 하면 참가자가 앱을 사용함에 있어서 더 집중하게 되고 개인적인 지식도 더 많이 활용하게 되기 때문이에요. 시간이 오래 걸리는 과제라면 하나로만 구성해도 무방해요.


참가자가 본인의 생각을 말하지 않고 있을 때는 그들이 소리 내어 말하도록 "지금 어디를 보고 계시나요?", "지금은 무엇을 하시나요?"와 같이 유도하는 질문을 해야 합니다. 참가자가 도움을 요청한다면 "제가 없었다면 어떻게 하셨을 것 같은가요?"와 같은 질문으로, 어떠한 행동으로 이어지는지 파악을 한 후 답을 제시해야 합니다.


5. 심층질문 (5분)

평가 중에 일어났던 일에 대해 묻고 싶었던 질문을 하는 시간이에요.


6. 마무리



사용성 평가 그 후, 브리핑 진행하기


사용성 평가 후 브리핑을 통해 프로덕트에서 수정할 내용을 정해요.


공동 목록을 만들어보세요.

진행자를 포함한 팀원이 관찰한 문제 중 가장 심각한 것 세 가지를 적어보아요. 이때 반드시 목격한 문제만 적어야 합니다.

그 후 팀원들이 작성한 리스트 중 가장 심각한 문제 10개를 고르고 각각의 순위를 매겨 목록을 정돈해보아요.

그리고 그 문제를 어떻게 해결할지 함께 논의를 하세요.


해결방법을 논의할 때 2가지를 주의해야 해요.


첫 번째, 새로운 문제를 더하려는 충동을 자제하세요.

사용성 평가에서 참가자가 이해하지 못하는 내용이 있다는 사실을 알게 되면 설명이나 안내처럼 무언가를 일단 더하려고 하는 경향이 있어요. 하지만 무언가를 더해서 주의를 흩뜨리는 것보다 의미를 흐리고 있는 무언가를 뺐을 때 문제가 해결되는 경우가 많답니다.


두 번째, 참가가 잠시 길을 잃었는 것은 무시하세요.

사용성 평가를 진행하다 보면 참가자가 일시적으로 길을 잃었다가 아무 도움 없이 곧바로 정상 궤도로 돌아오는 때가 가끔 있어요. 이때 정상 상태로 빠르게 돌아올 수 있기만 하다면 참가자는 이런 과정을 즐거운 경험의 일부로 여겨요.

문제를 경험한 모든 사람이 뭔가 잘못되었다는 사실을 빠르게 깨닫는다.

아무 도움 없이도 바로 이전 화면으로 돌아온다.

당황하는 기색이 없다.

보통 참가자가 이러한 모습을 보였다면 넘어가도 괜찮은 문제예요.




사용성 평가를 통해 만든 프로덕트 기능의 작동 여부나 개선 방법을 알 수는 있지만

사용자들이 무엇을 원하는지 파악하지는 못합니다. 프로덕트에 대한 의견, 경험, 느낌, 새로운 콘셉트에 대한 반응을 보기 위해서는 포커스 그룹 테스트를 진행해야 해요.


포커스 그룹 테스트


포커스 그룹 테스트는 5~10명의 인원이 함께 둘러앉아 프로덕트에 대한 대화를 나누게 하는 것을 의미해요.

이때 프로덕트와 프로덕트와 관련된 자신의 과거 경험이나 새로운 콘셉트에 대한 의견을 말하게 합니다.


포커스 그룹 테스트는 주로 아래와 같은 상황에서 사용되어요.  

프로덕트에 대한 사용자의 감정이나 의견 표본을 빠르게 추출해야 할 때

사용자가 원하는 것, 필요로 하는 것, 좋아하는 것이 무엇인지 추상적으로 알아내고자 할 때

프로덕트의 근간을 이루는 아이디어가 타당한지 확인할 때

프로덕트가 제공하는 가치에 매력이 있는지 확인할 때

기업이 프로덕트를 통해 해결하려고 하는 문제를 사람들이 현재 어떻게 해결하고 있는지 확인할 때

우리 프로덕트와 경쟁사를 사람들이 어떻게 생각하는지 알고자 할 때

때문에 디자인이나 제작 이전에, 프로젝트 기획 단계에서 수행하는 것이 좋답니다.



우리 회사에 어떻게 적용을 할까?


20년의 프로덕트 팀의 목표는 내부적으로 문제점 파악 & 가설 기반으로 모든 탭을 수정하는 것이었고

21년의 프로덕트 팀의 목표는 가설 검증 & 사용성 평가를 통해 프로덕트의 완성도를 높이는 것이에요. 


때문에 20년도에는 기획 > 와이어프레임 > 디자인 > 개발로 진행되었다면

21년도에는 사용성 평가 & CS 파악 > 기획 > 와이어프레임 > 디자인 > 개발로 진행할 예정이에요.


3월에 챌린지 신청률, 리텐션과 관련된 탐색 탭 & 상세페이지 업데이트를 해야 하는데요,

사용성 평가를 통해 탐색 탭과 상세페이지의 문제점을 도출하고

나머지 기능에서 보인 문제점들은 따로 백로그에 저장을 한 뒤 디자인 타임라인에 맞게 적용할 계획입니다.


사용성 평가 시 참가자에게 주는 과제는 앱의 메인 행동인 챌린지 신청과 챌린지 인증, 달성, 환급으로 구성될 것이고, 아직 사용자에 대한 지식이 없는 단계인 만큼 참가자들은 참가한 이력이 없는 사람, 초기 유저, 진성유저로 골고루 진행할 계획이에요.




출처: 사용자를 생각하게 하지마

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari