스토리보드 작성시 필수확인사항

스토리보드는 어쩌면 아주 간단한 것이지만 그것이 어려운 이유는 바로 생각을 현실로 만드는 첫 단계이기 때문이 아닌가 합니다.

스토리보드는 말 그대로 작업을 할때 구상하는 스케치부터 포함이 됩니다.

스토리보드에서 파워포인트에 작성할때는 이미 모든것이 정해진 상태로 진행해야 합니다.

파워포인트에서 생각하면서 작업하는 것은 그만큼 효율면에서나 시간면에서 문제가 발생을 합니다.

스토리보드를 잘 만드는 방법은 저의 경우는 다음과 같이 작업을 합니다.

1. 분석
만들고자 하는 사이트에 대한 기본적인 분석을 합니다. 이때 분석은 두가지로 진행이 됩니다.
- 컨텐츠 분석 : 어떤 것을 Web에 담을 것인지에 대한 분석입니다.
- 디자인(UI) 분석: 어떤 형태로 고객들에게 제공을 하는지 Web상의 표현방법을 찾습니다.
이렇게 분석을 완료하면 그에 따른 기초 토대를 쌓습니다.
산출물 : 벤치마킹 자료, 요구분석서

2. 기초설계(IA)
흔 히들 기초설계부분을 건너뛰고 스토리보드 작업을 진행하는 경우가 많이 있습니다. 아니면 간단한 사이트맵 수준으로 정하고 작업을 하게 되는데 이때 이 부분에서 명확한 정의를 내리지 않을경우 스토리보드 작업시에 정책적 배려없이 뒤죽박죽 된다거나 심할경우 다시 스토리보드 작업을 해야 하는 상황이 나타납니다.
일단 분석에 따라서 기본적인 사이트 구조와 각 구조별 형태 즉 게시판 형태인지 단순한 웹페이지 인지 아니면 보다 개발적 이슈가 강한 것인지에 따른 기본적 정보를 작성하게 됩니다.
이때 나오는 정보를 가지고서 Naming 부터 메뉴 구조등 다양한 기본 사이트 구조의 설계가 완료가 됩니다.
산출물: 기초 통합 기획서

3. 상세설계-1(브래인스토밍)
이제 기초설계에 따른 상세설계를 하게됩니다. 그런데 상세설계를 바로 파워포인트에 하는 것은 오히려 시간적 효율성에서 상당한 손해를 가져오게 됩니다.
일단 파워포인트 작업을 들어가기 전에 구축해야할 컨텐츠에 대한 성격을 고려하고 기초 통합 기획서에 나와있는 형태를 확인하여 일단 손으로 빈 용지에 그려보는 작업을 해야 합니다.
머리속에 있는 것을 가장 먼저 스케치하듯 그리면서 고객에게 어떻게 접근해야 하는가에 대한 기본 UI 안을 그리고 그에 따른 각 컨텐츠 성격에 맞게끔 다양한 스케치를 하게 됩니다.
이렇게 스케치를하고 기본적인 구조를 파워포인트 문서로 작성해서 1차적 브레인 스토밍을 거칩니다. 이때 의견에 따라서 기존 구조를 잡을것을 확인하고 보강해 나갑니다.

4. 상세설계-2(스토리보드 작성)
이 렇게 브레인스토밍에 따른 구체화된 기본구조에 옷을 입히는 작업을 합니다. 즉 기본구조에 링크를 달고 설명을 해서 각 링크간 페이지에 대한 내용을 최대한 자세하게 작성을 하게됩니다. 단 이점에서 주목할 것은 자신의 언어가 아닌 팀원의 언어로 정의를 내린다음 이것을 통해서 스토리보드의 언어를 사용해야 하는 것입니다.
간혹 자신만이 아는 방식으로 스토리보드를 제작하고 만들고 난 다음에 다시금 제작할때마다 스토리보드를 설명하려 왔다갔다 하는 것이 아닌 바로 스토리보드를 이해하면 바로 작업을 들어 갈 수 있도록 해야 하는 것이 스토리보드의 핵심입니다.
그래서 스토리보드를 작성할때는 이전에 이미 기초통합기획서에 대한 내용을 명확하게 이해하고 그에 따른 작업으로 스토리보드가 진행되는 점을 팀원들에게 명확하게 설명을 해야 합니다.
그에 따라 내부적으로 운영하기 위한 스토리 보드를 작성하기전에 명시할 사항은 다음과 같습니다.
- 파일명: IA때 파일명명에 대한 사항을 명시하여 스토리보드에는 메뉴와 파일명이 일치하도록 함.
- 링크 : 링크 처리된 사항에 대한 표시(페이지구분, 파일명구분)에 대한 정책수립.
- 문서명명 : 해당 스토리보드의 문서에 대한 일정한 기준으로 문서명에 대한 정책수립.
- 문서버전 : 작업자의 스토리보드가 변경될때에 대한 버젼 관리에 대한 정책수립
위 사항을 팀원 각자에게 주지 시키고 디자인과 개발로 넘어가는 단계의 정책에 있어서 혼선이 생기지 않도록 위 사항에 맞게 문서를 작성해야 합니다.

5. 마무리
스 토리보드를 작성한 후에 반드시 1차 전체 검수를 하게 됩니다. 링크는 제대로 표시가 된것인지 파일명은 확실한지 전달자에게 해당 파일명에 대한 버전표시는 제대로 이루어지고 있는지 작업자에게 정확하게 도달되었는지를 반드시 확인해야 합니다.
스토리보드 하나에 디자인과 개발진까지 고려해서 생성하지 않을 경우 결국 스토리보드는 기획의도와는 상관없이 왜곡 될 수 있는 점 반드시 명심하셔야 합니다.
큰 줄기가 바뀌지 않도록 제공하며 반드시 하나의 스토리보드에 따른 작업진행하기전에 반드시 디자인, 개발의 인원을 모아서 전체 브리핑을 하게 됩니다. 이유는 바로 전체 브리핑을 하지 않을경우 각 파트별 문제사항으로 인한 스토리보드의 변경에 차질이 오게 되며 불필요한 작업으로 인한 시간 손실을 감수해야 합니다.
그래서 반드시 하나의 스토리보드에는 1차 브리핑을 통해 팀원들의 의견과 잘못된 사항에 대한 내부적 토의를 거치고 이에 따른 결과는 전체 프로젝트에 참여한 인원들이 알 수 있도록 합니다.

스토리보드는 팀원간의 작업을 위한 언어입니다. 자신만의 언어가 아닌 공통된 기준과 스타일을 통해 보다 원활하게 사이트의 구축을 이룰 수 있을 것입니다.