데이터가 넘쳐나는 시대예요. 대시보드는 실시간으로 업데이트되고, 퍼널(Funnel)은 정확한 이탈 지점을 보여주고, 세션 리플레이(Session Replay)는 클릭과 스크롤을 밀리초 단위로 추적하며 사용자의 사용 행태를 세세하게 보여주죠. 겉으로 보면 사용자를 그 어느 때보다 잘 이해하는 것 같아요.
하지만 많은 팀에 “이 행동이 왜 일어났는가?”, “사용자가 실제로 뭘 하려고 했는가?”, “이 지표가 움직였을 때 현실 세계에서 무엇이 바뀐 건가?”과 같은 기본적인 질문에 대답하기 어려워 해요.
이 글에서는 UX 리서치를 통해 나온 관찰을 의미로, 의미를 설계 방향으로 전환하는 프레임워크인 엘리토 분석법(Elito Method)를 소개하고, 실무에서 어떻게 활용하는지 살펴볼게요.
1. 어떤 UX 리서치는 왜 의사결정에 영향을 미치지 못하는가
UX 리서치가 실패하는 직접적인 원인이 데이터가 부족해서인 경우는 드물어요. 대부분의 경우는 데이터가 제품에 적용할 수 있는 의미로 전환되지 못했기 때문이에요.
많은 팀이 이런 상황을 경험하죠.
- 리서치 리포트는 잘 만든 것 같은데, 의사결정은 그대로다
- 인사이트는 흥미롭게 들리는데, 다음에 뭘 해야 할지 아무도 확신하지 못한다
- “많이 배웠다”는 말 뒤에 침묵이 이어진다
문제는 보통 아래와 같이 UX 리서치에서 흔히 거치는 세 단계 사이에 있어요.
| 단계 | 무엇이 수행하는가 | 어디서 문제가 발생하는가 |
|---|---|---|
| 관찰(Observation) | 인용구, 행동, 관련 자료를 수집 | 데이터가 정리되지 않은 채로 너무 많은 세부 사항이 남겨짐 |
| 인사이트(Insight) | 규칙적인 패턴을 발견하고 의미를 정의 | 의미가 충분히 구체성을 띠지 않음 |
| 의사결정(Decision) | 제품이나 디자인에 관한 의사결정을 진행 | 뚜렷한 방향성이 보이지 않음 |
각 단계들이 별개의 활동으로 취급되면서 문제가 발생하기 시작해요. 이 간극은 노력의 문제가 아니에요. 각 단계와 다음 단계로 넘어갈 때 발생하는 의미의 번역의 문제예요.
1) 관찰이 관찰로만 남을 때
팀은 대개 무슨 일이 일어났는지 포착하는 데는 능숙해요.
- “참가자 세 명이 양식 작성을 중간에 포기했다”
- “사용자들이 설정 과정에서 탭을 자주 전환했다”
- “누군가 제출 버튼을 누르기 전에 오래 멈췄다”
이런 사실은 가치가 있어요. 하지만 사실만으로는 팀에게 무엇이 가장 중요한지 알려주지 못하죠.
해석을 위한 구조화된 방법이 없으면, 관찰은 쌓이기만 해요. 겉보기에는 중요하다고 보이지만, 실제 의사결정 논의에서는 명확한 이유를 설명할 수 없기에 우선순위가 뒤로 밀리기 시작하죠.
퍼즐 조각을 모으기만 하고 맞추지 않는 것과 같아요. 상자 안에 조각이 아무리 많아도, 조립하지 않으면 전체 그림은 보이지 않죠. 리서치 관찰도 마찬가지로, 해석이라는 조립 과정 없이는 의미가 드러나지 않아요.
2) 구조화되지 않은 복잡성의 숨은 비용
리서치 산출물은 종종 구조화되지 않은 복잡성(Unstructured Complexity)이라고 부를 수 있는 문제를 겪어요.
이런 경우에 발생하죠.
- 사용할 만한 데이터는 많은데 우선순위가 없다
- 인사이트가 정리되지만 의사결정에 직접 쓰이진 않는다
- 모두가 “흥미롭다”고 말하지만, 중요하다고는 느끼지 않는다
이렇게 되면 결국 인사이트는 슬라이드에 갇힌 순간적 지식으로 머무르게 돼요. 대화에서 언급되기는 하지만, 의사결정에 영향을 미치지는 못 하죠.
구조화되지 않은 복잡성을 비유하면, 도서관에 책이 가득하지만 분류 체계가 없는 상태와 같아요. 원하는 정보가 분명히 어딘가에 있지만, 찾아서 활용하는 데 너무 많은 에너지가 들어요. 리서치 결과도 구조 없이 쌓이면 같은 문제가 생기죠.
3) “많은 것들을 보긴 했는데, 그래서 뭘 해야 하죠?”
많은 분들이 UX 리서치를 한 후 이런 생각이 많이 들었을 거에요. 이 느낌이 들었다면, UX 리서치에서 나온 데이터들이 의미있게 연결되는 ‘종합(Synthesis’)이 충분히 이루어지지 않았다는 가장 분명한 신호이기도 하죠.
종합 단계에서 가장 어려운 부분은 반복되는 패턴을 찾는 게 아니에요. 다음과 같은 두 가지 질문에 답하는 거죠.
- 이 관찰 데이터가 왜 중요한가?
- 이 관찰 데이터가 제품 방향이나 디자인 방향에 어떤 의미를 가지는가?
바로 이 지점이 엘리토 분석법(Elito Method)이 명시적으로 만들고자 하고자 하는 것들이에요.
“많이 봤는데 뭘 해야 하죠?”라는 질문을 비유하면, 여행에서 수백 장의 사진을 찍고 돌아온 뒤 “어떤 사진을 앨범에 넣지?”라고 고민하는 것과 같아요. 사진이 많을수록 선택은 오히려 더 어려워지죠. 핵심은 찍는 게 아니라, 어떤 사진이 어떤 이야기를 하는지 해석하는 과정이에요.
2. 엘리토 분석법이란= 무엇인가
엘리토는 팀이 리서치 관찰을 실행 가능한 설계 원칙으로 전환하도록 돕는 센스메이킹(Sense-making) 프레임워크예요.
더 예쁜 리서치 요약을 만드는 게 목적이 아니에요. 데이터를 해석할 때 “무엇이 일어났는가”에서 “무엇을 의미하는가”를 거쳐 “다음에 무엇을 해야 하는가”로 이동하며 까다로운 부분을 가시화하는 게 목적이죠.
1) 의사결정을 돕는 의미로 전환하는 것이 어려운 이유
대부분의 팀은 리서치가 끝나면 자연스럽게 제품에 대한 의사결정을 돕는 인사이트가 나올 것이라는 암묵적 기대가 있어요.
하지만 현실에서 리서치는 의사결정에 필요한 기초 데이터(Input)을 만들어내지, 그 자체로 의사결정을 해결해주진 않아요.
기초 데이터와 의사결정 단계 사이에서 팀은 의미를 뾰족하게 만드는 작업을 해야 해요.
- 어떤 신호가 의미 있는지 판단하기
- 행동이 왜 일어났는지 해석하기
- 가치와 동기를 추출하기
- 팀이 이해할 수 있는 설계 방향으로 번역하기
이 단계가 명시적이지 않으면, 다음과 같은 불상사들이 일어나죠.
- 가장 목소리 큰 의견이 이긴다
- 팀은 만들기 쉬운 것을 찾는다
- 이해관계자가 자기 주장에 맞춰 데이터를 해석한다
- 리서치가 의사결정 도구가 아니라 “끼워맞추기 위한 근거”가 된다
엘리토 분석법은 팀이 의미에 대한 추론을 외부화하도록 강제해서 이 편향을 방지하도록 도와줘요.
2) 분석과 종합의 차이
많은 혼란이 “분석(Analysis)”과 “종합(Synthesis)”을 같은 의미로 쓰는 데서 나와요.
| 단계 | 무엇을 하는가 | 일반적인 산출물 |
|---|---|---|
| 분석(Analysis) | 정보를 분류하여 묶음으로 나눈다 | 메모, 태그, 클러스터, 테마 |
| 종합(Synthesis) | 묶음들을 재조합하여 의미와 방향을 만든다 | 원칙, 컨셉, 우선순위 |
분석은 이해를 돕고, 종합은 결정을 도와요.
많은 팀이 분석에서 멈추는 이유는 분석이 객관적으로 느껴지기 때문이에요. 메모를 클러스터링하고, 테마에 라벨을 붙이고, 언급 횟수를 세는 것은 모두 이성적이고 원칙적으로 보이거든요.
하지만 종합에는 해석이 필요해요. 해석은 판단을 수반하기 때문에 위험하게 느껴질 수 있죠. 엘리토가 유용한 이유는 다음과 같은 중요한 점을 인정하기 때문이에요.
- 해석 없이는 의사결정에 도달할 수 없다
- 목표는 판단을 피하는 게 아니다
- 목표는 판단을 더 합리적이고, 투명하고, 공유 가능하게 만드는 것이다
3) 엘리토가 답하도록 돕는 진짜 질문
팀은 종종 관찰을 한 후 해석과 종합을 거치지 않은 채 바로 기능을 만드려고 뛰어들어요.
- “사용자가 온보딩(Onboarding)을 이탈했으니 툴팁을 넣자”
- “필터에서 어려워했으니 UI를 재설계하자”
- “고객이 내보내기를 요청했으니 내보내기를 만들자”
때로는 이런 해결책이 맞기도 해요. 하지만 대부분의 경우에는 사용자의 진짜 동기를 놓치는 피상적인 처방이 되는 경우가 많아요.
엘리토는 단순한 질문을 중심으로 설계되었어요.
“이 관찰이 왜 중요하고, 그래서 우리는 무엇을 해야 하는가?”
이 질문은 당연해 보이지만, 구조화된 방식으로 답할 수 있는 경우는 드물어요.
엘리토는 관찰에서 해결책을 성급하게 만드는 것을 멈추고, 의미있는 의사결정을 위한 추론 과정을 가시화해요.
- 실제로 무엇을 관찰했는가?
- 왜 중요할 수 있는가?
- 그 행동 아래에 어떤 가치가 있는가?
- 어떤 컨셉이나 원칙이 설계 반응을 안내해야 하는가?
- 팀이 이해할 수 있도록 돕는 기억에 남는 프레이밍은 무엇인가?
탐정이 사건을 해결하는 과정과 같아요. “무엇을 발견했는가”(증거) → “왜 의미 있는가”(추론) → “범인의 동기는 무엇인가”(가치) → “어떤 수사 방향을 잡을 것인가”(컨셉). 각 단계를 건너뛰면 오판의 위험이 커지죠.
4) 이름의 유래
엘리토 분석법은 “엘리의 도구함(Eli Toolbox)”에서 이름을 따왔어요. 학술적 HCI(Human-Computer Interaction) 분야에서 엘리 블레비스(Eli Blevis)가 주도한 연구와 관련이 있고, 이후 2000년대 초반 트라이시 왈리그(Trysh Wahlig), 마거릿 알루츠(Margaret Alrutz), 벤 싱어(Ben Singer) 같은 협력자들의 디자인 리서치 프로젝트를 통해 발전했어요.
5) 엘리토 분석법의 산출물
엘리토를 잘 활용한다면 다음과 같은 두 가지 산출물을 만들어 낼 수 있을거예요.
- 기능 하나에 국한되지 않고 여러 기능에 적용할 수 있는 설계 방향
- 트레이드오프(Trade-off)를 더 쉽게 만드는 공유된 언어
“사용자가 X를 원한다”로 끝나는 대신, 이런 문장에 가까운 결론이 나오죠.
- “사용자는 설정 과정에서 통제감을 느끼길 원하므로, 되돌릴 수 있는 행동과 명확한 진행 신호를 우선시해야 한다”
- “사람들은 지연을 불확실성으로 해석하므로, 작업이 백그라운드에서 진행 중일 때도 시스템 상태를 가시적으로 설계해야 한다”
UI나 기능과 같은 해결책 중심적 결과물이 아니라, 의사결정의 기준점(Decision Anchor)이 만들어지는 거에요.
3. 엘리토 분석법의 5개 레이어
엘리토 분석법은 종합(Synthesis)을 다섯 개의 구분된 계층으로 나눠요. 각 계층은 서로 다른 질문에 답하고, 추상화 수준을 한 단계씩 높이죠. 각 계층은 건너뛰지 않는 규율과도 같아요
| 레이어 | 핵심 질문 | 산출물 유형 |
|---|---|---|
| 관찰(Observation) | 무엇이 일어났는가? | 사실적 진술 |
| 판단(Judgement) | 왜 중요한가? | 해석된 의미 |
| 가치(Value) | 사용자의 동기는 무엇인가? | 인간적 동인 |
| 컨셉/스케치(Concept/Sketch) | 어떻게 반응해야 하는가? | 설계 방향 |
| 핵심 비유(Key Metaphor) | 어떻게 기억할 것인가? | 공유된 언어 |
아래에서 각 계층을 간단한 예시와 함께 살펴볼게요. 여러 도구를 사용해서 반복적인 개인 업무를 관리하는 사람들을 리서치하는 팀을 예시로 들어드릴게요.
1) 관찰: 실제로 무엇을 보았는가
관찰은 해석이나 설명 없이, 보고 듣고 기록한 것만 기술해야 해요.
| 좋은 관찰 | 해석이 섞인 관찰 |
|---|---|
| “참가자가 같은 할 일 제목을 두 개 앱에 다시 적었다” | “참가자가 시스템에 혼란을 느꼈다” |
| “세 명의 사용자가 삭제 확인 전에 멈췄다” | “사용자들이 삭제에 불안을 느꼈다” |
| “할 일을 추가한 후 캘린더를 확인했다” | “할 일 목록을 신뢰하지 않았다” |
차이가 미묘하게 느껴질 수 있지만, 중요해요.
해석이 슬며시 들어오면, 이후 계층이 편향되거든요. 팀이 가정을 사실로 취급하기 시작하죠.
간단한 검증 방법이 있어요. “나는 ~을 보았다” 또는 “나는 ~을 들었다”를 문장 앞에 붙여도 자연스러우면, 유효한 관찰일 가능성이 높아요.
2) 판단: 사용자가 왜 그렇게 행동했다고 생각하는가
판단은 해석이 허용되고 권장되는 계층이에요. 여기서 관찰이 “무엇이 일어났는가”에서 “왜 이것이 중요할 수 있는가”로 전환돼요.
개인적 의견이 아니라, 관찰에 근거한 합리적 해석이에요.
| 관찰 | 판단 |
|---|---|
| “사용자가 같은 할 일 제목을 두 앱에 다시 적었다” | “할 일이 맥락에 따라 머릿속에서 재구성되고 있다. 사람들이 할 일을 고정된 객체로 인식하지 않는다는 신호다” |
| “참가자들이 삭제 전에 멈췄다” | “삭제가 위험하게 느껴진다. 복구 방법이 불분명하거나 되돌릴 수 없기 때문일 가능성이 높다” |
이 단계에서 유용한 점검 질문이 있어요.
- 이것이 사실이라면, 사람들의 사고나 행동 방식에 대해 무엇을 암시하는가?
- 사용자에 대한 어떤 기존 가정에 도전하는가?
판단에 관한 진술은 논쟁 가능하지만 방어 가능해야 해요.
- 아무도 반대할 수 없으면, 너무 피상적인 거예요
- 모두가 반대하면, 근거가 부족할 수 있어요
3) 가치: 사용자를 진짜로 움직이는 것은 무엇인가
이 레이어는 기능과 워크플로에서 벗어나 인간적 동기(Human Motivation)로 이동해요.
가치는 프로덕트가 제공하는 것이 아니에요. 사람이 진심으로 신경 쓰는 것이죠.
이 단계에서 빠지기 쉬운 함정이 있어요.
- 기능적 니즈를 가치로 기술하는 것
- “있으면 좋은 것”과 “감정적으로 격렬한한 것”을 혼동하는 것
비교해볼게요.
| 가치에 미치지 못하는 진술 | 맥락을 반영한 명확한 가치 |
|---|---|
| “사용자는 더 빠른 할 일 생성을 원한다” | “동시에 여러 캠페인을 운영하는 마케팅 매니저는 할 일이 또 다른 스트레스 원인이 되기 전에 빨리 내려놓고 싶어한다” |
| “사람들은 단계가 적길 원한다” | “회의 사이를 오가는 재택 근무자는 도구 관리가 아닌 실제 업무에 정신적 에너지를 아끼고 싶어한다” |
| “사용자는 더 나은 정리를 원한다” | “주니어 컨설턴트는 특히 마감이 다른 사람에게 달려있을 때, 중요한 것을 빠뜨리지 않고 있다는 안도감을 원한다” |
오른쪽이 달라진 것은 표현이 아니라 관점이에요.
- 주어가 더 이상 추상적인 “사용자”가 아니다
- 가치가 상황, 압력, 위험에 연결되어 있다
- 동기가 행동이 왜 존재하는지 설명한다
4) 컨셉 또는 스케치: 의미를 방향으로 전환하기
이 단계에서 팀은 화면이나 흐름을 바로 만드려고 하는 충동을 많이 느껴요.
엘리토 분석법에서 컨셉은 UI 아이디어가 아니에요. 미래의 의사결정을 제약하는 설계 관점(Design Stance)을 만드는 단계에요.
강한 컨셉은 좋은 의미에서 불편해야 해요. 특정 해결책을 배제할 수 있어야 하거든요.
여러 도구를 사용해서 반복적인 개인 업무를 관리하는 사람들을 리서치하는 팀 예시로 한번 다시 돌아가볼게요.
예시: “이게 왜 내 잘못처럼 느껴지지?”라고 느끼는 업무자
- 맥락
– 사용자 역할: 프리랜서 디자이너
– 주요 환경: 클라이언트 의존적 업무
– 상황: 피드백을 기다려야 진행 가능 - 관찰
– 할 일이 며칠째 “오늘”로 남아있다
– 사용자가 반복적으로 일정을 미룬다.
– 인터페이스가 “기한 초과”로 표시된다 - 실제 상황
– “피드백 없이는 진행할 수 없는데, 앱은 내가 실패한 것처럼 보이게 한다.
– 이걸 보면 목록 자체를 열기 싫어진다” - 근본 가치
– 이 사용자는 시스템이 개인의 태만과 외부 의존성을 구분해주길 원한다
컨셉 (설계 방향)
“통제할 수 없는 지연을 개인의 실패로 프레이밍하지 말라”
이 컨셉은 다음에 영향을 미쳐요.
- 시간이 어떻게 표현되는가
- 지연에 어떤 언어가 사용되는가
- 상태가 비난을 전달하는가 맥락을 전달하는가
어떻게 구현할지는 말하지 않아요. 시스템이 무엇을 나타내고 나타내면 안 되는지 말하는 거예요.
5) 핵심 비유: 팀이 기억하는 한 문장
마지막 계층인 핵심 비유는 리서치 결과를 공유된 기억으로 번역해요.
비유는 기억에 잘 남아요. 의미를 팀이 느낄 수 있는 형태로 압축하기 때문이죠.
좋은 핵심 비유는 기발한 게 아니에요. 자가진단을 유도(Diagnostic)해요. “우리가 이것을 위반하고 있는 건 아닌가?”라고 팀이 스스로 묻도록 돕거든요.
예시: “이게 왜 내 잘못처럼 느껴지지?”라고 느끼는 업무자
- 컨셉: 통제할 수 없는 지연을 개인의 실패로 여겨선 안 된다
- 핵심 비유: “기다림은 미루기가 아니다”
실무에서 이렇게 활용돼요.
- “이 라벨은 기다림을 미루기처럼 보이게 만들고 있어”
- “우리가 사용자에게 통제할 수 없는 것에 대해 비난하고 있는 건 아닐까?”
4. 엘리토 분석법이 가장 효과적인 상황
대부분의 종합(Synthesis) 도구처럼, 엘리토도 적절한 맥락에서는 강력하지만 맞지 않는 맥락에서는 답답하게 느껴질 수 있어요.
언제 사용할지 아는 것이 어떻게 사용하는지 아는 것만큼 중요하죠.
1) 리서치는 풍부한데 의미가 부족할 때
이런 상황은 보통 다음과 같은 리서치 이후에 발생해요.
- 생성적 사용자 리서치(Generative Research)
- 다이어리 연구(Diary Study)와 같은 종단 연구(Longitudinal Research, 장기간에 반복적으로 관찰하는 연구)
- 개방형 인터뷰
- 탐색적 현장 연구
이런 리서치 방법들을 수행한 이후에 보통 수십 개의 인용구, 많은 관찰, 그리고 여러 개의 그럴듯한 해석들이 많이 나올 거예요.
엘리토 분석법은 이 많은 데이터들을 수렴시켜 의미를 도출하도록 도와줘요.
어떤 인사이트가 “맞는지” 논쟁하는 대신, 팀은 이런 질문을 논의하게 되죠.
- 어떤 판단이 더 잘 뒷받침되는가
- 어떤 가치가 가장 핵심적으로 느껴지는가
- 어떤 컨셉을 설계의 중심에 놓여야 하는가
2) 기능이 아닌 설계 원칙이 필요할 때
기능 결정보다 더 지속적인 무언가가 필요한 순간이 있어요.
- 새로운 문제 영역에 진입할 때
- 기존 경험을 재정의할 때
- 여러 팀이나 화면에 걸쳐 설계 원칙을 통합해야할 때
엘리토 분석법은 다음과 같은 것들을 만들기 때문에 이러한 상황에서 효과적이에요.
- 미래 의사결정의 기준이 되는 원칙
- 하나의 화면을 넘어 확장되는 컨셉
- 팀이 스스로의 판단을 돕는 핵심 비유들
“이 기능을 추가할까?”라고 묻는 대신, 팀이 “이것이 우리의 핵심 방향과 부합하는가?”라고 묻기 시작하는 거예요.
3) 초기 단계이거나 문제를 재정의하는 단계일 때
엘리토는 제품이나 기능이 다루려는 문제 자체가 뚜렷하지 않은 상황일 때 특히 유용해요.
- 새로운 프로덕트나 서비스
- 사용자 행동의 큰 변화
- 오래된 기존 경험의 재구성
위와 같은 상황에서 성급하게 해결책을 만드는 것은 팀을 잘못된 가정에 고착시킬 수 있어요. 엘리토 분석법은 실제로 무언가를 만들기 전에 무엇이 중요한지 명확히 하도록 도와주죠.
마무리: 센스메이킹 도구로서의 엘리토
어느 시점이 되면 UX를 고도화하는 데에 필요한 고민의 성격이 달라져요. 더 많은 방법론을 아는 게 아니라, 복잡함을 더 빠르게, 그리고 다른 사람들과 함께 더 잘 이해하는 게 중요해지거든요.
대부분의 팀에게 부족한 것은 정보가 아니에요. 공동의 이해가 부족한 거예요.
엘리토가 도움이 되는 이유는 보통 암묵적으로 남아있는 사고를 외부화하기 때문이에요.
- 왜 한 관찰이 다른 관찰보다 중요한가
- 해석이 어떻게 방향으로 이어지는가
- 행동 아래에 어떤 가치가 자리 잡고 있는가
이 단계들에 이름을 붙이면, 팀이 서로 엇갈리는 대신 명시적으로 논의할 수 있게 돼요.
결과를 빠르게 무언가를 만들어야 한다는 생각에 화면, 흐름, 문서를 만들고 싶을 거에요. 하지만 의미가 제대로 정립 됐을 때 의사결정으로 이어질 수 있어요.