고객 데이터로 UX 가설 세우는 방법

 

 

UX 리서치, 수많은 방법론이 있다. 

휴리스틱, SUS, 사용성 테스트 등등... 이 방법들은 모두 '프로토타입'을 직접 사용하게 하고 사용성을 평가하는 행위이다. 

아무리 쉽고 간편한 제품을 만들어도 그 제품을 통해 사용자의 문제가 해결되지 않는다면 만들 가치가 없는 것이다. 그래서 우리는 일할 때 항상 '어디'를 '얼만큼' 개선하면 고객 경험의 지표가 'N%'만큼 나아진다는 가설을 수립하고 실행한다. 

이런 가설에서 가장 중요한 것은 가설을 뒷받침하는 근거이다. 하지만 대체 근거를 어디서 찾는지 디자이너 입장에선 막막할 때가 많다.

 

이미 운영 중인 제품의 개선을 효과적으로 하고 싶을 때, 데이터리서치 팀이 없어 막막할 때,

디자이너가 손쉽게 근거를 찾고 UX 가설을 만드는 방법을 소개한다.

 

 

 

고객이 어떤 환경에서 제품을 쓰는지 고려하라.

UX 디자이너는 고객중심으로 생각해야 한다며, 고객의 환경과 매우 동떨어져있고 그 환경을 고려하지 않을 때가 많다. 극단적인 예로 스리마일섬 원전 사고를 들 수 있다. 1100개의 다이얼과 600개의 스위치는 매우 조용한 사무실에서 봐도 복잡하여 헷갈리기 마련인데, 이 복잡한 인터페이스의 사용자는 불행하게도 원자력발전소 업무만으로도 과부화 상태였을 것이다. 

 

이 책의 1부는 잘못된 UX 설계 사례들을 알려준다

 

좋은 사례로는 Simple을 꼽고 싶다. 고혈압 환자의 병록 작성/기록하는 이 간단한 앱은 오프라인 환경에서도 사용이 가능하여 의료진이 산간벽지나 외부 데이터 수신이 제한된 병원 내 환경에서도 원활히 환자의 데이터를 기록할 수 있다. (데이터는 기기에 저장되었다가 네트워크가 연결되면 그때 동기화된다) 앱의 오프라인 작성 기능이 어떤 상황에서 문제를 해결하는지 깨달음을 얻었던 멋진 제품이다. 고작 20mb의 용량으로 성능이 낮은 기기에서도 자유롭게 사용할 수 있게 만든 점도 마음에 든다. 진짜 UX를 고려하는 디자이너라면 심미성을 넘어 최선의 사용성을 고려해야 한다는 것을 되새기게 되었다. 

 

그렇다면 우리 고객은 어떤 환경에서 쓸까? 환경은 어디까지지?

이 질문에는 다음 방법론이 도움을 줄 수 있다.

 

 

환경을 세분화하여 나눠 측정하라.

 

나는 아래와 같이 3가지로 측정 했다.

1. 어디서 쓰는가? (사용 위치)
2. 뭘로 쓰는가? (기기, OS)
3. 언제 쓰는가? (사용 일시)

 

 

1. 유저는 어디서 쓰는지 파악하고, 환경의 문제가 있는지 염두하라.

• 퍼소나, 유저 저니 등으로 설정해도 된다.
• 고객을 인터뷰하거나, 더 좋은 방법은 직접 방문하여 고객이 사용하는 환경을 확인하는 것이다.

웹 서비스를 운영하다 보면 엔드유저단에서만 발생하는 각종 버그들이 많다. '우리가 하면 멀쩡한데... 어디가 문제지?' 고객께 화면 공유도 요청해보고 코드를 뜯어봐도 원인불명인 버그들. 대부분 유저의 환경(네트워크 등)이 원인인 경우가 많았다.

 

나 역시 자주는 아니지만 분기에 한번은 이렇게 오류를 겪는 고객의 상황을 파악하고 문제 해결을 위해 방문 출장을 가기도 한다(개발자와 같이 ㅎㅎ) 처음에는 거의 하루를 통째로 소비하여 방문 출장을 가는 것이 리소스 낭비가 아닌가? 싶기도 했는데, 우리 서비스는 LTV가 매우 높은 서비스라 각 고객에게 많은 투자가 필요하기도 하고, 실제로 방문하였을 때 병원의 제한된 네트워크나 열악한 기기 사양 등을 보며 진짜 문제의 원인을 발견할 수 있어 도움이 되는 과정이다. 그리고 좋지 않은 경험으로 기분이 상한 고객에게는 직접 찾아뵙고 여쭤보고 문제 해결을 위해 노력함을 어필하는, 일종의 휴먼터치의 효과가 톡톡히 작용한다 생각한다 :) 

 

 

2. 유저의 접속 기기와 브라우저의 기술적 사양을 반영한다.

Hotjar에는 녹화 시 환경 정보를 함께 저장해주는데 그 정보들의 통계 확인은 물론, 원하는 정보값만 필터링하여 확인하는 것도 가능하다.

아래는 고객들이 어떤 기기와 어떤 브라우저를 사용하는지 확인한 값이다. 

 

확인한 고객 데이터: 기기별 비율, 브라우저별 비율, webp 미지원 브라우저의 사용자가 있는지 탐색

데이터에서 뽑아낸 근거: 데스크톱 사용자가 대부분이다. gif -> webp 변경 시 일부 고객은 루프 애니메이션을 보지 못한다.

UX 가설: 우리의 주요 고객들은 낮은 사양의 환경에서 접속하므로, 최신 기술이 지원되는지 유의하여 사용한다.

 

내가 만들고 테스트하는 기기는 모두 높은 사양과 최신 os로 구성되어 있다. 따라서 내 환경에서는 발생하지 않는 문제가 고객의 환경에서는 발생할 수 있다. 고객과 나의 환경의 기준을 일치시키기가 어렵다면, 위와 같이 고객 환경을 먼저 찾아보고 그 가설을 바탕으로 디자인을 하는 것이 좋다. 

 

 

3. 유저의 화면 크기를 고려하여 정보를 배치한다.

이것 역시 매우 중요하다. 고객은 우리 생각보다 스크롤을 정말 해보지 않는다. 괜히 1page1thing이란 격언이 있는게 아니다.

닐슨노먼 연구에 따르면 사용자는 총 시간의 57%를 스크롤 없이 볼 수 있는 구간에서 소비한다. 나 역시 Hotjar에서 고객 행동을 볼 때 가장 안타까운 상황이 화면 크기에 애매하게 잘린 컴포넌트를 사용자가 찾지 못하는 순간을 발견할 때이다. 

 

 

네이티브 앱을 만든다면 중요도의 실감이 낮을 수 있지만, 반응형 웹을 만드는 사람이라면 사용자의 사용 화면 분포를 꼭 확인해보길 바란다.

나는 1440*1080 크기로 데스크톱 화면 디자인을 했었는데, 고객의 사용 화면 분포 결과는 충격적이었다.

 

 

 

확인한 고객 데이터: 1년간 트래킹된 고객 화면비

데이터에서 뽑아낸 근거: 대다수의 사용자가 컨텐츠를 볼 수 있는 영역은 600px 안쪽이다.

UX 가설: 데스크톱 화면을 디자인할 때 주 요소 또는 그것의 위치를 안내할 수 있는 요소를 600px 안에 배치한다.

 

 

굳이 600px안에 꼭 배치하여야 하는가? 800px 정도로 해도 충분하지 않나? 하는 생각을 할 수도 있다.

커브컷 효과(Curb cut effect), 즉 접근성을 고려한 디자인은 결국 모두에게 도움이 되는 디자인이 된다. 상단 600px 안에 배치한 주 요소는 화면이 더 넓은 사람에게도 쉽게 인지하고 접근성을 향상할 수 있도록 돕는다. UX 디자이너는 항상 모두를 위한 포용적인 디자인을 고민하고 실행할 의무가 필요하다 ㅎㅎ

 

 

 

3. 유저가 언제 우리 제품을 쓰는지 파악하고 목적에 맞지 않는 기능 구현을 막아라.

언제 쓰는지가 중요한 이유는 다음과 같다.

• 유저가 어떤 상황에서 제품을 쓰는지 파악하고 상황에 맞는 인터페이스를 제공할 수 있다
• 사무실에서 사용이 편리한 인터페이스와, 이동 중 사용이 편리한 인터페이스는 확연히 다르다.
• 언제 쓰는지를 알면 업데이트/점검 등의 일정을 사용자가 쓰는 시간을 피해 잡을 수 있다.

 

우리 제품 역시 개선 방향을 고민하다가 DAU를 높이는 기능(월간 리포트 제공, 매일 새로운 소식 제공 등)을 신설하자는 아이디어가 제안된 적이 있다. 하지만 나는 유전 검사 분석 제품에서 가장 우선순위가 높은 것은, 자주 들어오게 만드는 기능보단 바쁜 의료진의 문제를 더 빠르게 해결하는 기능 개발이 우선시되는 방향이라 생각했다.(그래서 오히려 주문에 걸리는 접속 시간을 더 줄이고 싶었다) 이 과정에서 팀원 설득을 위한 근거로 가져간 것이 바로 사용 빈도가 높은 시간대였다.

 

 

이 평범하기까지한 지표가 왜 중요하냐면, 우리의 주 유저층은 의료진+스탭이기 때문이다. 하루 평균 34명의 환자를 보는 의료진들이 바쁜 근무시간에 우리 서비스에 접속하여 흥미로운 정보로 시간을 때우고 싶어할까? 아니면 5분 내에 신속하게 유전자 검사를 주문하고 결과지를 빠르게 받고 싶어할까? 나는 사용자를 위한 개선은 후자라 생각한다. 위 지표를 통해 아래와 같은 결론을 내렸고, 팀원 모두에게 공유하여 제품 개발 방향에 대한 합의를 이끌어낼 수 있었다.

 

주문/결과 보는 행위를 간편히 하는 것이 사용자를 돕는 것 
주문이 아닌 기능을 신설하여 고객이 서비스에 오래 머무르길 바라는건 공급자 욕심!

 

---

 

결론

1. 유저는 어디서 쓰는지 파악하고, 환경의 문제가 있는지 염두하라.

2. 유저의 접속 기기와 브라우저의 기술적 사양을 반영한다.

3. 유저의 화면 크기를 고려하여 정보를 배치한다.

3. 유저가 언제 우리 제품을 쓰는지 파악하고 목적에 맞지 않는 기능 구현을 막아라.

 

이렇게 데이터를 기반으로 가설을 세우면 아무도 쓰지 않거나 지표가 개선되지 않는 = 소위 실패한 피쳐를 만들 확률이 매우 낮아진다.

제품의 작은 부분이라도 개선을 시도하기 위해서는 기획, 디자인, 개발 등 많은 사람의 리소스가 필요하다. 애자일하게 일하는 방법은 모두가 잘 알지만, 실패만을 번복하다보면 어떤 훌륭한 팀이라도 지치기 마련이다. 데이터는 이전의 실패를 반복하지 않도록 돕는 효과적인 도구이다. 데이터를 기반으로 튼튼한 가설을 실행하고 팀원 모두가 성취감을 얻는 개선을 하는 것, 나의 지속적인 목표 중 하나이다 ㅎㅎ