오즈코딩스쿨 디자인 캠프 - 답을 정하지 않고 단서부터 모으기 — UX 리서치 방법론과 도구들 (day23)

어제가 UX 리서치가 왜 필요한지에 대한 날이었다면, 오늘(23일 차)은 실제로 문제를 어떻게 찾아내는지 그 지도와 도구를 배우는 날이었다.

오전 피드백에서 강사님이 계속 강조한 말이 먼저 마음에 남았다. UX엔 정답이 없다는 것. 정답을 맞히는 게 아니라 스스로 문제를 정의하고 풀어가는 과정이라는 건데, 정답이 있어야 마음이 놓이는 나 같은 사람에게는 이 '정답 없음'이 오히려 어렵다. 그런데 그게 바로 이 파트의 핵심이었다.

오늘의 흐름은 이랬다. 길을 잃지 않게 해주는 방법론이라는 지도, 문제를 넓혔다 좁히는 더블 다이아몬드, 발견 단계에서 쓸 도구 상자(STEEP·비즈니스 모델 캔버스·SWOT·3C·스크린 플로우), 그리고 불편을 설명하는 언어인 닐슨의 10가지 휴리스틱.

방법론은 길을 잃지 않게 해주는 지도

강사님은 방법론을 'UX 개선이라는 목적지에 가장 빠르고 안전하게 도착하기 위한 경로'라고 설명했다. 목적지는 정해져 있지만, 지도가 없으면 계속 헤맨다. 방법론 없이 리서치하면 산만해진다는 말이 와닿았다. 앱 리뷰도 보고 뉴스도 보고 경쟁사도 보고 화면도 캡처했는데, 정작 한 방향으로 모이지 않는 것.

UX 방법론은 리서처가 길을 잃지 않게 해주는 지도예요.

잘못된 방법을 고르면 목적지가 맞아도 소용이 없다. 오로라를 보러 가면서 반바지를 챙기는 격이랄까. 사용자가 왜 결제를 포기하는지 알고 싶은데 앱 다운로드 수만 들여다보면 답이 안 나온다. 다운로드 수는 시장의 관심 정도만 보여줄 뿐이니까.

그래서 방법론의 출발은 지피지기다. 지피는 사용자를 아는 것이다. 예를 들어 네이버 지도 사용자는 그냥 지도만 보길 원하는 게 아니라, 목적지까지 걸리는 시간, 교통수단, 영업시간, 리뷰, 예약 가능 여부까지 함께 알고 싶어 한다. 지기는 우리 서비스와 비즈니스를 아는 것이다. 강점은 무엇이고 경쟁사와 어떻게 다른지, 어떤 가치를 주는지. 사용자만 봐도, 서비스만 봐도 부족하고, 그 둘이 만나는 지점에서 좋은 UX 전략이 나온다.

더블 다이아몬드 — 넓히고, 좁히고, 다시

리서치의 전체 흐름은 더블 다이아몬드로 설명된다. 발견(Discover) → 정의(Define) → 구체화(Develop) → 산출(Deliver). 앞쪽 다이아몬드는 '왜 이 문제가 중요한지'를 탐색하는 구간이고, 뒤쪽은 '어떻게 해결할지'를 만드는 구간이다. 다이아몬드가 두 개인 이유는, 넓게 펼쳐 탐색하고(발견) 진짜 문제로 좁히고(정의) 다시 아이디어를 넓게 펼쳤다가(구체화) 최종안으로 좁히기(산출) 때문이다.

오늘의 초점은 앞쪽 다이아몬드였다. 그리고 여기서 가장 중요한 규율은 답을 먼저 정하지 않는 것이었다. 발견 단계는 "이건 뭐지, 일단 다 찾아봐"에 가깝다. VOC, 뉴스, 연구 자료, 사용자, 시장, 경쟁사를 넓게 본다. 가설로 범위를 좁힐 수는 있지만, 답을 정해버리면 그건 발견이 아니라 정해놓은 결론에 근거를 끼워 맞추는 일이 된다.

발견 단계는 답을 찾는 게 아니라, 단서를 모으는 단계예요.

이 대목에서 간호할 때가 겹쳐 보였다. 이건 정확히 사정(assessment)이었으니까. 진단을 먼저 내려놓고 환자를 보는 게 아니라, 병력·활력징후·검사·관찰로 전체 그림을 모은 다음에야 무엇이 진짜 문제인지 좁혀간다. 초반에 넘겨짚고 모든 소견을 그 짐작에 끼워 맞추면 진짜 문제를 놓친다는 걸, 배우면서도 실무에서도 지겹게 봤다. "답을 정하지 말고 단서부터 모아라"는 말은, 내가 훈련받았던 그 순서와 똑같았다. 사정이 먼저, 문제 정의는 그다음.

그렇게 모은 단서를 정의(Define) 단계에서 좁힌다. 이때는 그냥 "주문 과정이 불편하다"가 아니라, 누가·무엇을·왜(who/what/why)로 정리한다. "30대 직장인이 출근 시간에 커피를 빠르게 주문하려 할 때, 혜택 조건을 이해하지 못하면 결제 직전에 망설인다"처럼 어떤 사람이 어떤 과정에서 왜 어려워하는지를 문장으로 만드는 것이다.

발견 단계의 도구 상자 — STEEP·BMC·SWOT·3C

발견 단계엔 도구 상자가 있고, 각 도구는 단서를 서로 다른 각도로 정리해준다. 이것들도 다 데스크 리서치에 해당한다.

STEEP 분석은 비즈니스를 둘러싼 거시 환경을 본다.

요인무엇을 보나예시

Social (사회)	인구구조·라이프스타일·가치관	1인 가구 증가, 친환경 소비
Technology (기술)	기술·트렌드 변화	생성형 AI 보편화, 자율주행
Economic (경제)	금리·물가·소비 심리	경기 침체, 물가 상승
Environmental (환경)	기후·환경 이슈	탄소중립, ESG
Political (정치)	정책·법률·규제	플랫폼 규제, AI 관련 법안

**비즈니스 모델 캔버스(BMC)**는 서비스의 비즈니스 전반을 한 장에 담는다. UX 리서치에서 이걸 보는 이유는, 우리가 개선하려는 UX가 결국 비즈니스와 연결돼 수익으로 이어져야 하기 때문이다.

블록무엇을 적나

고객 세그먼트	이 서비스를 이용할 고객이 누구인지 ('모든 사람'은 지양)
가치 제안	고객에게 어떤 가치를 주는지 (기능 나열이 아니라 편익)
채널	어떤 접점에서 가치를 전달하는지
고객 관계	고객과 어떤 관계를 맺는지 (전담 응대 / 자동 추천 등)
수익원	어떻게 수익을 내는지 (구독 / 중개 수수료 등)
핵심 자원	비즈니스에 꼭 필요한 자산 (물류망 / 데이터 등)
핵심 활동	운영을 위해 해야 하는 핵심 일
핵심 파트너십	협력해야 하는 외부 관계
비용 구조	주로 어디에 비용이 드는지

여기서 가장 흔한 실수가 '가치 제안'에 기능을 나열하는 것이었다. 쿠팡 로켓배송은 '빠른 배송'이 아니라 "내일 필요한 물건을 오늘 받을 수 있다"처럼, 그 기능이 사용자에게 주는 편익까지 써야 한다.

SWOT 분석은 강점·약점(내부 요인)과 기회·위협(외부 요인)을 한 장으로 정리해서 복잡한 상황을 압축한다. 3C 분석은 자사(Company)·고객(Customer)·경쟁사(Competitor)를 보는데, STEEP보다 더 미시적으로 우리가 시장 안에서 어디에 서 있는지를 본다. 경쟁사 조사는 시장 점유율 기준으로 3~4개 정도를 골라 같은 기준으로 비교하는 게 핵심이다.

화면을 탐정처럼 — 스크린 플로우

데스크 리서치로 큰 맥락을 잡았다면, 이제 실제 제품 안으로 들어간다. 핵심 기능의 화면을 순서대로 캡처해 이어붙이는 스크린 플로우다. 머릿속으로만 생각하면 놓치는 게 많아서, 직접 눌러보고 캡처하고 흐름을 붙여봐야 사용자의 경로가 어디서 끊기는지 보인다.

강사님은 이걸 탐정에 비유했다. 서비스는 사건 현장이고, 리뷰·화면 흐름·클릭 데이터·경쟁사·시장 자료는 현장의 단서다. 코난이든 셜록이든, 단서를 많이 모으는 것보다 그것들을 연결해서 의미를 찾는 게 핵심이다. 사용자가 멈칫하는 화면이라는 단서와 VOC에서 반복되는 불만이라는 단서를 연결하면, 문제 해결의 가설이 된다.

스크린 플로우는 세 가지 관점으로 본다. 목표까지 가는 사용 흐름, 단계가 너무 많거나 정보를 반복 입력해야 하거나 선택지가 복잡해 이탈하게 되는 페인 포인트, 그리고 버튼 이름이 모호하거나 주문이 됐는지 안 됐는지 상태를 알 수 없는 혼란 지점.

그런데 여기서 가장 중요한 전환이 있었다.

"내가 불편했다"가 아니라, 사용자가 어디서 멈추는지를 봐야 합니다.

내가 불편한 건 이 앱에 익숙하지 않아서일 수도, 내 기존 멘탈 모델과 안 맞아서일 수도 있다. 그건 개인적인 경험에 가깝다. 가설과 직감에서 출발하는 건 괜찮지만, 분석은 사용자가 실제로 어디서 버튼을 못 찾고, 결제 전에 이탈하고, 같은 화면을 반복해서 오가는지 같은 객관적 지표로 옮겨가야 한다. (나중에 구글 애널리틱스 같은 걸 배우면 클릭·이탈·체류를 수치로 본다고 한다. 지금은 최대한 사용자 입장에서 보겠다는 마음만으로 충분하다고 했다.)

좋은 목표도 같은 맥락이었다. 막연하지 않고 구체적이며 검증 가능하고 사용자 중심일 것. "앱을 리뉴얼한다"가 아니라 "30대 직장인이 퇴근길에 원하는 상품의 재고를 확인하고 픽업 가능한 매장을 빠르게 찾을 수 있는지 확인한다"처럼.

불편을 설명하는 언어 — 닐슨의 10가지 휴리스틱

불편한 지점을 찾았으면, 그게 왜 불편한지 설명할 언어가 필요하다. 사용성 휴리스틱은 경험적으로 검증된 평가 기준이라, 사용자를 모으지 않고도 화면을 빠르게 점검할 수 있는 기준점이다. 제이콥 닐슨(닐슨 노먼 그룹 공동 창립자)의 10가지가 대표적인데, 100% 지켜야 하는 체크리스트가 아니라 좋은 화면의 기준 정도로 쓰면 된다.

"전반적으로 위계가 약해요" 대신 "시스템 상태의 가시성이 낮아 혜택 적용 여부를 확인하기 어렵다"라고 말하는 것 — 이게 분석의 언어로 커뮤니케이션하는 것이었다.

#원칙핵심

1	시스템 상태의 가시성	지금 무슨 일이 일어나는지 알려주기 (로딩·진행률·배달 상태)
2	현실 세계와의 일치	일상 언어·친숙한 메타포 (보내기, 받은 편지함, 장바구니)
3	사용자 제어와 자유	실수를 되돌릴 탈출구 (실행 취소, 뒤로가기)
4	일관성과 표준	같은 기능은 같은 방식으로
5	오류 예방	실수가 나기 전에 차단 (실시간 검증, 확인 팝업)
6	기억보다 인식	외우게 하지 말고 보여주기 (자동완성, 최근 본 상품)
7	유연성과 효율성	초보는 쉽게, 전문가는 빠르게 (단축키)
8	미학적·미니멀 디자인	목표와 무관한 요소 줄이기
9	오류 인식·진단·복구	원인과 해결을 친절히 안내 (사용자를 탓하지 않기)
10	도움말과 문서	필요할 때 빠르게 찾기 (툴팁·FAQ)

스크린 플로우에서 찾은 불편 지점을 이 휴리스틱과 연결하면, 페인 포인트가 훨씬 구체적이고 설득력 있게 정리된다.

정리하며

오늘은 프레임워크가 쏟아진 날이었지만, 결국 하나의 척추를 공유하고 있었다. 답을 먼저 정하지 말고 단서를 모으고, 그 단서를 연결해 진짜 문제로 좁히고, 그 문제를 남들이 행동할 수 있는 언어로 설명하는 것.

돌아보면 그건 침상 옆에서 하던 순서와 같았다. 진단보다 사정이 먼저였고, 소견은 정확한 언어로 남겨야 했다. 그 규율이 그대로 넘어왔다.

오전 피드백에서 한 가지 더 새겨둘 게 있었다. AI로 초안을 만드는 건 괜찮지만, AI는 내 말에 동조하는 경향이 있고 틀린 판단도 유창하게 포장해서 홀리기 쉽다는 것. 그래서 보조수단으로만 쓰고 직접 검증해야 한다고 했다. 면접에서 "AI로 도출했어요"라고 하면 오히려 신뢰도가 떨어진다는 말도 함께.

과제는 선택한 서비스의 비즈니스 모델 분석과, 핵심 기능 하나의 스크린 플로우 분석이다. 그리고 거기서 찾은 페인 포인트를 휴리스틱과 연결하는 것 — 탐정의 마인드로. 내일부터는 리서치를 직접 설계하는 단계(대상 선정·스크리너·설문)로 넘어간다고 한다.

다짐 세 가지. 첫째, 발견 단계에선 답을 정하지 말고 단서부터 모은다. 둘째, "내가 불편했다"가 아니라 "사용자가 어디서 멈추는가"로 본다. 셋째, 페인 포인트는 휴리스틱의 언어로 적는다.

UX 용어 정리

오늘 쏟아진 방법론·프레임워크 용어들을 모아둔다.

용어뜻

더블 다이아몬드	발견→정의→구체화→산출로 이어지는 디자인 프로세스 모델
디스커버 / 디파인 / 디벨롭 / 딜리버	발견 / 정의 / 구체화 / 산출 (더블 다이아몬드 4단계)
STEEP 분석	사회·기술·경제·환경·정치의 거시 환경 분석
비즈니스 모델 캔버스 (BMC)	서비스의 가치·고객·수익 등을 9블록으로 정리하는 도구
SWOT 분석	강점·약점(내부)·기회·위협(외부)을 한 장으로 정리
3C 분석	자사·고객·경쟁사를 분석하는 미시적 도구
스크린 플로우	사용자가 목표까지 거치는 화면을 순서대로 캡처·정리한 것
페인 포인트	사용자가 불편을 겪거나 이탈하는 지점
혼란 지점	사용자가 무엇을 해야 할지 헷갈리는 모호한 지점
VOC (Voice of Customer)	리뷰·문의·SNS 등 사용자가 남긴 목소리
사용성 휴리스틱	경험적으로 검증된 사용성 평가 기준
닐슨의 10가지 휴리스틱	제이콥 닐슨이 정리한 대표적 사용성 평가 원칙
멘탈 모델	사용자가 기존 경험으로 형성한, 작동 방식에 대한 기대
O4O (Online for Offline)	온라인 데이터·기술로 오프라인 매장 가치를 높이는 모델
가치 제안 (Value Proposition)	서비스가 고객에게 주는 핵심 가치