극초기 디지털 치료제 사용성 높이기
입사 후 첫 사용성 평가 진행기
처음 입사했을 때 새로운 버전의 프로덕트가 디자인되고 있었고, 중간에 들어온 저는 프로덕트 사용 flow에 대한 한 가지 사실에 놀랐습니다. 이 프로덕트의 온보딩은 사실상 프로덕트 밖에서 이뤄진다는 점이었습니다. 우리가 약을 처방 받기 위해 내원을 해서 증상에 대해 대화한 후 치료를 위한 약의 복용법에 대해 안내 받는 것과 마찬가지로, 환자는 병원에서 디지털 치료제를 처방을 받은 이후 사용법을 의료진에게 안내받게 됩니다.
그러나, 사용법의 안내는 처방 주체의 재량에 따라 크게 달라질 수 있습니다. 어떤 환자는 충분히 사용법을 인지하고 프로덕트를 사용할 수 있습니다. 반면 그렇지 못한 환자는 잘못된 사용법을 가지고 앱을 사용합니다. 환자가 서비스에 대해 충분히 이해하지 못하면, 앱에 대한 효용을 충분히 느끼지 못해 치료 과정에서 순응도(compliance)가 떨어질 것이며, 결국 충분한 약효 또한 발휘되지 못할 것입니다. 혹은 안전하지 않은 방식으로 서비스를 사용하게 될 수도 있습니다.
결국 의료진이 적극적으로 개입하지 않더라도 사용자는 알아서 프로덕트를 적절히 사용할 수 있어야 합니다. 사용성 평가를 하기에 적절하지 않은 시점이란 없지만, 특히 시스템이 완전하게 구성되지 않은 상태에서, 새로운 개념의 디지털 치료제를 Real World에 내놓기 전에도 필연적으로 사용성 평가를 해야 하는 이유가 바로 여기에 있습니다. 사용성 평가는 단순히 기능이 제대로 동작하는지를 확인하는 차원을 넘어서, 사용자가 실제로 프로덕트를 사용할 때 어떤 경험을 하게 되는지를 깊이 이해하는 과정입니다. 다른 프로덕트와 달리 디지털 치료제는 환자들이 자신의 건강 상태를 관리하는 데 직접적으로 사용하기 때문에, 사용성 문제가 있으면 환자의 건강에 실질적인 위협이 될 수도 있습니다.
평가 계획 수립
국제표준기구 가이드라인 (ISO 9241-210)에 따르면, 사용성(Usability)이란 특정 사용 맥락에서 특정한 사용자가 특정한 목표를 효과적으로, 효율적으로, 그리고 만족스럽게 달성할 수 있는 프로덕트의 사용 가능한 정도입니다. 이 정의는 사용성 평가를 실시하기 전 특정 사용 맥락, 특정한 사용자, 그리고 특정한 목표를 설정해야 한다는 것을 의미합니다.
효과성(Effectiveness)
사용자가 주어진 작업을 성공적으로 완료할 수 있는지 여부를 측정합니다. 이때 중요한 것은 사용자에게 주어진 작업이 얼마나 성공적으로 완료되었는지를 평가하는 것입니다.
효율성(Efficiency)
작업을 완료하는 데 걸린 시간과 노력을 측정합니다. 효율성은 사용자 경험의 중요한 요소로, 사용자가 얼마나 빠르고 쉽게 작업을 수행하는지를 나타냅니다.
만족도(Satisfaction)
사용자가 제품을 사용하면서 느끼는 전반적인 만족감을 평가합니다. 이는 설문 조사나 인터뷰를 통해 주관적으로 측정할 수 있습니다.
사용 맥락 설정
디지털 프로덕트를 사용하는 여러 상황 속에서 사용자가 시스템을 이용하는 포괄적인 제반 환경이 바로 맥락입니다. 맥락은 일반적으로 물리적 맥락, 사회 문화적 맥락, 그리고 기술적 맥락으로 구성되곤 합니다.
물리적 맥락이란 실제 객관적으로 측정할 수 있는 물리적인 환경에 대한 정보입니다. 가령 만들고 있는 불면증 앱의 경우 일반적으로 밤 시간 대, 침실이라는 공간에서 접속한다는 맥락적 특성이 있습니다. 이런 경우 야간 조명 조건에서 앱 작동이 적절할지 등을 고려해야 합니다.
사회 문화적 맥락은 사회 및 문화적 특성과 관련된 주관적 가치를 이해해야 제대로 평가할 수 있는 요소를 의미합니다. 가령 수면을 건강 관리의 아주 중요한 요소로 여기고 선제적 예방 혹은 치료에 적극적으로 힘을 쓰는 문화가 있는 반면, 어떤 문화에서는 잠은 줄일 수 있는 요소라고 과소평가하거나 수면 문제를 개인의 의지 문제로 보는 문화가 있을 수도 있습니다.
마지막으로 기술적 맥락은 사용자가 디지털 기술을 이해하고 사용할 수 있는 능력인 기술 이해도, 기술에 대한 거부감 또는 호의의 정도를 의미하는 기술 수용도, 그리고 경험 제공을 위해 사용되는 기술 자체가 얼마나 완숙한지를 나타내는 기술 성숙도를 포함하는 개념입니다. 예를 들어 제가 만들고 있는 디지털 치료제에 사용되는 오디오 신호처리 기술은 사용자에게 친숙하지 않습니다. 따라서 제품을 만드는 사람들은 해당 기술을 사용해서 인터랙션 하는 방식에 대한 멘탈 모델이 형성되지 않았음을 고려하면서 제품을 설계해야 합니다.
사용성 평가 시행 전 이런 사용 맥락에 대해 자세히 설정하고 해당 맥락을 최대한 구현하는 방향으로 평가를 진행해야 합니다. 모든 조건을 만족하기는 어렵겠지만, 참가자가 사용성 평가보다는 실제 불면증을 개선하기 위해 처방을 받는 듯하게 오프라인으로 사용성 평가 세션을 구성했습니다.
사용자 설정
사용성 평가는 실제로 서비스를 사용할 타겟 사용자를 대상으로 해야 합니다. 예를 들어, 불면증 치료제를 위한 사용성 평가라면, 실제로 불면증을 겪고 있는 환자를 테스트에 참여시켜야 합니다. 환자는 비환자와 다른 특성을 가지고 있으며, 비환자 사용자군들은 불면증 환자들이 앱 사용 과정에서 겪는 문제를 실제로 겪지 않기도 하기 때문입니다.
이를 위해, 전에 했던 리서치들과는 다르게 처음으로 인센티브를 따로 두지 않고 진실된 패널을 모으기 위해 노력했습니다. 사용자에게 금전적 보상이나 기타 인센티브를 제공하면 사용자의 동기가 왜곡될 수 있기 때문입니다. 일부 사용자는 인센티브를 받기 위해 적극적으로 문제를 찾거나 비판적으로 평가하거나 혹은 우호적으로 평가합니다. 이들은 실제 상황과는 다른 피드백을 제공할 확률이 있기 때문에 프로덕트를 만드는 이들이 집중해야 할 방향에 혼선을 줄 수 있습니다.
다소 참여자 리크루팅이 힘들 수는 있어도 타겟 사용자들이 모여 있는 경로를 통해 모집하면 적합한 사용자들을 모집하는 데 큰 도움을 얻을 수 있습니다. 제가 만들고 있는 불면증 디지털 치료제의 경우, 환자 커뮤니티, 의료기관을 통해 실제 불면증 환자 모집을 시도했습니다. 이를 통해 문제를 직접적으로 경험하고 있는 사람들을 통해 실제에 가까운 인사이트를 얻고자 했습니다.
또 사전 설문이나 인터뷰를 통해 신청자가 실제로 문제를 겪고 있는지, 그렇다면 어떤 패턴으로 문제를 겪고 있는지 등을 자세하게 살펴볼 수 있습니다. 사용성 테스트 참가자 스크리닝을 위해 불면증을 판단 할 수 있는 기준을 정하고 설문 문항을 구성했습니다. 또 불면증도 다 같은 불면증이 아니라 세부적인 증상에 따라 환자군이 나뉘어집니다. 제외 기준 또한 리스트업 한 후, 이를 판별할 수 있는 문항들을 추가했습니다. 이를 통해 제품의 타겟 사용자에 적합한지 판단하여 선발했습니다.
그렇다면 얼마나 많은 참가자를 모아야 신뢰도 있는 평가가 될까요? 사용성 평가는 많은 양의 데이터보다는 실제 문제의 빠른 식별과 해결에 중점을 둡니다. 제품이 다양한 사용자 그룹에 의해 사용되거나 시스템이 복잡할 경우, 혹은 구체적이고 정교한 통계적 모델링이 필요한 경우에는 훨씬 많은 패널이 필요하겠지만, 일반적으로 사용성 테스트 진행에 있어 5명의 참가자가 가장 적당합니다.
1990년대 후반, Jakob Nielsen은 수많은 테스트를 거친 후, 사용성 문제의 대다수가 소수의 참가자에 의해 발견된다는 것을 알아냈습니다. 약 5명의 참가자가 전체 사용성 문제의 85%를 발견할 수 있다는 결과가 나왔습니다. 초기 몇 명의 참가자로도 가장 빈번하고 심각한 문제를 발견이 가능하며, 추가적인 참가자는 중복된 문제를 보고할 가능성이 높습니다. 5명이라는 소수의 참가자로 테스트를 진행하면 적은 비용으로도 유의미한 결과를 얻을 수 있기 때문에 신속하게 결과를 분석하고, 제품을 개선하며, 다시 테스트할 수 있습니다. 이러한 반복적인 과정은 제품의 점진적 향상에 크게 기여합니다.
과업 설정하기
사용성을 효과적으로 측정하기 위해서는 사용자에게 명확한 과업(Task)을 부여해야 합니다. 과업은 사용자가 시스템에서 수행해야 하는 구체적인 작업으로, 실제 사용 환경을 반영하여 구성됩니다. 여기서 유저빌리티 매트릭스는 어떤 형태로든 측정 가능해야 합니다. 사용자가 서비스를 사용하게 되는 Flow를 고려하여, 불면 증상 완화를 위해 필요한 요소들을 제대로 사용할 수 있는지를 위주로 주요 과업과 해당 과업을 달성하기 위해 필요한 세부 과업들로 구성했습니다.
대표적 매트릭스
Task success
binary 혹은 level 등으로 과업을 완료했는지를 측정
Time on task
과업을 완료하는 데 필요한 시간이 어느정도인지를 측정
Errors
과업을 수행하는 동안 사용자가 범한 실수를 포함
Efficiency
클릭 횟수 등 과업 완료에 들이는 노력의 양을 측정
Learnability
시간이 지남에 따라 사용자들의 수행 수준이 어떻게 변했는지를 측정
사용성 테스트 수행
이렇게 사용 맥락부터 과업까지 잘 설정했다면 사용성 테스트를 수행하면 됩니다. 사용자에게 과업을 제공하고, 해당 과업을 어떻게 달성하는지 관찰(Observation)을 통해 인사이트를 도출할 수 있습니다. 행동(behavior)의 실제적인 측면과 그 행동이 발생하는 맥락에 대한 객관적인 데이터 획득이 가능합니다. 특히 사용자가 제품을 사용할 때 무의식적으로 수행하는 동작, 패턴, 그리고 문제점을 확인하는 데 매우 유용합니다.
그러나 일반적인 관찰 방법론으로 사용자가 특정 행동을 보이는 의도와 이유를 이해하기 어렵습니다. 이때 Think-Aloud 방법을 사용하면 좋습니다. Think-Aloud란 사용자가 작업을 수행하면서 자신의 생각, 의도, 의문 등을 소리 내어 표현하는 방법입니다. 이 방법을 통해 사용자가 특정 작업을 수행할 때 단순 관찰에서는 확인하기 어려운 내용인 어떤 생각을 하는지, 왜 그 선택을 했는지 등의 의사결정 과정을 놓치지 않고 깊이 있게 이해할 수 있습니다. 특히 사용자가 가진 기대와 프로덕트 시스템과의 괴리를 파악하기에 아주 좋은 방법입니다.
관찰이나 Think-Aloud 방법론을 활용할 때 주의해야 할 점은 모더레이터의 개입을 최소화하는 것입니다. 사용자가 어려움을 겪더라도 도와주거나 가이드를 주지 않고, 사용자가 어떻게 문제를 해결하는지 스스로 알아보도록 하는 것이 중요합니다. 이 과정에서 시스템이 사용자의 기대에 부합하는지, 직관적으로 사용 가능한지에 대한 중요한 피드백을 얻을 수 있습니다.
특히 Think-Aloud는 사용자가 어색하거나 불편함을 느낄 수 있습니다. 참여자들이 느끼는 부담을 얼마나 완화시킬 수 있는지에서 리서처의 역량이 드러납니다. 참가자를 테스트하기 위함이 아니라, 사용하시는 과정을 보며 도움 되는 서비스를 만들기 위해 사용성 평가를 진행하는 것이니, 부담을 전혀 갖지 않아도 된다는 내용을 본격적인 과업 수행 전에 전달하면 좋습니다.
참여자별 사용성 평가 세션이 종료된 직후, 세션의 주요 내용을 팀원들에게 짧게 공유하는 디브리프(Debrief) 세션을 진행했습니다. 머릿속에 강렬히 남은 이슈는 보통 심각한 사용성 문제를 가지고 있던 부분이라 향후 심각도 파악에도 도움이 되었을 뿐 더러 기억이 휘발되기 전 리캡을 하니까 데이터 정리를 할 때에도 도움이 되었습니다. 또 기획팀 이외에 연구팀 및 개발팀 구성원들도 함께 사용성 평가에 참여했는데, 서로 다른 관점에서 문제를 파악함과 동시에 팀 전체가 해결이 필요한 문제에 대한 얼라인을 할 수 있다는 점이 참 좋았습니다.
문제 해결
사용성 평가를 완료했다면, 관찰과 Think Aloud를 통해 도출한 데이터를 정리합니다. 저희 팀의 경우 참가자 별로 발견한 현상과 이유에 대해서 기술하고, 공통된 이슈 지점으로 묶는 작업을 선행했습니다. 팀 내에서 소통할 때 현상과 해당 현상이 발생한 이유, 그리고 솔루션을 최대한 분리했는데, 문제를 정확하게 짚어내고 오해를 최소화할 수 있어서 좋았습니다.
이제 유용한 솔루션을 만들면 됩니다. 해당 현상이 발생하는 이유에 대해 면밀하게 파악한 후 이를 해결할 수 있는 솔루션을 백로그화 합니다. 늘 인력이 부족한 스타트업에서는 모든 개선 사항을 시간 내에 구현하기 어려운 법이니, 우선순위를 결정합니다. 기획팀과 개발팀은 ICE Score 프레임워크를 사용하여 이번 개발 주기에서 구현할 부분과 그렇지 않은 부분을 가려냈습니다.
ICE Score
Impact
이 부부분이 해결된다면 얼마나 임팩트가 클까?
Confidence
성공 가능성에 대해 확신이 있는 정도
Ease
필요한 리소스, 난이도
마무리
사용성 평가를 이렇게 한 번 돌린 이후에 전체 팀 구성원들이 짧게 회고를 진행했습니다. 기획팀, 연구팀, 그리고 개발팀 모두 내부적으로 생각하지 못한, 실제 사용자들의 고충을 확인할 수 있었고 이를 통해 확실하게 발전해야 할 부분들을 명확히 할 수 있어서 좋았다는 의견이 많았습니다. 사용자 지향적 프로덕트 개발의 중요성을 이해해 주시는 구성원들과 일할 수 있음에 감사하며... 첫 글을 마칩니다.
Reference
Nielsen, J., & Landauer, T. K. (1993, May). A mathematical model of the finding of usability problems. In Proceedings of the INTERACT'93 and CHI'93 conference on Human factors in computing systems (pp. 206-213).
김진우 , 연세대학교 HCL Lab. (2024). HCI 3.0: 인간과 인공지능의 상호작용(HAII)를 중심으로
톰 툴리스 , 빌 알버트. (2009). 사용자 경험 측정: 사용자 경험 개선을 위한 단계별 가이드라인
