스토리보드 잘 그리는 법?
왜 필요한지를 알아야 잘 그릴 수 있습니다
* 과거에 썼던 글들을 브런치로 옮기다 보니 시점이 안 맞는 문제가 있습니다. 내용 전달과 무관하니 수정하지 않는 점 양해바랍니다. (무려 5년 전 글이군요)
왜 필요한지를 자각하는 것이 첫번째라 생각합니다
단지 수단이지만, 수단이 목적화 되는 걸 많이 봅니다
Comm. 이라고 하면 무엇이 좋은SB인지가 명확하죠참여중인 스터디의 오늘 주제가 '스토리보드'입니다.
각자 후배에게 '스토리보드는 이렇게 그려라'를 알려줘야 한다면 어떻게 할 것인가를
얘기하기로 했는데, 위 아젠다로 생각하면서 정리한 개념을 공유합니다.
일단 스토리보드란게 딱히 정답이 있는 거 같진 않습니다.
팀웍에 따라, 분위기에 따라, 프로젝트 성격에 따라 계속 변하니깐요.
그냥 형식으로 구분되는 문서일뿐, 정석과 정답이란 개념은 없다고 생각합니다.
다만, 저라면 아래와 같이 알려줄 거 같네요.
(이 글은 그냥 제 '생각'입니다. 다른 분들은 어떤 생각을 하시는지 같이 담론을 형성하고, 생각을 공유하는 장이 됐음 좋겠습니다.)
1. 스토리보드란 무엇인가.
무엇인가를 알려줄 때는 '왜'필요한지에 대한 설명이 필수라고 생각합니다.
'어떻게'만 알려주면 그 방법론에 생각이 굳어지는 거 같더라고요.
(사고가 뛰어난 사람은 '어떻게'만 알려줘도 스스로 '왜'를 찾기도 하지만)
그런 의미에서 '스토리보드는 왜 필요하지?'란 질문으로 치환해보겠습니다.
기본적으로 스토리보드는 협업관계에 있는 사람들과 커뮤니케이션하기 위한 도구입니다.
서두에서 언급했다시피 커뮤니케이션 관점이기 때문에 그 대상자가 누구냐, 대상자와 합의된 게 얼만큼 있느냐 등에 따라 방법이 달라질 겁니다.
그럼 좋은 커뮤니케이션을 하려면 어떻게 해야 할까에 대한 질문으로 연결될텐데요.
제 기억에 logical thinking 초반에도 비슷한 내용이 나오는 것으로 기억하는데, 커뮤니케이션의 기본 매커니즘은 '발신자-메시지-수신자'이죠.
이를 좀 더 구체화한 게 로만 야콥슨이란 언어학자의 의사소통 행위상의 구성요소 6가지입니다.
이것만 잘 이해하고 활용해도 충분히 좋은 커뮤니케이션이 될 거라 생각합니다.
야콥슨은 발신자/수신자/메시지/상황(context)/접촉/code로 구성요소를 정의합니다.
야콥슨의 의사소통 행위상의 구성요소 모델이걸 풀어서 설명하면, 스토리보드의 수신인은 고객사일수도, 디자이너일수도, 개발자일수도 있겠지요.
메시지는 스토리보드의 본문일테고요.
상황은 수정안을 넘길수도, 제안시안용일수도, 개발 검토용일수도, 구축용일수도 있겠고요.
접촉은 이메일로만 보내는 상황인지, 프리젠테이션 상황인지, 테이블 미팅인지 등이 있을테고,
코드는 개발자식 표현으로는 protocol의 개념인데 약속된(합의된) 언어입니다.
그러니 수신자에 따라 개발자와의 코드, 기획자와의 코드 등이 있겠지요.
종합해보면 수신자에게 상황과 접촉, 그리고 수신자와 합의된 코드에 따라 메시지를 만들어 전달하면 되겠지요. (참~ 쉽죠?는 개뿔. 복잡하네요)
실무 여건상 스토리보드 하나 그리는데 수신자에 맞춰 일일이 메시지를 수정할 순 없지만, 그래도 이메일로 고객사에게 보내는 스토리보드에 고객은 알아들을 수도 없는 개발용어 등만 기재되어 있다면 좋은 커뮤니케이션으로 보긴 어려우니깐요.
응용해보면, 가장 상위개념(합집합의 의미로)으로 스토리보드를 작성하고, 리뷰할 땐 수신자와의 코드에 따라 리뷰를 하는 거겠지요.(동일한 스토리보드로 기획자/디자이너/고객에게 같은 말을 하는 건 오해를 만들기 딱 좋잖아요. 그 고객들끼리의 코드가 다르니깐요. protocol이 다르면 통신이 불가하다는 것을 생각해보세요)
여튼, 스토리보드가 본질적으론 comm.을 위한 도구란 걸 이해하고, 좋은 comm.을 위해서 야콥슨의 커뮤니케이션 모델을 지표로 해서 생각해보면 좋을 거 같다는 거죠.
2. 스토리보드에 무엇을 담을 것인가.
요구분석을 통해 기능명세서가 나왔다면, 바로 스토리보드를 그리면 될까요?
전 일단 아니라고 생각해요.
요구분석 할 시간이 충분히 주어져서, 확실하게 검토할 수 있다면 모를까. 시간=돈인 이 바닥의 매카니즘에선 비현실적인 얘기라고 봐요.
그러다보니 요구분석 단계에서는 러프하게만 정의가 되고요.
스토리보드를 그리면서나 디테일한 기능을 정의하고, 요구분석단계에서 했었어야 할 것들을 할 수 있는 상황이 된다고 봅니다.(그런면에서 요구분석단계에서 고민해야 할 질문들의 비중이 높습니다. 그게 다 돼야 그리죠)
일단, 스토리보드 그려야 하는 상황에서 파워포인트를 열기 보다는 연습장을 펴서 아래의 질문들에 대한 답을 찾는게 좋으리라 생각됩니다.
1. 왜 쓰지?
: 그려야 하는 페이지(서비스일수도, 메뉴일수도 등등)를 '왜' 써야하는지를 알아야죠.
게시판이라고 한다면 이 게시판의 목적을 정의해야죠. KSF는 뭔지, KPI는 뭔지.
2. 누가 쓰지?
: 누가 쓰는 서비스인가요? 사용자를 단순히 'end-user'로 묶어서 보면 좀 위헙합니다.
위에서 예로 든 게시판을 계속 예로 들어볼게요.
게시판의 참여 정도에 따라 '창작자형, 비평가형, 수집가형, 참여자형, 관람자형, 비참여자형-테크노그래픽스 사다리 기준에서 분류하는-' 로 사용자를 정의할 수도 있고요. 사용 행태에 따라 목적형 사용자와 탐색형 사용자를 구분할수도 있고요. 인구통계학적으로 구분해도 좋고요. 어찌됐건 이 서비스를 누가 쓸 것인지 정확히 알아야지요. 물론 관리자도 사용자니 빼먹지 말고요.
3. 언제 쓰지?
: 시간대를 말하는 게 아니라, 서비스의 흐름에 대한 겁니다.
글쓰기 전/글쓰는 중/글쓴 후(또는 이용 전/중/후) 이렇게 세 가지로 구분만 해도 어떤걸 표현해야 하는지가 더 명확해 집니다.
글쓰기 전에는 글을 쓰게끔 유도하는 것이 핵심일테고, 글쓰는 중일 땐 쉬운 글쓰기 환경이 중요할테고, 글쓴 이후에는 해당 글에 대한 사용자 피드백의 알림 등이 중요할테고. 등등등 이런식으로요.
4. 무엇을 쓰지?
: 2번의 사용자가 1번의 목적에 따라 3번의 시점에서 무엇이 필요한가요?
사용자 시나리오를 그려보면 필요한 기능이 나오지요.
사용자별로 사용 시점별로 예상 가능한 케이스를 정의하다 보면 기능이 정의되고, 케이스를 그려보다 보면 연결고리가 생길텐데, 그 연결고리를 잘 만들면 살아있는 서비스가 되겠지요. (적어도 선순환을 기획적으로라도 고민하는 것과, 각 단계를 끊어진 고리로 보고 기획하는 건 다르다고 봅니다)
5. 어디서 쓰지?
: 이 서비스를 제공하는 플랫폼이 무엇인지 고민해야 할테고. 멀티플랫폼이라면 플랫폼별 특성을 다르게 갈 것인지 등을 생각해야 할테고. 등등.
6. 어떻게 쓰지?
: 인터페이스와 인터랙션을 포함한 UX를 생각하는 단계입니다.
위에서 정의한 것들을 효과적으로 표현하기 위한 표현 방법을 고민합니다.
그들은 어떻게 해야 '잘' 사용할까를 말이지요.
6번 단계에서 시간을 좀 많이 할애하는 편입니다.
저 총 6단계를 거쳐 고민한 답이 어느정도 정리됐다면 이제 파워포인트를 켜고 그리시면 됩니다.
그리는 방법이요? 글쎄요. 저도 잘 못그려서.
커뮤니케이션 하는데 문제 없음 되니까, 잘 그려보세요.
디스크립션의 수준과 범위 등은 저도 잘 몰라요.
커뮤니케이션 하는데 문제만 없음 되니까요.
남들보다 예쁘게 그리지도 못하고, 남들보다 디스크립션을 자세하고 누락없이 적지도 못하고, 남들보다 빨리 만들지도 못해요. 그래서 이게 정답인지 잘 모르겠어요.
게시판만 보면 그냥 기존에 만들어 놨던 list/view/write/modify 화면 가져다 붙여넣기 하면 끝인데 말이지요.
그래도,
붙여넣기 하는 거보다 좀 멍청하고, 비효율적이더라도
고민하면서 새로 그리는게 더 재미있더라고요.
(근데, 스토리보드 그리는 걸 엄청 싫어하는 게 함정. 아. 귀찮은. 스토리보드.)
