사용자는 덜 원하고, 비즈니스는 더 원할 때

*원문을 번역한 글입니다.

*원문은 발행 이후 수정될 수 있으며, 본 번역은 발송 시점 기준으로 작성되었습니다.

성공하는 제품은 사용자와 비즈니스 모두에게 가치를 만듭니다.

지난 8년 동안 제가 내린 모든 제품 의사결정은 결국 이 한 가지 긴장 관계로 귀결됐습니다. 그 갈등을 풀면서 배운 것을 이야기해보려 합니다.

한 사용자가 금융 앱을 엽니다. 2분 안에 계좌를 만들고 싶어 합니다. 반면 비즈니스는 본인 확인을 하고, 규제 요건을 충족하고, 어떤 고객인지 파악하기에 충분한 정보를 받아야 합니다.

사용자는 질문이 적기를 원하고, 비즈니스는 더 많은 데이터를 원합니다. 그 사이에서 디자이너는 어떻게든 경험이 제대로 작동하게 만들려고 합니다.

저는 제 경력의 대부분을 이와 비슷한 문제에 매달렸습니다. 핀테크의 온보딩, 마켓플레이스의 가입, 저축 플랫폼의 회원 등록이 그랬습니다. 제가 참여했던 모든 제품은 어느 순간 같은 질문을 던졌습니다. 사용자가 쓰고 싶어 하는 제품을 만들면서도, 그 제품을 계속 운영해야 하는 기업의 수익성을 해치지 않으려면 어떻게 해야 할까?

오랫동안 저는 답이 사용자를 위해 싸우는 것이라고 생각했습니다. 적극적으로 사용자의 편에 서고, 비즈니스의 요구에 맞서고, 사용자 경험을 지켜야 한다고 생각했습니다. 제가 아는 최고의 디자이너들은 어느 한쪽을 대변하지 않습니다. 대신 양쪽 모두가 실제로 필요했던 것을 더 많이 얻을 수 있는 의사결정의 형태를 찾아냅니다. 완전히 다른 역량입니다. 그런데 아무도 이 역량을 가르쳐주지 않습니다.

대부분이 잘못 생각하는 두 가지

대부분의 디자이너는 두 가지 방식 중 하나로 이 문제를 잘못 다룹니다.

첫 번째 실수는 사용자가 말한 선호를 절대적인 것으로 받아들이는 것입니다. “사용자는 입력 필드가 적기를 원하니 필드를 없애야 한다.” 사용자 중심적인 접근처럼 들립니다. 하지만 대개 그렇지 않습니다.

사용자는 자신에게 무엇이 필요한지 제대로 설명하지 못하는 경우가 많습니다. 대신 우리가 제공한 것에서 무엇이 마음에 들지 않는지는 말할 수 있습니다. 입력 필드 세 개를 없애면 당장의 불편은 해소될지 모릅니다. 하지만 동시에 사기를 막거나, 경험을 개인화하거나, 애초에 서비스를 제공하기 위해 비즈니스에 필요한 정보까지 사라질 수 있습니다.

두 번째 실수는 비즈니스가 제시한 요구사항을 이미 확정된 것으로 받아들이는 것입니다. “그로스 팀이 랜딩 화면에 팝업을 원하니 팝업을 디자인하자.” 실용적인 접근처럼 들리지만, 이것 역시 그렇지 않습니다.

비즈니스가 정말 원하는 것은 요청한 그 기능 자체인 경우가 드뭅니다. 그 기능이 만들어낼 결과를 원하는 것입니다. 팝업은 누군가 떠올린 하나의 해결바카라일 뿐입니다. 실제로 원하는 것은 더 많은 가입, 더 많은 매출, 더 높은 인게이지먼트입니다. 같은 결과를 얻는 방법은 대개 몇 가지가 더 있고, 그중 대부분은 사용자에게 팝업보다 덜 거슬립니다.

사용자도 비즈니스도 자신에게 실제로 필요한 것을 그대로 이야기하는 경우는 많지 않습니다. 이미 머릿속에 그려둔 해결바카라의 형태로 말합니다. 디자이너의 역할은 양쪽이 말하는 해결바카라을 다시 그들이 실제로 원하는 것으로 번역하고, 두 요구를 모두 충족하는 답을 찾는 것입니다.

‘항상 사용자가 이기는’ 제품의 실제 모습

제가 아는 대부분의 디자이너는 사용자가 항상 이기는 제품이라는 발상을 좋아합니다. 폼은 더 짧고, 플로우는 더 빠르며, 사용자가 하려던 일을 방해하는 것은 아무것도 없는 제품입니다.

저는 그런 접근이 실제 제품에서 어떻게 전개되는지 지켜봤습니다. 잘되지 않습니다.

한번은 비즈니스가 요청했던 입력 필드를 거의 전부 없앤 가입 플로우를 출시한 적이 있습니다. 논리는 명확했습니다. 사용자는 긴 폼을 싫어하니 줄이자는 것이었습니다. 완료율이 올랐고, 모두가 약 6주 동안 성과를 축하했습니다.

그러자 고객 지원 문의가 급증하기 시작했습니다. 다음 단계를 진행하는 데 필요한 정보를 가입 과정에서 받지 않았기 때문에, 사람들은 정작 가입한 목적을 달성할 수 없었습니다. 해지도 늘었습니다. 리뷰에는 “헷갈리는 앱”이라는 불만이 등장했습니다. 현관문으로 들어오기는 쉽게 만들었지만, 집 전체에서는 살기 더 불편하게 만든 셈이었습니다.

사용자가 원하는 것은 입력 필드가 적은 것이 아닙니다. 그들은 자신이 이루고자 했던 목표를 달성하고 싶어합니다. 때로는 둘이 같은 의미일 수 있지만, 그렇지 않은 경우가 많습니다.

‘항상 비즈니스가 이기는’ 제품의 실제 모습

겉으로는 건강해 보이지만, 밑에서는 신뢰가 조용히 무너져가고 있는 제품

반대 상황은 훨씬 더 자주 벌어지며, 제품에 미치는 해악도 더 큽니다.

디자이너라면 누구나 이해관계자가 “그냥 플로우에 넣어주세요”라고 말하는 회의에 참석해본 적이 있을 겁니다.

사용자가 고르지도 않은 금액으로 미리 입력돼 있는 기본 입금액. 이미 체크돼 있는 마케팅 수신 동의. 해지하는 것보다 알아차리지 못하고 지나치기가 더 쉬운 자동 갱신. 메뉴 세 단계 안쪽에 숨겨둔 해지 플로우.

이런 결정 하나만으로 제품이 망하지는 않습니다. 하지만 하나씩 쌓입니다. 비즈니스에 유리한 작은 결정을 6개월 동안 계속 내리고 나면, 어느 순간 제품이 더는 우리가 만들던 제품처럼 느껴지지 않는다는 사실을 깨닫게 됩니다. 사용자를 돕는 제품이 아니라 사용자에게서 무언가를 뽑아내기 위해 설계된 기계처럼 느껴집니다.

제가 존중하던 회사들에서도 이런 일이 벌어지는 것을 봤습니다. 대시보드의 숫자는 좋아 보였습니다. 리텐션은 유지됐고, 전환율도 원하는 방향으로 움직였습니다. 하지만 리뷰의 불만은 점점 거세졌고, 고객 지원팀은 더 바빠졌습니다. 사용자 조사에서 계속 불편한 결과가 나오자 팀은 조사 자체를 피하기 시작했습니다.

지표에서는 이기면서 사용자는 잃는 일이 실제로 벌어집니다. 문제는 너무 조용히 진행돼서, 결국 그 문제가 지표에까지 드러나기 전에는 알아차리지 못한다는 것입니다. 그리고 그때쯤이면 대개 너무 늦습니다.

실제로 효과가 있는 방법

답은 타협이 아닙니다. 타협은 재미없는 중간 지점에 머무는 것입니다. 비즈니스가 원하는 것의 절반, 사용자가 원하는 것의 절반을 주고 결국 어느 쪽도 만족하지 못하는 결정을 만드는 방식입니다. 해답은 관점을 바꾸는 것 입니다 .

제가 겪었던 사용자와 비즈니스 간의 갈등 대부분은 답을 두고 벌어진 것이 아니었습니다. 애초에 질문이 문제였습니다. 질문을 바꾸면 양쪽 모두에게 맞는 답을 찾기가 훨씬 쉬워지는 경우가 많습니다.

예를 들어보겠습니다.

잘못된 질문: 온보딩 폼은 얼마나 짧아야 할까?

더 나은 질문: 사용자가 지금 바로 입력해야 하는 항목은 무엇이고, 실제로 필요할 때까지 미뤄도 되는 항목은 무엇일까?

잘못된 질문: 가격을 나중까지 숨겨야 할까?
더 나은 질문: 가격에 비해 얻는 가치가 명확하게 느껴지도록 어떻게 전달할 수 있을까?

잘못된 질문: 사용자가 클릭 한 번으로 구독을 해지하게 해야 할까?
더 나은 질문: 애초에 사용자가 구독을 해지하고 싶지 않도록 무엇을 할 수 있을까?

이렇게 질문을 다시 정의하면 “어느 쪽이 이겨야 하는가”라는 논쟁이 “이걸 어떻게 잘 디자인할 것인가”라는 대화로 바뀝니다. 사용자는 자신에게 실제로 필요한 것을 더 많이 얻고, 비즈니스도 실제로 필요한 것을 더 많이 얻습니다. 어느 쪽도 무언가를 양보할 필요가 없습니다. 그저 잘못된 문제를 놓고 싸우는 것을 멈췄을 뿐입니다.

이런 문제 대부분을 해결하는 구체적인 방법

막힐 때면 저는 셀 수 없을 만큼 여러 번 효과를 봤던 한 가지 방법을 씁니다.

양쪽 모두에게 자신이 원하는 것을 그대로 얻는다면 어떤 일이 벌어질지 묻습니다.

사용자가 원하는 플로우를 정확히 구현한다면 무엇이 문제가 될까요? 비즈니스가 요구한 기능을 정확히 구현한다면 무엇이 문제가 될까요? 대부분은 이렇게 물으면 상대방도 자기 요청에 어떤 문제가 있는지 바로 알아차립니다. 반대 의견으로 듣는 대신, 그 선택이 가져올 결과로 볼 필요가 있었던 것입니다.

그 순간 디자이너의 역할은 그 결과를 말로 분명하게 짚어주는 것입니다. “그건 틀렸습니다”라고 말하는 게 아닙니다. “이대로 진행됐을 때 어떤 일이 일어날지 한번 따라가 볼게요. 정말 의도하신 바인지 말씀해주세요”라고 말하는 것입니다. 작은 차이지만, 모든 것을 바꿉니다.

사용자는 아무런 마찰도 없는 경험을 원한다고 말할 겁니다. 그 요구를 끝까지 적용하면 어떻게 되는지 생각해봅시다. 마찰을 완전히 없애면 처음 온 사용자의 본인 확인을 할 수 없고, 돈에 문제가 생길 수 있으며, 결국 사용자는 제품을 탓하게 됩니다. 사용자가 원한 것은 그런 게 아닙니다. 실제로 하고 싶은 말은 이것입니다. 내가 하러 온 일과 상관없는 것으로 내 시간을 낭비하지 말아 달라.

비즈니스는 더 높은 전환율을 원한다고 말할 겁니다. 역시 그 요구를 끝까지 따라가 봅니다. 압박을 통해 전환율을 높이면 사용자의 불만은 커지고 3개월 차 이탈률도 높아집니다. 비즈니스가 원한 것도 이런 결과는 아닙니다. 실제 요구는 이렇습니다. 우리에게 맞는 더 많은 사람이 선택하도록 도와달라.

양쪽 모두 자신이 실제로 무엇을 원했던 것인지 알게 되면, 어떤 디자인 결정을 내려야 할지도 분명해집니다.

시니어 디자이너의 역할이란 무엇인가

대부분의 디자이너는 경력 3~5년 차쯤 한계에 부딪힙니다. 결과물도 잘 출시하고, 감각도 좋고, 자신의 작업도 잘 설명합니다. 그런데도 중요한 회의에는 초대받지 못합니다.

그 한계를 돌파하게 해주는 것은 더 뛰어난 디자인 스킬이 아닙니다. 서로의 언어를 번역하는 능력입니다.

더 큰 바카라임을 맡게 되는 디자이너는 비즈니스 논의에 들어가 사용자를 무조건 방어하려 하지 않습니다. 대신 사용자의 말을 해석합니다. 사용자의 불만을 회의에 있는 사람들이 중요하게 받아들이는 비즈니스 리스크의 언어로 바꿉니다. 비즈니스가 요청한 것을 그 이면의 목표로 다시 해석한 뒤, 그 목표에 도달할 수 있는 세 가지 방법을 제안합니다. 그중 비즈니스가 원래 생각했던 방법은 하나뿐입니다. 그리고 다른 사람이 꺼내기 전에 먼저 트레이드오프를 짚습니다.

부트캠프에서는 이런 것을 가르쳐주지 않습니다. 이에 대해 쓰는 사람도 많지 않습니다. 하지만 이것이 결과물을 출시하는 디자이너와, 제품의 방향을 결정하는 의사결정을 맡길 수 있는 디자이너를 가릅니다.

불편한 진실

디자이너가 더 이상 양쪽의 언어를 번역하지 않으면 어떻게 될까요?

대부분의 시니어 UX 관련 글에서는 잘 이야기하지 않는 부분이 있습니다.

오랫동안 사용자 입장만을 대변하다 보면 디자이너는 전략적 의사결정의 자리에서 밀려납니다. 극적인 변화가 아니라 조용히 일어나는 일입니다. 디자인 팀은 초기 기획 단계에 더 이상 초대받지 못합니다. 트레이드오프에 대한 결정은 프로덕트 매니저가 내리기 시작합니다. 디자이너에게는 해결해야 할 문제 대신 그대로 실행해야 할 브리프가 전달됩니다. 그러면서도 전사 미팅에서는 모두가 여전히 사용자 중심 디자인에 대해 그럴듯한 말을 합니다.

누구도 이런 상황을 원하지 않습니다. 하지만 회의에서 혼자만 비즈니스의 언어로 이야기하지 않는다면, 결국 그 회의에 참석하지 못하게 됩니다.

제가 이렇게 말하는 건 사용자가 중요하지 않다고 생각해서가 아닙니다. 원칙을 지킨다는 생각으로 사용자를 대변하다가 의사결정의 자리에서 밀려나고, 결국 자신이 지키려 했던 사용자에게도 좋지 않은 결과를 만드는 디자이너를 너무 많이 봐왔기 때문에 하는 말입니다.

사용자를 위해서는 디자이너가 전략적 의사결정의 자리에 있어야 합니다. 그러려면 디자이너 스스로 그 자리에 계속 있을 자격을 얻어야 합니다.

마치며

제가 참석했던 회의 중 ‘디자이너 대 비즈니스’의 대립처럼 느껴졌던 상황은 사실 서로 다른 언어를 쓰면서도 그 사실을 깨닫지 못한 두 사람이 대화하는 자리였습니다.

그 회의에는 통역사가 필요했습니다.

그것이 시니어 디자이너가 하는 일입니다. 아름다운 화면을 만드는 일이 전부가 아닙니다. 즐거운 마이크로인터랙션을 만드는 일도 아닙니다. 물론 그런 것들도 중요하지만, 제품의 생존을 결정하는 것은 아닙니다.

제품의 생존을 좌우하는 것은 회의에 있는 누군가가 사용자의 경험을 비즈니스 리스크의 언어로 번역하고, 비즈니스의 요구를 사용자 관점의 결과로 번역하며, 양쪽의 언어를 동시에 충족하는 의사결정을 찾아낼 수 있느냐입니다.

그게 디자이너의 일입니다.

우리가 처음 배웠던 디자인의 모습과는 다릅니다. 더 어렵고, 더 조용히 이루어지며, 포트폴리오에서 주목받는 일도 거의 없습니다.

하지만 바로 이것이 “이걸 만들어주세요”라는 요청을 받는 디자이너와 “무엇을 만들어야 할까요?”라는 질문을 받는 디자이너의 차이를 만듭니다.

원문 출처: https://medium.com/design-bootcamp/when-users-want-less-and-the-business-wants-more-c1107bf76238

DEET를 구독하고 커리어 성장을 위한 작은 습관을 시작해 보세요.