주니어 UXer가 성장하기 위해 필요한 고민, (1)
입사 3개월 차 UX Designer의 깨달음
7월 초에 O2O 서비스 스타트업에 입사하고 나서 3개월이 되어간다. 거의 한 쿼터를 지내고 나서 글을 쓰는 이유는, 창업과는 또 다른 차원인 series B 스타트업의 레거시를 이해하고 조심스럽게 움직이기까지 자그마치 3개월이 걸렸기 때문이다.
이제는 규모가 큰 서비스의 생태계도 이해하고, 나와 전혀 다른 세계에 사는 사용자를 이해하는 법도 (얼추) 알겠다. 더 나아가 UX Designer 로서 태도나 생각하는 방법도 알겠다. 일을 시작하자마자 이걸 알았더라면 더 나았을 테지만 3개월의 발버둥은 내 최선이었음을 안다. 대충 어렴풋이 아는 것과 지식을 설명하는 것은 하늘과 땅 차이기에 앎을 글자로 써서 증명하고 싶다. (보실지는 모르겠지만... 전반적으로 도움 주신 시니어 디자이너님께 무한한 감사를 드립니다.)
이 글이 도움 될 분들
사수가 있건 없건 중요하지 않다.
1. 어딘가에 곧 속해질 주니어거나,
2. 어딘가에 속해진 주니어거나,
3. 그 주니어가 특히 Product Designer, UX Designer라면 이 글이 도움이 될 것이다.
글의 시작과 끝을 아우르는 가장 중요한 소재는 나의 뼈피살이 되어준 두 단어 'User', '왜' 이 두 키워드다.
이번 글 : 'User'의 맥락을 이해하는 방법, 해피 패스 그리기
다음 글 : '왜?'하고 묻는 연쇄질문마 되기 (작성 중)
아마 다 이럴 걸...
다 똑같은 주니어의 고민
자리가 배정되고, 주변 동료들과 인사하고 모니터를 마주한 후 가장 먼저 드는 생각은 '난 여기서 무엇을 하게 되는 거지?' 다. 당장 나에게 일을 달라. 전 회사나 창업에서 구른 경험을 튀겨서라도 보여주겠다는 열정이 샘솟고, 이내 매니저님이 서비스의 Background를 브리핑해주면 노션에 열심히 받아 적는다. 적다가 모르는 용어가 들리면 빠짐없이 물어보고, 대답을 받아 적어서 나름의 Dictionary를 만든다. '받아 적은 걸 읽을 땐 알겠는데 기억해내려면 모르겠네. 나 같은 뉴비를 위한 용어 사전이나 온보딩 자료를 만들어볼까?' 하는 딴생각에 빠져있다가, 노션에 1년 전부터 이미 있는 걸 발견하고 뒷걸음질 친다.
그리고 자리로 돌아와 이전 쿼터의 PRD, OKR 자료들을 보면서 서비스가 어떻게 커왔는지 감히 레거시를 이해하려 든다. 역시나 와닿지 않는다. 모르는 말 투성이. 그래서 Figma나 Testflight으로 설치한 Staging version App으로 돌아와 이런저런 페이지를 둘러본다.
그러다 PM님을 통해 적응을 돕기 위해 마련된, 조금은 작고 중요도가 떨어지는 Task를 받는다. 아까 받아 적은 용어를 활용하여 어떤 임무인지 이해하(려 애쓰)고, 핵심적인 문제를 찾아서 바로 와이어프레임을 짜간다. 그러면 다시 생각해보라고 정중하게 반려당한다.
'이 건 ~한 이유로 구현될 수 없어요.'
'이 건 Best가 아닌 거 같아요.'
'이 건 서비스 전반적에 적용 가능한 아이디어가 아니에요.'
하루 종일 고민한 아이디어였는데...!경력자라면 2~3일 만에 끝날 작은 테스크가 내 손에서 일주일 가량 놀고 있다는 걸 알게 되는 순간부터 점점 안색이 어두워진다. 어쩌다 운 좋게 프로덕트 팀 동료들의 애정 어린 도움 덕분에 한 테스크의 피쳐가 배포되고 나면, 자연에서 채집한 흙으로 빚은 내 자식이 세상에 난 느낌마저 들며 희열을 느낀다. 하지만 딱 거기까지다. 여전히 아무것도 모르겠다.
이 장황한 이야기는 내가 6년 된 O2O 플랫폼 서비스 스타트업에 입사한 지 두 달 동안 일어났던 일을 함축한 일기다. 가장 무서웠던 건 내가 '뭘 모르는지 모른다'는 거였다. 주변에서는 모르는 게 있다면 물어보라고 친절히 도와주시는데, 아는 게 있어야 모르는 게 있는 법이었다. 혼란스러운 마음에 아이디어를 마구 떠올리고, 그 아이디어에 변화를 주어 마구마구 시안을 뽑지만 본질이 비어있는 상태였다.
무엇을 놓치고 있는걸까.
가장 기본으로 돌아가자.
User, User, User
아무것도 모르겠다면 기초로 돌아가 보자. UX designer(기획자), UI designer, UX writter 하여튼 'U'가 들어가는 모든 직군이라면 가장 중요한 건 사용자다. 우리는 입사한 후로 그 누구보다도 사용자를 위하고 그들을 위해 움직인다. 회사에서 우리보다 이들을 더 생각하는 사람은 없어야 한다.
하지만 사용자는 우리에게 가장 밀착되어 있지만 동시에 미지의 존재이기도 하다. 회사에 입사하기 전, 최대한 관심사가 맞거나 실제 사용해본 서비스 프로덕트 팀을 택하여 입사했더라도 사용자와 나는 완벽히 같을 수 없다. 때문에 입사 직후 가장 먼저 해야 할 일은 머릿속에 User를 들여오는 것이고, 정확히는 사용자의 '맥락'을 이해하는 것이다. 사용자가 어떤 사람인지, 우릴 통해 원하는 것부터 얻게 될 것 까지.
Q. User는 어떻게 이해할 수 있지?
A. User Journey Map, Happy Path를 그려보자.
테스크가 주어지자마자 해결방법에 몰입해선 안된다. 더 정확히 말해서는, 문제를 해결하기 위해 화면과 컴포넌트, Feature단위로 생각하는 걸 멈춰야 한다. 사용자가 어떤 존재인지 이해하고, 우리 서비스에서 뭘 얻어가고 싶어 하는지 공감하는 게 첫 번째 목표다. 테스크를 주신 매니저님도 그걸 바라셨을 것이다.
그럼 첫 주부터 User Interview를 해야 하나? 선각자가 이미 해둔 인터뷰가 있다면 그걸 참고하면 된다. 하지만 준비된 소스가 없다는 이유로 입사 하루만에 뜬끔없이 유저 인터뷰를 기획하기는 어렵다.(고객 당신이 누구신지 묻는 인터뷰를 하는게 문제가 아니라, 목적에 의해 적소에 하는 게 중요하다는 뜻.) 게다가 사용자가 어떤 사람인지, 어떤 동기로 서비스에 진입하게 됐는지, 만족도는 어떻게 되는지 알기 위해서는 정성적인 인터뷰가 가장 좋겠지만 우리는 당장 사용자가 어디서 뭘 하고 있는지 보기 위한 '단계적인' 설계도도 필요하다. 그렇다면 내가 직접 내 지식의 베이스를 구축한다는 마음으로 사용자의 해피 패스를 담은 User Journey를 천천히, 한 단계씩 정리해보면 어떨까.
사용자가 어떻게, 무슨 과정을 거쳐 서비스를 받고 있는지 조감도로 볼 수 있고, 내가 받은 테스크가 정확히 어떤 부분에서 마찰을 일으켰는지 이해하는 데까지 도움이 될 수 있다. 더불어 User Journey Map을 그림으로써 단기간 내에 서비스의 Flow를 익히고, 화면도 눈에 익히고, 어떤 이벤트와 정보를 추적하고 저장하는지까지 알 수 있다는 장점이 있다. 여기에 시간을 들이면 들일 수록 사용자와 서비스에 대한 이해가 촘촘해진다.
내 경우, O2O 서비스인 만큼 User Segment가 두 분류로 나뉘었다. 플랫폼에서 제공하는 서비스를 이용하고 싶은 '고객' 사용자와, 해당 서비스를 오프라인에서 실질적으로 제공해줄 수 있는 '파트너' 개념의 사용자. 각 사용자와 플랫폼 서비스 제공자인 우리를 포함해 세 분류의 이해관계자를 포함한 Happy path, 그렇지 않은 path를 지도로 그렸다.
정리해보자면
고객 유저와 파트너 유저는 플랫폼에서 어떻게 시작하고 끝나길 바라는지 (Happy Path)
+ 이상적이지 않은 패스의 경우도 있다면 추가해 촘촘하게 그릴수록 좋다.
두 유형의 유저 행동을 어떻게 구분할 것인지 (Event)
유저의 행동 이후로 서비스의 상태는 어떻게 변화하는지 (Status)
각 status에 사용자의 행동을 유인하기 위해 제공하는 메시지는 어떤 단계에서 어떻게 제공되는지 (Alert)
더 나아가 우리 서비스에서 사용자가 행동을 할 때마다 어떤 정보를 받아오고 있는지? (DB Data)
사용자가 서비스를 받기까지 자동화되지 않은 부분이 있는지 구분해서 작성
O2O 서비스일 때, 온라인의 경험과 오프라인의 경험을 구분해서 작성
입사 후 제작한 User Journey Map (Happy path), 내용 공개는 불가하므로 블러 처리.앞에서 잠시 언급했지만 테스크를 받자마자 바로 와이어프레임을 그리지 않고 사용자의 맥락을 먼저 이해한 다음 다시 문제 상황을 돌아보면, 이 문제가 어느 단계에서 어떤 유저의 행동을 저해하게 되는지 힌트를 얻게 된다. 그럼 한 발짝 더 나아가서, Amplitude나 Mixpanel 등의 User Tracking Tool에서 문제가 발생한 Event의 Pannel을 쪼개, 어떤 단계에서 주로 이탈이 일어나고 있는지 확인하는 식으로 응용할 수 있다.
+
문제를 해결하기 위해 만든 기획이 어떤 영향을 끼쳤는지까지 추적하고 관리하는 것이 Uxer의 몫이기에, 나 또한 데이터에 능숙해지는 미래에 알면 좋을 것들을 정리해보겠다.
이를 기반으로 다양한 가설로 접근해 아이데이션을 진행하면 '이 건 Best가 아닌 거 같아요.', '서비스 전반적으로 적용 가능한 아이디어가 아니에요.'라는 답을 듣게 될 아이디어를 소거한 기획을 짤 수 있게 되는 것이다. 물론 '이 건 이런저런 이유로 구현될 수 없어요.' 하는 문제는 팀의 기술 부채가 무엇인지 개발자 동료에게 여쭤보는 절차가 필요하지만...!
이 자료가 이미 입사한 회사에 있다고 하더라도, 혹은 그 양이 가늠이 되지 않을 정도로 방대하더라도 짬을 내어 혼자의 힘으로 처음부터 끝까지 제작해보는 게 주니어 Uxer에게 굉장한 힘이 되어줄 것이다.
결국은, 나무가 아닌 숲을 보라는 말을 하고 싶었다. 어느 순간부터 시니어와 주니어를 가르는 첫 번째 능력이 '사용자에게 공감하고, 그들의 맥락을 이해하는 빠른 속도'인 것 같다는 생각을 차츰 해왔는데, 이번에 소개한 User를 이해하는 방법 중 하나인 Journey map을 딱히 그리지 않아도 사용자를 이해하게 되는 게 시니어일 수도 있다는 느낌이다. 물론 인터뷰나 Journey map 같은 게 시니어에게 필요하지 않다는 말은 아니지만, 주니어인 우리보다 조금 더 필요한 것과 필요하지 않은 정보를 고민을 거치지 않고도 구분해내는 차이가 있지 않을까.
다음은 사용자가 겪는 문제를 헤매지 않고 해결하기 위한 생각의 고리를 보여주고 싶다. 시니어 디자이너님이 내 뇌에 박아버린 그 생각의 고리... 커밍 쑨
