기획 - 서비스 기획에 관련한 산출물

안녕하세요. 기획과 문서는 때놓고 싶어도 땔 수 없는 관계라고 생각이 듭니다.

기획이라는 분야가 사실 스페셜리스트보다는 제너럴리스트에 가까운 편입니다. 어떻게 보면 쉽게 접근할 수 있죠.

그 속에서 매니징을 하는 것은 특별할 수 있겠지만요. 그래서 더욱 산출물(문서)를 남겨야 한다고 느낍니다.

생각이라는 것이 워낙 휘발적이고 생각나는 것도 갑자기 느낌표처럼 나타났다가 또 잃어버리곤 하니까요.

 

그래서 이번엔 대표적으로 기획에 관련된 산출물 몇가지에 대해서 나열 해보려고 합니다.

---

서비스 정책서입니다.

딱딱하게 어떤 느낌인지 나열을 해보죠.

• 서비스에 적용될 수 있는 법적인 요소를 모두 고려하여 작성된 정책 문서
• 기획된 서비스의 법적 가능 여부, 이슈 및 규제 제한 사항 등 관련 법령에 대한 정리
• 산업 생태계 등 여러 외부 환경 요인 및 경쟁사 분석, 타사 정책, 차별화 전략 등을 설정함
• 프로젝트의 규모와 비용, 내부 개발 인력 등 전반적인 내용을 포함함

사실 서비스 정책서라는 이름을 가지고 있는 문서는 너무 범위가 넓습니다. 

회사마다 다르기도 할 것이고요. 사람마다도 다를 것입니다. 위에 있는 여러가지 목록 중에서 몇가지를 꼽아서 원하는 목적에 맞게 작성을 한다고 생각하면 될 것 같습니다. 

발빠르게 성장하는 회사에서는 이런 앞 단계의 문서는 가볍게 하는 것 같기도 합니다.

---

정보 계층구조도(Information Architecture)

IA라고 불리는 정보구조도 입니다.

문서가 아무리 간소화 된다고 하여도 IA가 띄는 목적을 잃는 곳은 많이 없다고 생각 됩니다.

물론 케이스가 여러가지 있겠지만요..?!

• 서비스가 어떻게 구성되는지, 어떤 기능이 어떤 화면으로 보이는지, 전체적인 서비스 설계를 정리하는 문서 혹은 도구
• 서비스의 구조의 틀을 보여주어, 디자이너와 개발자가 구현할 수 있도록 작업할 수 있도록 만든 문서
• IA는 사용자, 콘텐츠, 시나리오를 고려하여 작성
• 기능에 따른 검토와, 일정 산출이 용이함.

제가 작성한 예시를 가볍게 넣어보자면

위와 같이 처음 단계부터 차곡차곡 쌓이는 구조도라고 생각하면 됩니다. 

고객이 우리의 서비스를 만졌을 때 어떻게 들어갈 수 있는지에 대해서 전부 나열한다고 생각하면 편할 것 같습니다.

---

기능 명세서 (기능 정의서)

새롭게 기획되거나 추가되야할 기능에 대해서 소통을 위한 문서입니다.

주로 개발자들과 이야기가 되는 문서라고 생각하시면 편할 것 같습니다.

• 기획한 기능에 대해 개발자와 소통하기 위한 문서로, 개발자에게 기획한 기능을 구현해 달라고 요청하는 문서
• 기획자가 만든 '무엇(기능)'을 '어떻게 만들어야 하는지(개발로 구현)'에 대해 정리한 문서
• 기능 명세서 내에는 ID, 페이지, 기능 설명, 버전/수정 이력 등이 포함됨
• 정해진 양식은 없으며, 프로젝트, 팀, 기업 내에서 협의하여 양식을 정함 (대체로 엑셀/스프레드시트 등의 표 형태로 작성)

제 개인적인 생각으로는 이 기능 명세서야말로 정말 정해진 것이 없다고 생각됩니다. 정말 가볍게 전달하기도 하고

무거운 기능이라면 길어지기도 하고.. 어디는 피그마 어디는 엑셀로 작성합니다.

하지만 분명한 것은 자신이 원하는 바를 최대한 상대방이 알아듣기 쉽게, 명료하고 정확하게 작성해야하는 것은 중요합니다.

---

화면 정의서(Story Board)

스토리보드의 단계까지 왔다면 일의 진척이 많이 진행된 상태라고 생각이 됩니다.

더욱 견고한 사용자 경험을 위해서 자세하고 꼼꼼하게 설계해야할 부분이죠.

이 화면을 바탕으로 서비스가 도출될 경우가 높으니까요.

• 화면 정의서는 와이어프레임(화면)과 기능 구현을 위한 기능 명세서(or 기능 정의서)를 함께 정리해 놓은 문서
• 화면 정의서의 목적은 최종적으로 유저에게 보일 화면의 모습을 작성하는 것
• 화면 정의서는 서비스에 대한 전체적인 방향성이며, 모든 과정에서 세세한 부분까지 체크할 수 있도록 하는 문서

여기서 주의해야할 점은

와이어프레임과 스토리보드의 차이라고 생각됩니다.

사실 말로 풀기 좀 어렵지만 대충 풀어보자면 와이어프레임은 말 그대로 대~충 여기에는 이게 있고 저기에는 저게 있을 거다.

같은 정말 대략적인 스케치? 언제든지 지워질 수 있는 것입니다.

와이어프레임 정도의 수준을 그리고 디자이너에게 가서 이대로 해주세요! 하면 정말 난처할 겁니다.

 

스토리보드는 기본적으로 디자인 레이아웃을 짤 수 있는 수준이며, 개발자와 디자이너가 모두 확인 가능한 정보와 기능에 대한 기술이 들어가야 합니다. 부가적으로 개별적인 요소에 대해서 디자이너에겐 디자인적인 고민이, 기능에 대해선 개발자가 개발적인 고민이 녹아들어 갈 수 있다면 좋다고 생각됩니다.

견고하고 자세하게 쌓아갈 수록 좋은 사용자 경험을 도출할 수 있다고 생각 됩니다.

 

이런 산출물들이 견고하게 나올 수 있는 바탕은 더욱 초기로 돌아가서 전략부터라고 생각 됩니다.

그 때의 생각과 노력들이 바탕이 되는 것이기 때문이라고 생각합니다.

건물을 지을 때에도.. 초기 공사가 중요하다고 하듯 마찬가지라고 생각됩니다.

 

가볍게 읽으시면서 자신이 맡고 있는 단계에서 가져가야할 것에 대해서 상기해보는 글이었으면 좋겠습니다.