기획서(SB) 쓰는 법 (1)
안녕하세요. 연두씨입니다.
기획자로서 많은 내용들을 정리하고 많은 문서들을 쓰지만, 그중에서도 제일 많이 쓰는 문서가 스토리보드 일 거예요.
기획서라고 부르기도 하고 SB라고 줄여 부르기도 하고 화면 정의서라고 하기도 하는.
용어야 뭐 어떤 용어를 쓰든지 크게 상관은 없을 것 같고요, 그 기획서에 대한 이야기를 해보고자 합니다.
먼저, 기획서의 역할은...
1. 계약서 같은.
아파트나 차 계약할 때 얼마큼의 옵션을 얼마의 가격으로 하겠다는 합의의 내용이 들어 있잖아요.
그것처럼 이번 개발 분량과 요건에 대한 최종 합의 내용을 기록하여 개발 시, 혹은 개발 이후 이게 왜, 어떻게 개발되었는지 알 수 있도록 합니다.
2. 설계도면 같은.
조립식 가구를 사면 어떻게 조립하는지 설명서가 나와 있잖아요. 그것처럼 실제 디자인-퍼블리싱-개발을 할 때 어떻게 할지 설명서 역할을 합니다. 안 보고 개발하는 사람도 많지만, 사실 이거 보고 개발하는 게 맞아요.
3. 시뮬레이션의.
건축할 때 보면 스티로폼으로 모형을 한번 만들어 보잖아요. 축소된 모형으로 실제 건축이 완료가 되었을 때를 예상해 볼 수 있도록요. 그것처럼 미리 기획서를 써서 시뮬레이션해 볼 수 있는데 여기서 두 가지를 얻을 수 있어요.
하나는 실제로 제작이 되었을 때 문제가 없는지 모의 동작을 통해 가늠해보고 부족한 것을 채우고요
두 번째는 제작을 할 때의 분량과 시간을 가늠할 수 있어요.
이러한 역할을 거꾸로 얘기하면, 그게 바로 기획서를 쓰는 법이 되겠습니다.
-왜 개발하게 되었는지, 어떻게 개발할지 목적과 요건을 잘 기록하고
-디자인-퍼블리싱-개발 때 헷갈리지 않도록 디스크립션을 성실히 달아야 하고
-시뮬레이션을 통해 빠진 화면 없이 꼼꼼히 리체크 해서 완성시키면 되겠습니다.
기획서를 쓸 때 제가 개인적으로 생각하는... 하지 않으셨으면 하는 것들은요.
1. 무턱대고 화면부터 그리지 않으셨으면 합니다.
기획서도 문서이고, 문서는 기록하고 여럿이서 그 내용을 공유하려고 하는 건데 날짜도, 작성자도 없고, 개요도, 수정 이력도 없이 그저 화면만 뚝 있는 기획서는 정말이지 반쪽짜리 기획서입니다. 반도 아니고 25%짜리.
화면을 얼마나 예쁘게 그리고 배치하느냐보다 중요한 것은 필요한 정보가 다 들어 있는지라고 생각돼요.
2. 나만 알아볼 수 있는 문서를 쓰지 않으셨으면 합니다.
물론, 기획서를 보면서 리뷰를 하긴 하지만 정말 좋은 문서는 말로 설명을 더하지 않아도 아웃풋만으로도 모두가 이해가 되는 문서라고 생각돼요. 여럿이서 보면서 이해하고 그 기준으로 작업해야 하는 만큼 명확하고 상세하게, 간결하지만 빠짐없이 다 들어 있는 기획서가 되도록 노력이 필요합니다. 괜히 복잡한 말이나 쓸데없는 용어로 허세 부리지 말고 모두가 쉽게 이해할 수 있도록 하는데 중점을 두었으면 합니다. 이게 사실은 용어를 많이 쓰는 것보다 훨씬 더 어려운 일인 것 같더라고요.
저는 개인적으로 잘 썼다고 생각하는 문서는 제가 아무런 배경지식 없이 그냥 보고 그 의도와 개발 분량을 다 알겠는 문서예요. 이쁘게 알록달록 그려진 ppt보다 대충 그려졌어도 모든 요건이 다 보일 때 더 감탄하게 되더라고요.
3. 디자인을 하지 않으셨으면 합니다.
잘 배치되고 미려하게 꾸며진 화면들은 이해를 돕기에 쉬운 방법이긴 하지만 기획서는 완성된 화면을 만드는 것이 목적이 아니라 각각의 담당자들이 이 문서를 보고 작업을 하여 완성된 화면을 만들 수 있게 하는 게 목적입니다.
문서는 가벼워서 공유가 쉽게 하고 내용은 명확하여 문서만으로도 이해가 되며, 필요한 정보는 모두 있게 하고, 불필요한 프로세스나 추가가 필요한 항목들을 체크할 수 있도록 글과 그림이 잘 배치되어 있어야 함이 먼저입니다.
디자인되어 있는 걸 캡처해서 넣지 마세요. 캡처가 나쁜 게 아니라 그림파일이면 문서가 무거워지고 바로바로 수정이 필요할 때 어렵잖아요. 이미 디자인이 끝난 아웃풋에 디자인 수정사항을 넣어야 하거나 기능만 넣으면 되는 경우는 다르지만, 그냥 생 기획서 쓸 때 어디다가 따로 그려서 그걸 다시 캡처해서 사이즈를 줄여서 붙이는 방법은 운영 이슈 상 효율적이지 않은 것 같아요.
글에서 저는 문서라고 표현을 했는데, 프로그램을 통해 기획서를 쓸 때에도 혹은 프로토타입 툴로 만들 때에도 똑같아요. 분명 목적과 요건에 대한 기록을 남기는 공간이 있을 것이니 프로토타입에서도 그런 부분들을 잘 기록하고, 굳이 디자인을 업로드하여 파일 자체를 무겁게 만들 필요는 없어요. 프로토타입일 때 특히 더 완성된 아웃풋을 만들어야겠다는 욕심이 스멀스멀 생기는 것 같아요. 기능도 많고 더 막 유려하게 표현되니까 욕심이 막막 자라나서 정신 놓고 하다 보면 프로토타입 그 자체를 잘 만드는 것에 너무 매몰될 때가 있어요.
프로토타입은 어디까지나 최종 아웃풋이 아니니 목적에 맞게 시간과 리소스를 쓰시면 좋을 것 같아요.
이번 글에서는 개괄적인 쓰는 법에 대해서 말씀드렸고요, 다음 글에서부터 장마다 반드시 들어가야 하는 요소들과 파트(?)마다 작성법을 보다 상세히 써 보겠습니다.
