분명 데이터 드리븐 디자인 했는데 왜 내 디자인은 설득력이 그대로지?
사용자 인터뷰를 수차례 진행하고, 분석 툴로 데이터를 꼼꼼히 뜯어봐도 제품의 지표가 제자리걸음인가요? 많은 UX/UI 디자이너와 프로덕트 디자이너들이 '데이터 드리븐(Data-driven)'을 외치며 화면을 수정하지만, 정작 오픈 후 사용자의 외면을 받는 상황이 반복되곤 합니다. 애초에 거기까지 가지 못하고 내부 의사 결정권자를 설득조차 못하는 경우도 많죠.
이것은 툴의 숙련도나 인터뷰 스킬의 문제가 아닙니다. 데이터라는 숫자를 해석하기 전, 그 숫자를 만드는 '사용자의 본질'을 이해하는 프레임워크가 부재하기 때문입니다. 프로덕트 디자이너는 사용자 경험과 비즈니스를 연결하는 사람입니다. 비즈니스의 성공 지표인 리텐션(재방문율)과 전환율은 단순한 기능 추가가 아니라 사용자의 맥락을 정확히 관통하는 설계에서 나옵니다. "이 사용자는 왜 이 화면을 쓰는가?"라는 본질적인 질문에 답하지 못한 채 그리는 화면은 결국 길을 잃을 수밖에 없습니다.
UXUI 디자이너들은 현재 어떤 순서로 디자인 하고 있는가?
가장 흔한 패턴은 이렇습니다. 요구사항을 받고 레퍼런스를 찾고 화면을 그려요. 빠르게 움직이는 것처럼 보이지만 이 과정 어디에도 "이 사람이 왜 이 화면을 쓰는가"라는 질문이 없습니다. 결과물은 기능적으로 완성되어 있지만 쓰는 사람 입장에서는 어색하거나 불필요한 흐름이 남아요. 수정 요청이 오고, 다시 그리고, 또 수정됩니다. 지표도 그대로이거나 오히려 떨어집니다. 이건 툴의 문제가 아니에요. 시선의 방향이 잘못된 겁니다.
데이터 드리븐 디자인, 도대체 어떤 사용자 데이터를 얻어야 하는가?
❶ 사용자의 최종 목적
이 프로덕트를 통해 사용자가 궁극적으로 이루려는 것이 무엇인가를 말합니다. 사용자는 갑자기 가만히 있다가 우리 제품을 쓰지 않아요. 자신의 일상 생활 속에서 무언가를 이루기 위한 정거장으로 우리 서비스를 이용하죠. 그러니 그 ‘목적’을 알아야 해요.
식단 관리 앱을 만들고 있다면 사용자의 최종 목적이 ‘외모를 가꾸기 위한 다이어트 성공’인지 ‘잃어버린 건강 회복 성공’인지 아는 것 만으로도 상세 기능을 정의할 수 있습니다. 모른다면 결국 ‘나’를 기준으로 만들게 됩니다. 뭐, ‘내가 쓸 서비스’를 만들고 있다면 상관없겠죠!
❷ 최종 목적에 따른 사용자 세그먼트 유형
사용자는 단일하지 않아요. 여러명의 사용자가 존재하는데 그들의 목적은 서로 조금씩 다릅니다. 그렇다면 그 최종 목적에 따라 사용자를 나눠서 봐야해요. 목적에 따라 원하는 것이 다르니까요. 사용자 세그먼트를 분류해줍니다. 사용자 세그먼트 분류는 같은 특징을 지닌 그룹끼리 모아준 뒤 그 그룹을 분류하는 것을 말합니다. 여기서 분류한 특징은 ‘목적’입니다. 즉, 목적을 기준으로 사용자를 분류하여 그룹을 지어준 것이죠.
방금 위에서 예시를 든 ‘식단 관리 앱’에서도 세그먼트로 나눠볼 수 있습니다. 정답은 없지만 이렇게 나눠볼 수 있습니다.
•
세그먼트 A : 예쁜 몸매를 위해 다이어트를 하는 그룹
•
세그먼트 B : 잃어버린 건강을 회복하려는 그룹
•
세그먼트 C : 가족력이 있어 건강을 미리 지키려는 그룹
•
세그먼트 D : 부모님/자녀/배우자의 건강을 직접 챙기는 그룹
그렇다면 이들은 각각 그 앱에 원하는게 조금씩 다를겁니다. 예쁜 몸매를 위해 다이어트를 하는 그룹인 세그먼트 A는 내가 먹은 음식이 살이 찌는지 안찌는지 알고 싶을 것이고, 건강을 챙기는 그룹인 세그먼트 B, C, D는 내가 먹은 음식이 내 건강에 어떤 영향을 미치는지 알고 싶을 것입니다. 같은 식단 관리 앱을 사용하는 사용자들이지만 원하는게 이렇게 다를 수 있습니다.
참고로 사용자 세그먼트는 정답이 있는 영역은 아니고 우리 프로덕트의 성격이나 이번 프로젝트의 목적에 맞춰서 나누면 됩니다. 지금처럼 ‘목적’을 기준으로 나눠서 그들이 원하는게 뭔지 차이를 볼 수도 있고, ‘전환 지점’을 기준으로 나눠서 전환되지 않은 이유를 유추해볼수도 있습니다. 그 외에도 ‘디바이스’나 ‘연령’, ‘접속 요일’ 과 같은 것으로 나눠서 사용자의 행동 특성 차이를 확인해볼 수도 있습니다. 사용자 세그먼트에 대해서는 다른 글에서 더 자세히 다뤄보겠습니다.
❸ 최종 목적을 이루기 위한 하위 목적들
앞에서 알아본 이 최종 목적은 한 번에 이룰 수 없습니다. ‘꽃집을 차리겠다’나 ‘유럽으로 유학을 가겠다’와 같은 목적은 마음 먹는다고 바로 이뤄지는게 아니죠. 중간 중간 달성해야 하는 하위 목적들이 있어요. 바로 이 하위 목적 즉, 각 세그먼트가 최종 목적을 이루기 위해 거치는 중간 단계를 파악해야 합니다.
위에서 다룬 식단 일기 앱을 예시로 들어볼께요. 세그먼트 A는 매력적인 외모를 갖기 위해 다이어트를 합니다. 그렇다면 그 목적을 이루기 위해 식단 관리 뿐만 아니라 운동도 해야하고 틈틈히 스트레칭도 해야 합니다. 살이 찌지 않은 음식 레시피도 찾아야 하고 포기하지 않도록 중간 중간 치팅데이도 가져야 합니다.
이 모든 것이 하위 목적입니다. 대부분의 서비스는 이 하위 목적을 이루게 해주는데서 출발합니다. 지금 당신의 UXUI 디자인은 누구의 어떤 하위 목적을 이뤄주고 있나요?
❹ 하위 목적을 이루기 위해 하는 행동과 문제
중요한 사실이 있습니다. 하위 목적은 이루려고 마음 먹는다고 뿅 하고 이뤄지지 않는다는 점이에요. 무언가를 이루려면 반드시 행동을 해야 하는데 우리 인생사가 그렇게 호락호락하지 않아요. 행동에는 꼭 방해 요소들이 있습니다. 그게 결국 우리 서비스 이용까지도 방해합니다. 아니, 오히려 우리 프로덕트가 사용자의 행동을 방해하고 있을수도 있습니다. 소중한 우리 서비스 사용자의 행동을 방해하는 문제를 파악합니다.
이번에도 식단 일기 앱으로 예를 들어볼께요. 세그먼트 A 그룹에 속한 사용자가 다이어트라는 최종 목적을 이루기 위해서는 ‘꾸준히 식단 일기를 작성해야 하는’ 상황입니다. 이게 하위 목적이 되며 사용자는 이를 이루기 위해 ‘식사 후 식단 일기를 작성하는 행동’을 하겠죠. 그 행동을 방해하는 문제로 ‘내가 먹은 음식 종류가 많을 때 일일이 적기 귀찮음’이 있을 수도 있고, ‘저녁에 몰아서 작성하려니 기억나지 않음’도 있을 수 있습니다. 이 문제가 지속되면 사용자는 결국 하위 목적 달성의 의지를 잃고 식단 일기 앱을 더이상 이용하지 않으려 할 수 있습니다.
그럼 그 문제를 우리 앱이 제거해줌으로써 사용자가 행동을 지속할 수 있게 만들어야 합니다. 조심하세요. 우리 앱의 UX가 불편하면 오히려 우리의 존재 자체가 사용자의 행동을 방해하는 문제가 될 수 있거든요.
❺ 문제가 있어도 행동하게 만드는 지속 동기
사용자의 지속 동기도 중요합니다. 행동에 불편함을 느끼면 그 행동을 안하면 되는데 그럼에도 불구하고 계속 시도하는데는 이유가 있거든요. 말 그대로 지속하는 동기입니다. 참고로 지속 동기는 회피 동기, 보상 동기로 나뉩니다.
•
회피 동기 : 위험이나 부정적인 상황을 피하려는 마음
•
보상 동기 : 이득이나 즐거움을 얻으려는 마음
세그먼트를 목적에 따라 나눴으면 지속 동기도 다를 확률이 높습니다. 그러니 이번 프로젝트에서 또는 우리 프로덕트에서 세그먼트를 어떻게 공략해야 할지 모르겠다면 지속 동기에 집중해보세요.
그리고 우리 서비스에 허들이 있는데 기술로는 풀 수 없을 때도 유용합니다. 사용자가 직접 그 허들을 넘어 올 수 있게 넛지를 줄 수 있거든요. 더불어 지속 동기는 브랜딩을 할때도 유용합니다.
식단 일기 앱으로 예를 들면 이렇습니다.
•
회피 동기 (위험이나 부정적인 상황을 피하려는 마음): 세그먼트 B나 C의 경우, ‘지금 식단을 기록하지 않아 건강이 나빠지면 나중에 더 큰 병원비를 쓰거나 고통을 겪을 수 있다’는 공포가 동기가 됩니다. "오늘 기록하지 않으면 당신의 혈당 수치가 위험해질 수 있습니다"와 같은 알림은 불편함을 감수하고도 앱을 켜게 만드는 강력한 트리거가 됩니다.
•
보상 동기 (이득이나 즐거움을 얻으려는 마음): 세그먼트 A의 경우, ‘오늘의 식단을 완벽히 기록했을 때 변화하는 신체 데이터나 앱 내에서 부여하는 뱃지, 혹은 타인의 칭찬’이 동기가 됩니다. 기록 과정이 다소 번거롭더라도, 눈에 보이는 그래프의 변화나 성취감이 그 허들을 넘게 만듭니다.
❻ 의사결정 기준
의사결정 기준은 우리가 다양한 선택지 앞에서 어떤 것을 선택하게 만드는 필터와 같습니다. 말 그대로 ‘어떤 기준으로 의사결정 하는가’를 알 수 있게 해주는겁니다. 우리의 사용자가 어떤 의사결정 기준을 잣대 삼아 세상을 판단하고 선택하는가를 파악합니다.
역시나 식단 일기 앱으로 예시를 살펴보면 이렇습니다.
•
직장인이라면 효율성 중심 : 바쁜 직장인 사용자는 ‘얼마나 빠르게 입력할 수 있는가’를 기준으로 앱을 선택할 수 있습니다. 사진 한 장으로 칼로리를 자동 계산해주는 기능이 있다면 다른 부가 기능이 적더라도 그 앱을 최종 선택할 것입니다.
•
질병 관리 앞에서는 정확성 중심 : 질병 관리가 목적인 사용자는 입력의 간편함보다 ‘데이터가 얼마나 공신력 있고 정확한가’를 기준으로 삼습니다. 조금 입력이 귀찮더라도 영양 성분이 상세히 분류되어 있고, 의료 전문성이 느껴지는 인터페이스를 선호하게 됩니다.
생각보다 중요한 사용자 데이터, 그렇다면 왜 이 과정이 실무에서 생략되는가?
시간 부족이라는 말을 많이 하는데 실제로는 “이런걸 알아야 하는지 아무도 가르쳐주지 않아서”에 가깝습니다. 피그마나 포토샵 툴 사용법, 컴포넌트 구조 만드는 방법, 디자인 시스템 설계 방법, 더블 다이아몬드, 페르소나, 유저 저니맵. 이런건 가르쳐주는 곳이 많아요. 이건 모두 ‘방법’입니다. 방법 전에 ‘무엇을 알아야 하는가’가 있어야 하는데 그건 학교도, 회사도, 학원도 제대로 가르쳐주지 않아요.
여기서 한 가지 또 짚고 넘어갈게 있어요. “사용자 인터뷰 하는 방법은 배웠어요. 그게 사용자를 이해하기 위해 필수 아닌가요? 그런데 문제는 우리 회사는 그런걸 안해요.” 라고 말한다는 점이에요. 네, 맞아요. 사용자 인터뷰는 사용자를 이해하는 좋은 방법이에요. 그러나 이 또한 ‘방법’이고 ‘도구’입니다. 그런데도 많은 디자이너에게 ‘사용자 이해 = 유저 인터뷰(또는 설문조사)’로 각인되어 있어요. 그러다보니 유저 인터뷰를 못 하는 환경이면 사용자 이해 자체를 포기합니다. 회사가 안해줘서, 리소스가 없어서, 사용자를 모으기 어려워서와 같은 이유를 대죠.
사실 문제는 그보다 더 앞의 지점인 ‘우리가 사용자를 이해하려면 무엇을 알아야 하는지 모른다는 점’에 있는데 말이에요. 사용자의 목적, 사용자 세그먼트의 다름, 그들의 지속 동기, 의사결정 기준, 행동과 문제. 이 개념 자체를 모르니 유저 인터뷰가 없으면 아무것도 할 수 없는 상태가 되는 것 입니다.
결국, 데이터는 '현상'이고 사용자의 목적은 '원인'입니다.
열심히 화면을 그렸음에도 지표가 제자리라면, 우리는 다시 질문의 방향을 틀어야 합니다. 피그마(Figma) 컴포넌트를 정교하게 만들고, 복잡한 사용자 저니맵(User Journey Map)을 그리는 것은 '방법'일 뿐입니다. 그 방법 이전에 사용자가 이 제품을 통해 궁극적으로 얻고자 하는 가치를 명확히 정의했는지 자문해 보세요.
성공적인 데이터 드리븐 디자인을 위해 우리가 기억해야 할 6가지 핵심 체크리스트를 요약하자면 이렇습니다.
1.
최종 목적 : 사용자가 우리 제품을 정거장 삼아 도달하려는 종착지는 어디인가?
2.
사용자 세그먼트 : 목적에 따라 사용자를 어떻게 그룹화했는가?
3.
하위 목적 : 최종 목적지에 이르는 과정에서 거쳐야 할 중간 단계는 무엇인가?
4.
행동과 문제 : 하위 목적을 달성하는 데 방해가 되는 진짜 허들은 무엇인가?
5.
지속 동기 : 그럼에도 불구하고 사용자를 움직이게 할 '넛지'는 무엇인가?
6.
의사결정 기준 : 사용자가 선택의 기로에서 사용하는 판단의 잣대는 무엇인가?
우리는 사용자를 인터뷰하는 '방법'을 모르는 것이 아니라, 사용자를 이해하기 위해 '무엇을 물어야 하는지'를 놓치고 있었을지도 모릅니다. 데이터라는 숫자의 미로 속에서 길을 잃지 않는 유일한 방법은, 사용자의 '목적'이라는 나침반을 놓지 않는 것입니다.
지금 당신의 UXUI 디자인은 사용자의 어떤 하위 목적을 해결해주고 있나요? 그 질문에 대한 답이 선명해질 때, 비로소 숫자를 움직이는 진짜 데이터 드리븐 디자인이 시작됩니다.
실무에서 만들기 어려운 데이터 드리븐 디자인 능력, 란란클래스에서 만드세요.
란란클래스에서는 AI 리서치로 이 6가지 질문에 답하는 방법을 알려드려요. 오로지 오늘 배워서 오늘 써먹을 수 있는 것만 다루고 있어요. 지금 확인해보세요!
다른 인사이트 보러 가기