기획 업무, 문서 작성 이렇게 해보자

모든 문서를 작성하기 전에 양식(형태, 레이아웃, 기준)을 갖추는 작업을 먼저 할 것이다.
화면 설계서도 예외는 아니다.

다양한 문서를 보면서 가끔 자신만 알아볼 수 있게 작업하는 경우가 종종 발견된다.

• 주어진 템플릿을 그대로 이용하는 케이스
• 우선 내용부터 채우는 케이스

명확한 기준을 세우지 않고 작업하는 경우, 중구난방으로 문서 작성이 시작되어 헤매기 십상이다.
또한 완성된 결과물은 자신을 위한 문서가 될 뿐, 리뷰자들이 보기 어려워진다.

모든 문서는 문서를 보는 사람에 맞게 작성해야 되는 원칙을 지켜야 한다.
그래서, 틀을 갖추는 이야기를 하고자 한다.

 

---

 

첫 번째, 표지에 "제목"과 "부 제목", "작성자"를 기입해라.

 

내가 다니던 회사의 공식 형태는 아래와 같다.

< 좌 : 회사 샘플 , 우 : 필자 샘플 >

주 제목과 부 제목의 가중치를 고려해보면,

[주 제목]에는 본 문서를 대표할 수 있는 내용이 들어가야 할 것이고, 
[부 제목]에는 이 문서가 무엇과 관련 있는 정보를 표시하면 될 것이라 생각한다.

그리고 작성자는 소속만 명확히 할 수 있으면 된다고 생각한다. 문서는 담당자가 변경되면, 이력에서 작성자를 확인할 수 있기 때문에 굳이 전면에 내세워 수정을 할 필요가 없다고 생각하기 때문이다.

한 발 더 나아가서 클라우드에 공유를 하거나 협업 툴을 통해 공유할 때
업로드된 문서의 썸네일 이미지까지 고려할 수 있어야 한다.

반응형

< 위 : Slack 에 문서 공유,&nbsp; 아래 : 구글 드라이브에 업로드(썸네일 보기) >

 

필자는 개인적으로 왼쪽 정렬이 깔끔하여 선호하는 편이지만, 구글 드라이브를 사용한다면, 썸네일을 고려하여 가운데 정렬을 하는 것도 좋다. 또한 아직 한글 지원이 미흡한 서비스라면, 영어를 선택하는 것도 좋은 선택이 될 것이다.

폰트 크기는 40 이상이면 잘 보인다.

 

 

---

 

 

두 번째, 이력(버전) 관리 페이지를 만들어라.

 

가장 귀찮은 일이며, 그냥 하기 싫다. 

대부분 v1.0 제정, v.0.1 초안에서 끝나는 경우를 많이 봤다. 필자도 그중 한 놈이다. 너무나 완벽한 문서를 만들었고, 이후 수정 배포할 일이 없다면 다행이지만, SW는 유연하게 변화할 수 있어야 하기 때문에 문서 또한 변경이 자주 발생하게 된다.

이력관리를 당연하게 생각하고 겸허히 받아들이길 바란다.
아래 샘플은 필자가 최근에 작성한 문서에서 갈무리해왔다.

< 모바일 화면설계서 이력관리 페이지 >

 

필자는 문서에 이력은 관리는 하고 있지만 버전을 별도로 명시하지 않는다.
문서 버전과 개발 버전이 미스 매치되는 경우가 발생할 수 있어 혼란을 줄 수 있기 때문이다. 
버전은 제품 릴리즈 이후, 문서 표지의 부 제목에 제품 릴리즈 버전과 동일하게 맞춰주어 연결성만 유지한다.

변경 내용은 문서를 보는 모두가 쉽게 알아볼 수 있는 내용만 함축적으로 표시한다.
 - 정책 변경 사항
 - 화면 코드 + 액션 (추가, 삭제, 변경)

페이지 번호는 매번 변경될 수 있으니 가급적 지양하길 바란다.

 

검토자와 리뷰자 항목은 책임 분담용으로 기입해 둔다.
리뷰록이나 회의록이 작성되었다면 링크로 근거를 남겨두는 것도 좋은 방법이 될 것이다.

비고는 자유롭게 작성하기 위해 칸을 두었다. 필자는 TAG 라는 표현으로 수정 부분을 찾아갈 수 있는 키워드를 명시해 둔다. 이력 관리의 꽃이라면 변경 사항을 바로 찾아가서 확인할 수 있는 TAG 라고 말하고 싶다.

단, PPT 에서 표를 작성한다는 것은, 컴퓨터의 매우 큰 메모리 리소스를 쓰겠다는 것과 같다. 표 안에 글을 작성하는 것은 상당히 버벅거릴 것이다. 

텍스트 상자로 템플릿을 만들어보는 것이 정신건강에 이로울 수 있다.

 

 

---

 

 

세 번째, 사이트 맵을 작성 해라.

 

비즈니스 플로우를 작성할 때, 화면 코드를 이미 작성했다면 문제는 없으나, 그러지 않았을 경우 이제 작명 센스를 키워보자.
아래 예시를 보면 필자는 "[ ]" 안에 이미 화면 코드를 작성해 두었다. 코드 기반으로 레벨 구조를 잘 표한하도록 사이트맵을 구성하면 된다.

 

< 비즈니스 플로우 예시 >

 

 

아래 사이트맵은 필자가 작성한 사이트맵이다. (미적 감각이 좀 떨어지는 듯..)
예시로써 몇 가지 팁을 공유한다.

 

 

 

 

우선 사용한 도형은 2가지가 있다.

화면과 화면과 화면 사이를 이어주는 주요 기능을 표현하고 있다.
앱의 흐름이 한 방향으로만 흐르고 끝나면 화면만 표시하면 된다.

하지만, 대부분 홈에 접근하고 나서 여러 갈래로 뻗어 나갈 수 있기 때문에 반드시 어떠한 조건, 기능을 통해서 이동한다면 화면과 다른 도형으로 브릿지를 만들어 준다.

 

 

화면 코드 작성에도 센스가 필요하다.

1. 종속(레벨) 관계를 표현한다.

사이트맵 내에서는 종속관계가 명확히 알 수가 있지만 세부 화면에 대한 페이지에 접근했을 때, 내비게이션 정보를 표시하지 않으면 어디서 접근한 화면인지 헷갈릴 수 있다.

문서는 내가 만들지만 문서를 보는 사람은 내가 아니라는 것을 꼭 명심해야 한다.

 

2. 코드의 통일성을 부여한다.

필자는 명사형을 선호한다. 화면은 명사로 작성을 하고 버튼은 동사로 작성하는 것이 글로벌화 진행 시, 번역에 용이성을 가지게 된다. 

또한, 띄어쓰기보다는 "-" 하이픈(또는 "_" 언더바)을 이용하는 것이 디자인/개발 코드와 통일성을 가질 수 있다. 

필자는 문선 내 가독성을 위해 "_" 언더바 보다 "-" 하이픈은 이용한다. 보통은 "_" 언더바를 많이 사용하게 될 것이다. 

 

- or _

문서 내에서 하이픈을 애용하는 필자. (개취) 강조를 위한 언더라인 또는 하이퍼링크가 걸릴 경우 문서 내 가독성이 떨어진다

 

 

나만의 순서도 작성하기 (feat, 범례 & SW기획자)

 

---

 

 

네 번째, 목차를 작성해라

 

인덱스를 문서를 다 작성하고 나서 만드는 후배를 봤다. 
인덱스를 만들면서 문서의 순서를 변경하고 인덱스를 수정하고 문서 순서를 변경하고.... (반복)

목차의 작성은 필요 없는 리소스 낭비와 스토리를 가진 문서, 즉 기본이 탄탄한 문서의 시작이다.
(가급적 목차 순서대로 문서를 작성하세요.)

이제 작성된 사이트맵을 가지고 목차를 구성한다.

들어가기 / 홈 / 설정 / 메인 기능 등.... 제품(서비스)에 맞게 순서를 정한다. 뜬금없이 메인 기능부터 작성하면 문서를 보는 사람은 앞뒤 연관성을 알지 못해 문서를 헤매게 될 것이니 스토리 연계성을 잘 고려하기를 바란다.

필자는 크게 3개로 구분하여 순서대로 작성을 한다.

• 들어가기 : 홈(메인)에 도달하기 전까지, 스플래쉬, 로그인, 워크스루, 가이드 등...
• 메인 기능 : 홈(메인)과 서비스가 제공하는 가치를 기능 단위로 묶어서 표시
• 설정 기능 : 설정, 앱 정보, 로그인 정보 등...

이런 습성은 사이트맵에서도 잘 드러난다.
그래서 후배 기획자들의 화면설계서를 볼 때 목차와 사이트맵을 보고 이 친구가 말하고자 하는 스토리를 예측하고 리뷰를 진행한다.

목차(인덱스) 페이지는 별도의 템플릿이 필요 없다. 필자도 목차는 매번 형태가 바뀐다. 구조와 순서만 잘 갖추면 된다.
가끔 후배는 각 목차별로 서브 페이지를 넣어 링크를 걸어주기도 한다.

 

---

 

 

다섯 번째, 용어 및 약어 페이지 추가 (선택 사항)

 

모든 프로젝트에는 용어집이 갖추어져 있을 것이다. 그래서 굳이 화면설계서에 넣을 필요까지는 없다고 생각한다.
단, 문서 작성자가 용어집의 용어를 제대로 쓴다는 가정으로

그래도 누군가 요구한다면 넣어줘야 할 것이다.

용어 및 약어가 중요한 가장 큰 이유는 바로 통일성이다.

똑같은 기능을 수행하는 A를 "A1", "A2" 두 단어를 혼용하여 문서를 작성했다고 가정한다.
- 의사소통의 어려움을 겪을 것이다.
- 리뷰자들은 A1과 A2가 다른 기능이냐 물어볼 것이다.
- 문서 작성자는 편집을 위해 A1과 A2 를 따로따로 찾아서 수정해야 할 것이다.

 

예시, 용어집

 

필자는 용어집 소스를 복사하여 문서의 한 페이지에 붙여넣기 한 후,

문서를 작성하며 찾기(Ctrl+F)를 통해 정의된 용어인지 확인 후 가져다 쓴다. 만약, 정의되지 않은 용어가 추가된다면, 역으로 용어집을 업데이트하면 된다. 문서 작성이 완료되면 용어집 기반으로 문서를 검토하여 혼용되어 잘 못 쓰인 용어는 없는지 확인하는 습관을 기르길 바란다.

문서 작성자는 반드시 하나의 기능을 2개의 용어로 사용하게 만드는 일을 만들지 않아야 한다!
- 기능, 버튼 레이블, 화면 이름 등..

---

마무리

• 표지 구성 : 주제는 제목, 관련성은 부제목, 작성자, 가운데 정렬
• 이력 관리 : 화면 코드 기반 함축적 표시, TAG로 찾기
• 사이트맵 : 네이밍 규칙을 갖는 화면 코드, 레벨 구조
• 목차 : 순서(스토리)를 갖는 구조화
• 용어집 : 용어 통일

 

기획업무, 화면설계서 체크리스트 만들어 보기

기획자도 개발을 알아야 한다. 기획자의 개발 용어 알아가기