프로덕트 디자이너의 프로젝트 정리하기 2
나 이거 쓸 수 있나? 의 시간 마주하기..
이전 글과 이어집니다.
업무일지를 평소에도 작성해 놓자.
경력으로 활용할 수 있는 프로젝트를 골라보자.
이번 글에서 알려드릴 내용은 아래와 같다.
프로젝트를 뜯어보자
모르겠다.
아니, 글 보러 왔는데 첫마디가 모르겠다라니, 완전 사기꾼 같지만 정말 모르겠다.
어제도 하루종일 앰플리튜드로 내 프로젝트 데이터를 뜯어보다가 잤다. 난 과연 한 게 뭐가 있을까? (좌절 중) 하지만 나만 이런 것은 아닐 거라고 생각하고 글을 작성해 본다. 만약 본인의 프로젝트의 기승전결이 완벽하신 분이라면요 부럽습니다. 저를 제자로 삼아주십시오..
이 글을 읽으면 좋은 분
- 뭘 하긴 했는데 프로젝트를 어떻게 정리해야 할지 모르겠는 분
- 기획 없이 무작정 디자인만 진행하셨던 분
- 더 좋은 아이디어로 광명의 피드백을 하실 수 있는 분
프로젝트 뜯어보기
애초부터 PO가 있어서 PRD(Product Requirements Document)를 받는 디자이너도 많겠지만
PRD가 생략되거나, 성의 없거나, 요구사항 단 한 줄만 받는 디자이너도 많을 것이라 생각한다.
'왜 이따구로 주는 거야?'라고 생각하지 마시라, 당신은 기획의 기회를 얻은 것이다. 여기서 잘되면 당신의 커리어에 한 줄로 남으리니... 하지만 여기서 기획에 대해 작성할 것은 아니다. 이미 우리는 끝낸 프로젝트에 대해 얘기를 하고 있다. 어영부영 애매하게 시작해서 끝나버린 프로젝트, 이제 완전히 씹어 먹어보자!
우리는 우리의 프로젝트를 뜯어볼 수 있어야 한다. 프로젝트가 시작되기에 앞선 배경부터 시작한 목적과 그 목적을 달성하기 위한 목표, 그리고 목표를 향한 설계를 어떻게 했는지. 그리고 우리의 목적이 잘 달성되었는지 판단할 수 있는 지표 설정부터 지표는 어떻게 나왔는지 말이다.
앞서 말하지만, 모든 프로젝트에서 배경, 문제, 목적, 목표, 가설, 지표 등등을 다 작성할 필요가 없다. 프로젝트에 필요한 것만 가져가면 될 것이고 각자가 단어들을 정의하는 것도 다를 것이기에 본인에게 맞춰서 작성하면 된다.
프로젝트의 목적 파악하기 & 배경 작성하기
프로젝트는 이유 없이 시작하지 않는다. 애초에 목적이 있다. 그 목적은 서비스의 가치에서부터 시작한다. 비즈니스의 가치는 수익을 얻는 것이기에 그 수익을 어떻게 얻을 것인지? 사용자에게 어떤 가치를 전달하여야 우리의 가치 달성을 할 수 있는지?를 파악해야 한다.
가상의 프로젝트를 하나 설정하겠다.
검색결과 페이지에 필터 기능을 추가하는 프로젝트를 시작했다고 하자.
왜, 이 프로젝트를 시작하는 것일까? 단순하게 '그래야 사용자들이 원하는 상품을 더 빨리 찾을 수 있으니까' 일까? 더 크게 말하자면 '검색 결과 페이지에서의 수익 증대'이다. 그게 목적이기에 수많은 선택지 중 하나인 필터 기능 추가를 선택한 것이다.
그렇다면 왜 필터 기능 추가였을까? 그전에 앞선 데이터가 필요하다.
검색 결과 페이지에서 상품 페이지로서의 전환 시간이 오래 걸리거나, 결과 페이지에서 상품을 거의 보지 않은 채 이탈하거나, 아니면 단순하게 결과 페이지에서 거래액이 나오지 않거나 등등 여러 가지 이유가 있을 것이다. 데이터가 없다면 단순히 거래액 비교로서만 진행해도 좋을 것 같다.
그래서 진행했던 프로젝트의 목적이 무엇이었는지, 단 한 줄로 적어보는 것이 좋겠다. (꼭 포폴이나 경력 기술서에 적지 않아도 된다. 인지만 하고 있어도 된다.) 그리고 앞선 결과물 '필터 기능 추가'에 대한 명분인 데이터를 가지고 오면 그것이 바로 프로젝트의 배경이 된다. 여기서 한 가지 짚고 싶은 것은 배경 자체는 문제가 아니라는 것이다. 배경은 데이터고 그것을 묶어서 문제 정의를 해야 한다. 이미 지난 프로젝트를 다시 하라는 얘기가 아니라, 그것을 정리하고 '만들라고 하는 얘기'다.
프로젝트의 목적 : 검색 결과 페이지의 수익 증대
프로젝트의 배경&문제 : 검색 결과 페이지에서의 상품 클릭률이 낮고, 이탈하는 유저가 많음.
PLUS
각 페이지, 각 기능마다 목적이 있다. 결국 최종의 목적은 수익증대를 위한 것이지만, 상품 페이지에서의 목적은 상품에 대한 유익한 정보를 상품이 더 가치 있어 보일 수 있도록 쏙쏙 들여 전달하는 것이고, 설정 페이지의 목적은 사용자가 우리 서비스를 좀 더 본인에게 맞춰서 사용할 수 있도록 도와주는 것이다. 그 모든 페이지들의 가치들이 모여서 서비스의 가치, 수익화를 이뤄낸다고 생각하면 된다.
문제 정의 및 가설 세우기
바로 문제 정의로 넘어왔다. 배경이 데이터를 종합했더니 '사용자들이 원하는 상품을 바로 찾을 수 없다'라는 문제 정의가 나왔다. 그렇다면 원하는 상품을 바로 보여줄 수 있도록 해결해야 한다. 여기서 가설이 필요한 것이다. 레퍼런스와 인사이트를 찾았더니, 다른 커머스는 검색 결과 페이지에서 결과에 대한 필터 값을 제공하고 있는 것을 확인했다. 우리 서비스 또한 필터 기능을 제공하면, 사용자들이 원하는 상품을 바로 찾을 수 있지 않을까? 추론, 가설을 세울 수 있는 것이다.
그래서 본인이 진행했던 프로젝트도 아마, 어떠한 생각의 흐름으로 그렇게 작업해야만 했던 이유가 있을 것이다. 그것이 가설이 된다. 그렇게 생각했기 때문에, 그렇게 디자인했으니까.
문제정의 : 사용자들이 원하는 상품을 바로 찾을 수 없음
가설 : 상품 필터 기능을 넣으면 사용자들이 좀 더 원하는 상품을 클릭할 것이다.
목표 및 지표 세우기
목표는 간단하다. 가설이 참이라는 전제하에 진행되는 설정이다. '검색 결과에서 필터 기능 추가하고, 사용자들이 이를 통해 원하는 상품을 더 잘 찾게 한다'
지표설정은 문제정의가 해결이 되었다는 것을 증명할 수 있는 지표 설정이다.
문제 정의의 배경이 되었던 데이터를 개선하면 된다. +더 많이 세울 수도 있다.
결국엔 '사용자들이 원하는 상품을 필터 기능을 통해 바로 찾았다'라는 데이터를 보여주면 된다.
검색 결과 페이지에서 필터를 거친 사용자들이 상품 클릭하는 시간이 단축되는 것
필터를 사용했을 때와 필터를 사용하지 않았을 때의 구매 전환율을 비교하는 것
필터를 사용했을 때와 필터를 사용하지 않았을 때의 상품 찜을 비교하는 것
등등
하지만 여기까지는 기획자 혹은 PO가 설정하는 단계가 많을 것이라고 생각이 든다.
다음 설계 단계부터는 디자이너의 영역이다. 만약 설계까지 기획자 및 PO가 개입을 많이 한다면 여기서는 디자이너로서 많은 의견을 개진해야 한다.
설계의 이유 쓰기
설계는 목표를 더 드라이브할 수 있게 하는 설계여야 한다. 당신이 무엇인가를 해야 한다고 받았을 때, 수많은 디자인 시안이 있었을 텐데, 왜 하필 그 디자인이었을까를 적어보면 된다.
그 모든 행위의 목적은 목표인 '필터추가'를 함과 동시에 '검색결과에서의 거래 증가'에 초점을 둔 디자인 논리면 된다.
필터를 추가함과 동시에 상품카드가 덜 보이게 됨으로, 상품카드를 한눈에 더 많이 보이게 하고 싶어서 검색바를 상단에 배치했다.
필터를 설정한 사용자는 필터를 재 사용할 가능성이 있으므로, 스크롤 시, sanp 되며 고정시켜서 언제든 필터 값을 변경할 수 있게 했다.
주로 가격대가 저렴한 것을 선호하는 사용자의 특성을 반영하여, 가격 필터를 앞단에 배치하고, 단순히 범위 설정만 선택하는 것이 아닌 구체적인 가격도 입력할 수 있게 했다.
TAP으로서 이동하는 것을 선호하지 않는 사용자의 특성을 반영해서 One Scroll로 필터 페이지를 생성했다.
그러면서 ASIS와 TOBE를 보여주면 설명하면 된다.
배포 후, 결과 지표 공유하기
가장 힘든 시간이다. 막상 디자인 설계로서 드라마틱하게 변화된 지표가 없다면 그나마 긍정적인 지표를 찾기 위해 고군분투를 해야 하기 때문이다. 지표는 앞서 설정한
검색 결과 페이지에서 필터를 거친 사용자들이 상품 클릭하는 시간
필터를 사용했을 때와 필터를 사용하지 않았을 때의 구매 전환율 비교
필터를 사용했을 때와 필터를 사용하지 않았을 때의 상품 찜을 비교
등등이다.
데이터를 볼 수 있는 회사고, 내가 데이터를 볼 수 있다.
좋다. 앞서 말했던 프로젝트의 성과를 나타낼 수 있는 지표를 설정하고 본인이 보면 된다.
하지만 긍정적인 지표가 없다면 그래도 그래도 어떻게든 찾아내서 성과를 증명하라. 그리고 생각보다 성과가 좋지 않다면, 그것에 대한 이유를 생각해 놓는 것이 좋다. 그렇게 된다면 앞으로는 어떻게 개선할지가 눈에 보이니까!
데이터를 볼 수 있는 회사고, 내가 데이터를 볼 수 없다.
이것은 적극적으로 데이터를 볼 수 있는 PO나, 데이터를 담당하시는 분께 적극적으로 요청을 해야 한다.
그들은 성과를 볼 수 있는 지표를 만들고, 보는 사람이니 디자이너가 궁금해하는 거에 대해서 전혀 개의치 않아 할 것이다. 본인이 보고 싶은 지표를 설정하고, 요청하면 된다.
데이터를 전혀 볼 수 없는 회산데 어떻게 하나요?
성과를 공유할 수 없다면, 지표 이전에 모든 프로세스를 명확히 논리적으로서 설명하는 수밖에 없다.
설계 단계에서 내가 왜 이렇게 디자인했음을 명확하게 쓰고 어필하도록 하자.
디자이너는 본인의 프로젝트를 설명할 수 있어야 한다.
우리 서비스의 가치는 무엇인지, 가치를 드라이브하기 위해서 한 이 프로젝트의 목적과 문제점은 뭔지,
그것을 해결할 수 있는 가설과 목표는 무엇인지, 그리고 설계는 어떻게 했는지, 성과를 판단할 수 있는 지표는 무엇이고 어떻게 됐는지.
정말 정말 정말 작은 프로젝트라도 쪼갠다면!! 쪼개진다.
그러니, 쪼개는 연습부터 해서 프로젝트를 완전히 씹어먹어 보자.
그렇게 되면 경력 기술서, 포트폴리오, 면접 등 중간에 멘탈붕괴될 일 없이
모든 질문에, 모든 의문에 답을 할 수 있게 될 것이다.
