프로젝트의 최종 산출물, 스토리보드(Storyboard | SB)

2020. 6. 15. 14:38기획 ⛳️

안녕하세요, Jlight입니다.

이번 포스팅에서는 서비스 설계의 최종 산출물, 스토리보드(Storyboard | SB)에 대해 알아보겠습니다. 

 

그럼 본격적으로 들어가 볼까요❓

 

스토리보드(Storyboard | SB)란?

스토리보드는 디자이너 / 개발자가 참고하는 최종적인 산출물입니다. 서비스에 대한 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의 등 서비스 구축을 위한 모든 정보가 담겨있는 문서입니다. 

IA(Information Architecture)과 와이어프레임(Wireframe)이 서비스를 통해 서비스에 대한 전체적인 청사진을 그렸다면, 

스토리보드를 통해 어플리케이션의 정책부터 프로세스, 핵심기능에 대한 와이어프레임뿐만 아니라 예외. 오류 처리 등 전체적인 설계가 들어간 문서입니다.

 

※이전 포스팅에서 반복해서 이야기 하지만, 설계에는 정답이 없기 때문에 흐름을 이해하는 것이 중요합니다.

 

스토리보드는 보통 PPT 형식으로 작성을 합니다.

 

위 문서 안에는 다양한 정보를 포함하는데, 

 

1. 버전 정보 (Document History)

2. 서비스 정책 (Service Policy)

3. 정보 구조도 (Informatiom Architecture)

4. 와이어프레임 (Wireframe)

5. 기능 프로세스(Function Process)

6. 기능 디스크립션(Function Description)

 

이 6가지를 기본적으로 포함합니다.

 

 

1. 버전 정보 (Document History)

버전 관리

문서 앞단에 버전 정보를 넣습니다. 

처음 문서가 완성된 작성된 날짜를 기준으로 사소한 변경사항이 있을 경우 어떤 점이 변경되었으며

추가된 기능 혹은 제거된 기능 등 세세한 부분까지 작성을 합니다. 여기서 사소한 변경사항이 있을 경우 소숫점 단위로 숫자를 올립니다. ( e.g : v1.0 -> v1.1)

어플리케이션의 큰 기능 변화가 있을 경우 일단위에 숫자를 더합니다. ( v1.0 -> v2.0 )

 

버전 관리가 없거나 제대로 이루어지지 않는 경우 개발자와 디자이너가 수정된 사항을 알 수 없을 뿐만 아니라

이를 놓치고 개발 혹은 디자인 작업에 들어가 추후 결과물을 보고 뒤늦게 아는 불상사가 있습니다.

따라서 버전 관리를 통해 디자이너와 개발자에게 수정 사항을 명확히 전달함으로써 수정 및 변경사항을 수시로 체크하고

이를 놓치지 않을 수 있습니다. 이를 방지하고자 기획자는 스토리보드 앞단에 모든 수정 및 변경사항에 대한 작성을 해야 합니다.

 

 

2. 서비스 정책(Service Policy)

 

참고 : 유세균무기

 

법적인 요소를 고려하며 정책을 결정 및 문서로 작성 작성된 정책 문서를 공유하며 합의를 이룰 때까지 수정 및 피드백을 반복합니다.

 

관련 법령

기획에 대해 법적으로 가능한지, 저작권 이슈는 없고 규제에 막히지 않는지 관련 법령을 찾아야 합니다.

 

외부 환경 생태계

산업 생태계를 단숨에 바꾸기 어렵기 때문에 여러 외부 환경을 살펴야 합니다.

 

경쟁사

경쟁사를 살펴보며 Pain point를 분석하고, 타사 정책을 살피고, 경쟁력 및 차별화 전략을 설정합니다.

 

내부 환경 및 리소스

개발 인력, 프로젝트 규모 및 비용설정에 대한 전반적인 내용을 작성합니다.

 

 

3. 정보 구조도 (Informatiom Architecture)

작성된 IA 문서 

즉 서비스에 전체적인 구조를 포함합니다.

( IA관련 포스팅 : plavement.tistory.com/27 )

4. 기능 프로세스 (Function Process)

 

서비스에 대한 기능 프로세스를 작성합니다. 

비교적으로 복잡한 절차를 가진 회원가입, 아이디/비밀번호 찾기에 적합하며 더 나아가 결제 시스템, 환불 시스템 등

복잡도가 큰 Flow에 대해 다음과 같은 기능 프로세스를 작성합니다.

 

출처 : 유세균무기

기능에 대한 흐름을 표시하며 Y/N를 구분하여 어떤 화면으로 넘어가는지, 

어떠한 형식의 인증을 사용하고 내부적으로 어떤 흐름을 가지고 있는지 등 전체적인 흐름을 작성합니다.

 

 

5. 와이어프레임 & 기능 디스크립션

기능 디스크립션

작성한 와이어프레임을 토대로 상세 동작에 대한 텍스트를 작성합니다. 

큰 틀은 두 가지, Function Description / Button Description으로 나누어집니다. 

Function Description에서는 기능에 대한 상세한 설명을 작성합니다.

이메일 주소를 입력하는 기능에서는 택스트가 몇 글자로 입력 제한되는지, 기호 혹은 숫자 사용이 가능한지, 유효성 체크 방식 등 내부적으로 동작하는 자세한 기능을 작성합니다. 

추가적으로 상황에 따라 변하는 색의 변화(이메일 주소가 틀렸을 경우 빨간색으로 바뀐다 등)를 표시해야 합니다.

 

Button Description에서는 버튼이 어떤 기능을 수행하는지, 어떠한 경우 활성화/비활성화되며 알림은 어떻게 표시되는지, 색은 어떻게 변경되며 어떠한 링크로 이동되는지 등 버튼에 대한 전체적인 설명을 작성합니다.

 

이렇게 작성된 디스크립션을 통해 개발자가 수월하게 개발할 수 있으며 여러 가지 오류 상황에 대해 대처할 수 있습니다. 

더 나아가 기획자가 본인의 서비스 동작을 정확히 이해할 수 있습니다.

 

이번 포스팅을 통해 스토리보드에 들어가는 구성요소들에 대해 알아보았습니다.

스토리보드는 프로젝트 산출물의 꽃이라 불릴 정도로 굉장히 중요합니다.

특히 와이어프레임과 기능 디스크립션을 바탕으로 개발자 및 디자이너가 작업을 진행하기 때문에 정확하고 자세히 다뤄야 합니다.

 

 

그럼 이만 포스팅 마치겠습니다!