이 글은

서비스를 만든 지 얼마 되지 않았거나, 서비스를 고도화한 이후

아직 제대로 객관화하여 되돌아본 경험 없이 다소 감에 의존해

서비스를 만들어 나가고 있는 상황에서 개선방향을 더 쉽게 잡게 도와줄 수 있습니다.

우리 회사에는 프로덕트 디자이너가 있었지만, 내가 합류했을 때는

회사에서 신규 프로덕트를 구축해서 내놓은 상황이었고, 디자이너 없이 제법 많은 부분이

구축되어 있었다. 그런 상황에서 첫 번째 프로덕트 디자이너로 업무를 맡게 되었다.

당연하게도 빠르게 또 깊게는 고민하지 못한 상황에서 프로덕트가 출시되다 보니

개선해야 하는 부분들이 많았다. 하지만 나 또한 우려했던 부분이, 출시한 지 얼마 되지 않은

서비스이다 보니 쌓여있는 데이터와 경험들이 부족해서 사용자들이 이렇게 사용하겠지?라고

다소 감에 의존해서 서비스를 개선해가고 있었다.

그러던 와중에 뷰저블을 도입해서 사용하게 되었다.

무엇보다도 큰 장점은

- 별도 학습이 필요 없을 정도로 쉽고 직관적이다.

- 효율적으로 필요한 인사이트를 얻을 수 있다.

- 주변 동료를 귀찮게 할 필요가 없다. (미안해할 필요가 없다.)

또한, 서비스 분석 툴은 어렵고 왠지 어느 정도 충분히 준비과정이 세팅된 이후에 사용할 수 있고

개발자나 기획자등 서비스를 둘러싼 여러 직군들의 긴밀한 협조가 필요해서, 별도로 일정을 잡아두고

준비해야만 할 수 있는 것으로 인식되고 있는 것 같다.

하지만 뷰저블은 굉장히 심플했다. 단 한 줄의 코드만 설치하면 끝이다.

프로덕트의 뷰저블을 설치한 뒤 큰 노력 없이도 얻을 수 있었던 인사이트는 아래와 같다.

1. 히트맵을 통해 사용자의 관심/집중요소 파악

사용자들이 현재 어떤 요소에 가장 많이 집중하고 있는지 시각적으로 바로 파악이 가능하며,

순위를 통해서 보여준다. 화면을 설계할 때 생각했던 부분대로 사용자들이 사용해주고 있는지를

확인할 수 있었다. 예시와 같이 1,3번째로 사용자들이 많이 집중한 페이지네이션의 경우

처음에 상품추천영역을 설계할 때는 크게 고려하지 않은 부분이었다. 당연히 바로 보이는

상품영역이나 혜택명시 부분에 좀 더 많은 집중을 할 것이라고 생각했는데, 실제로 사용자들은

페이지네이션을 통해서 원하는 상품을 탐색하는, 즉 상품 탐색영역으로 사용하고 있음을 알 수 있었다.

물론 더 깊은 인사이트를 얻기에는 추가적인 정성적 조사나, 신뢰성을 위한 변수통제등이

필요하겠지만 아직 본격적으로 세팅이 되어있지 않은 상황에서 굉장히 빠르고 효율적으로

유의미한 인사이트를 얻을 수 있었다.

또한, 위 예시에서 볼 수 있듯 사용자들은 2번째로 혜택명시/혜택진행사항을 알려주는 프로그래스바에 집중하고 있었다. 해당 영역에 대한 사용자들의 관심을 확인할 수 있음과 동시에 많은 인터랙션 (터치, 스크롤등..)이 발생하고 있다는 걸 확인했는데, 해당 영역은 아무런 동작이 되지 않는 영역이었다.

그래서 사용자들이 왜 해당영역을 클릭하게 되는지, 클릭 후에 어떤 걸 기대하고 있을지? 에 대한 의문이 들었고

팀 내부적으로 공유하여 해당 부분에 대한 개선작업을 다음 스프린트에 진행하게 되었다.

그리고 아래 사진과 같이 여러 기능(탭)이 있다면, 사용자가 어떤 기능을 가장 많이 사용하는지 한눈에 확인할 수 있으며 이를 통해 PMF를 찾는대도 활용하여 기획적인 측면에서도 충분히 활용하기 쉽다.

실제 제품을 만들다 보면, 고객 관점에서 생각해야지라고 생각하지만 간과하기 정말 쉽다.

사용자 입장에서 필요한 여러 기능을 제작하지만, 사실은 아닐 수도 있다. 제작자 입장에서 매력적인

기능을 만들고 사용자가 필요할 거야(그럴 거야)라고 생각하는 경우도 더러 있다.

그런 상황에서 단순히 히트맵에서 어느 정도 사용자들이 특정 기능에 대해서 관심이 있는지 없는지

보는 것만으로도 서비스를 객관화해서 되돌아볼 수 있을 것이다.

2. 사용자들의 서비스 사용환경 파악

사용자의 경험을 설계하다 보면 간간히 놓치는 게 있는데, 그중 하나가 사용환경(디바이스)이다.

매끄러운 경험을 설계할 때 절대 빠져서는 안 되는데, 예를 들어 어떤 서비스가 있는데 그 서비스의

대부분 사용자들이 많이 사용하는 환경이 낮은 해상도의 Desktop을 Window에서 사용한다고

가정했을 때, 그 환경에서 어떻게 보이고 해당 디바이스가 갖고 있는 특징들을 고려하지 않은 채

디자이너나 제작자의 환경 (예를 들면 고성능, 고해상도의 Mac OS)에서만 제작했다가는 놓칠 수 있는

부분이 굉장히 많을 것이다. 제작할 당시에는 잘 동작하고 문제없이 보이던 부분이 사용자 입장에서는

안 보인다던지 하는..

우리 서비스를 사용하는 사용자들의 어떤 디바이스와, 어떤 해상도가 가장 많은지 알 수 있다.

당연히 운영체제는 어떤 걸 가장 많이 쓰는지도 확인할 수 있으며

어떤 경로로 진입했는지도 알 수 있다.

보편적으로 가장 많이 쓰는 해상도나, 디바이스 환경이 있지만

그게 꼭 우리 서비스(프로덕트)에도 똑같이 적용되지 않을 수 있다.

특히 내가 만들고 있는 서비스의 경우 자사몰의 형태가 대부분인데, 브라우저 통계에서 알 수 있듯.

크롬이나 사파리등의 인터넷 접속보다는 인스타그램(SNS)의 광고를 통해 들어오는 경우가 50% 가까이 된다.

이런 부분들을 통해서 SNS 채널에서 접속했을 때의 특징(팝업형태로 화면이 채워져서 위아래에 헤더와 내비게이션이 필수적으로 생긴다)을 고려해서 사용자가 보게 될 화면에서의 설계를 할 수 있게 되었다.

앞에서 말했다시피, 더 깊은 인사이트를 얻거나 데이터의 유효성을 따지자면 좀 더 디테일한 설계와 작업이

필요하다. 하지만 아직 충분히 세팅되지 않은 상황이나 시간적으로 여유롭지 않은 상황에서도 뷰저블 도입만으로도 충분히 방향성을 뾰족하게 하는데 도움이 될 것이다.

특히나 다른 솔루션 도입에는 여러 타 직군들의 협조와 도움이 필요하지만 코드 한 줄로 설치가 가능하고

그 이후의 추가작업이 필요 없어서 사용하다 보면 이게 또 은근히 큰 장점으로 다가온다.

ㄴ뷰저블 서포터즈 1기로 제품을 무료로 제공받아 작성된 솔직한 후기입니다.

효과적으로 서비스의 문제와 개선점을 파악하는 방법

효과적으로 서비스의 문제와 개선점을 파악하는 방법