스포카 UX 디자이너는 어떻게 일하고 있는가

안녕하세요. 스포카 UX 디자이너 남유정입니다.

2015년 11월, 스포카의 새로운 서비스 도도 매틱 이 출시되었습니다.¹ 새 서비스 런칭을 맞아 그간의 기억을 돌이켜보며, 스포카 UX 디자이너가 주로 어떤 일을 하고 있는지, 새 서비스를 준비하는 과정에서는 어떠한 기여를 하였는지를 도도 매틱 서비스를 준비하며 있었던 일들을 예를 들어 써보고자 합니다.

01. 새로운 문제의 발견

2012년 도도 포인트 런칭 이후, 고객의 피드백을 들으며 기능을 추가하고 있었습니다. 서비스 안정기에 접어들기 시작했던 당시는 ‘포인트 적립’ 기능에 초점을 맞추고 있었을 때였습니다. 또한, 초기 QR 카드 적립에서 휴대전화번호 적립으로 대표 적립 방식을 변경한 후, 매장 수와 도도 포인트 이용 고객 수가 가파르게 증가하던 시점이기도 했습니다.

그러던 중 휴대전화번호로 적립하는 고객이 늘자, 매장에서 ‘고객 휴대전화번호를 넘겨달라.’ 는 요구가 빗발치기 시작했습니다. 우리 매장 고객인데 왜 내가 고객 휴대전화번호를 볼 수 없느냐는 문의가 들어오기 시작한 것이죠. 하지만 고객 휴대전화번호는 고객들이 개인정보 중에서도 가장 예민하게 유출을 걱정하는 정보이기도 하고, 해당 정보가 유출되었을 때의 악영향 또한 가장 심각하게 우려되는 정보이기 때문에 매장에 이를 제공할 수는 없는 일이었습니다.

02. ‘문제’와 ‘문제를 해결하려는 디자인’ 나누기

우리는 매장의 요구사항을 해결하기 위한 고민을 시작했습니다.

다만 많은 매장 점주들이 요구하는 고객 휴대전화번호를 어떻게든 줄 수 있는 좋은 방법 을 고민한 것이 아니라, 왜 많은 매장 점주들은 고객 휴대전화번호를 받기를 원하는 것일까 에 대한 이유를 고민하였습니다. 문제 상황과 문제를 해결하려는 디자인을 나누어 생각해야 한다는 기본적인 원칙을 지켰기 때문입니다.

문제와 문제를 해결하려는 디자인은 서로 다릅니다. 이는 ‘서비스를 만드는 사람들’’ 이라면 머리로는 다 알고 있는 사실일 것으로 생각합니다. 더욱이 스포카의 크리에이터들은 프로그래머, 비주얼 디자이너, UX 디자이너를 막론하고 모두가 함께 서비스 설계 및 기능 방향성에 대해 고민하고 있습니다.²

하지만 안팎으로 업무가 쌓이거나 현장에서 다급하게 요구사항이 들어오는 경우, 이를 놓치게 되는 상황은 언제든 발생할 수 있습니다. 이때 ‘왜 이러한 요구사항이 들어왔나?’ 에 대한 질문을 항상 던지고, ‘문제’ 자체가 아닌 ‘문제를 일으키는 상황’과 ‘문제를 해결하려는 디자인’에 집중할 수 있게 하는 것, 그리고 이에 대한 답을 반드시 들어야 하는 역할을 UX 디자이너가 담당합니다.

“왜?” 라는 질문을 반드시 UX 디자이너가 할 필요는 없지만, 다만 그 질문을 아무도 하지 않았다면 UX 디자이너가 반드시 이를 캐치하고 “왜?” 를 질문할 수 있도록 업무를 진행하고 있습니다.

03. 함께 조사하기

‘문제 상황’과 ‘문제 상황을 해결하기 위한 디자인’ 에 대한 가설을 검증하기 위해서는 조사를 빠르게 시작해야 합니다. 만약 B2B, B2C 영업 및 고객 응대를 모두 인하우스로 하고 있는 회사라면 다양한 채널을 통해 사용자 피드백을 수집할 수 있는 기회를 확보한 것입니다. 특히 B2B를 타깃으로 하는 제품이라면, 우리가 지금 해결하고자 하는 문제가 어떤 상황에서 pain point 가 되는 것인지 문제를 더욱 명확히 판별해야 할 필요가 있습니다.

1. 해당 문제 상황은 최종 구매로 이어지기 전, 영업 피칭 상황시 발생한다.
2. 해당 문제 상황은 최종 구매 이후, 실제 제품 사용 시 발생한다.

영업 피칭 상황시 발생하는 문제 상황이나 요구사항은 고객이 서비스를 처음 보았을 때 매력적으로 보여야 하는 목적을 방해하는 상황이고, 실제 제품 사용시 발생하는 문제 상황이나 요구사항은 고객이 서비스를 쉽고 편리하게, 해결하고 싶은 상황을 충분히 해결할 수 있도록 사용해야 하는 목적을 방해하는 상황이기 때문에 이 두가지는 분명히 구분되어 수집되어야 합니다.

하지만 B2B 피드백은 영업 및 고객 응대를 관장하는 부서와 직접 소통하지 않으면 문제 상황을 수집하기 어렵다는 특징이 있습니다. 이에, 유관 부서와 협력 하에 해당 요구사항이 들어오는 매장과 브랜드를 빠르게 리스트업 하고, UX 디자이너가 인터뷰와 설문조사에 대한 지침을 제작한 뒤 다 함께 실행하는 방식을 통해 문제 상황과 왜 이를 문제 상황으로 느끼는지에 대한 고객의 소리를 빠르게 수집할 수 있었습니다.

저희는 이 조사를 통해 매장과 브랜드가 고객 휴대전화번호를 받기 원하는 이유가 궁극적으로 우리 매장에 온 고객들에게 쿠폰을 보내거나 매장 이벤트 알림 메시지를 보내고 싶다. 라는 사실을 확인할 수 있었습니다. 이를 통해 문제 해결을 위해 휴대전화번호를 고객에게 주는 것보다, 점주들이 매장 방문 고객에게 문자 메시지를 편리하게 보낼 수 있는 기능을 제공하는 것이 합당하다고 판단하였습니다.

1. 점주는 매장 운영에 바빠 메시지를 보낼 시간이 없다.
2. 점주는 메시지를 어떻게 써야 하는지 내용을 고민할 때 적절한 도움을 받기 어려운 상황에 직면한다.
3. 점주가 전체 세일 쿠폰 메시지 등을 보냈을 경우 실제 쿠폰 회수율 및 효과 측정이 되지 않는다.
4. 점주는 원하는 고객에게만 메시지를 보내거나 하는 등의 필터링을 하기 어렵다.

‘메시지를 편리하게 보낼 수 있는 기능’을 제공해야겠다고 판단한 이유는 점주가 고객 휴대전화번호를 받아 알아서 메시지를 보냈을 때 해결하기 어려운, 위와 같은 문제들이 추가로 많이 발생하기 때문이었습니다. 하지만 한꺼번에 이 모든 문제를 해결하려면 점주들에게 ‘완벽한’ 기능을 제공하기까지 너무 많은 시간이 걸릴 우려가 있었습니다.

04. 빠르게 하기

‘문제 해결을 위한 디자인’에 대한 단서를 찾은 이후에는 빠르게 이를 제품에 적용해보아야 했습니다. ‘린하게 해야 한다.’ ‘빠르게 해야 한다.’ 라는 말은 많이 들었고, 실행에 옮겨보고 싶지만, 현업에서 결과적으로 ‘빠르게 하기’ 를 실패하게 되는 상황들은 여러 가지가 있습니다.

1. ‘일단 리서치를 한다.’, 또는 ‘일단 프로토타이핑을 한다.’ 까지는 빠르게 한다. 이후 개선해야 할 점이 보여서 이터레이션을 여러 번 돈다. 디벨롭 하는 만큼 볼륨이 커져 빠르게 구현해 올려보기에는 이미 덩어리가 커져 버렸다.
2. 빠르게 리서치한 후 빠르게 초기 프로토타입을 도출했는데, 이를 구현할 개발 리소스가 턱없이 부족하여 일정이 미뤄져 버렸다.
3. 초기 가설에 대한 검증을 확실히 해야 할 것 같아 리서치 볼륨을 크게 잡아버렸더니 리서치에 시간을 너무 많이 써버렸다.

위와 같은 상황을 맞닥뜨리지 않으려면 다음과 같은 과정을 반드시 거쳐야 합니다.

1. 문제를 해결할 수 있는 가장 간단한 방법이 무엇일지 생각한다.
2. ‘있어야 하는 것’을 리스트업 하기보다는, 없어도 되는 것을 소거하는 방식으로 접근한다.
3. ‘없어도 되는 것’을 소거하면서도 가설을 검증할 수 있는 최소 요건을 갖추고 있는지 확인한다.
4. ‘없어도 되는 것’을 소거하면서도 서비스로서의 완결성을 지니고 있는지 확인한다.

이를 결정하는 데에는 UX 디자이너의 역할이 중요합니다. ‘서비스를 만드는 사람’이 만들기 원하는 서비스의 최소 요건과 ‘서비스를 사용하는 사람’이 생각하는 서비스의 최소 요건, 그리고 ‘서비스를 파는 사람’이 필요하다고 생각하는 서비스의 최소 요건을 수집한 다음 서로 조율하고 협의하여, 같은 그림을 그리도록 유도하는 것이 이 단계에서 UX 디자이너가 해야 할 역할입니다.

그렇다면 저희 문자 서비스는 맨 처음을 어떻게 시작했을까요? ‘서비스’의 최소 요건은 ‘원하는 고객에게 문자를 보낼 수 있는 것’ 한 가지이기 때문에, 사용자에게 보여지는 UI 하나 없이 내부 직원이 제어할 수 있는 간단한 UI만 구축한 후 전화 서비스로 처음을 시작했습니다. 일단 시작하고 나니 점주들이 어떤 고객 필터링을 원하는지에 대한 통계를 얻을 수 있었고, 문자 서비스를 쓰는 일정 수 이상의 고객 또한 확보하게 되었습니다. 이후 고객이 충분히 확보되어 전화 서비스로 100% 대응을 할 수 없는 시점이 되었을 때 사용자가 볼 수 있는 인터페이스를 제공하기 시작했습니다.

05. 어떻게 쓰는지 보기

‘빠르게 하기’를 수행한 뒤에는, 사용자들의 행동을 보기 시작해야 했습니다. 사용자가 볼 수 있는 인터페이스가 구축된 뒤에는 일반적으로 Google Analytics(이하 GA)나 Mixpanel을 기본으로 붙이게 됩니다. 그러나 GA나 Mixpanel 사용법 등에 대한 이야기는 다른 곳에서도 많이 소개하고 있으니, 본 글에서는 따로 이에 대한 내용을 기술하지는 않겠습니다. 여기에서는 트래킹 툴을 붙인 뒤 오히려 쉽게 간과할 수 있는 부분에 관해 이야기하고자 합니다.

트래킹 툴을 붙인 다음에는 아래와 같은 질문을 해야 합니다.

1. 보아야 하는 데이터를 충분히 수집하고 있는가 (트래킹 툴 외에 쿼리 등을 통해 보아야 하는 데이터를 챙기고 있는가. 그 데이터들은 보고 싶을 때 언제든 볼 수 있도록 기록되고 있는가)
2. 자료를 쌓은 만큼 보는 데에도 시간을 쓰고 있는가
3. 사내 CS를 통해 서비스를 쓰고 있는 등 트래킹 툴에 잡히지 않는 사용자에 대한 고려가 있는가

우선 GA나 Mixpanel로 수집할 수 없는 형태의 자료는 무엇이고, 언제든 찾아볼 수 있도록 기록되고 있는지에 대한 검토를 해야 합니다. 가령 특정 항목 변경 히스토리에 대한 자료를 수집해야 한다면, 해당 영역의 변경 내역이 로그로 기록되도록 구현되어 있는지 확인해야 합니다. 기능을 구현하는 과정에서 ‘반드시 기록되어 어떠한 형태로 저장되어 있도록’ 구현해야 하는지 아닌지에 대한 전달이 프로그래머에게 정확히 전달되지 않으면 발등에 불이 떨어졌을 때 볼 수 있는 데이터가 없는 상황이 발생할 수 있기 때문입니다.

또한, 사내 CS 부서를 운영하는 경우, 사용자 인터페이스를 사용하지 않고 전화 등 다른 루트를 통해 서비스를 이용하고 있는 고객에 대한 트래킹 또한 함께 이루어져야 합니다. 트래킹 툴을 통해 잡히는 사용자는 인터페이스에서 제한하는 범위 내에서 행동할 확률이 높습니다. 또한, 맥락정보까지 함께 수집되지 않는 경우에는 특정 과업을 수행하지 못하고 이탈한다 하더라도 이탈한 이유가 무엇인지 완전히 파악하기 어려울 수 있습니다. 이럴 때 CS 부서의 상담 및 AS 처리 기록은 더없이 소중한 자료가 됩니다.

이처럼 여러 곳에 산재해있는 데이터를 모으고 보는 등, ‘데이터’를 책임져야 하는 것 또한 UX 디자이너의 역할 중 하나입니다. 문제 상황이 발생했을 때 바로 근거가 되는 자료를 볼 수 있는 환경이 구축되어 있는가, 수집할 수 있는 귀한 자료가 새고 있는 루트는 없는가, 그리고 이렇게 모은 자료를 잘 보고 있는가를 확인하고 이를 책임져야 합니다. 저희는 사용자들이 문자 서비스를 실제로 어떻게 사용하고 있는지 보기 위해 점주들의 문자 발송 관련 로그 데이터와 CS 응대 자료를 함께 수집하고 문자 내용 패턴을 분석하여, 현재 문자 서비스가 가진 문제점을 도출하고, 개선 방향에 대한 가설을 세울 수 있었습니다.

06. 답을 위한 리서치가 아닌, 문제의 유무를 판별하기 위한 리서치

문제 상황의 유무에 대해 검증을 하는 방법으로 주로 사용자 인터뷰나 유저빌리티 테스트 등의 리서치를 수행하곤 합니다. 그렇다면 적당한 리서치 볼륨은 어떻게 산정할 수 있을까요? UX 디자이너들이 리서치 볼륨을 고민할 때에는 주로 다음과 같은 고민을 하게 됩니다.

1. 여러 사용자 그룹에서 편향되지 않는 선에서 적절히 추출해야 하는 사용자 볼륨은?
2. 통계적으로 유의미하지는 않더라도 ‘충분히 보았다’고 판단할 수 있는 적정선은?

이러한 의문들에 대해 제이콥 닐슨은 Why You Only Need to Test with 5 Users를 통해 ‘문제 상황을 판별하는 데에는 5명이면 충분하다’는 이야기를 하고 있습니다. 5명 이상의 사용자를 표본으로 추출한 경우, 5명 이후의 사용자부터는 최초 5명이 제시한 내용 중 중복되는 결과를 도출할 확률이 매우 높다는 것입니다.

물론 여러 명의 사용자가 어떤 비율로 특정 문제 상황을 제기하는지 또한 서비스를 개선하는 데 중요한 자료가 될 수 있습니다. 또한, Rapid Iterative Testing을 목표로 하는 것이 아니라, 서비스 전반에 대한 사용성 테스트를 하는 등 리서치 목적 자체가 큰 경우에는 반드시 리서치 대상자 수를 적게 가져가야 할 필요 없이 다른 많은 방법론을 따를 수도 있습니다. 5 usability test에 대한 다양한 견해 및 다른 방법론을 소개하는 글들은 여러 가지가 있지만 이곳에서는 3가지만 더 소개를 드릴까 합니다.

1. 체계적인 UX 리서치를 위한 5가지 팁
2. 사용성 테스트에서 몇 명의 참여자가 필요한가?
3. How Many Test Users in a Usability Study?

하지만 아래와 같은 상황에서는 똑같은 리소스로 30명의 사용자 리서치를 한 번 하는 계획을 세우기보다, 5명씩 6번 단계별로 사용자 리서치를 수행하는 것이 훨씬 이로울 수 있습니다. 이는 스타트업 뿐만 아니라 모든 업무 환경에 적용할 수 있는 방법입니다. 우리는 언제나 한정된 시간과 자본 내에서 문제를 해결해야 하는 임무를 부여받기 때문이지요. 요는 ‘5명’이 아니라, ‘최대한 빠르게 실행할 수 있는 단위’를 설정하는 데 있다고 보아야 할 것입니다.

빠르게 실행할 수 있는 리서치를 고려하면 좋은 상황

1. 해결해야 하는 문제 상황이 많고, 빠른 사이클로 이를 단계적으로 개선하고, 빨리 개선한 문제 상황에 대한 빠른 피드백을 다시 듣는 Rapid Iterative Testing 을 목표로 하고 있다면
2. 리서치 리소스를 사전에 크게 설정했다가 이런저런 사정으로 인해 아예 해당 단계를 건너뛰는 결정을 한 적이 여러 번 있다면 (타 직군에 리서치의 필요성과 리소스에 대한 설득을 해야 할 경우)
3. 고객의 목소리를 들어야 할 것 같은데 전수 조사를 계획하다 보니 무엇을 얼마나 어디까지 봐야 할지 헤매게 된 적이 있다면

마치며

사용자는 답을 알고 있습니다. 그러나 사용자에게서 답을 끌어내야 하는 것은 UX 디자이너의 역할입니다. 때문에 스포카 UX 디자이너들은 아래의 명제들을 명심하며 일하고 있습니다.

1. 하늘에서 떨어진 아이디어로 시작하지 않습니다. 어느 날 새로운 기능에 대해 기획을 하기보다는 사용자의 목소리에서 시작된 재료를 가지고 문제를 해결하기 시작합니다.
2. 데이터 드리븐 UX를 실천합니다. 다만 데이터를 자신이 허구 속에서 만든 기획에 끼워 넣지 않고, 데이터에 기반을 둔 사고를 하고, 이에 기반을 둔 서비스 디벨롭을 실천하고 있습니다.
3. 빠르게 만들고 빠르게 개선합니다. 실제 사용자에게 보이기까지의 단계와 기간을 최소화하고, 개선과 릴리즈의 단위 역시 고객과 항상 맞닿고자 합니다.

앞서 기술한 내용 중 사실 특별히 새로운 것은 없다고 생각합니다. Lean UX, 5 usability test 등은 여러 곳에서 이야기 되어온 주제이거나, 누군가는 이미 오래전부터 사용한 방법론들입니다. 하지만 실제로 이 방법들을 지켜가면서 일을 하는 곳들은 그만큼 많지 않으리라고 생각합니다. 또한, 저희는 서비스를 만들면서 ‘기본’을 지키고 있다는 이야기를 하고 싶었을지도 모르겠습니다.

이와 같은 과정을 통해 만들어진 스포카의 새 서비스 도도 매틱이 2015년 11월 첫선을 보였습니다. 여러분들의 많은 관심 부탁드립니다. 감사합니다.