[주.프.디.살] 스타트업 디자이너는 어떻게 일할까
'주니어 프로덕트 디자이너로 살아남기' 시리즈, 일곱 번째 이야기
엄밀히 말하면 '스타트업 프로덕트 디자이너'이다. 사실 이 글의 주제는 나의 첫 꼬꼬마 디자이너 (지금은 꼬마 정도이지 않을까?) 시절을 떠올리며 정하게 됐다. 그때는 UXUI 디자이너에서 서서히 프로덕트 디자이너라는 단어들이 점점 떠오르고 있던 시기였기에 '프로덕트 디자이너'에 대한 정보가 부족했다. 그래서 난 도대체 프로덕트 디자이너는 뭐고 어떻게 일하길래 이름난 스타트업들이 너도나도 직군을 내놓을까 하고 궁금해했다. 그래서 이 글은 그에 대한 현재의 내가 보내는 답장처럼 써보고자 한다.
프로덕트 디자이너와 UXUI 디자이너의 차이
그렇다, 단골 질문이다. 심지어 요즘도 면접을 보러 갈 때 면접관이 심심치 않게 물어보는 질문이기도 하다. 결론부터 말하자면 나도 세부적인 차이는 잘 모르겠다. 하지만 그 둘의 차이를 한 단어로 얘기할 수는 있다. 바로 비즈니스 임팩트이다. 이 말은 즉, 사업적인 관점에서 디자이너가 얼마나 고려하는지에 대한 차이라고 할 수 있다. 극단적인 예시를 들어보자면, 결제하는 데에 어려움으로 느끼는 유저가 있다고 가정하자. 아마도 극단적인 UXUI 디자이너라면 "결제 과정을 아예 빼버리고 모든 것을 무료로 제공합시다!"라고 외칠 수 있다는 것이다. 하지만 프로덕트 디자이너라면 사업적인 이윤을 고려하지 않을 수 없다. 그렇기 때문에 모든 것을 무료로 결정하는 행동을 하지 않을 것이다.
그렇기 때문에 일반적인 경우 UXUI 디자이너와 프로덕트 디자이너는 일하는 방식과 관점이 달라야 한다. 물론 사용자 경험을 좋게 만들었을 때, 사업적인 이득이 더 클 경우가 대부분이기 때문에 둘의 결과는 같을 수 있다. 하지만 프로덕트 디자이너는 보통은 PO와 짝꿍이 되어 문제를 정의하고, 정의한 문제에 대한 해결책을 내고, 그 해결책이 얼마만큼의 가치가 있을지를 따져볼 수 있어야 한다. 굉장한 데이터 지식과 수학적인 능력으로 실제로 돈을 얼마나 벌어다 줄 수 있을지까지 계산할 수 있다면 매우 매우 좋겠지만, 사실은 그 부분보다는 디자이너만의 장점을 살려 사업적인 이득을 내는 게 바로 프로덕트 디자이너가 하는 일이다.
그래서 난 이런 관점으로 스타트업 프로덕트 디자이너가 일하는 방식에 대해 얘기해보고자 한다. 사실 내가 모든 회사를 다녀본 것도 아니고, 경험이 쌓이고 쌓여 모든 것을 관철하는 시니어도 아니다. 그렇지만 약 5년 차 디자이너가 되어가는 지금까지의 경험을 소개해보고자 한다.
디자인, 어떻게 하세요?
요새 난 종종 면접관으로써 프로덕트 디자이너 면접으로 보러 들어간다. 그때 꼭 하는 질문이 있는데, 바로 "자신만의 디자인 프로세스가 있으신가요? 있다면 어떤 것인지 소개해 주세요."이다. 이 질문의 의도는 크게 두 가지가 있다. 디자인 솔루션을 낼 때 어떤 근거와 논리를 가지고 작업하는지, 그리고 우리 회사와 일하는 방식의 결이 맞는지이다. 물론 이 질문을 했을 때 제대로 이해하고 답변한 디자이너는 많지 않았다. 대부분 자신이 일하는 모습을 목록화해서 생각하기보다는 "뭐, 그냥 매번 하던 건데.. 뭘 설명하라는 거지?"라고 생각할 가능성이 높다. 나는 이런 상황이 발생하는 이유가 많은 디자이너들이 늘 습관처럼 하고 있기에 설명을 못하는 경우가 많다고 생각한다.
나의 경우 (많은 디자이너들과 비슷하게) 나의 디자인 프로세스는 단순하다. PO와 함께 문제를 정의하고, 다양한 비주얼, 경쟁사 레퍼런스를 살펴보고, 내부의 데이터를 요청해 적절한 디자인 솔루션을 시안으로 여러 개를 만든다. 그 후에 개발이 진행되면 디자인 QA를 하고, 배포가 완료된 결과물을 성과를 꾸준히 추적한다. 얼핏 보면 매우 단순하고 어디서 본 듯한 내용이다. 하지만 이를 목록화해서 실제로 내가 하고 있는지 대입해 보면 무언가 빠져있을 가능성이 높다. 예를 들면, '데이터를 볼 수 있는 환경이 아니어서...', 혹은 'PO는 커녕 나 혼자 고군분투하고 있어서...', '내 뜻대로 된 디자인이 아니고 시키는 대로 만든 디자인이어서...' 등 다양한 이유들로 인해 어딘가 구멍이 있는 게 어색하지 않다.
이렇게 많은 예시를 들어가면서까지 중요성을 얘기한 이유는, 바로 내가 몸소 체험했던 상황들이었기 때문이다. 사실 어딜 가던 이상적인 환경에서 디자인하기란 쉽지 않다. 하지만 이에 녹아들어 상황을 타파하지 않으면 결국 손해 보는 것은 나 자신이다. 그래서 나름대로 만들어 낸 것이 '자신만의 디자인 프로세스'이다. 물론, 처음부터 모든 것을 만들어 낸 것이 아니다. 선배 디자이너분이 스크럼마스터와 팀과의 오랜 시행착오 끝에 만들어진 프로세스를 나만의 방식으로 만들었다. (감사하지 않을 수가 없다.) 이 방식을 살짝 공개해 보겠다.
피드백은 최대한 빨리, 발산은 깊지만 넓지 않게
나의 디자인 프로세스
문제 정의와 가설 설정
레퍼런스 수집 & 아이디어 발산
1차 디자인 리뷰 세션
2차 디자인 리뷰 세션
UI 상세 스펙 전달
엣지 케이스, 추가 UI 및 정책 전달
디자인 QA 이슈 등록
디자인 QA 이슈 해결 여부 검수
임팩트 점검 및 Next Step 고민
위에서 소개한 것처럼 나의 디자인 프로세스는 총 9단계이다. 꽤 긴 것 같지만, 실제로 적용해 보니 제거가 어려운 핵심적인 단계가 많았다. 이 모든 프로세스를 하나하나 설명하기엔 불필요해, 중요한 핵심만 짚고자 한다.
바로 디자인 리뷰 세션이다. 나는 1,2차 세션을 나누어 리뷰한다. 1차 세션엔 다양한 이해관계자가 모인다. 개발자, PO, 대표님 등, 관련 있는 모든 사람이 모일 수 있도록 준비한다. 세션이 시작되면 이전까지 모았던 레퍼런스와 PO가 제안한 지표를 먼저 설명하고, 프로젝트의 목표와 목적을 반드시 설명한다. 그 후 일반적인 와이어프레임보다는 고도화된, 실제 UI보다는 덜 완성된 형태로 1차 세션에서 리뷰한다. 리뷰가 끝나면 최대한 다양한 피드백을 받기 위해 노력한다. (심지어 터무니없는 아이디어도 괜찮다.) 그리고 1차 세션을 마무리하며 PO와 나온 피드백을 함께 정리한다. 반영해 볼 사안의 범위를 좁히는 것이다.
그리고 2차 세션을 준비한다. 2차 세션엔 최대한 구현될 UI와 동일한 퀄리티로 디자인한다. 이 때는 다양한 프로토타이핑 툴을 활용하는데, 모션 스펙을 확인할 수 있는 프로토파이와 같은 툴도 활용하면 좋다. 실제로 모션이 구현되었을 때와 정적인 디자인 화면은 유저 경험에 있어 많은 차이를 유발하기 때문이다. 그리고 2차 세션을 진행할 때는 PO와 담당 개발자만 모여 가볍게 진행한다. 기술적으로 도전적이거나 전체적인 플로우는 1차에서 협의되었기 때문이다.
이렇게 번거롭게 보일 수도 있는 2개의 디자인 리뷰 세션은 사실 많은 장점을 가지고 있다. 1차에선 최대한 많은 발산을 통해 다양한 가능성을 제안할 수 있을 뿐만 아니라, 이후 시간이 촉박할 때 새로운 피드백을 받아 당혹스럽지 않기 때문이다. 또한 발산의 방향이 흩어지지 않도록 2차에선 최소 이해관계자만 모여 목표에 어긋나지 않을 수 있다. 또한 이런 프로세스가 제대로 작동하는 모습이 지속되면, 동료와 조직의 신뢰를 얻을 수 있는 큰 장점도 있다.
결국 이 프로세스의 핵심은 피드백은 최대한 빠르게 받아서 혼란을 없애고, 피드백 세션에서는 다양한 사람들의 의견을 최대한 모아서 더 나은 결과물을 만드는 것이다. 그리고 디자인적으로 최종적인 의사결정권은 프로덕트 디자이너가 가져가야 한다는 점이다. 제품의 정책이나 방향은 PO의 책임일지라도, UX에 있어서 디자이너만큼 전문성을 가지기 어렵다. 그리고 그렇기 때문에 팀에서 UX 전문성을 갖기 위해 꾸준히 공부하고 노력해야 한다는 점도 역시 중요하다. 뿐만 아니라 피드백을 주고받는 상황에서 종종 방향을 잃은 채 마구 발산만 하는 경우도 있기 때문에, 걸러낼 피드백을 구별해야 한다. 이렇게 디자인 리뷰를 마친다면 이제 사용자에게 전달될 Final을 준비하면 된다.
퀄리티를 높이는 방법
유저에게 전달될 Final은 의심의 여지없이 적절한 퀄리티를 보장해야 한다. 시각적으로 뿐만 아니라 길을 잃지 않도록 잘 설계하는 과정도 필요하다. 그러려면 어떤 방법으로 유저에게 적절한 경험을 줄 수 있을까? 나는 디자이너의 풍부한 경험이 바탕이 된다고 생각한다. 그를 바탕으로 좋은 디자인과 제품을 보는 눈이 생기고, 이런 평소의 배경지식을 통해 실무를 할 때 적재적소에 퀄리티를 올릴 수 있기 때문이다.
좋은 제품과 나쁜 경험을 구분해 내고 적용하려면 평소에 많은 제품을 사용하는 것이 좋다. 다양하게 써보는 것도 좋지만 사실 바쁘디 바쁜 현대사회에서는 제품을 골라서 써보는 것도 좋은 방법이다. 나의 경우에는 비슷한 기능을 하는 경쟁사를 써보고, 경쟁사는 아니지만 관련이 있을 법하거나 유저들이 관심을 가질 것 같은 앱을 사용해 본다. 자주 경험하다 보면 유저들의 반복적인 행동 패턴을 발견할 수 있고, 디자인을 할 때 올바른 Gut Feeling을 가질 확률이 높아지게 된다.
또한 면밀한 프로토타입을 만들어 보는 것이 중요하다. 단순한 정적인 스크린뿐만 아니라 실제로 유저가 어떤 모션을 통해 경험을 하게 되는지에 따라 프로덕트의 퀄리티가 달라지게 된다. 진동 한 번과 매끄러운 애니메이션 하나가 프로덕트 자체의 신뢰도를 올릴 수도 있기 때문이다. 이런 부분들은 주니어에게 다소 낯선 디자인일 수 있기에 앞서 말한 레퍼런스 수집 시에 많이 경험하는 것이 좋다.
