당신은 아이디어를 포기할 수 있는 용기가 있나요?

사용자는 항상 옳지만 그들을 해석하는 나는 항상 옳지 않을 수 있으니까요

Summary.

내 아이디어를 논리적으로 주장할 수 있는 자신감만큼 내 아이디어가 틀릴지도 모른다는 가능성도 감당할 수 있는 용기 있는 디자이너가 되시길 바랍니다.

사람은 미워하지 않으려고 노력하지만, 지금도 이름만 들어도 살짝 소름이 돋는 분이 한 명 있습니다. 바로 제가 전 직장에서 담당한 서비스의 기획팀 리드를 맡으신 분인데요, 이분은 보고나 협업부서와의 미팅에서는 모호하지만 장황한 언어구사가 특기였고, 자기 팀원들에게는 자신의 스타일대로만 기획하길 강요하는 권위적인 독불장군이었으며, 유관부서에게는 협의도 전에 상부에 본인이 원하는 일정으로 보고를 한 후 서비스 개발을 보채는 그런 사람이었습니다. 하루는 기획 & UX부서의 미팅이 있었는데요, 여느 때와 같이 그 그룹장님이 '우리 서비스는 ooo 해야 한다'면서 설교를 한참 하고 있는 중에 제가 제 성질을 견디지 못하고 그분에게 대들었던(?) 에피소드가 있습니다. 하하하 이 거지 같은 성격은 어쩌면 좋으니

나: 그룹장님. 질문 하나만 하겠습니다. 작년부터 이 서비스를 담당해온 사람으로서, 저는 도대체 우리 서비스의 핵심 가치제안이 무엇인지 모르겠습니다. 그룹장님께서는 올해 초 서비스를 전면 개편을 한다고 상부에 보고하신 이후 약 5개월 동안 우리 서비스의 핵심가치에 대한 입장을 3번이나 수정하셨습니다. 처음에는 SMB(Small & Medium Business) 점주들이 본인이 원하는 마케팅을 간단하게 '구매'할 수 있는 신개념 플랫폼을 만든다고 하셨습니다. 그리고 얼마 전에는 매장 점주들이 우리 서비스를 통해 마케팅을 '관리'할 수 있는 플랫폼을 만든다고 하셨고요, 그리고 오늘은 우리 서비스는 고객들과의 '관계'를 데이터를 통해 구축하고 관리하는 플랫폼이라고 하셨습니다. 이젠 만드는 사람마저도 모호한 서비스 핵심 가치제안을 고객들이 공감할 수 있을 것 같지가 않습니다. 도대체 저희가 집중해야 하는 핵심 경험은 어떤 것입니까?

그룹장: (피식 웃으며) 3가지 다입니다.

나: 서비스를 론칭하면서부터 3가지 핵심 가치제안을 가지고 접근을 하기에는 너무 무리라고 생각하시지 않습니까? 한 가지 방향성만 집중해서 경험을 제공해도 지금은 벅찰 것 같은데요...

그룹장: (한심하다는 듯이 한숨을 살짝 내 쉬며) 가치제안이 세 가지라고 하는 게 뭐가 그렇게 힘든 거죠?

나: 첫 번째 '구매'라는 경험을 놓고 봤을 때는, 우리가 대상으로 하는 점주들은 마케팅 상품을 자체적으로 PC나 앱을 통해 온라인으로 '구매'한다고 하는 상당히 새로운 경험이 직관적으로 받아들여지지 않을 것 같은 우려가 있습니다. 두 번째 '관리'라고 하는 맥락은, 우리가 제한적으로 제공하는 마케팅 툴을 사용하는 유저가 우리가 기대하는 만큼의 의존도를 보일지 그것이 우려이고, 마지막으로 세 번째 '관계'를 데이터를 통해 구축하고 관리하는 맥락에서는 저희 UX팀에서 했던 리서치를 보시면 우리 대상 유저들은 데이터에 상당히 친숙하지 않은 그룹이라는 시사점이 있었습니다. 각각 가치제안에 대해서도 검증을 해야 할 것 같은 상황에서 3가지를 한꺼번에 집중하는 것이 우리 서비스의 정체성을 너무 처음부터 모호하게 제공하는 거 같아 우려가 됩니다.

그룹장: 그래서 Ji매니저가 주니어라고 하는 겁니다.

나: 네...?

그룹장: 그렇게 시장에 대한 인사이트가 없으니 주니어라고 하는 겁니다. 제가 마케팅 서비스를 10년 이상 영업을 하면서 이 시장에 대한 인사이트가 저보다 많은 사람이 없는데, Ji매니저는 아직도 학교에서 배운 현실성 떨어지는 어설픈 접근방식들로 일을 하려고 하니까 그게 참 안타깝네요. 마케팅에 있어서 궁금한 게 있으면 저한테 그냥 다 물어보세요. 제가 다 대답해드릴게요. 굳이 돈이랑 시간 아깝게 리서치 같은 거 하실 거 없이 저한테 그냥 다 물어보세요- 아까 전에 세 가지 가치제안이 왜 필요하냐고 했죠? 제가 설명드릴 테니까 잘 들어보세요...(이하 생략)

그렇게 그룹장님이 한참 설교(?)를 하는 동안 사실 표정관리가 안되었습니다. 다시 한번 말을 자르고서라도 그룹장님의 그 오만함에 대해 태클을 걸고 싶었고 그룹장님이 지금까지 상대해왔던 대기업들과 골목상권의 가게 사장님들은 그 물질적이고 심리적인 환경(Context)과 마케팅에 대한 이해도의 수준이 완전 다른 대상자들이라고 하는 부분을 이야기하고도 싶었습니다. 하지만 벌써 UX팀과 기획팀과의 전체 미팅에서 가장 막내인 저의 돌발행동이 저의 팀장님과 특히 제가 너무 존경하는 사수님을 곤란한 입장으로 몰고 가는 것 같아 함구할 수밖에 없었죠. 그렇게 그때 저의 발언과 질문들은 '파이팅 넘치는 주니어 매니저의 당돌한 객기'로 상황이 정리가 되었고 너무나도 당연하게 묻혀버리고 말았습니다. 그렇게 3가지 가치제안을 가지고 세상에 얼굴을 드러낸 그 마케팅 서비스는 런칭한지 6개월이 채 되지 않아 앱 스토어에서 자취를 감추었습니다.

두 가지 레슨과 또 한 가지 새로운 레슨

위에 소개한 전 직장에서의 에피소드는 저에게 두 가지 큰 교훈을 주었습니다. '아무리 경험이 쌓여도 내 주관적 경험에 눈이 멀어 사용자의 경험을 확신하지 않겠다'는 교훈과 '중요한 경험일수록 최대한 증명할 수 있도록 노력하겠다'라는 교훈이 바로 그 두 가지였습니다.

저 두 가지 교훈을 얻은 지 그리 오랜 시간이 지나지 않은 지금 회사에서는 서비스에 대한 경험을 기획하고 디자인할 수 있는 입장이 되었습니다. 그리고 저는 서비스에 추가적인 경험을 제공하려고 하거나 기존 기능을 수정하려고 할 때 아래와 같은 단계를 거쳐 일하고 있습니다.

1. Consumer Research 리뷰: 이 리서치는 제가 지금 일하는 회사에 오자마자 약 2개월 동안 진행했던 UX Research + 제 여가시간동안 진행했던 추가적인 리서치를 통해 완성한 persona들과 각 persona별 인사이트들을 리뷰하는 단계입니다.

2. Target Consumer를 위한 Ideation: 위의 리서치에서 알게 된 여러 persona 중 이번 기능은 누구를 위한 기능이며, 그렇다면 해당 기능이 어디에 어떤 방식으로 표현되어야 할지 아이디어를 고민하는 단계입니다.  

3. 이사님의 피드백 수렴 후 Iteration: 상~~~당히 까다로운 이사님의 날카로운 피드백을 수렴하면서 기능을 수정하고 동시에 해당 기능을 얼마나 구체적으로 '증명'할 것인지에 대한 기준도 정립하는 단계입니다.  

4. 개발 및 테스트: 말 그대로 디자인한 기능을 개발하고 QA 하는 단계입니다. 이때는 처음 의도했던 그 경험이 제대로 잘 구현이 되었는지를 검증하는 단계입니다.

위의 프로세스는 제가 지금 일하는 이 회사에 입사하면서부터 제가 구축을 한 프로세스입니다. 같은 프로세스를 적용해서 지금 현재 주니어 디자이너와도 조그마한 UX프로젝트를 하나둘씩 담당하고 있고요, 개인적으로는 UX를 중심으로 설계된 것 같아서 나름 뿌듯하기도 한 프로세스입니다. 하지만 해당 프로세스로 일을 하기 시작하면서 발견하게 된 한 가지 중요한 레슨이 있는데요, 그것은 바로

내 아이디어를 포기할 수 있는 용기

입니다.

내 아이디어를 냉정하게 바라볼 수 있는 용기

위에 언급한 매우 UX중심적인 프로세스로 일을 하게 되면 내가 열심히 연구하고 고민한 유저들에 대한 인사이트를 기반으로 아이디어를 도출하게 됩니다. 유저에 대한 이해도와 인사이트가 많을수록 그만큼 다양하기도 하고 색다른 아이디어가 나오기도 하죠. 하지만 반면에 그렇게 깊은 고민을 통해 귀하게 얻게 된 아이디어는 그만큼 내려놓기도 쉽지가 않다는 걸 알게 되었습니다. 저는 저 위의 프로세스 중 3번째 단계인 이사님의 피드백을 얻는 단계에서 어설픈 논리나 막연한 인사이트로 아이디어를 소개하는 경우 얄짤없이 까입니다. 정말 신명 나게 까이죠. 덕분에 저도 몇 번이나 이사님과 치열하게 다툰 일도 있습니다. 그래서 망신을 안 당하려면 제 아이디어가 리서치 단계의 인사이트로 탄탄하게 무장되어 있어야만 합니다. 뿐만 아니가 제가 그렇게 고민하고 만들어낸 아이디어를 이사님이나 대표님께 설득시키려면 그만큼 자신감도 있어야 합니다. 하지만 정말 어려운 건 내 아이디어가 '틀릴 수도 있다'라고 인정할 수 있는 자신감보다 더 높은 수준의 자존감이 필요하다는 것입니다. 실제로 제가 이사님한테 아이디어에 대한 피드백을 받는 과정 중 가장 힘든 부분은 '이 아이디어가 이런 이런 이유에서 좋은 아이디어인 것 같아'라고 설득하는 것보다 '... 그런데 내가 틀릴 수도 있어'라고 인정하는 부분입니다.

전 직장에서는 기획보다 더 강력한 논리력으로 무장된 UX의 아이디어만 채택될 수 있었습니다. 그리고 그렇게 채택된 아이디어는 그게 끝이었습니다. 그냥 앱에 반영이 되는 거였죠. 도출한 아이디어에 대한 증명 단계는 형식적이거나 아예 없었습니다. 지금은 그때보다는 한 단계 더 발전한 목표를 바라보고 있습니다. 단순히 내부 담당자들을 설득시키는 디자인이 아닌 고객들이 정말 원하는 경험이 맞는지 증명을 하는 것이 그 목표입니다.

저번 포스팅인 '감당할 수 있는 만큼만 디자인하세요'에서는 서비스의 핵심 경험은 최대한 증명할 수 있어야 한다고 이야기를 했는데요, 저 말은 단순히 '나의 디자인 덕분에 우리 서비스의 매출이 3% 증가했어!'라는 성과적인 측면만이 아닌 '내가 생각한 고객의 니즈가 실제 우리 고객들의 니즈와 맞지 않았던 것 같아'라는 검증의 측면도 내포하고 있습니다. 내가 틀렸을지도 모른다는 증명을 하려는 시도 자체가 사실 엄청난 용기가 필요하다는 것임을 요즘 많이 느끼고 있습니다. 하지만 동시에 그런 책임까지 끌어안을 수 있는 디자이너가 정말 멋진 디자이너라고도 생각하고 있습니다.

사용자는 항상 옳지만 그들을 해석하는 나는 항상 옳지 않을 수 있습니다

UX 디자이너로 일하는 것은 정말 쉽지 않은 것 같다고 느낄 때가 있습니다. 회사 내부적으로는 내부 담당자들의 pain point가 늘어나는 한이 있더라도 유저가 원하는 경험에 집중을 해야 한다고 고집해야 하고, 그런 와중에 자신이 구상한 유저를 위한 아이디어가 틀릴 수도 있다는 가능성까지 열어두면서 일을 해야 합니다. ㅎㅎㅎ 협업을 하는 사람들에게 미움을 얻기 딱 좋은 포지션이죠 ㅎㅎㅎ '유저들의 경험을 위해서 추가적인 고생을 좀 해야 할 것 같은데, 어쩌면 그 고생을 하는 게 의미가 없는 삽질일 수도 있어'라고 얘기하는 것과 다름이 없으니까요. 그래서 항상 고민을 합니다. 도대체 어떻게 접근하는 방식이 옳은 방식인 것일까 라고요... 하지만 한 가지 꼭 하지 말아야겠다고 다짐한 부분이 있다면, 증명을 하기도 전에 '내가 새로 적용하려는 이 기능이 유저들을 위해 더 낫다'라고 확답을 하는 행동입니다. 사람들은, 유저든 같은 서비스 담당자이든, 자신들이 모르는 상황에 대한 확신을 얻고 싶어 합니다. 그리고 그 책임을 누군가가 지어주길 원합니다. UX 디자이너들은 기획자들과 협업을 하는 데 있어서 서비스 차원의 큰 책임들은 맡지도 않으면서 자꾸만 훈수를 두고 태클을 건다고 질책을 받곤 합니다. 저는 UX 디자이너도 사용자의 경험에 대한 '책임'을 좀 더 주체적으로 감당하기를 원하지만, 개인적인 실패사례들을 통해 단순히 내부 담당자들에게 지키지 못할 확답을 주는 것은 진정 유저를 위한 방법이 아니라는 것도 알게 되었습니다. '나의 리서치는 최선을 다했지만 언제나 완벽하지만은 않을 것이고, 나의 아이디어는 진심으로 유저를 생각하며 만들어냈지만 유저들은 원하지 않을 수도 있다'는 태도를 지키는 게 중요하다고 생각합니다. 말은 쉽지만 엄청난 인내와 겸손함과 자존감까지 있어야 지킬 수 있는 마음가짐이지요 ㅎㅎ

일을 하다 보면, 아직은 많은 사람들이 UX 디자이너가 일하려는 방식에 대해 낯설고 신뢰하지 못하는 것 같다고 느끼고 있습니다. 그리고 그런 척박한 환경에서 일을 하다 보면 참 에너지 소모가 불필요하게 크고, 심지어는 나도 모르는 사이에 꼰대 같은 행동들이 나오기도 합니다. 비겁하긴 해도 그 방법이 일하기에는 쉬우니까요. 하지만 지금까지 제가 노력해 온 것들이 아까워서인지, 아니면 이제 와서 제가 믿는 방식들을 포기하는 것이 자존심이 상해서인지 아직은 그저 그냥 계속 노력해야 하는 상황이라고 생각합니다. 언젠가는 기업에서도 유저들에게도 그 가치를 인정을 받는 그런 '실전 UX'의 성공사례를 만들어내고 싶습니다. 오늘도 저와 같이 'UX 디자이너'라는 이름을 증명하기 위해 항상 자신과 싸우고 있는 분들을 응원하며 이 글을 바칩니다-