서비스 기획자가 문서 작성하는 법

도그냥의 서비스 기획 스쿨 책 리뷰4

출처: pixabay

111p분량의 내용 중 주요 설명을 재구조화해서 5p정도로 썼습니다.

문서설명이긴 한데 구체 사진 사례를 안올렸습니다.

책에 있는 문서 사례를 직접 보는 게 가장 좋습니다.

왜냐하면 본 리뷰&정리 글은 책을 대체하는 게 아니기 때문입니다.

책을 안 보신 분들에겐

"~~ 이런 내용의 문서가 필요하구나"로 이해하시면 됩니다.

책을 보신 분들에겐

"~~ 이렇게 간단히 정리되는 내용이구나"로 이해하시면 됩니다.

1. 문서 작성은 전략적 선택에서 나옵니다.

전략을 구현하기 위한 문서를 제작해야 합니다.

문서제작은 근본적으로 전략에 있어서 업무 진행 방식의 선택에서 나옵니다.

첫 번째 방식, 규모가 크고 정확함을 위해

절차와 분업이 중요한 워터폴은

최종적으로 화면설계서가 나옵니다.

스토리보드로도 불립니다.

다만 이 둘의 정확한 의미는 다소 다릅니다.

참고하여 적자면,

화면설계서는 화면을 구성하기 위한 기획 과정에 나오는 모든 문서를 포함하는 문서입니다.

스토리보드는 사용자의 서비스 이용 흐름을 보여주는 문서입니다.

영상편집의 스토리 보드와 맥락이 비슷합니다.

두 번째 방식, 규모가 작고 유연함을 위해

협업하는 스프린트가 중요한 에자일은

사용자스토리가 나옵니다.

이 두 가지 방식에 따라서,

네 단계 문서에서 기획자가 처리하는 양이 다릅니다.

어떻게 다른지 단계별로 소개합니다.

2. 네 단계의 서비스 문서 작성 단계

첫째, 공유된 서비스 전략 기획서를 바탕으로

서비스의 프로세스를 정리합니다.

프로덕트의 설계의 밑그림입니다.

이게 미준맵과 IA입니다.

둘째, 어떻게 얼마큼 구현할지 정했으면

이게 가능한지 비용은 얼마마나 드는지 개발자에게 물어야 합니다.

이게 요구사항 정의서입니다.

셋째, 개발자의 피드백이 끝났으면

서비스의 시각적인 모습을 가볍게 만듭니다. UI디자인입니다.

넷째, 워터폴이면 디테일한 화면설계서를 만듭니다.

애자일이면 가벼운 사용자 스토리를 그립니다.

다음은 각 단계의 문서를 어떻게 작성할지 구체적으로 적어봅니다.

3. 서비스 기획자의 문서 작성법

(1) 미준맵과 IA

미준맵은 도그냥님이 독창적으로 개발한 방식입니다.

무엇을 위한 방식일까요?

미준맵의 목적은

프로젝트 범위를 예상하기 위한 문서입니다.

본격적인 제품 설계를 위한 문서들을 그리기 전에 만듭니다.

왼쪽에서 시작해 오른쪽으로 뻗어나가는 마인드맵 형식입니다.

미준맵을 만들면 서비스를 기능과 데이터의 관점에서 더 쉽게 이해할 수 있습니다.

작성에는 크게 3단계가 있습니다.

첫째, 필요한 기능과 데이터부터 정의합니다.

필요한 기능, 데이터, 정책을 마인드맵에 써봅니다.

여기서 데이터 정책이란 데이터 활용 기준입니다.

ex) '인근 미용실 지도' 서비스를 생각해 볼 수 있습니다.

미용실 위치 표시하는 기능은,

내 위치 중심으로 반경 몇 미터 내의 영역을 표시해 줄 건지 정해야 합니다.

예를 들어 10분 내외로 걸을 수 있는 200m 정도 등의 근거가 필요합니다.

또한 정책을 만들 땐 서비스 운영과 관련된 제약사항을 떠올려야 합니다.

예를 들어 개인정보를 활용한다면 개인정보법을 고려해야 합니다.

둘째, 내부와 외부 사용자별 플로우를 정리합니다.

예를 들어

프로덕트-사용자 분류-필요기능분류-필요 데이터 분류 순으로

마인드맵을 가지를 확장해 나갑니다.

셋째, 정보구조도 그리기(Information Architecture)

첫째에서 기능과 데이터만을 보고 지도를 그렸습니다.

둘째에서 사용자가 무엇을 할지를 중심으로 지도를 그렸습니다.

셋째에서는 사용자가 기능과 데이터를 활용하는

'페이지'를 중심으로 지도를 그립니다.

이걸 IA라 부릅니다.

IA는 서비스프로세스 설계를 정리합니다.

고객의 화면+ 어드민의 화면까지 고려합니다.

미준맵 이외에 다른 문서도 있습니다.

'유저 플로우'는 실제 고객이 이용하는 순서에 따라 변화하는 UI를 보여줍니다.

이에 따라 크게 3가지 성질이 있습니다.

프로세스 설계보다 UI를 작업하는 과정에 편리합니다.

자연스러운 사용성을 개선하는 시점에서 필요로 합니다.

모바일 환경에 잘 쓰입니다.

마지막으로 IA를 작성할 때 주의점에 대해 정리해 봅니다.

-목적에 맞는 범위로 좁힌 것이 맞나?

전체를 설계하면 쓸 때 없이 양이 늘어나는 것을 막을 수 있습니다.

주니어들은 작은 기능의 구현 비용을 간과하는 경우가 많습니다.

-모든 케이스를 고려했나?

데이터의 모든 경우의 수에 맞는 기능을 만드는 겁니다.

어떤 데이터가 들어와도 이에 맞는 화면과 기능이 있어야 합니다.

밑그림을 그렸으면 개발자와의 소통을 해야 됩니다.

소통의 시작은 요구사항 정의서입니다.

(2) 요구사항 정의서

서비스완성에 필요한 기능을 리스트로 정리한 문서입니다.

전략에 있어 '서비스 운영 개발 요청서'는

타 부서가 기획자에게 주는 문서였습니다.

전략의 구현에 있어 '요구사항 정의서'는

기획자가 개발자에게 주는 문서입니다.

따라서 기능의 중요성, 방향성, 스펙에 대한 큰 그림이 그려져야 합니다.

큰 그림을 통해 개발의 구현이 되는지 안 되는지 개발자가 고민할 수 있도록 돕습니다.

책에는 빽빽하게 적힌 표의 형태로 사례가 제시되어 있습니다.

x축엔 다음과 같은 사항들이 있고,

y축엔 구체적인 사항들이 적혀있습니다.

-시스템 구분: 프런트 / administrator/ 기타 aPI Batch

-기능 신규 여부: 신규/기존 수정

-요구사항(기능) 번호: 모둘명, 숫자

-요구사항 명

-요구사항 상세설명과 분석

-비고: 다른 요청 사항과의 관계

-개발 수용 여부: y/n/보류

-완료 여부: y/n

이런 문서가 전달된 뒤 리뷰에는 전략적인 부분도 설명해

공감대를 형성합니다.

공감대를 위해 개발 리더의 사고방식에서 가장 중요한 2가지를 생각하면 좋습니다.

첫째, 기존 시스템으로 구현 가능한가?

둘째, 기존 시스템에 영향을 최소화할 수 있는가?

왜냐하면 코딩은 긴 글과 같기 때문입니다.

수정하면 할수록 복잡해지고, 문제가 생길 수 있습니다.

(3) UI 디자인

UI부터 그리지 않습니다.

시장, 사용자 등을 분석하여 도출한 전략을 먼저 생각합니다.

그리고 이를 염두하며 논리적으로 사용자의 어떤 문제를 해결하는지 생각합니다.

그러므로 사용자 경험, UX에 대한 이해가 중요합니다.

이해를 할 땐,

데이터 검증 없이 상식에 의존하거나

'테스트'를 위해 UX를 경험하면 안 됩니다.

예를 들어 자기돈을 쓰면서 테스트하는 거랑

테스트를 위해 돈을 안 쓰면서 테스트하는 것과는 큰 차이가 있습니다.

이러한 전략과 UX이해를 바탕으로 디자인을 설계합니다.

5단계의 문서들이 있습니다. 차이점을 적어봅니다.

다섯째로 갈수록 디자인 완성도가 높아지는 경향이 있습니다.

첫째, 스케치: 손으로 빠르게 밑그림 그립니다.

여러 디자인을 가장 저비용으로 그려봅니다.

둘째, 와이어 프레임: '선'으로 이루어진 프레임 구조를 말합니다.

스케치보다 구체화되어있습니다.

구체화 내용은 크게 세 가지가 있습니다.

UI구조(생김새), 기능, 단순화된 콘텐츠가 있습니다.

셋째, 목업: 겉으로 보이는 게 중요합니다.

UI가 2D 형태로 만들어져 있습니다.

목업의 프레임에 스타일, 컬러, 정렬, 실제 콘텐츠가 입혀져 있습니다.

넷째, 아트보드: 해상도별로 나란히 펼쳐놓은 겁니다.

혹은 나란히 서비스 순서대로 화면을 펼쳐 놓은 겁니다.

다섯째, 프로토타입: 사용성 테스트를 위해 완성본이 움직여야 합니다.

왜냐하면 서비스 프로세스와 디자인까지 검증해야 하기 때문입니니다.

이에 반해 다른 의미도 있습니다.

서비스 콘셉트를 검증입니다.

이때는 목업형태로 간단히 표현하면 됩니다.

5가지의 차이점을 알아보았습니다.

구체적으로 그리는 사례와 방식은 책에도 간략합니다.

따라서 인터넷에서 키워드를 검색해 보기를 추천드립니다.

디자인 견적이 나오면 개발자와 함께

본격적으로 구현할 문서가 필요합니다.

이를 위한 문서가 화면설계서입니다.

(4) 화면설계서

화면설계서의 핵심은,

문서를 쓰기까지의 과정 모두를 담아내는 것입니다.

전략 수립, 전략에 따른 구현 방안이 나와야 합니다.

구현 방안의 수준에 있어 화면의 UI 구조만을 담지 않습니다.

'디스크립션'이라는 글쓰기도 해야 합니다.

글쓰기는 구체적으로 어떤 맥락에서 이 기능이 필요한지,

어떻게 사용하는지까지 적습니다.

책에는 화면설계서의 핵심적인 6가지 요소가 있습니다.

첫째로 배경이 되는 내용을 적습니다.

-수정이력 관리: 표 구조로 수정된 날짜, 버전, 내용, 수정자를 기록합니다.

-기획의도: 전략과 지표인 KPI를 작성합니다.

둘째로 개발 밑그림을 위한 프로세스를 그립니다.

제가 이해하기론 앞에 설명했던 미준맵과, IA를 말하는 것 같습니다.

-프로세스 플로우 차트: 서비스의 사용자별 혹은 케이스 별 프로세스 플로우입니다.

왼쪽에서 오른쪽으로 가지를 만들어 나가는 마인드맵 형식을 떠올리면 됩니다.

-수정 및 신규 IA

-화면이 없는 형태로 개발되는 대상을 적습니다.

예를 들어 API가 있습니다.

셋째로 구체적인 UI구현을 그립니다.

-와이어프레임을 상황별로 세분화해서 작성합니다.

-또한 디스크립션(기능명세서)을 와이어프레임에 숫자를 매겨 적습니다.

여기서 화면순서를 보여줄 때 2가지 방식이 있습니다.

모두를 한 장에 빼곡히 보여주는 방식이 있습니다.(Full case description)

복잡합니다.

이에 비해 더 깔끔하게,

케이스 별로 분리해서 보여주는 방식도 있습니다. (Case descrption)

또한 화면설계서는 전략구현의 핵심이기에 쉽지 않습니다.

좋은 디스크립션은 기능에 대해 구체적으로

모든 경우의 수를 생각하며 써야 되기 때문입니다.

쉽지 않기에 주니어들은 회사 선배 문서들을 참고합니다.

참고하더라도 협업을 하며 계속 개선됩니다.

개선을 위해 개발자들과 계속 질문을 주고받습니다.

질문을 주고받으며 크게 3가지 사항에 대해서 체크합니다.

예외 처리: 정상적으로 기입되지 않은 상황의 경우,

기입해 달라는 문구를 적는 등 차선책을 마련합니다.

분기 처리: 1개의 페이지가 유형에 따라 다르게 나와야 합니다.

ex) 10% 할인, 1000원 할인

정합성 체크: 데이터 처리 규칙에 맞는지 체크합니다.

ex) 숫자 항목에 글자를 넣는다거나

누락되었을 때 다음 프로세스로 넘어가지 않도록 확인하는 것.

(5) 사용자 스토리

에자일은 유연하기 위해 빠른 제작&검증을 합니다.

따라서 체계적 과정보다 기본적인 이해를 바탕으로 빠르게 진행합니다.

기획자가 제시한 명확한 방향성만으로 각자의 포지션에서 자율적으로 진행합니다.

이는 과정이 명확한 화면설계서 방식과 다릅니다.

어떻게 다른지 간단히 과정을 적어봅니다.

첫째, 우선 서비스 기획자가 콘셉트를 위한 프로토 타입을 준비합니다.

둘째, 이 방향성을 바탕으로 협업자들이 규칙에 맞게 각자 사용자 스토리를 만듭니다.

일반적으로는 포스트잇을 사용합니다.

아래는 책에 있는 사례입니다.

[사용자 스토리 주요 내용]

-제목:

-주내용:

사용자: 나는 누구누구인데~

사용자의 목적: 무엇을 위해 ~

서비스 목표: ~가 필요하다.

-완성기준:

중요한 특성은 기획자는 방향성만을 제시합니다

따라서 구체적 UI 등은 디자이너가 해결합니다.

셋째, 각자의 많은 케이스의 스토리들을 모아 '사용자 스토리맵'을 만듭니다.

스프린트 업무 단위를 산출해 내는 방법입니다.

스토리맵은 사용자 플로우에 따라 과업을 정합니다.

그리고 이를 위한 기능들을 우선순위로 정리해 표로 만든 겁니다.

첫 줄엔 사용자 플로우가 있습니다.

그다음 줄엔 플로우를 만족시킬 상위 기능 있습니다.

그다음 줄들에는 높은 우선순위대로 디테일한 기능들이 있습니다.

예를 들어 간단히 유튜브를 들 수 있습니다.

시청자를 기준으로 추천 영상 시청, 영상 평가, 영상 검색 등의 사용자 과정이 있습니다.

이를 첫 줄에 네모 박스로 가로로 띄엄띄엄 적습니다.

그러면 바로 다음 줄에

'추천 영상 시청을 위한 에픽 과업' 박스들을 배치합니다.

추천영상 보기, 광고 등 각 과정당 두세 가지의 에픽이 있습니다.

마지막으로 그 아래엔 작은 사용자 스토리를

세로 방향의 우선순위대로 놓습니다.

우선순위 별로 디테일한 과업들이 나열되어 있습니다.

시선에 따라 스크롤 내리기,

추천 영상 미리 보기,

추천 영상 누르기,

광고보기 등입니다.

이걸 실행하는 계획을 시간순으로 정리한 게 '칸반보드'와 '번다운 차트'입니다.

칸반보드는 해야 할 일, 하고 잇는 일, 완료한 일 순으로 3 등분하여 봅니다.

그리고 3등분의 내용물인 백로그를 진행상태에 따라 이동시킵니다.

효과적 이동을 위해서 중요도에 따라 포인트를 설정할 수도 있습니다.

포인트를 기반으로 각 작업자에게 포인트만큼 업무를 분배합니다.

이렇게 숫자가 들어가면 그래프를 통해 시각적으로 조망할 수 있습니다.

번다운 차트는,

주어진 포인트를 얼마큼 빠르게 처리해 내는지 볼 수 있게 하는 그래프입니다.

X축이 날짜고 Y축이 총포인트 입니다.

왼쪽에서 오른쪽으로 날짜가 진행될수록 전체 Y축이 줄어듭니다.

즉 시간별로 얼마큼의 중요도 있는 백로그를 완료할 수 있는지 한 번에 볼 수 있습니다.

4. 더 좋은 문서를 만들기 위해

회사의 서비스의 시스템을 잘 파악하면 더 좋은 문서가 나옵니다.

이를 위해 전체 프로세스를 정리하고, 부족한 디테일은 질문해야 합니다.

크게 4단계입니다.

첫째, 기존 정책 문서를 읽습니다.

둘째, 스토리 보드와 화면을 차례로 봅니다.

셋째, 프로세스를 이해하기 위한 기능을 테스트합니다.

넷째, 직접 프로세스 도식 만들고 이해 못 한 구멍은 질문합니다.

지금까지 전략의 구현을 위해 문서 장성법을 이야기했습니다.

이젠 만들어진 문서를 바탕으로 협업하며 구현하는 이야기를 해봅니다.

미준맵과 IA -> 요구사항정의서 -> UI디자인 -> 화면설계서 or 사용자 스토리