[데벨챌, UXUI] '데이터 삽질 끝에 UX가 보였다' 3주차 - 감각이 아니라 근거로 말하는 디자이너

출처: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=368679219

 

데벨첼 세미나 후기는 여기 ▼

[seminar] 데이터 드리븐 디자인 세미나 : UXUI 디자이너에게도 비즈니스 관점이 필요해 !

 

📚 챌린지 일정 및 기록 방식

출처: https://datarian.io/blog/data-next-level-challenge-5th-noti?utm_source=slack&utm_medium=camp&utm_campaign=referral

 

드디어 마지막 3주차 미션! 데밸챌을 신청한 덕분에 책을 다 읽을 수 있었다.

 

📚 인상 깊었던 구절과 생각

이번 주차에는 책을 읽으면서 노션에 정리해둔 내용을 제미나이한테 요약해달라고 부탁했다. UX 기획자의 입장에서 당장 프로젝트에 사용할 수 있을 정도로 요약해달라고 했더니 '적용 방안 요약'을 함께 덧붙여주었다. 

 

마지막 주차의 챌린지 범위인 Part3-4를 읽으면서 부트캠프 강의때 들은 내용들이 머리를 스쳐 지나가는 느낌을 받았다. 비슷한 내용을 반복해서 학습하다 보니 내용을 빠르게 읽어도 무슨 말인지 파악이 됐다. 책에 나오는 예시를 보면 나도 실전에서 저렇게 할 수 있을 것만 같은데 현실은 또 다르겠지..허허 다음주부터 팀 프로젝트를 시작하는데 공부한 내용들을 요긴하게 써먹어볼 수 있으면 좋겠다.

 

-

1. 데이터 요청 시 필수 포함해야 할 5가지 구성 요소

데이터를 가지고 있는 유관 부서에 요청할 때, 단순히 '이탈률'이나 '검색 키워드'만 요청하는 것이 아니라, 요청의 배경, 목적, 사용자 행동, 기간, 데이터 종류를 모두 명확히 해야 효율적입니다. 이 5가지 요소는 데이터 분석가와의 커뮤니케이션 비용을 줄이고, 원하는 답에 가까운 데이터를 정확하게 확보하는 데 결정적인 역할을 합니다.

 

적용 방안 요약: 데이터 요청 시 아래 5가지 정보를 반드시 포함하는 양식을 만들어 활용하세요.

1. 업무 배경/상황: (예: 검색 기능 개선 프로젝트 진행 중)
2. 데이터를 통해 이루려는 목적: (예: 상세페이지 이탈률 감소)
3. 사용자의 행동/특성: (예: 검색 후 제품을 구매하는 사용자 플로우 파악)
4. 필요한 데이터의 기간: (예: 2025년 1월 ~ 6월)
5. 필요한 데이터 종류: (예: 검색 기능을 사용한 후 상세페이지로 이동한 사용자 수)

-> 원하는 데이터가 무엇인지 정의해보는 과정이 꼭 필요할 것 같다. 마케터로 일할 땐 권한을 받은 데이터들은 직접 볼 수 있어서 오히려 데이터를 보려는 목적을 정의하지 않고 무작정 대시보드를 펼쳐본 적이 많은 것 같다. 혹은 팀 내에서 필요한 데이터를 미리 정의해두고 나에게 그 데이터를 뽑아주라는 지시를 내려서 무지성으로 데이터를 정리한 적이 대부분이었다. 

 

그렇기에 업무의 배경과 데이터를 통해 이루려는 목적을 정의하는 프로세스가 나에게 생소하게 다가왔다. 사소해보이는 일 같아도 이걸 거치느냐 안 거치느냐에 따라서 업무를 얼마나 주도적으로 진행할 수 있을지가 달라질 것 같다. 어쩌면 여태까지 내가 업무를 수동적으로 해낸 것도 이런 배경에 있는 정보들을 정의하지 않고 닥치는 대로 일을 했기 때문이 아닐까 싶다.

 

2. UX 지표를 비즈니스 성과와 연결하여 정의하기

프로젝트의 궁극적인 목표는 비즈니스 성과(예: 매출 증대)일 수 있지만, UX 기획자/디자이너는 그 '너머'에 있는 사용자 경험 측정 지표를 정의해야 합니다. 어떤 UX 지표(예: 검색 결과 정확도, 태스크 성공률, 사용성 점수)를 개선했을 때, 결과적으로 비즈니스 성과에 기여할 수 있는지에 대한 논리적 연결 고리를 만드는 것이 중요합니다. 이 접근법은 UX 개선의 우선순위를 정하고 가치를 입증하는 데 필수적입니다.

 

적용 방안 요약: "이 UX 지표(X)를 개선하면 사용자의 어떤 경험(Y)이 나아지고, 결과적으로 어떤 비즈니스 지표(Z)에 영향을 미칠 것이다"라는 논리 구조(X → Y → Z)를 프로젝트 초기에 명확히 문서화하세요.

 

-> 이 대목을 읽고나서 내가 개인 프로젝트에서 프로젝트 목표를 잘 못 설정했다는 걸 알게 됐다. 내 프로젝트의 목표는 '앱 이탈률을 줄이는 것'이었기 때문이다. 궁극적인 목표로서 '앱 사용자들이 이케아앱을 통해 일상의 주거 문제를 해결할 수 있다는 믿음을 가지는 것' 을 설정해두긴 했으나, UX 를 기획할 때 비즈니스를 보는 시각이 중요하다는 말이 머리에 박혀있던 나는 '어떻게 하면 이탈률을 줄일 수 있는가?' 에 현안이 되었었다. 사용자 입장에서 문제를 정의하지 못한 것이다. 이럴 경우 사용자 경험 개선과는 동떨어진 방향으로 디자인을 발전시킬 수 있다는 대목을 어디선가 읽은 것 같다. 

 

3. 화면 설계 전, 서비스 정책 및 FAQ 사전 확인

아무리 사용자 편의를 극대화한 디자인이라도 서비스 정책(내부 규제, 제약 사항)과 충돌하면 구현이 불가능하거나 사용자의 혼란을 초래합니다. 정책이 문서화되어 있지 않다면 '자주 묻는 질문(FAQ)'은 사용자들이 어떤 제약 때문에 방해를 받는지, 어떤 정보에 대해 궁금증을 느끼는지를 파악할 수 있는 훌륭한 '정책서의 대안'이 됩니다.

 

적용 방안 요약: 와이어프레임이나 프로토타입 설계에 들어가기 전, 기존 FAQ를 분석하여 디자인에 반영해야 할 핵심적인 서비스 제약 사항(Constraints) 목록을 작성하고, 이를 바탕으로 정책과 충돌하지 않는 사용자 여정을 설계하세요.

 

-> '서비스 정책'이 중요하다는 걸 이 부분을 보며 깨달았다. 기껏 디자인을 설계해뒀더니 정책 상의 이유로 반영하기 어렵다는 답변이 돌아오면 허망할 것 같다. 기획 단계에서 꼭 서비스 정책을 살펴보며 아이디어를 적용해야할 것 같다. 

 

FAQ도 막연하게 '사용자가 서비스에 대해 궁금한 점을 묻는 창구' 로만 생각했는데, 빈번하게 발생하는 질문의 경우에는 서비스 정책 자체에 문제가 있을지도 모른다는 인사이트를 도출할 수 있다는 점이 놀라웠다. 사용자 경험을 다루는 일인 만큼 정말 사용자와 맞닿은 여러 창구에서 프로덕트를 개선할 실마리를 얻을 수 있구나 하는 생각이 들었다.

 

4. 사용자 인터뷰 목적: '상위 정보'를 수집하는 질문 설계

사용자 인터뷰에서 우리가 얻으려는 정보는 '우리 서비스만의 문제'가 아니라, '사용자가 서비스 바깥에서 내리는 선택의 기준'이어야 합니다. 즉, "왜 이케아 앱을 쓰세요?" 대신 "왜 가구를 구매하시나요? 구매를 결정하는 기준은 무엇인가요?"와 같은, 프로덕트를 벗어난 상위 질문을 던져야 사용자의 근본적인 니즈와 의사결정 가치를 파악할 수 있습니다. 이것이 문제 해결의 핵심 열쇠입니다.

 

적용 방안 요약: 인터뷰 질문지를 만들 때, '우리 서비스 사용 행동'을 묻는 질문 1개당 '사용자의 삶, 목적, 선택 기준'을 묻는 상위 질문을 2개 이상 배치하여 질문의 초점을 제품 사용 경험에서 사용자의 근본적인 동기로 전환하세요.

 

-> 프로덕트의 문제점을 바라볼 때, 사용자의 행동 범위를 프로덕트 내에서만 한정시켜 바라보지 않아야 한다는 깨달음을 얻었다. 사용자는 프로덕트 바깥에 사는 사람들이고, 우리의 프로덕트는 사용자가 문제를 해결하기 위해 거치는 무수한 선택지 중 하나임을 알아야 한다. 그렇기 때문에 더욱 본질로 파고들어야 한다고 생각한다. 과연 사용자는 어떤 문제를 가지고 있고, 그 문제를 해결함으로써 얻는 것은 무엇인지를 말이다.

 

5. 감각이 아닌 근거로 말하는 '객관화된 인사이트' 도출

데이터 드리븐 UX 기획의 최종 목표는 주관적인 감각이 아닌 객관적인 근거를 제시하는 디자이너가 되는 것입니다. 이를 위해, 정성적/정량적 데이터를 최종 인사이트로 종합할 때 반드시 다음 두 가지 기준을 지켜야 합니다.

 

적용 방안 요약: 사용자 행동의 원인(Why)을 파악하고, 그 해석이 오해의 여지 없이 명확한지 확인하여 디자인 의사결정의 근거를 확립하세요.

1. 사용자 행동의 '해석' 포함: 단순한 현상 나열이 아닌, '사용자가 왜 그런 행동을 했는지'에 대한 근본적인 이유와 의도를 반드시 내포해야 합니다.
2. 모두가 동일하게 이해하는 명확한 문장: 인사이트는 모호한 표현을 피하고, 10명이 읽어도 10명 모두 동일한 장면을 떠올릴 수 있을 만큼 간결하고 명확하게 작성해야 합니다.

-> “감각이 아니라 근거로 말할 수 있는 디자이너”(400p) 라는 문장을 읽고 내가 이 책을 통해 얻고싶은 게 무엇이었는지를 알게 됐다. 나는 감이 아니라 분명한 근거를 가지고 기획하는 디자이너가 되고 싶었던 거다. 사실 이건 내가 디자이너가 아니라 기획자 혹은 마케터가 된다고 해도 필요한 관점인 것 같다.

 

자소서를 쓸 때마다 힘이 들었던 점은 '내가 왜 이 업무를 진행했고, 그 업무를 왜 해야했는지'를 설명하는 게 어려웠던 것이다. 사실 나는 시키는 대로만 일을 하고 있었기 때문이다. 사수님이 또는 대표님이 그렇게 하라고 하니까, 우리 팀은 늘 그렇게 해왔으니까 그 업무를 한 것이었지 내가 어떤 목적을 가지고 일을 한 적은 거의 없었던 것 같다. 그래서 어떤 업무를 할 때마다 기존의 결과물과 비슷한 느낌이 나는 걸 목표로 했고, 광고소재나 이벤트페이지를 기획할 때도 감으로 레퍼런스를 찾고, 단순히 눈에 보이기에 괜찮을 정도의 퀄리티를 뽑아내려 했던 것 같다. 

 

감각이 아니라 근거로 말하고 싶다. 그게 내가 이 책을 읽은 이유이고 앞으로 나아가고 싶은 방향이다. 근거를 통해 내 생각이 이렇다는 걸 표현할 것이고, 그걸 바탕으로 내 업무를 정당화하고 싶다. 계속해서 이 업무를 하는 이유를 찾고 근거를 쌓아나가다 보면 어느샌가 성장해있지 않을까 하는 막연한 기대감이 차올랐다.