프로덕트 디자이너의 프로젝트 정리하기 1
업무일지 작성과 프로젝트 선별하기
이제 곧 이직한 지 2년이 된다.
2년밖에 되지 않았고, 지금 내게 주어진 일이 커리어적으로 값지다고 생각해서 이직 생각은 전혀 없지만
프로젝트와 포트폴리오를 정리해야 될 때가 왔다.
이 글을 읽으면 좋으신 분들 =)
- 1~3년 차 디자이너
- 이직준비 중인 디자이너
- 이제 꽉 찬 5년 차 디자이너 허쉬에게 피드백을 주고 싶은 디자이너
업무일지를 평소에도 작성해 놓자.
평소 메모를 하지 않으면 까먹는 성격이기도 하고, 업무에 대한 짤막한 메모라도 남겨야 할 것 같아서 노션으로 업무일지를 작성했었다. 업무일지표를 작성하면 아래와 같은 내용을 확인할 수 있다.
업무일지의 장점
내가 하고 있는 일, 앞으로 해야 할 일, 한 일을 볼 수 있다.
화면별로 작업된 내용이 무엇인지 파악할 수 있다.
UX작업과 마케팅 작업을 분류해서 볼 수 있다.
내가 포트폴리오로 쓸 수 있는 작업을 모아서 볼 수 있다.
개발 일정과 배포일자를 볼 수 있다.
작업 중 프로젝트내 업무일지의 분류는 다음과 같다. 그리고 각 분류마다 페이지 보기를 다르게 했다. 각 목적에 따라서 보드형, 리스트 형으로 분류해서 보면 같은 프로젝트라도 필요한 정보만 쏙쏙 골라볼 수 있다!
진행상황/속성/페이지/Major/개발일정&배포일자
진행상황 필수
진행예정 : 미리 PO에게 전달받은 것이나, 내가 진행하고 싶은 프로젝트
상시진행
작업 중
작업완료 : 디자인 작업이 완료되어 피드백받고 있는 단계, 혹은 FE에게 넘긴 상태의 작업들
개발 중
개발중지
작업중지 : 기획 및 디자인에서부터 중지된 작업
최종작업완료 : 개발 및 QA까지 완료되어 프로덕션에 배포 나간 상태
속성
UX/UI : 프로덕트 플로우나 UI에 관한 작업
Figma : 작업 및 업무 최적화를 위한 정비 작업
리서치
디자인 시스템
마케팅 디자인
f/u : 단순 팔로우 업 작업 > 요런 것들은 나중에 볼 때 걸러서 보면 된다.
속성에 맞춰서 내가 한 작업을 나열시킬 수 있다.페이지 (UXUI 작업에만 국한됨) 권장
서비스의 페이지별로 작업을 나열한 분류 방법이다. 주로 공통 (로그인, 앱 공통 플로우) 및 개별 페이지로 나눠서 나열했다. 내가 어느 페이지에 이만큼이나 작업했는지, 어떤 목적을 중점으로 진행했는지 알 수 있다.
Major 권장
내가 생각했을 때 크게 가져갈 수 있고 데이터를 뜯어보기에 의미 있어 보이는 작업들이다.
모든 작업들에 major인지 아닌지 체크 표시를 해서 나중에 모아보려고 했다.
개발일자 & 배포일자 필수
경력 기술서나 포트폴리오에 들어가야 하는 개발 일정이다. 그리고 배포 일자 또한 표시해 두면, 그 이전과 이후의 데이터를 비교해 볼 수 있기 때문에 배포일자는 꼭 적어두자. 만약에 모른다면 슬랙을 열심히 뒤져보자.
그 외 프로젝트의 목표, 설명 등등이 있다.(안 쓰면 의미 없음)
하지만 단점 또한 분명하다.
적어야 하고, 분류해야 하는 게 많은 만큼, 그렇게 하지 않으면 말짱 도루묵이 된다.
급해서 제목만 대충 적고 내용도 적지 않아서 나중에는 "이게 뭐더라.." 하면서 삭제하게 된다.
나도 좀 열심히 적을걸...
경력으로 활용할 수 있는 프로젝트를 골라보자.
이제 경력 기술서나, 포트폴리오로 활용할 수 있는 프로젝트가 무엇인지 골라야 한다.
그 기준은 아래와 같다.
수동적으로 임한 업무가 아닌 스스로 아이디에이션 하거나
스스로 기획하고 디자인한 업무인데 성과도 좋아야 함.
뭐라는 거야...왜냐하면 비즈니스 사회는 비즈니스의 목적을 파악하고 주도적으로 업무에 임해 성과를 내는 사람을 기대하고 있기 때문이다. 하지만 나 또한 그렇고 우리는 대부분 요구받는 업무를 하고 있다. (가끔 디자인까지도.. 나만 그런 거 아니겠지?)
그래서 우리의 프로젝트들은 대부분 위와 같은 이상적인 작업물이 아닐 것이다. 하지만 되도록이면! 그 방향에 맞출 수 있도록 작업물들을 나열해 봐야 한다.
내가 주도하고, 성과도 괜찮게 나왔다면?
꼭 넣어야 한다. 프로젝트의 목적과 진행, 성과 결과까지 기록한다.
내가 주도하지 않았지만, 성과도 좋고 프로젝트의 일부분이 나의 아이디어로 이뤄졌다면?
내가 해당 아이디어를 어떤 목적을 위해서 내었는지 미리 정리해 두고 그 부분을 강조해야 한다. 성과와 연계시켜 말할 수 있는 방향을 생각한다.
나는 시키는 대로만 했고, 프로젝트의 성과 데이터가 좋게 나왔다면?
성과 데이터를 꼭 기록하되, 성과 데이터가 본인의 디자인에서 나왔다면 그것과 꼭 연결 지어 기록하자.
그게 아니라면.. (디자인에 자기 생각이 없다면) 우선순위는 낮다. 하지만 정 올릴 프로젝트가 없다면 올리도록 하자.
내가 주도적으로 한 프로젝튼데 성과가 별로라면?
패스, 꼭 넣어야 한다면 나중에 디벨롭한 시안을 곁들여보자.
내가 주도적으로 한 프로젝튼데 성과가 어중간하다면?
프로젝트의 목적과 진행에 대해 논리적으로 기록하자. 그리고 좋은 데이터를 골라골라 찾아보고, 그 데이터가 확장될 가능성에 대해서 기록해 보자. 앞으로 어떻게 하면 더 좋을지 디벨롭 방향도 생각해 보자.
내가 주도적으로 했는데 개발이 안 됐다면
정 쓸 프로젝트가 없다면 기획서처럼 배경, 목적, 진행에 대해서 기록하자. 예상되는 데이터 수치가 있다면 좋다. 그리고 왜 개발이 되지 않았는지도 배경 파악을 해두자.
PLUS
문제제기는 PO가 할 수 있다,
하지만 해결은 디자이너가 해야 한다.
나는 2년간의 업무 일지를 펼쳐봤을 때 든 생각은, 내가 여기서 얼마나 내 생각을 들여서 디자인을 했을까였다. 물론, 내가 생각하기에 나는 그냥 수동적으로 디자인하는 디자이너는 아니기에 많은 생각과 아이디어를 나눴겠지만 과연 문제의 처음부터 해결을 위했을까? 싶다는 것이다.
문제 대신 해결점을 던져주는 팀원이 있다고 하자.
"A문제가 있는데, B를 하면 될 것 같아요"
이런 경우 당신은 어떻게 반응하시는가?
나 같은 경우는 '왜 B를 해야 하는지 물어보고, B보다는 C가 더 공수에 효율적이고 빠르게 처리할 수 있음에 대해서' 얘기한다. 하지만 내가 모든 순간 그랬을까? 그러지 않았을 것 같다는 것이다. 그냥 던져주는 해결안에 동조해서 그렇게 작업한 적도 많았을 것이다.
그렇다면, 그게 내 것일까? 그러니 디자이너의 역할은 어떤 작업물이든 단 하나의 버튼을 넣더라도
"어떻게 하면 목적에 더 가까이 다가설 수 있을까?"를 고민해 보는 거라고 생각한다.
그렇게 한다면 버튼 하나에도 다양한 기능이 추가가 될 수도 있는 것이고, 버튼 아래에 설명을 위한 텍스트가 추가될 수도 있는 것이고 어찌 됐든 작업물에는 당신의 생각이 묻게 되는 것이다.
그러니 적극적으로 생각한 프로젝트를 가져가라는 것이 이 단락의 요점이었다. 하하
