다양한 직군과 UX 관점을 맞추는 방법
에듀테크 업계에서 5년 차 프로덕트 디자이너로 일하며 깨달은 점이 있습니다. 우리가 마주하는 진짜 벽은 기술적인 한계가 아니라, 마케팅, 운영, 사업부 등 UX가 생소한 직군과 같은 방향을 바라보게 만드는 일이라는 점입니다.
“이렇게 하면 사용자 경험이 떨어집니다.”라는 말만으로는 생각보다 설득력이 크지 않습니다. 상대방에게는 논리적인 근거라기보다 개인의 의견이나 취향처럼 들리기 쉽기 때문입니다.
어쩌면 특별한 방법은 아닐지도 모르지만, 일을 하며 경험했던 타 직군을 설득하는 과정과 그때 유용했던 방법들을 정리해 보려고 합니다.
의견이 팽팽하게 맞설 때, 논쟁을 끝내는 가장 빠른 방법은 기준점을 '우리'가 아닌 '사용자'로 옮기는 것입니다.
완벽한 환경이 아니어도 괜찮습니다. 모수가 적어도 상관없습니다.
저 같은 경우에는 실제 서비스 타깃인 아이들 몇 명과 함께 진행한 간이 테스트(Usability Test) 영상을 회의실에서 보여주었더니, 설득이 훨씬 쉬워졌습니다. 버튼을 찾지 못해 아이가 머뭇거리는 30초의 영상은 PPT 10장의 논리보다 훨씬 강력한 설득력을 갖습니다.
이때 디자이너가 Framer 같은 프로토타이핑 툴에 능숙하다면 좋습니다.
개발 전에도 실제 사용 흐름을 자연스럽게 재현할 수 있기 때문입니다. 비디자인 직군 동료들에게 이 시뮬레이션은 단순한 시안이 아니라, 눈앞에 구현된 실제 서비스로 다가오며 강력한 의사결정의 근거가 됩니다.
데이터를 가져가는 것은 중요하지만, 숫자 그대로 전달하면 비개발 직군에게는 잘 와닿지 않는 경우가 많습니다. 예를 들어 “전환율이 12% 하락했습니다” 라는 말보다 히트맵 한 장이 훨씬 직관적으로 상황을 이해시키기도 합니다.
그래서 저는 데이터를 설명할 때 숫자보다 시각화를 함께 보여주려고 합니다.
제가 자주 활용하는 방식은 다음과 같습니다.
클릭 히트맵은 사용자가 화면 어디에 머물고 무엇을 누르는지 한눈에 보여줍니다.
CTA(Call to Action)가 아닌 곳에 클릭이 몰리거나, 버튼이 아닌 텍스트를 버튼처럼 누르는 행동이 발견되면 구조적인 문제를 비교적 쉽게 확인할 수 있습니다.
이런 자료를 함께 보여주면 단순히 “디자인이 어색하다”는 의견이 아니라
사용자가 실제로 혼란을 겪고 있다는 근거로 이야기할 수 있습니다.
퍼널 분석은 사용자가 어떤 단계에서 이탈하는지 시각적으로 보여줍니다.
단순히 “결제 단계에서 이탈이 많다”고 말하는 것보다,
단계별로 좁아지는 퍼널 그래프를 함께 보여주면 문제가 발생하는 지점을 훨씬 쉽게 이해할 수 있습니다.
이렇게 이탈 구간이 명확해지면 팀 전체가 같은 문제를 바라보며 개선 방향을 함께 논의하기 쉬워집니다.
설득이 쉽게 되지 않을 때는 방향이 완전히 다른 두 가지 시안을 만들어 데이터로 비교하기도 합니다.
예를 들어 정보 밀도를 높인 버전과 단순화한 버전을 각각 제작해 실제 사용자 반응을 확인하는 방식입니다.
사용자의 행동 데이터를 통해 어떤 접근이 더 나은지 확인하면 논의가 훨씬 빠르게 정리되는 경우가 많습니다.
무엇보다 중요한 점은 전문적인 설명 없이도 한눈에 이해할 수 있는 형태로 보여준다는 것이라고 생각합니다.
UX 용어를 그대로 사용하면 오히려 설명이 더 어려워질 때가 있습니다.
내용보다 낯선 단어 자체에 먼저 막히기 때문입니다.
그래서 저는 이론이나 용어를 그대로 말하기보다 사용자가 겪는 상황과 결과 중심으로 설명하려고 합니다.
같은 내용이라도 표현을 조금 바꾸면 이해도가 훨씬 높아집니다.
직군마다 중요하게 보는 포인트도 조금씩 다릅니다.
예를 들어 개발자에게는 구현 복잡도나 유지보수 관점으로 설명하고, 사업이나 운영 팀에게는 이탈률이나 사용 흐름과 연결해 이야기하면 맥락이 더 빠르게 전달됩니다.
결국 중요한 것은 UX 용어를 정확히 말하는 것보다, 상대가 이해할 수 있는 방식으로 설명하는 것이라고 생각합니다
여러 방법을 써도 설득이 되지 않는 경우가 있습니다.
UX 관점에서는 필요하지 않다고 판단한 기능이지만, 사업부나 다른 부서의 이해관계 때문에 포함해야 하는 상황입니다. 이럴 때 “UX가 나빠집니다”라는 말만 반복하면 논의만 길어지기 쉽습니다. 그래서 저는 데이터를 기준으로 타협점을 제안하는 방식을 사용했습니다.
필요하지 않다고 판단한 기능들의 실제 사용 데이터를 확인해 보니 해당 기능들의 사용률이 5% 미만이었습니다. 이 데이터를 바탕으로 “없애자”가 아니라 “구조를 바꾸자”는 방향을 제안했습니다.
기능을 완전히 제거하는 대신, 사용 빈도가 낮은 기능들을 한곳에 모은 ‘모아보기’ 메뉴를 만들었습니다. 메인 화면에는 자주 사용하는 기능만 남기고, 나머지는 탭 하나로 접근할 수 있도록 정리했습니다.
부서 입장에서는 기능이 유지되고, 사용자 입장에서는 화면 복잡도가 줄어드는 구조였습니다.
결국 설득은 누가 맞는지를 증명하는 과정이 아니라, 팀이 사용자와 같은 방향을 바라보게 만드는 과정이라고 생각합니다.
제가 경험한 많은 설득은 의견보다 먼저 데이터를 꺼내는 것에서 시작되었습니다.