이전 글
문서화가 필요해
프로덕트 디자이너는 화면을 바로 그리지 않는다는 말, 들어보셨나요? 실제로 저도 작업을 할 땐 피그마를 바로 켜는 일은 드문 것 같습니다. 유저 인터뷰/테스트를 통한 인사이트를 정리하거나, 스펙에 대한 기능 정의를 구체화하거나, 디자인 작업에 앞서 고려해야 할 점을 적거나 하는 작업을 선행하고 있습니다.
그리고 이 모든 건 노션을 통해 문서화하고 있는데요. 노션은 문서화하기 아주 가벼운 툴이고, 여러 명이 같은 문서를 편집하며 협업하기에도 좋은 툴입니다. 또 문서화뿐만 아니라 개인 워크 플로우를 기록하는 용도로도, 블로그로도 활용도가 높아 프로덕트 디자이너가 노션을 어떻게 활용하는지 소개하려 합니다.
함께 보거나 누군가에게 보여 줄 문서
생각 발산, 스펙 문서
책 <당당한 디자인 결정을 위한 9가지 방법>에선 이렇게 말합니다.
상대가 디자인을 보지 못한다고 가정하고 디자인의 모든 세부사항을 문장으로 설명해보는 건 어떨까? 예를 들어 전화 통화로 여러분의 디자인을 어떻게 설명할 수 있을까? 이메일로는? 여러분의 디자인이 어찌 보이는지 한번 적어보면 이전에 미처 몰랐던 디자인에 관한 근거를 깨닫게 될 것이다. 자신이 사고했던 과정을 깨닫고 먼저 자신의 디자인을 스스로에게 명확하게 설명하는 데 도움이 될 것이다.
이렇듯 디자인을 글로 적는 과정이 중요한데요. 스스로에게뿐만 아니라 상대방을 설득하는 데에도 좋은 도구가 됩니다. 그래서 저는 다른 팀원들이 디자이너의 생각을 깊이 공감할 수 있도록 시안만 보여주기보다는, 제 생각을 적어 놓는 문서를 만듭니다. 그러면 어떤 문제에 대해 공감 받고, 이 공감은 설득으로 이어져 보다 빠른 디자인 결정을 내릴 수 있습니다.
내린 결정을 기반으로 엔지니어 또는 이해 관계자가 모든 스펙을 똑같이 이해할 수 있도록 PRD(Product Requirement Document)를 잘 작성하는 것도 중요합니다. 저는 디자이너 관점에서 주로 UI를 기반으로 유저가 어떤 액션을 취했을 때 제품이 어떻게 동작하는지, 예외 상황은 어떻게 되는지, 배리에이션은 어떻게 갈 건지 위주로 기록합니다.
스펙이 크게 복잡하지 않다면, 잘 적어 놓은 스펙 문서는 QA 시트로도 꽤 훌륭한 역할을 해냅니다. PRD를 그대로 복제해 항목 전체를 체크리스트로 토글해 QA를 진행하기도 합니다. 이렇게되면 QA 시트를 따로 만들 필요도, PRD와 뭐가 다른지 비교할 필요도 없습니다. (다만 스펙이 조금 복잡해진다면 노션이 아닌 다른 툴이 더 효율적일 수 있습니다.)
포트폴리오, 이력서
노션으로 포트폴리오나 이력서를 만드는 것에 대해 여러 의견이 있던데, 개인적으로는 읽는 사람이 편하고 내용이 좋으면 형식은 크게 문제 되지 않는다고 생각합니다. (하지만 hwp는 문제가 됩니다 ) 특히 프로덕트 디자이너의 고민의 흔적과 여러 시도들을 PDF 형태로 담다 보면 깨알 같은 글씨가 되기 마련입니다.
그래서 전 포트폴리오를 PDF와 노션, 반반 무 많이로 구성했습니다. 내용 축약 버전을 PDF 형식으로, 더 자세한 이야기를 적어둔 노션으로 가는 브릿지를 PDF 포트폴리오 안에 삽입해두었습니다. 물론 서류 검토자에 따라 호불호가 갈릴 수 있음을 염두에 두고 본인에게 맞는 선택을 하시길 바랍니다.
저처럼 글로 포트폴리오를 구성하실 분이라면 Design Wrap Up을 사용하셔도 좋겠습니다. 이전 회사 동료분들과 포트폴리오 작업을 함께하던 도중, ‘포트폴리오를 더 쉽게 만들 수 없을까?’라는 고민에서 출발해 이 툴을 만들었습니다. 프로젝트의 시작 부분부터 끝부분까지, 프로덕트 디자이너가 일하는 방식을 그대로 본떠 포트폴리오를 구성할 수 있도록 도와주는 템플릿입니다. 물론 제 포트폴리오도 이를 기반으로 작업했습니다.
블로그
지금 읽고 계신 이 글과 블로그도 노션으로 만들었습니다. 노션은 WYSWYG가 되기 때문에 여타 다른 블로그보다 편하고 직관적으로 글을 읽고 쓸 수 있습니다. 공유 설정만 바꾸면 되기 때문에 업로드할 필요도 없고, 수정도 쉽습니다.
또 우피와 함께 쓴다면 더 확장성 있는 기능도 사용할 수 있습니다. 요즘은 회사 웹사이트나 채용 공고에도 우피를 사용하는 사례가 심심찮게 보이는 것 같습니다. 제가 현재 우피에서 사용하는 기능으로는 댓글, GA, Disqus, 페이지 비밀번호, 스타일 변경 등이 있습니다. 간단한 통계도 볼 수 있는데, 특정 IP를 PV에서 제외하고 볼 수 있으므로 본인을 제외한 방문 수를 확인하기 좋습니다. 이외에도 노션에서 지원하지 않는 고급 기능들이 많으니 블로그나 웹사이트 용도로 노션을 생각하시는 분들에게 좋은 선택지가 될 수 있을 것 같습니다.
나만 보는 문서
업무 일지 기록하기
노션으로 업무 일지를 쓴 지 3년 정도 되었는데요. (이전에는 dynalist를 사용했고 이 툴도 훌륭합니다.) 노션으로 옮긴 후 최적의 업무 일지 템플릿을 찾기 위해 여러 번의 테스트를 거친 결과, 현재의 템플릿까지 이르렀습니다. (아직 100% 만족하는 건 아니지만요…) 구조는 아래 사진과 같습니다.
보드 뷰의 인라인 데이터베이스를 활용합니다. 1년을 4분기로 나누며 카드 하나가 일주일을 의미합니다. 카드 내부의 프라퍼티는 날짜, 분기, 일주일을 요약할 키워드로 구성되어 있습니다. 여기서 입력된 날짜를 데이터베이스 상에서 내림차순으로 정렬하기 때문에 분기별 가장 최신 날짜의 카드가 맨 윗 줄로 오게 됩니다. 이렇게 구성하면 1년이자 56주를 한눈에 볼 수 있습니다.
하나의 카드 내부 맨 위에는 ‘이번 주 할 일’을 적습니다. 그 주에 언제 해도 상관없는 일을 체크리스트 형식으로 기록합니다. 아래부턴 월요일부터 일요일까지 7개의 블락을 나누어 체크리스트를 작성합니다. 평일이라면 회사 일, 회사 외의 일, 개인 루틴을 기록하고, 주말이라면 회사 일은 제외하고 기록합니다. 한 주를 마무리하는 일요일에는 항상 ‘다음 주 스케쥴 준비하기’ 태스크를 배치합니다.
하루치 체크리스트 아래엔 토글을 만들어 그 안에 일기를 기록합니다. (원래는 페이지로 썼으나 뎁스를 왔다 갔다하는 게 귀찮아서 토글로 변경했습니다.) 토글 내부엔 그날의 일기, 배운 영어 표현, 감사한 일, 잘한 일, 아쉬운 일을 씁니다. 그리고 그날의 생산성에 따라 토글 제목은 신호등처럼 기록합니다.
•
생산성도 훌륭했고 체크리스트를 대부분 이행했다면
•
조금 아쉬운 점이 있었다면
•
아주 많이 아쉬웠다면
이렇게 표기하면 일주일의 생산성을 시각적으로 판단하기 좋습니다. 또 주말엔 일하지 않기 때문에 그날 있었던 일을 이모지로 기록하는데요. 오늘 하루를 표현할 이모지를 찾는 것도, 시간이 지난 후에 이모지만 보고 그날 무슨 일이 있었는지 맞춰보는 것도 쏠쏠한 재미 중에 하나입니다.
회고록 쓰기
매달 말(또는 연말), 무슨 일이 있었는지 회고록도 쓰고 있습니다. 스스로의 성장이 더디다 생각될 때도 예전 회고록을 보다 보면 ‘그래도 많이 성장했구나’ 하는 생각이 들기 때문인데요. 회고록도 나름의 템플릿이 있습니다.
연말 회고를 대비해 이번 달 요약이 맨 윗줄에 있습니다. 이미 업무 일지(이자 일기인) 카드에서 일주일을 요약하는 키워드가 있으므로 4개~5개의 카드를 모아 다시 한 두 줄로 요약한다고 생각하시면 됩니다. 연말에는 다시 12개의 요약본(=회고록)을 보고 1년을 되돌아보는 것이죠.
그달에 수행한 일을 회사 일과 회사 외의 일로 나누어 적습니다. 또 그 달에 공부한 것, 만족한 것, 아쉬운 것, 개선할 방향, 느낀 점을 씁니다. 마지막으론 그 달에 즐긴 콘텐츠(영화, TV, 책, 공연 등)를 적습니다. 제가 좋아하는 뉴스레터 중 하나인 ㅎㅇ 님의 <콘텐츠 로그>로부터 영감을 받았는데요. 대부분 최신 콘텐츠를 보기 때문에 그달을 가늠하기 좋은 척도가 되기 때문입니다.
아카이빙용으로 활용하기
앞에서 회고록에 그달에 본 콘텐츠를 기록한다고 소개해 드렸는데요. 그중에서도 책은 직무와 관련된 것들도 있으므로 리스트 형식의 데이터베이스로도 기록하고 있습니다.
책을 읽은 기간, 책의 종류(문학, 에세이, 직무…), 저자 등을 프라퍼티로 설정해 기록합니다. 역시나 날짜 기준으로 최근에 읽은 책이 맨 위에 오도록 정렬을 해놓았고, 1년 동안 몇 권을 읽었는지 측정하기 위해서 연도별로 그룹화해놓았습니다. 감명 깊게 읽은 책엔 이모지를 달아 가끔씩 꺼내 보기 쉽도록 표기했습니다.
리스트 내부에는 책에서 발췌한 내용을 적거나 제 생각을 적어 놓는데요. 크게 세 가지로 구분해 기록합니다. (주로 직무 관련된 책에 적용하는 방법입니다)
•
information: 새롭게 알게되었거나 깨달은 내용
•
question: 의문점이 있거나 누군가에게 질문할 내용
•
specification: 책에서는 나오지 않은 관련 내용의 추가 정보
특히나 새로 알게 된 단어는 단어장을 따로 만들어 놓습니다. 우리가 영어 단어를 외우듯이, 책에서 나오는 전문 용어도 사전처럼 만들어 놓으면 나중에 적절한 단어를 구사해야 할 때 좋은 자료가 됩니다. (그렇다고 어려운 말만 쓰는 건 지양하려 합니다.)
이외에도 여행 계획이나 레시피, 세미나, 스터디도 모두 노션으로 기록합니다. 기록하는 것 자체는 조금 귀찮을지 몰라도 누군가에게 공유하거나 후에 필요한 자료가 있을 때 좋은 자산이 됩니다.
노션 더 잘 활용하기
어떤 문서를 만들지 소개해드렸으니, 문서를 어떻게 써야하는지도 다뤄보겠습니다. 아래 네 가지 항목을 참고하시면 좋겠습니다.
용례에 맞는 마크다운을 사용하자
노션에서 슬래시(/)를 치면 지원하는 여러 서식을 발견할 수 있는데요. 제목에는 헤더를, 중요한 알림에는 콜아웃을, 순서가 없는 리스트엔 불렛 리스트를 사용하는 식의 용례에 맞는 마크다운을 사용한다면 표준형에 가까운 문서를 작성할 수 있습니다. 특히나 누군가에게 보일 문서라면 이런 용례를 잘 활용해야 보는 사람이 이 정보가 어떤 종류의 정보인지 파악하기 쉬워집니다.
시각적 흐름이 예상가도록 하자
가독성을 챙기는 또 하나의 방법은 시각적 흐름을 안정되게 만드는 것인데요. 우리가 화면을 디자인하는 것처럼 문서도 일종의 디자인이 필요합니다. 문서에서 활용되는 여백이나 H값의 크기, 정보들의 적절한 생략과 확장 등이 활용되어야 전체적인 문서의 흐름이 예상가고 심미적 안정감도 생깁니다. 특히나 노션 특성상 가독성을 높이기 어렵기 때문에 시각적 흐름에 특히나 신경 쓰면 좋겠습니다.
두 번 이상 지속된다면 템플릿을 활용하자
앞에서 소개해드렸던 업무 일지나 회고록 등 모두 지속해서 n개 이상 생성하는 문서입니다. 따라서 생성할 때마다 매번 복사, 붙여넣기를 하는 것이 아닌 템플릿을 활용해 동일한 여러 개의 문서를 쉽게 생성합니다. 템플릿을 만들더라도 템플릿 자체의 수정이 가능하기 때문에 쓰다가 개선할 점이 있으면 언제든지 템플릿을 수정합니다. 이렇게 하다 보면 좀 더 나은 템플릿으로 진화되는 과정을 볼 수 있습니다.
직접 못하겠으면 가져다 쓰자
역시 모르겠으면 베끼는 게 짱입니다. 직접 템플릿을 만드는 게 어렵다면 아래 링크에서 나에게 맞는 템플릿을 가져다 활용해보세요. 사실 노션 템플릿은 용례만 다를 뿐이지 전체적인 틀은 크게 차이 나지 않기 때문에, 다른 템플릿을 스크랩하는 것부터 시작해도 좋은 출발점이 될 것입니다.
그럼에도 불구하고
노션 영업 글 같지만, 이 툴에는 단점도 많습니다. 검색과 데이터베이스, 알림 기능이 외에도 불편한 점이 많습니다. 그럼에도 불구하고 앞에서 나열한 장점들이 아직까진 충분하므로, 당분간은 계속 노션으로 문서화를 해보려고합니다. 여러분도 더 나은 문서화를 위해 노션을 활용해보세요!