프로덕트 제작을 위한 청사진
Story Board
스토리보드란?
프로덕트를 개발하는 과정에서 가장 먼저 필요한 단계는 바로 기획이다. 서비스 기획자라면 우리가 개발하려는 프로덕트, 혹은 개선하려는 프로덕트가 어떠한 목적을 가지고 있고, 사용자에게 어떤 경험을 주려고 하는지 팀원들에게 설명하고 이해를 시킬 수 있어야 한다.
스토리보드는 서비스 개발을 위해 디자이너, 개발자 등과 협업을 하기 위한 협업도구이다. 다양한 변수를 고려하여 화면을 구성하고 각기 화면의 동작과 전환을 확인하는 기획문서라고 할 수 있다.
스토리보드의 목적
스토리보드는 기획자가 디자이너와 개발자에게 무엇을 디자인하고 개발해야 할지 알려주기 위해 작성한다. 정책, 와이어 프레임(Wire Frame), IA(Inforamtion Architecture) 등을 모두 포함하고 있으며, 서비스가 만들어지기 전 어떤 서비스가 만들어질지 미리 확인하는 용도가 있다.
스토리보드를 관통하는 단 하나의 목적은 '시각화'이다. 프로덕트를 화면에 어떻게 구현할 것인가, 화면의 각 페이지에 포함되는 구성 요소는 무엇이고 어떻게 배치를 할 것인가, 프로덕트의 구조와 정보의 흐름을 통해 사용자와 어떤 식으로 상호작용할 것인지를 나타낼 수 있다.
스토리 보드의 필수 구성
작업 이력(Docs History)
출처: https://plavement.tistory.com/34정책, 화면 구성 등 많은 업데이트에 대한 내용을 기입한다. 프로젝트 구성원들이 프로젝트의 변경 사항을 쉽게 확인하고, 각자 담당한 업무의 변경사항을 반영할 수 있도록 변경 이력을 반드시 기록한다. 큰 정책/기능의 변화가 있을 경우 첫 번째 숫자에 1을 더하며(v1.0 → v2.0), 사소한 변경이 있을 경우 소수점에서 숫자를 더한다(v1.0 → v1.2)
화면 ID
출처 : https://brunch.co.kr/@cysstory/153Wireframe과 Flowchart에 화면 ID를 제공함으로써 개발자가 작업할 때 Flow를 이해하기 쉽도록 표현한다. 차후 페이지가 추가되거나 업데이트되어도 오류가 발생하지 않도록 하기 위함이다. 일반적으로 기능을 예측할 수 있는 영문자를 사용하거나, 연결성을 나태낼 수 있도록 연속적인 숫자를 사용한다. 특정한 화면을 지칭할 수가 있기 때문에 서비스 담당 사업부, 개발자들과 나누는 커뮤니케이션에서 소통 오류를 줄일 수 있다.
IA(Information Architecture)
IA는 '서비스의 목차'라고 할 수 있다. 서비스의 주요 기능들이 어떻게 구성되어 있는지, 어떤 기능인지를 전체적으로 표현한다. 개발자나 디자이너들이 IA를 통해 DB구조 설계 등의 작업을 하는데 유용한 정보를 제공한다. PM이 서비스 기획을 하는 과정에서 모든 것을 세세하게 다 기억하고 기획하기는 어렵기 때문에 IA설계를 통해 큰 그림을 1차적으로 그리고 그 안에서 세부적인 그림 기획한다. IA는 크게 [트리구조]와 [엑셀타입] 두 가지 작성방법이 있다.
트리구조의 IA(출처: https://plavement.tistory.com/34)
엑셀 타입의 IA(출처 : https://smkdir.tistory.com/3)플로우차트(Flowchart)
화면의 전환과 흐름에 대한 정보를 제공한다. Wireframe과 Description만으로는 서비스의 전체 흐름을 확인하기 어렵기 때문에 Flowchart를 추가로 제작하 간단한 흐름을 전달한다. 서비스 구조가 간단한 경우 생략할 수 있지만, 복잡하다면 필수로 작성해야 한다. 전체 흐름을 기능별/프로세스별로 보여줄 수 있다면 좋지만, 만약 전체 Flow를 보여주지 못하더라도 주요 사용자 Flow에 대한 정보를 제공하는 것이 유리하다.
Flowchart (출처 : https://www.mural.co/resources-hub/flowcharts)Flowchart는 모양에 따라와 의미와 기능이 다르다. 아래의 표를 참고하길 바란다. 처음 그리자고 하면 굉장히 그리기가 귀찮을 수도 있다. 하지만 Flowchart도 쉽게 그릴 수 있도록 도와주는 툴들이 많으니 찾아보길 바란다.(https://app.diagrams.net/)
(출처 : https://visme.co/blog/flowchart-examples/)Wireframe 및 기능 Description
서비스의 구성화면을 간단한 모양만 사용하여 시각적으로 묘사한 것이다. 디자인적 요소가 들어가지 않은 저품질로 그려지기 때문에 실제 완성되는 모습과는 전혀 다른 모습이다. 사실 디자인적 요소는 디자이너가 해결해야 할 부분이지 PM이 미리 괜찮은 디자인을 하겠다고 힘쓸 필요가 전혀 없는 부분이기도 하다.
Wireframe(출처 : https://www.sketch.com/blog/wireframe-examples/)기능 설명(Description)은 특정 버튼 또는 특정 기능이 어떤 역할을 하는지 상세하게 설명해 놓은 것이다. 충분한 커뮤니케이션이 필요하겠지만 Description만 보고소 해당 기능과 내용이 무슨 의미인지 알아차릴 수 있도록 구체적으로 작성이 되어야 한다. 나만 알아볼 수 있는 단어와 의미로 작성되면 협업에 불편함을 초래할 수 있다.
출처 : https://plavement.tistory.com/34정책
정책은 서비스를 운영하면서 필요한 일종의 '규칙'을 정해 놓은 것이라 생각하면 이해에 도움이 될 것 같다. 정책에는 시스템 연동, 정보 노출 정책, 준법 사항, 계산 산출 근거 4가지 정도의 정보가 기입된다. 시스템 연동은 응답 코드, 응답 코드명, 응답 메시지에 대한 내용을 테이블 형태로 보여주고, 정보 노출 정책은 같은 화면이라도 사용자 액션에 따라 정보가 추가로 보일 수 있기 때문에 각 케이스 별로 노출될 수 있는 정보와 상태 값을 화면으로 그리거나 테이블 형태로 정리하여 안내한다. 케이스가 다양하지 않거나 레이아웃이 이해하기 어려운 경우, 직접 화면을 그리기도 하고 정보의 양이나 케이스가 많은 경우는 테이블 형태로 정리해 주면 좋다. 준법 사항은 예를 들어 금융 서비스는 금융감독원 준수사항 등이 있는데 이런 사항을 함께 명시한다. 계산 산출 근거 역시 예를 들면 운동량 체크가 필요한 서비스는 칼로리 소모량의 산출 공식을 제공하는 식으로 명시한다. 정책은 서비스의 공통적인 정책이라면 스토리 보드 앞부분에서 제공하는 경우도 있다.
작업툴
우리가 보고서를 작성할 때 노션, Word, 한글 등 여러 가지 워드프로세서를 활용하는 것처럼 스토리보드도 여러 가지 툴을 활용할 수 있다. 대표적으로 파워포인트와 피그마(Figma)인데 아무래도 요즘은 Figma를 많이 활용하는 것으로 판단된다. Youtube에도 관련된 강의를 무료로 제공해 주는 유튜버들이 많으니 관심이 있는 사람들은 참고하길 바란다!
출처 : https://www.cnet.com/tech/computing/figma-design-tool-gets-internet-scale-sharing-and-community