웹/앱 기획자를 위한 스토리 보드 양식과 작성법 예시

웹 사이트 또는 앱 개발 프로젝트에서 가장 첫 번째 단계는 바로 기획입니다. 기획자라면 제품이 어떠한 목적을 가지고 있으며, 사용자가 어떠한 경험을 하길 의도하는지를 토대로 프로젝트 팀원들을 제대로 디렉팅하고, 다음 단계가 원활하게 진행될 수 있도록 해야 합니다. 

웹/앱 기획자라면 본 블로그 포스트를 통해 스토리 보드 툴과 양식, 작성법 예시까지 알아보세요!

웹/앱 기획 스토리 보드, 왜 중요할까요? 

기획 > 디자인 > 웹 퍼블리싱 > 프런트 엔드 개발 > 백엔드 개발

어떤 일이든 첫 단추를 잘 끼워야 합니다. 웹 사이트 또는 앱 개발 프로젝트의 첫 단추는 바로 ‘기획’인데요. 이때 필요한 것이 바로 기획 문서인 ‘스토리 보드’입니다. 추상적인 아이디어만 가지고 디자이너가 바로 디자인 작업을 시작하는 것이 아니라는 것을 알아둘 필요가 있습니다.
 

| 스토리 보드란?

스토리 보드는 웹/앱 서비스 개발을 위해 UX 측면에서 시각적으로 표현한 청사진이자 기획서입니다. 화면 설계도라고도 하며, 완성될 예정인 제품의 ‘기능’에 초점을 맞추어 필요한 구성 요소와 흐름 등의 정보를 담은 핵심 문서입니다.

| 스토리 보드의 목적

스토리 보드를 만드는 목적은 주로 다음과 같습니다.

• 시각화 ㅡ 웹/앱 서비스를 사용자 입장에서의 화면에 어떻게 구현할 것인가

• 구성 요소 ㅡ 웹/앱 화면의 각 페이지에 포함할 구성 요소는 무엇이며, 어떻게 배치할 것인가 

• 상호작용 ㅡ 웹/앱의 내비게이션 구조와 정보의 흐름을 통해 사용자가 어떻게 상호작용하게 될 것인가

   
   

| 스토리 보드, 이래서 중요해요

웹/앱 개발 프로젝트에서 스토리 보드는 기획자와 디자이너, 퍼블리셔, 개발자가 동일선상에서 제품 및 서비스에 대해 완벽한 이해와 의사소통을 바탕으로 성공적인 개발을 완료할 수 있도록 돕는 역할을 합니다. 즉, 제품이 기획 의도대로 동작하고, 사용자들이 제대로 사용할 수 있으며, 결과적으로 실질적인 전환이 이루어지도록 하기 위해 필요합니다. 

따라서 스토리 보드는 완성 제품의 ‘미리보기’를 위한 방법론이라고 할 수 있습니다!

예를 들어, 신제품(또는 서비스) 개발에 대한 아이디어를 구상 중이라면 그것을 각 부서에 말로 설명하거나 추상적인 느낌만으로 디자인, 개발까지 진행하기가 어려운데요. 제품 기획의 목적과 필수 구성 요소, 그리고 사용자 경험을 어떻게 최적화할 것인지에 대한 명확한 기획서가 준비되어야 합니다. 여기에서 출발하여 각 담당자가 자신의 파트에서 전문성을 발휘하여 개발이 진행될 수 있습니다.

웹/앱 개발 프로젝트의 가장 첫 단계인 기획에서 기획자가 ‘제대로 된’ 스토리 보드를 제시할 수 있다면 그 바로 다음인 ‘디자인’ 단계에서 디자이너가 더 효과적으로 작업할 수 있습니다. 각 구성 요소와 그 목적에 대해 파악하고 있어야 사용자를 위해 어떻게 디자인을 구현하는 것이 가장 좋은지도 캐치할 수 있는 것이죠.

가령, 앱의 한 화면에서 특정 버튼의 역할이 무엇인지 또는 얼마나 중요한지 안다면 이를 강조할 수 있는 디자인을 고민할 것입니다!

그리고 그다음 단계인 퍼블리싱과 개발 단계에서도 각 담당자가 스토리 보드를 바탕으로 실제로 구현 가능한가, 오류가 발생할 가능성이 있는가 등에 대한 검토를 통해 실제 개발 단계에서 발생할 수 있는 문제들을 사전 예방하는 역할도 합니다.

 

웹/앱 스토리 보드 작성 꿀팁

| 스토리 보드 툴 선택하기

스토리 보드 작성 시, 일관성 있는 프로젝트 관리를 위해 하나의 툴을 사용하는 것이 좋습니다. 팀원들마다 각기 다른 도구를 사용할 경우 불필요한 작업을 반복해야 할 수 있기 때문인데요. 스토리 보드 툴 선택 시 포인트는 모두에게 익숙하고 사용하기 쉬운 도구를 사용하는 것입니다.

전통 강자 ‘파워포인트’ vs. UX/UI 디자인 툴

실제 기업에서 스토리 보드 프로그램으로 가장 많이 사용하는 툴은 ‘파워포인트’입니다. 프로젝트 내의 모든 팀원이 이용 가능하므로 접근성 측면에서 뛰어나며, 가장 익숙한 프로그램이기도 하죠. 또한, 보안 관리 측면에서도 훌륭한 툴로 평가받고 있습니다.

하지만 오늘날 기획에 사용할 수 있는 작업 툴이 다양해진 만큼, 파워포인트 이외에도 선택지가 넓어졌습니다. 대표적으로 팀원들 간 공유 측면에서 편리한 UX/UI 디자인 협업 툴 ‘피그마(Figma)’를 사용할 수도 있는데요. 피그마를 사용하면 규격 그리기 및 레이어 수정 시 반복 작업을 최소화할 수 있다는 장점이 있습니다. 

반면, 개발자들을 위한 디스크립션 작업에는 효과적이지 않다는 단점도 존재합니다. 또한, 모든 팀원이 피그마 사용에 익숙한 것은 아니기 때문에 이러한 점도 고려하여 툴을 선택하는 것이 좋습니다.

그 밖에도 파워목업(PowerMockup), 스케치(Sketch), Visio 등 다양한 스토리 보드 툴이 있는데요. 팀원들에게 모두 익숙하다는 가정하에 가장 적합한 도구를 선택할 것을 추천합니다.

| 스토리 보드 양식

과거에는 파워포인트를 사용하여 처음부터 양식을 직접 작성하는 것이 일반적이었지만, 현재는 템플릿을 제공하는 다양한 서비스가 생겨났습니다. 앞서 소개한 파워목업(PowerMockup)을 설치하면 각 소스를 일일이 만들 필요 없이 바로 배치하여 작업할 수 있어 편리합니다. 또는 디자인 관련 사이트에서 UI 세트를 유료로 구매하여 사용할 수도 있습니다. 

다음의 템플릿 제공 사이트를 확인해 보세요.

• Flaticon ㅡ 프로젝트를 위한 무료 아이콘 및 스티커를 PNG, SVG, EPS, PSD 및 CSS 형식으로 다운로드할 수 있는 사이트

• Creately ㅡ 데이터 연결을 지향하는 비주얼 업무 관리 플랫폼. 플로우차트, 와이어 프레임 등 다양한 템플릿 제공

| 스토리 보드 작성 시 주의할 점 

‘스토리 보드’는 와이어 프레임과 다르다!

많은 초보 기획자분들이 하는 실수는 ‘스토리 보드’와 ‘와이어 프레임’을 혼동한다는 것입니다. 와이어 프레임은 레이아웃을 잡는 데 중점을 두며, 각 요소에 대한 정보는 없습니다. 만화에 비유하자면, 구도와 스케치만 대략적으로 완료한 상태로 디테일이 빠져있는 것과 같습니다. 사람을 그렸다면 성별도 알 수 없고, 말풍선에 대사도 없어 인물의 캐릭터에 대해 파악하기도 어려운 상태입니다.

따라서 이러한 세부 정보가 없는 상태에서는 디자이너가 제대로 작업할 수 없습니다! 

각 페이지의 구성 요소에 대한 정보와  

그 흐름까지 알 수 있도록 한 

화면 설계도가 바로 ‘스토리 보드’입니다.

기획자라면 자신의 스토리 보드가 프로젝트 내의 다른 부서 및 담당자들에게 필요한 정보를 충분히 담고 있는지 점검해 보세요!
 

웹/앱 스토리 보드 작성법의 예시

01 | 표지

일반적으로 표지에는 프로젝트명, 문서 버전, 작성일, 소속 및 작성자 이름을 표기합니다.

02 | 작업 히스토리 

작업 이력을 기록합니다. 문서 버전, 반영된 페이지 및 내용, 날짜, 수정한 사람 등의 항목을 포함하여 작성합니다. 이 부분을 건너뛰게 되면 변경 사항에 대해 추적하기 어렵고 팀원들 간에 혼란이 발생할 수 있어 중요합니다.
 

03 | 목차

순번 또는 불릿 포인트(Bullet point) 형식으로 문서의 순서를 작성합니다. 이때 페이지 번호를 표기하거나, 하이퍼링크로 연결하면 특정 페이지로 바로 접근할 수 있어 더욱 편리합니다.

04 | 개요 

개발하는 웹/앱 서비스(제품)에 대해 간략하게 서술합니다. 사용자에게 해당 서비스를 제공하는 목적과 개발 범위 등이 여기에 포함될 수 있습니다.
 

05 | 메뉴 구조도 (IA; Information Architecture) 

메뉴 구조도는 서비스(제품)의 전체 구조를 시각화하여 나타낸 한 장짜리 표입니다. 메뉴를 구조별로 도식화하고, 필요시 간단한 디스크립션까지만 제공합니다.

06 | 화면 ID 목록

각 화면의 UI에 ID를 부여하고, 이 목록을 표로 제시합니다. 기획서의 페이지 수가 아닌, 화면 ID를 기준으로 작업할 경우 개발자가 페이지 전환을 쉽게 확인할 수 있습니다. 또한, 페이지가 추가될 경우에도 변경된 기획서 페이지의 수에 맞춰 별도의 디스크립션 추가 작업이 필요 없습니다.
 

07 | 플로우차트 (flowchart) 

이제 설계 단계로 넘어가서 작업 흐름도를 작성합니다. 플로우차트는 화면 전환을 나타내는 흐름도입니다. 문서를 읽는 사람이 서비스(제품)의 전체 흐름과 프로세스를 쉽게 이해하는 데 도움이 됩니다. 설계 화면이 간단하다면 경우에 따라 생략하기도 하지만, 복잡하다면 플로우차트가 꼭 필요합니다. 

사용자의 동선과 각 요소와의 상호작용에 따라 어떻게 다음 화면으로 이어지는지 흐름을 보여주는 중요 정보이기 때문입니다. 

＋ 플로우차트 작성 팁

• 페이지 ㅡ 사각형

• 프로세스 ㅡ 평행사변형

• 분기(Y/N) ㅡ 마름모

• 시작/종료 ㅡ 배경색으로 강조

• 범례 ㅡ 참고 사항으로 각 구성 요소들의 의미 표기

   

08 | 정책 

정책은 플로우차트에 이어 함께 묶어서 작성하면 좋습니다. 예를 들어, 웹/앱의 경우 회원가입정책과 같은 기본 정책이 있는데요. 하위 카테고리를 나누어 국가, 주소, 연락처, 기본 언어, 통화 등을 정하고 디스크립션을 작성합니다.

또한, 같은 화면이지만 사용자 액션에 따라 노출되는 정보가 다르다면 이러한 정보 노출 정책을 명시합니다. 계정의 성격에 따라 수행할 수 있는 작업의 범위가 다르다면 권한 정책을 작성할 수 있습니다.
 

‘스토리 보드 작성’ 

꿀팁이 도움되셨나요?

그렇다면 이제 스토리 보드를 

실전 프로젝트의 기획 단계에 적용할 때입니다!

프리랜서 기획자라면 

이랜서에 오픈된 웹/앱 기획 프로젝트를 

지금 당장 확인하고, 수주하세요!

→ 이랜서 프리랜서 기획자 프로젝트 보러가기