서비스 스토리보드(Wireframe) 작성하기

기획자와 뗄레야 뗄 수 없는 애증의 관계, 스토리보드(Wireframe) 작성하기!
당신이 이 어려운 걸 왜 시작했는지는 모르겠지만 이왕 이렇게 시작한 것 잘 그려야 할 텐데 어떻게 하면 잘 그릴 수 있을지 고민하는 기획자들에게 조금이나마 도움이 되기를 바라며 순전히 개인적인 경험에 비추어 작성을 해본다.

물론 기획자들이 스토리보드만 작성할까? 한 프로젝트에서 생성되는 폴더와 파일을 보면 한국의 기획자들은 Planner라고 지칭하기엔 업무의 범위가 너무 광범위하기 때문에 Product manager가 더 적합한 표현이 아닐까 싶다.

1. UI는 연습장에, UX는 프로토타이핑툴에

나는 A4 이면지를 활용하여 UI를 빠르게 스케치하고 이 스케치를 가지고 프로젝트 구성원들과 함께 사전 미팅을 하며 기능을 협의하고 정리한다. 보통 이런 스케치는 몇 시간이면 충분하기 때문이다.
기능에 대한 정의가 끝나면 UX를 고민하며 프로토타이핑툴(나의 경우엔 익숙한 PPT를 사용한다. 물론 익숙하다는 것 이외에도 여러가지 이유가 있지만...)에 스토리보드를 그리기 시작한다. 이면지에 그린 스케치는 수정이 어렵지만 프로토타이핑툴에서는 이리저리 기능이나 버튼의 위치를 변경하며 UX를 고민할 수 있기 때문이다.

조악하게 낙서한 듯 하지만 주요한 기능이 모두 포함되어 있고 실제 구현된 앱하고도 거의 비슷하다.

2. 변동성과 확장성을 고려해야 한다.

스토리보드는 여러 상황과 환경의 변화 또는 상사나 프로젝트 구성원들의 요청에 의해 수시로 변경될 수 있으며 완벽한 기획서는 없기 때문에 항상 수정과 추가를 고려하여 작성을 해야한다.
이를 위해 스토리보드에는 다음과 같은 장치가 필요하다.

1) 변경이력
프로젝트 구성원들이 스토리보드의 변경사항을 쉽게 확인할 수 있도록 변경이력을 기록하며 문서의 버전을 관리를 해야 한다.

보시다시피 v0.2.7이면 27번의 변경이 있었다는 이야기이며 큰 프로젝트의 경우에는 이런 페이지가 여러 장 나온다.

2) 페이지 코드
페이지 곳곳에 타 페이지 또는 문서를 참고하라고 표시를 하게 되는데 페이지가 추가(특정 페이지가 필요없어지더라도 삭제는 하지 않는다. 다만 위에 크게 레이어를 씌워 해당 문서를 삭제한다고 표시한다.)될 수 있기 때문에 페이지의 번호로는 표시할 수 없으니 별도의 페이지 코드를 정의하여 페이지 상단마다 표시를 하게 되며 프로젝트가 큰 경우에는 별도의 페이지 코드를 정의한 문서가 하나 작성되기도 한다.
보통 나의 경우 해당 기획서를 암시하는 영문(BO; Back office)에 주요 페이지를 숫자로 표시(01)한 다음 주요 페이지에서 파생되는 하위 페이지 또는 늘어나는 설명 페이지를 숫자로 표시(01)한다.
결국 페이지 코드는 'BO-01-01'과 같이 표시되고 중간에 추가되는 페이지는 어쩔 수 없이 'BO-01-01-01'과 같이 표시한다.

3) 모듈화(그룹화)
스토리보드를 그리다보면 반복적으로 사용하는 UI나 버튼 등이 있는데 PPT에선 선과 면의 조합으로 UI나 버튼 등을 표현하다보니 복사 후 붙여넣기를 자주 사용하게 된다. 이때 빠르고 편하게 복사하여 붙여넣기를 할 수 있도록 빈번하고 반복적으로 사용하는 UI나 버튼 등은 그룹화를 해놓거나 자신만의 포트폴리오에 모듈화를 해서 보관하고 있으면 좋다.
가끔 좋은 프로토타이핑툴이 많은데 왜 이렇게 PPT를 고집하냐고 묻는 경우가 있는데 PPT를 오래 사용한 기획자들은 이런 모듈화가 잘되어 있어 타 프로토타이핑툴을 사용하는 것보다 PPT에서 스토리보드를 작성하는게 더 빠르기 때문이다.

---

내가 PPT를 사용하는 이유

- 프로젝트 구성원들에게 프로토타이핑툴을 설치하라고 설득하고 학습하기가 어렵고 번거롭다.
- 모바일과 웹사이트 스토리보드를 함께 작성해야 하는데 두개를 모두 만족시키는 프로토타이핑툴이 없다.
- 규모가 커서 다수의 프로젝트 구성원이 참여하는 경우, 스토리보드에 단순히 Wireframe만 그리는 것이 아니라 정책과 프로세스 등 설명할 것이 많은데 보통 프로토타이핑툴은 Wireframe에만 최적화되어 있다.
- 12년을 PPT만 사용하다보니 위에서 언급한 것처럼 모듈화가 잘 되어 있어 타 프로토타이핑툴을 사용하는 것보다 작업속도가 빠르다.

---

3. 스토리보드를 읽는 독자를 고려해야 한다.  

프로젝트 구성원에는 개발자와 퍼블리셔, 디자이너, 마케터, 운영자, CS담당자 등 다양한 파트에서 온 SI, 웹에이전시, 서비스 회사 출신의 신입과 경력자가 섞여있을 수 있기 때문에 최대한 쉽게 이해할 수 있도록 작성을 해야 한다.
경력자답게 기획서를 작성해야 한다는 생각에 또는 잘난 척을 하고 싶어 어렵게 작성하고 싶은 욕망에 사로 잡히는 경우가 있는데 프로젝트는 팀플레이이기 때문에 최대한 쉽게 작성하기 위해 노력을 해야 한다.


4. 공통 기능은 따로 설명한다.

모듈화(그룹화)와 비슷한 이야기일 수도 있지만, 모듈화(그룹화)가 기획자 본인을 위한 작업이라면 공통 모듈은 프로젝트 구성원 즉 팀을 위한 작업이다.
기본 Wireframe이나 Grid, 빈번하게 사용되는 기능이나 액션 등은 따로 빼서 별도 정리를 해야 한다. 프로젝트에 다수의 구성원이 참여하는 경우, 페이지를 나눠서 작업하는 경우가 많은데 공통 기능으로 빼서 별도 정리를 해둬야 페이지마다 반복되는 설명을 최대한 줄일 수 있기 때문이다.
결국 기획자 본인을 위한 작업인건가?

나의 경우 변경이력 > 사이트 메뉴 구조 > 공통 기능 설명 > 각 페이지의 Wireframe 순으로 기획서를 작성한다.

5. 프로세스와 정책, 용어를 따로 정리하여 설명한다.

Wireframe과 그 설명만 보고서 이해를 못하는 프로세스와 주요 정책, 용어는 별도 페이지를 할애하여 설명을 해야 한다. 그렇지 않으면 프로젝트 구성원들이 기획서를 분석하는 기간 내내 기획자 옆에서 번호표를 뽑고 줄서서 기다리는 촌극을 맞이할 수 밖에 없다.
물론 아무리 자세하게 설명을 하더라도 번호표를 뽑는 상황 자체를 없앨 수는 없겠지만 그 빈도수를 줄일 수는 있을 것이다.

이런 프로세스는 Wireframe만 보고 절대 이해할 수 없다.

6. 스토리보드는 완벽할 수 없다.

많은 기획자들이 스토리보드를 작성하는데 많은 시간과 노력을 기울이고 그만큼 스트레스를 많이 받는다. 그런데 제 아무리 기획의 신이라 할지라도 완벽한 스토리보드를 그릴 수 없다는 걸 기획자 스스로도, 프로젝트 구성원들도 인정을 해야 한다.
가끔 개발자, 퍼블리셔, 디자이너 등 프로젝트 구성원들이 완벽한 스토리보드를 요구하는 경우가 있는데 당당히 이야기해라.
'당신이 짜놓은 코드에 버그 하나 없이 개발할 자신이 있으면 그때 완벽한 기획서를 요청하라.'고 말이다.
다만 전체적인 프로세스에 논리성이 결여되어 프로세스 자체가 크게 변경되지 않게끔 끊임없이 고민하고 노력해야 한다. 


7. 끊임없이 시뮬레이션을 해야 한다.

내가 부사수에게 습관적으로 묻는 질문이 있다.
'머리 속에서 서비스가 제대로 돌아가나요?'

기획자의 머리 속에서 기획한 서비스에 회원이 가입을 해서 사용을 하고 탈퇴하기까지 사용자의 전 생애주기가 그려지면서 각 기능들이 논리적 오류없이 동작을 해야 한다.
이런 시뮬레이션을 통해서 끊임없이 논리성을 확인하고 동작이 매끄럽지 않거나 연결이 끊긴다면 그 부분을 다시 확인하고 수정하며 논리성을 보강해야 한다.
그렇지 못하다면 서비스가 너무 커서 스스로 감당할 수 있는 범위, 즉 역량을 넘어서거나 아직은 메인 기획자나 홀로 기획을 하기엔 어려운 실력이라고 생각하며 어떤 서비스를 보더라도 머리 속에서 사용자의 전 생애주기가 서비스와 맞물려 시뮬레이션이 되고 이런 시뮬레이션이 습관화되어야 뛰어난 기획자라고 생각한다.

보시다시피 백오피스 스토리보드만 312장. 프런트(모바일)를 포함하면 400장 정도에 관련된 정책, 알고리즘 등의 문서를 합치면 수백여장이 되는데 기획자는 이 모든 것이 머리 속에서 유기적이고 논리적으로 돌아가야 한다.

마지막으로 오늘도 텍스트 하나, 버튼 하나, 기능 하나의 생사를 쥐락펴락하며 머리를 쥐어짜고 있을 수많은 기획자들에게 응원의 메시지를 보냅니다. 힘내세요!

 

세균무기가 알려주는 서비스 기획의 모든 것 | 세균무기 - 교보문고