사이드 프로젝트로 레벨업 하기 - 4장
비사이드 참여기 4. 기획 문서 작성
이전 장에서 서비스의 컨셉과 주요 기능을 정의했다. 이들을 실제 개발로 옮기기 전에 디자이너와 개발자가 제대로 업무를 하기 쉽게 판을 깔아 줘야 한다. 특히나 일은 나 혼자 하는 게 아니기 때문에 객관적인 문서로 남겨야 모든 팀원이 아이템 개발 방향에 대해 일관적으로 생각할 수 있다. 그 중 가장 자주 쓰이는 문서 5가지를 작성했다.
서비스 프로세스, 정책
주요 컨셉과 기능을 정했다면 사용자가 서비스 내에서 어떻게 행동을 하는지 루트를 설계해야 한다. 이때 사용자 권한, 서비스 정책을 고려해야 한다. 그러나 우리팀은 프로세스부터 설계했기 때문에 마땅한 서비스 정책이랄 것이 추상적인 아이디어만 있었을 뿐 구체적인 문서는 없었다. 따라서 프로세스를 하나둘씩 그려가는 과정에서 개인정보, 서비스 운영처럼 깊게 고민해야 할 내용들이 생각나면 장표 상단에 따로 메모했다.
프로세스는 Figjam으로 작성했다. 상단에 작성한 텍스트는 서비스 정책 초안이며 이 문서를 노션으로 디벨롭했다.
서비스 정책은 너무 중요한 문서기 때문에 노션으로 디벨롭하고 아카이빙했다.IA (Information Architecture)
서비스의 논리적 구조를 한 눈에 보여주는 문서다. 개발자 디자이너 할 거 없이 모든 팀원이 가장 많이 보게 될 문서 중 하나다. IA에 넣으면 좋을 화면ID, 작업 우선순위, 페이지 속성, 접근 가능한 사용자 타입, 본수를 넣었다. 히스토리를 남기기 위해 삭제한 화면 및 기능은 지우지 않고 취소선 처리를 했다.
특히 IA는 구조 특성 상 모든 화면 별 본수와 존재를 알 수 있으므로 IA 문서 우측에 진척도 Column을 추가했다. 진척도 체크 덕분에 어떤 화면이 작업이 필요한지, 완료됐는지 한 눈에 체크가 가능했다. 다만 팀원들을 수시로 쪼았기 때문에 무난한 진척도 체크가 가능했다..
하루냥 개발에 유용하게 사용했던 IA기능정의서
사람은 망각의 동물이다. 열심히 회의해서 결정한 사항도 시간이 지나면 까먹기 마련이다. 하물며 서비스 기능을 까먹는다면? 만약 팀원끼리 생각하는 방향이 다르다면? 재앙이다. 이 재앙을 막기 위해 기능정의서 문서를 만들었다. 아래처럼 문서를 작성했으며 높은 우선순위에 가장 난이도가 낮은 기능과 서비스에서 필수적이지만 시간이 다소 소요되는 기능을 배치했다. 비고에는 아이디에이션 내용을 적었으며 실제로 비고 내용이 기능에 많이 반영되어 논리적, 감성적으로 부족한 부분을 메꿀 수 있었다.
하루냥 기능정의서 최종본. 주로 서버개발자, 프론트개발자가 보는 문서다.화면설계서 (스토리보드)
모든 팀원이 가장 많이 보는 문서인 만큼 피그마 코멘트가 가장 많이 달렸고 수정도 많았다. 화면설계서는 디자인 되기 직전, 앞서 작성한 프로세스 흐름대로 화면을 그린다. 여기엔 그 어떠한 디자인도 들어가면 안 된다. 기획자가 디자이너의 감각과 사고를 방해할 수 있기 때문이다(이러한 이유 때문에 왠만한 화면설계서는 ppt로 일부러 못생기게 작성한다.). 실시간 협업을 위해 피그마로 작성해서 디자인적 요소를 100% 덜어내긴 힘들었지만 디자이너 팀원들에게 절대로 화면대로 디자인하면 안된다고 수시로 요청드렸다.
또한 개발의 편의를 위해 IA에서 정의한 화면 ID, 화면 경로, 접근 가능한 회원 타입을 명확하게 명시한다.
디자인적 요소가 거의 들어가지 않은 화면설계서. 다만 피그마 표 기능은 디벨롭이 필요해 보인다...다음 편에서는 '디자이너와 협업'을 다루겠다.
하루냥 앱 다운로드 링크
