프로덕트 디자이너 데이터 활용, 화면이 아닌 기획서 앞에서 시작해야 하는 이유
프로덕트 디자이너가 데이터 드리븐을 못 하는 진짜 이유는 데이터 부재가 아닙니다. 기획서를 받자마자 화면에서 시작하는 습관이 문제입니다. UXUI 디자이너, 프로덕트 디자이너가 실무에서 데이터를 쓰려면 무엇부터 바꿔야 하는지 짚습니다.
프로덕트 디자이너, UXUI 디자이너와 데이터 활용을 이야기할 때 가장 자주 듣는 말
"우리 회사는 데이터가 없어요."
하지만 이건 사실이 아닙니다. 데이터는 있어요. 문제는 데이터를 볼 수 있는 질문이 없다는 것입니다. 그리고 그 질문이 없는 이유는 하나입니다. 기획서를 받는 순간, 화면에서 생각을 시작하는 습관때문입니다.
화면이 먼저인 디자이너는 데이터도 못 본다
기획서가 오면 대부분의 디자이너는 바로 화면으로 갑니다. 이 기능은 어떻게 동작하는 걸까, 플로우는 어떻게 연결해야 할까, 컴포넌트 설정은 어떻게 하고 UI는 어떻게 그릴까. 생각도 거기서 시작하고, 작업도 거기서 시작합니다.
이 순간, 데이터 활용은 사실상 불가능해집니다.
데이터를 보려면 먼저 "이 기능은 누구의 어떤 문제를 풀기 위해 존재하는가?"라는 질문이 있어야 합니다. 그 질문의 답부터 명료하게 정의하는 과정에서 데이터가 쓰입니다.
예를 들어 "장바구니 UI를 개선해주세요"라는 기획서가 왔다고 합시다. 화면에서 시작한 디자이너는 레이아웃, 버튼 위치, 상품 정보 구조를 먼저 생각합니다. 반면 이 기능이 "장바구니 이탈률을 낮추기 위한 것"이라는 맥락을 먼저 확인한 디자이너는 완전히 다른 질문을 먼저 합니다.
•
지금 이탈이 어느 단계에서 일어나는가?
•
이탈하는 사용자는 어떤 행동 패턴을 가지고 있는가?
•
그 데이터가 있는가?
같은 기획서, 완전히 다른 출발점입니다. 화면에서 시작한 디자이너는 데이터를 어디서 찾아야 하는지 모르는 채로 작업을 끝냅니다. 그리고 그것을 "데이터가 없어서"라고 오해하는 것 입니다.
프로덕트 디자이너, UXUI 디자이너가 화면에서 시작할 수밖에 없는 구조적 원인
이건 디자이너 개인의 문제이기 보다는 전체 구조의 문제입니다.
첫 번째, 업무 유형 분류의 문제입니다.
대부분의 기획 프로세스에서 디자이너에게 오는 것은 완성된 기획서입니다. "이 기능을 만들어주세요"라는 요청이지, "이 문제를 함께 정의해봅시다"가 아닙니다. 주어진 것이 기능이고 화면이다보니 자연스럽게 거기서 시작하게 됩니다.
두 번째, 디자이너에게 가해지는 압력이 '빠른 결과 도출'이라서입니다.
화면 작업을 시작하지 않으면 아무것도 보여줄 것이 없고, 아무것도 없으면 진행이 느리다는 인식이 생깁니다. 데이터를 먼저 보고 질문을 정리하는 시간은 "생각하는 시간"이 아니라 "아직 시작 안 한 시간"으로 보이기 쉽습니다.
그래서 많은 디자이너가, 스스로도 원하지 않으면서 화면에서 시작합니다. 아니, 대부분 ‘화면에서 시작하는 것이 맞는 것’으로 생각합니다.
하지만 이 구조에 그냥 올라타면, 디자이너는 영원히 실행자로 남습니다. 데이터를 제대로 활용하는 디자이너는 기획서가 왔을 때, 그것이 어디서 출발했는지를 먼저 묻습니다. 그리고 그 질문 자체가 협업 방식을 바꾸기 시작합니다.
데이터 드리븐 디자이너가 기획서 앞에서 하는 질문: 실무 적용법
기획을 받았을 때 화면 이전으로 돌아가는 방법은 간단합니다. 단 하나의 질문을 먼저 하는 것입니다.
“이 기능이 해결하려는 문제가 무엇인가?”
단, 이 질문은 머릿속으로만 하면 흐지부지됩니다. 실제로 문서에 써야 합니다. 문제 정의를 누군가 앞에서 안 해줬다면, 내가 하고 넘어가는 겁니다. 디자이너가 받는 기획서는 보통 '이 기능을 만들자'는 결론입니다. 그래서 기획서에는 주로 "기능 설명"이 있습니다. 하지만 기능 설명은 솔루션이지, 문제가 아닙니다.
예시)
•
"장바구니 UI 개선" 이건 솔루션입니다.
•
"구매 전환율이 업계 평균 대비 낮고 장바구니 단계에서 이탈이 집중되고 있음" 이건 문제입니다.
•
즉, 잘 쓴 기획서는 문제와 솔루션이 분류되어 있습니다.
잘 쓴 기획서는 문제와 솔루션이 분리되어 있습니다. 이 두 가지가 분리되어 있지 않으면 직접 물어봐야 합니다. PM이나 기획자에게 "이 기능이 해결하려는 문제가 무엇인가요? 한 문장으로 써주실 수 있나요?"라고 요청하는 것이 가장 빠릅니다.
이상 말고 현실에서 대응하는 방법
그런데 실무에서는 물어봐도 답을 받지 못하거나, 물어볼 수조차 없는 상황이 태반입니다. 상황별로 현실적인 대응 방법을 정리했습니다.
상황 1 : 기획자 본인이 문제 정의의 필요성을 못느낄 때
•
상황 상세 : "그냥 위에서 하라는데요?", "원래 필요하지 않나요?" 식의 막연한 답변이 돌아오는 경우입니다. 기획자조차 목적 없이 기능의 '존재' 자체에 매몰되어 있습니다.
•
대응 팁 : 기획자를 추궁하기보다 '역추론 가설'을 제시하세요. "그럼 이 기능이 없으면 사용자가 어떤 불편을 겪나요?"라고 질문해 기획자가 문제를 거꾸로 생각하게 유도합니다. 그 답을 토대로 문제 정의를 한 문장으로 정리해서 "이게 맞나요?"라고 확인합니다. 기획자가 여전히 모르는 것 같으면 자신의 정의를 믿고 진행하세요. 어차피 기획자도 모르는데 내 정의가 틀리면 좀 어떻습니까?
상황 2 : 상대가 너무 상급자라 물어보기 어려울 때
•
상세 상황 : 대표님이나 그 외의 C-Level, 본부장 등과 같이 상급자가 직접 지시한 사항이라 "왜요?"라고 묻는 것 자체가 불편하고 위축되는 상황입니다.
•
대응 팁 : 질문의 목적을 ‘의구심’이 아닌 ‘정렬(Alignment)’에 두세요. "지시하신 의도를 정확히 반영해 최적의 UI를 도출하고 싶습니다. 제가 이해한 이 기능을 만드는 이유가 ~한 문제 해결을 위한게 맞을까요?"라고 확인 질문을 던지는 형식을 취하세요. 이마저도 불가능하다면 내가 추측한 뒤 진행하고, 결과물을 보여줄 때 디자인 의도를 그에 맞춰 설명하면 됩니다.
상황 3 : '속도' 자체가 목적인 경우 (경쟁사 대응, 투자 대비 등)
•
상세 상황 : 사용자의 문제 해결보다는 빠른 결과물 도출이 목적인 상황입니다. 경쟁사보다 앞서야 한다거나, 특정 도메인의 특수성을 대응해야 한다거나, 투자를 대비해야 한다거나 하는 등의 비즈니스 목적이 앞선 경우에 주로 나타납니다.
•
대응 팁 : 문제를 사용자에게서 찾지 말고 비즈니스에서 찾아야 합니다. "이 기능이 완성되면 우리 회사에 뭐가 좋은가요?"라고 물어보세요. 상대도 모른다면 직접 추론합니다. 비즈니스 관점이 갖춰져 있다면 어렵지 않습니다.
상황 4 : 그 솔루션(기능, UX/UI 디자인 포함)을 이미 정답이라 확신할 때
•
상세 상황 : 기획서에 이미 버튼 위치, 팝업 방식까지 고정되어 있어 디자이너의 수정 제안을 거부하는 상황입니다.
•
대응 팁 : UI 자체가 아닌 사용자 시나리오로 대화하세요. “기획하신 팝업 방식으로 갔을 때 사용자가 [B]라는 행동을 하다가 이탈할 가능성은 없을까요?”라고요. 사용자 이탈 우려 사항을 시나리오로 보여주며 기획자가 스스로 솔루션의 허점을 발견하게 만들어 문제 정의가 제대로 되어있지 않음을 깨닫게 하세요. 사용자에 대해 깊은 이해를 한 상태라면 가능합니다.
상황 5 : 결정권 없는 '단순 전달자'인 경우
•
상세 상황 : 중간 관리자나 주니어 기획자가 위에서 시킨 내용을 그대로 복사해서 가져온 상황입니다. 물어봐도 "저도 잘 몰라요"라는 답만 반복됩니다.
•
대응 팁 : 전달자를 '조력자'로 만드세요. "이대로 작업했다가 나중에 윗선에서 디자인이 의도와 다르다고 하면 기획자님도 곤란해지실 텐데, 제가 질문지를 드릴 테니 의사결정권자에게 한 번만 확인받아 주실 수 있나요?"라고 명분을 주어 대리 질문을 부탁합니다.
상황 6 : 데이터 없이 직관에만 의존할 때
•
상세 상황 : "내가 써보니까 불편하더라", "다들 이렇게 생각할 거다"라며 개인의 경험을 보편적 사실인 양 주장하는 경우입니다. 이 경우 대부분 자신이 겪는 ‘현상’을 ‘문제’로 착각한다는 특징이 있습니다. 그래서 ‘문제’로 시선을 돌려야 합니다.
•
대응 팁 : 반박하면 상대방은 더 고집스러워집니다. 그러니 반박하기보다는 오히려 그 문제를 정당화하여 뾰족한 문제 정의를 이끌어내세요. “그럴 수 있겠네요. 솔루션도 좋아보여요. 그렇다면 그 불편함이 이어지면 어떤 문제가 생기나요? 그 문제를 이참에 제대로 해결해보면 좋을 것 같아서요.” 참고로 ‘하지만’이라거나 ‘그런데’와 같은 접속어를 쓰지 않는 것이 포인트입니다.
상황 7 : 과거의 관성에 묶여 있을 때
•
상세 상황 : 상대방이 "5년 전부터 이렇게 해왔다", "예전에 해봤는데 안 됐다"며 과거의 데이터나 경험에 갇혀 변화를 거부하는 상황입니다. 이 경우 문제 자체가 그때나 지금이나 변하지 않고 똑같을거라고 생각합니다.
•
대응 팁 : '현재의 변화된 컨텍스트’를 강조하세요. “그 당시와 지금은 사용자 층이나 시장 트렌드가 많이 달라졌습니다. 과거의 데이터도 소중하지만, 지금의 사용자들이 보여주는 새로운 패턴(최신 데이터)을 한 번만 더 들여다보고 판단하면 어떨까요?”라고 접근합니다.
상황 8 : 이미 확정된 기능으로 예산이 투입되어 중단 불가능할 때
•
상세 상황 : 해당 기능으로 외부 업체 계약이 완료되었거나 연간 계획에 확정되어 있어 기능의 효용성을 따지는 것 자체가 의미 없어진 상황입니다. SI 업체 또는 에이전시에게 일을 맡기거나 또는 그 업체 자체에서 많이 일어나는 상황입니다.
•
대응 팁 : 그럼에도 문제 정의는 필요합니다. 그 문제 정의가 UI의 명료함도 함께 해결해 주기 때문입니다. 이 경우 대부분 ‘이 기능 배포 이후 어떤 지표를 볼지’에 대해서도 정의하지 않습니다. 그러니 기획자에게 확인을 거치거나 논의하기 보다는 나 혼자서 각 기능별로 ‘이 기능이 누구의 어떤 문제를 해결해주는가’에 대해 정의해보세요. 할 수 있는데까지만 해도 됩니다.
상황 9 : 여러 부서의 요구사항이 섞인 기획안일 때
•
상세 상황 : A팀은 광고 노출, B팀은 정보 전달, C팀은 가입 유도를 원해 화면이 누더기가 된 기획안입니다. 그마저도 이 요구사항을 하나로 모아주는 PM이나 PO이 부재하면 짬뽕도 전국 팔도의 짬뽕이 한 자리에 모인 것과 같습니다. 잘 없는 상황이지만 어딘가에서는 분명 일어나는 일입니다.
•
대응 팁 : 그냥 하세요…. 는 농담이고요. 내가 기준을 잡습니다. 애초에 책임자도 없이 나에게 떠밀려 온건데 뭘 고민합니까. 이럴때는 각 팀에게 기준을 두지 말고 그보다 높은 기준인 회사를 기준으로 둡니다. ‘지금 우리 회사에서 가장 중요한 지표가 무엇일까’를 생각해보고 그에 맞춰 요구사항을 정렬합니다. 그리고 각 팀에게도 그렇게 알립니다. 안되면 그냥 깊게 생각 하지말고 해달라는대로 해서 해치워버리세요. 그로 인한 후폭풍은 프로덕트를 책임지는 사람의 부재를 내버려둔 회사의 책임입니다. (이런 경우는 대표님에게 정리해달라고 하는게 가장 좋습니다)
문제 정의 습관이 프로덕트 디자이너의 포지셔닝을 바꾸는 방법
모든 상황이 참 쉽지 않습니다. 하지만 나라도 제대로 질문하고 제대로 답해야 합니다. 이 질문을 화면 작업 전에 하는 것이 습관이 되면, 실무에서 세 가지가 달라집니다.
첫 번째, 어떤 데이터를 봐야 하는지 보이기 시작합니다.
문제가 정의되면 질문이 생기고, 질문이 생기면 내가 지금 무슨 데이터를 봐야 하는지 자연스럽게 알게 됩니다. 또한 막연하게 GA4나 Amplitude를 열어도, 또는 리뷰나 VOC를 봐도 아무것도 안 보이던 것이, 문제를 먼저 정의한 상태에서는 봐야 할 지표가 자연스럽게 좁혀집니다. "데이터가 없다"는 말이 더 이상 나오지 않게 됩니다.
두 번째, 디자인 결정에 논리가 생깁니다.
"왜 이렇게 디자인했나요?"라는 질문에 "이 기능이 해결하려는 문제는 ○○이고, 이 화면 구조는 그 문제를 해결하기 위해 ○○한 흐름을 만들기 위한 것입니다"라고 답할 수 있게 됩니다. 취향이나 감각의 언어가 아닌, 비즈니스 언어로 설계 근거를 말할 수 있는 디자이너가 됩니다.
세 번째, 협업 방식이 바뀌고 포지셔닝이 달라집니다.
기획서가 왔을 때 화면을 그리기 전에 문제를 먼저 묻는 디자이너는, 점차 "기획 단계에서 함께 생각하고 싶은 사람"으로 인식됩니다. 실행자가 아니라 결정에 참여하는 사람으로 보이기 시작합니다. 이것이 비즈니스 파트너로 포지셔닝되는 시작점입니다.
데이터가 없는 게 아닙니다. 데이터를 볼 수 있는 질문이 없었던 것입니다. 그리고 그 질문은 화면이 아니라, 기획서 앞에서 나옵니다. 시선을 옮기세요. 화면이 아닌 그 앞으로요. 당신의 디자인은 그때서야 문제 해결의 열쇠로 인정받을 수 있습니다.
** 참고 : 아참, 자존심 부리느라 협조에 응하지 않는 상대는 어디에나 있습니다. 그럴 때는 그냥 해달라는대로 해주고 빠르게 손 터는게 좋습니다.
기획서 앞을 보는 이 능력, 혼자 만들기 어렵다면?
란란클래스에서는 디자이너의 시선과 사고 방식을 완전히 바꿔드립니다. 기획서에서부터 일하는 디자이는 수행자에 머뭅니다. 기획서 그 너머를 읽을 줄 아는 디자이너는 전략가가 됩니다.
