프로젝트에서 리서치 결과를 설득력 있게 전달하려면?
데이터의 정확도만큼이나 어쩌면 더 중요한 '개연성'
안녕하세요 멘토님! 저는 현재 서비스디자인을 공부하고 있는 2학년 대학생입니다. UX 관련 수업과 동아리 활동을 하며 사용자 리서치의 중요성을 많이 느끼고 있는데요, 막상 팀 프로젝트에서 리서치한 내용을 전달할 때는 제 의견이 잘 먹히지 않아 답답할 때가 많습니다.
특히 리서치 결과를 정리해서 발표할 때, 팀원들이 “그래서 이게 무슨 의미야?”, “이걸 왜 해야 해?”라고 반응하면 제가 뭔가 빠뜨린 건 아닐까 자꾸 고민하게 돼요. 리서치에 시간을 많이 쏟았는데도 실질적인 설득력이 떨어지다 보니 점점 자신감도 줄고, ‘내가 제대로 하고 있는 걸까?’ 싶기도 하더라고요.
멘토님은 UX 리서치를 통해 도출한 인사이트를 팀이나 클라이언트에게 설득력 있게 전달하기 위해 어떤 방식이나 스킬을 사용하셨는지 궁금합니다. 혹시 실무에서 잘 먹히는 리서치 전달 방식, 스토리텔링 방식이 있다면 알려주실 수 있을까요?
➥ 사용자 리서치의 중요성은 충분히 느끼고 있지만, 실제 팀 프로젝트에서 리서치 결과를 전달할 때 팀원들의 공감을 얻지 못해 답답함을 느끼고 있으시군요. “이게 무슨 의미야?”, “왜 해야 해?”라는 반응 앞에서 자신감이 떨어지고, 리서치 전달력의 부족함을 실감하고 계시네요. 실무에서 잘 먹히는 리서치 전달 방식이나 스토리텔링 방법이 궁금하다는 질문에 관해 답변드려 보겠습니다.
설득력 부족의 원인 분석
리서치 자체에 대한 문제도 있겠지만, 리서치가 잘 되었다는 가정 하에 결과가 팀원들에게 와닿지 않는 이유는 두 가지로 요약할 수 있습니다.
첫째, 사용자 목소리가 충분히 살아있지 않은 경우입니다. 즉, 사용자 본인의 말이나 생생한 맥락 없이 조사자가 요약한 문장만 던지면 듣는 사람은 그저 '주관적인 판단'처럼 느낄 수밖에 없습니다. 한마디로 전달의 문제일 수 있습니다. 조사는 잘했지만, 전달의 문제라면 어떻게 이를 효과적으로 전달할지 고민해보셔야 하는데, 그 방법은 지금처럼 많은 피드백을 수용하고 개선해서 다시 피드백을 받아보는 방법 외에 뾰족한 수가 없습니다.
둘째, 사용자 니즈와 제품 방향 사이에 구체적인 연결고리가 부족할 수 있습니다. 사용자 불편이야 많지만 이게 실제로 우리가 만든 서비스에서 어떻게 해결되어야 할지에 대한 해석이 빠지면, 그저 ‘문제 나열’로만 들립니다. "So what?"이라고 하죠? 실무에서는 이 해석의 다리 놓기가 가장 중요합니다. 즉, 아무리 올바른 인사이트와 맞는 소리를 해도 비즈니스 기여와 연결고리가 미약하면 힘이 부족하게 됩니다. 심지어는 방향 감각이 없다는 인식도 줄 수 있습니다.
사용자 목소리의 생생한 전달
저는 실무에서 리서치 내용을 전달할 때 가능하면 사용자 인용을 직접 활용하려고 노력합니다. 단순히 "A라는 니즈가 있다"라고 말하기보다는, "사용자 B는 인터뷰에서 ‘요즘은 앱 열어보는 것조차 스트레스예요’라고 말했습니다"처럼 구체적인 문장으로 전달하면 효과적입니다.
나아가 인용과 함께 당시의 행동이나 맥락(예: 언제, 어떤 상황에서 그런 말을 했는지)을 붙여 설명하면 '한 문장의 진위'가 아닌 '경험 전체의 흐름'으로 받아들여져 설득력이 높아집니다. UX 포트폴리오를 만들 때에도 마찬가지입니다. 이러한 조치를 저는 프로젝트에 의미 있는 '현장감'을 부여했다고 말합니다. 이 현장감을 일을 실제로 수행한 인상을 주는 것은 물론이고, 리서치 대상이 실존 인물로 느껴지고 공감도가 높아집니다.
인사이트 도출과 설계의 연결
리서치 결과를 보여주는 것만으로는 부족하고, 그것이 ‘그래서 우리 서비스에 어떤 함의가 있는지’까지 해석이 함께 따라가야 합니다. 말했듯이 말이 되고 맞는 이야기를 하는 것만으로는 부족하다는 것입니다.
예를 들어 “대부분의 사용자가 OO을 불편해했다”는 사실을 말한 뒤, “이것은 곧 우리가 이 기능을 더 잘 설계해야 한다는 시사점이며, 현재 서비스 UI는 이러한 니즈를 충족시키지 못한다”는 식의 설명이 따라와야 합니다. 어느 상황에나 접목 가능한 명제는 엣지가 없습니다. 지금 우리가 다루는 제품이나 서비스의 현실적 문제를 꺼내 들어야 공감을 얻을 수 있습니다.
이렇듯 맥락과 긴밀한 화법과 설명 방식은 실무에서 설득력을 높게 만드는 중요한 기술입니다. 단순히 데이터가 많고 그로부터 다채로운 인사이트를 얻었다는 것으론 역설적으로 부족하단 것입니다. 그보단 그 데이터를 팀이 이해할 수 있게 '번역'해주는 것, 그리고 우리가 할 일과 매칭시켜 공감을 얻는 것, 이것이 UX 리서처 혹은 UXer가 수행해야 할 역할이라고 생각합니다.
스토리텔링 구조의 중요성
저는 리서치 결과를 전달할 때 구조적인 스토리텔링을 많이 활용했습니다. 흔히 말하는 '기-승-전-결'일 수도 있겠지만, 사용자 여정을 따라가며 불편, 감정, 행동을 엮어가는 구조입니다.
“사용자는 이런 목표를 갖고 이 서비스를 시작했으나, 이런 순간에 좌절을 경험했고, 이로 인해 서비스 이탈이 발생했다”는 식의 흐름을 만들어 주면, 단순 수치나 이슈 나열보다 훨씬 몰입도가 높아집니다. Journey Map이라고 볼 수 있는데, Journey Map이란 프레임워크를 사용했는지 여부도 물론 중요하지만 중요한 것은 내러티브입니다.
특히 실무에서 제품팀이나 개발팀과 협업할 때 이런 사용자 중심 시나리오 기반 리서치 전달이 매우 효과적이었습니다. User Journey는 이러한 내러티브를 엮는 하나의 예입니다. 프로젝트가 성격과 프로세스 맥락에 따라서 담당자는 얼마든지 더 효과적인 내러티브 설계에 이바지할 수 있습니다.
시각 자료와 메타 정보의 활용
가능하면 리서치 발표 자료에도 ‘텍스트만 나열’ 하지 않고 시각적 자료를 적극 활용합니다. 예를 들어 인사이트별로 대표 사용자의 여정, 감정 곡선, 인터뷰 발언 요약 등을 넣고, 전체 리서치 목적 및 프로세스를 맨 앞에 간결하게 정리합니다. 듣는 사람 입장에서 “이게 어떤 맥락에서 나온 말이지?”라는 의문이 들지 않도록 하기 위한 장치입니다. 또 아무래도 보고를 하거나 짧은 시간에 전달을 해야 할 경우 시각자료보다 효과적인 것은 없습니다.
그렇다고 문서를 치장하고 꾸미는데 너무 많은 시간을 쏟는 것은 주객전도겠죠. 여력이 되는 한도 내에서 행해야 하고, 그런 의미에서 가장 쉽고 명확한 방식이 AS-IS/TO-BE 구성이라고 생각합니다. 결국 리서치의 ‘근거’를 강조하되, ‘무슨 말인지 직관적으로 이해되게’ 보여주는 것이 관건입니다. 여건이 충분하다면 프로토타이핑을 통해 실제 구현감을 느낄 수 있도록 한다면야 금상첨화일 것입니다.
실무의 경험에서 느낀 변화
사실 저 역시 처음엔 리서치가 답이라고 믿었고, “이런 결과가 나왔으니 당연히 반영해야지”라는 태도를 취하곤 했습니다. 하지만 시간이 지나면서 리서치 결과는 ‘권위’가 아니라 ‘이해를 위한 매개’라는 점을 절실히 깨달았습니다. 리서치 만능주의는 역설적으로 때로 필요한 UXer의 재치나 번뜩임을 말살하기도 합니다. 데이터가 없이는 아무것도 선택도 결정도 못하는 것도 결코 유능하다고 할 수 없기 때문입니다. 실전에는 데이터가 없는 경우가 더 많기 때문이죠.
팀원들이 리서치 결과를 설득력 있게 느끼지 못하는 것은, 내용의 부족도 있겠지만 대체로 해석과 연결의 부족이라고 생각합니다. 어차피 리서치는 완벽할 수 없습니다. 우리가 논문을 쓰는 게 아닌 이상 데이터를 제시하는 것이 전부가 될 수 없습니다. 그보단 실무적인 쓸모를 설계하는 것, 그들이 공감할 수 있는 ‘사람 이야기’로 풀어주는 것이 진짜 전달이고 설득이었습니다.
멘티님의 고민은 매우 유효하며, 실무에서도 자주 부딪히는 벽입니다. 리서치라는 결과물 자체보다도, 그것을 누가 어떻게 전달하느냐에 따라 의미가 달라집니다. 결과를 전달할 때는 단순 요약이 아니라 ‘사용자가 어떤 상황에서 무엇을 느꼈는가’라는 정황 설명과, ‘그래서 우리가 뭘 바꿔야 하는가’라는 제안까지 포함되어야 합니다.
이것이 리서치를 통한 설득력의 핵심이라고 생각합니다. 부족하더라도 지금부터 ‘결과를 어떻게 전달할지’를 계속 고민하고 실험해 보는 것이 실무 감각을 키우는 지름길이 될 것입니다. 저도 그렇게 조금씩 변화를 만들어갔으니까요.
