스토리보드 디스크립션은 어떻게 쓸까?
초등학생 코딩 교육에서 찾아낸 디스크립션의 정석
책임님, 디스크립션은 어느 정도까지 정의해줘야 해요?
모두가 퇴근한 금요일 저녁, 신입사원이 끙끙대며 일어날 생각이 없길래 이유를 물었더니 이런 대답을 했다.
"우리 회사는 코드명 빼고 정책적으로 필요한 건 다 정의해줘야지~"
대답을 듣고도 신입사원은 고개만 갸우뚱한다.
디스크립션이란 전통적인 기획자의 기획 문서 중 스토리보드(SB) 문서에서 동작이나 로직, 정책 등이 모두 섞여있는 설명 문구를 이야기한다. 화면을 기반으로 한 기획이라면 비주얼을 기반으로 성장한 UX 디자이너와 기획자(혹은 Product Manager)의 차이는 바로 여기서 발생한다. 경우에 따라서는 개발을 위한 커뮤니케이션 한 것으로 채워지기도 하고, 또 어떤 때에는 실무자들이 비즈니스를 이해할 수 있도록 자세한 상황과 입장을 기록한 문서가 되기도 한다. 그렇다 보니 기획서를 작성한 사람과 상황에 따라서 디스크립션의 분량과 기록 방식은 크게 차이 나기 마련이다.
디스크립션 작성의 깊이나 방법들은 보통 선배들의 SB를 보면서 스스로 감을 잡아서 배우거나 직접적인 선배의 검수를 받으면서 자신만의 감을 찾기 마련이다. 그것도 아니면 경험 많은 개발자들과 진행하는 과정에서 욕을 많이 먹으면서 자연히 어디까지 정의해야 되는지 알게 된다. 버전이 0.1에서 한 단계씩 3.0까지 올라가면서 계속 업데이트하고 추가하면서 말이다.
일단 그 신입 친구에게도 내가 그 친구의 연차 때 썼던 SB를 보내주면서 감을 잡을 수 있길 바랬다. 그런데 계속 마음에 걸렸다. 뭔가 제대로 설명해줄 수는 없었을까?
그러다 오늘 문득 EBS 방송에서 괜찮은 설명방법을 찾았다.
디스크립션의 수준이 중요한 이유
EBS 소프트웨어야 놀자 시즌2. 2회 순차편위의 영상은 EBS 교육방송의 초등학생 소프트웨어를 위한 방송인 '소프트웨어야 놀자 시즌2'의 한 장면이다. 초등생 아이들이 두 팀으로 나뉘어서 가상의 로봇인 '선생봇'에게 이 닦기를 명령하기 위해서 어떻게 해야 할지를 물어봤다. 처음 나온 답변은 '양치질해라'였다. 당연히 로봇은 못 알아들을 용어이다. 왜냐면 이 로봇은 아무것도 정의되지 않은 상태니까. 선생님은 좀 더 자세하게 설명해야 한다고 설명해준다.
EBS 소프트웨어야 놀자 시즌2. 2회 순차편설명을 듣고 아이들은 양치질을 나름의 방법으로 자세하게 나눠서 정의했다. 하지만 설명을 그대로 실행해본다면 알겠지만 아직 설명대로만 하면 제대로 로봇에게 원하는 행동을 이끌 수가 없다.
선생님은 더욱 자세한 예시를 보여준다.
EBS 소프트웨어야 놀자 시즌2. 2회 순차편이 세부적인 정의의 조합이 의도한 행동을 이끈다. 물론 이 예시는 굉장히 단순하다. 하지만 디스크립션의 정석을 보여준다.
즉, 스토리보드의 디스크립션은 세밀하고 정밀하고 확실하게 순서를 알 수 있게 만들어야 한다. 동작도 쓰고 로직도 써야 한다. 목표도 쓰고 정책도 쓰고 예외조항도 써줘야 한다. 그래야 개발하는 사람이 명확한 코딩을 할 수 있기 때문이다.
이런 디스크립션이 세부적으로 잘 쓰여있을 때 우리는 '디스크립션 수준이 높다'라고 한다.
기획과 디스크립션 수준을 높이는 방법
실제 SB예시로 한번 살펴보자.
출처 네이버 이미지 검색위의 스토리보드는 인터넷에서 주운 샘플이다. 아마도 온라인 교육용이라 간단히 모양만 갖춘 것이라고 생각된다.
만약 이 SB가 진짜 개발을 위한 것이었다고 가정하고 한번 살펴보도록 하자. 이 스토리보드는 실시간 동영상과 하단의 채팅으로 이루어져 있다.
디스크립션이 있는 1번 영역과 2번 영역은 동일한 영역이 분기 처리된 형태다. 디스크립션 내용은 이렇다.
입장 등수 표시.
- 내용이 5초 후 아래로 롤링되어 바뀌는 방식
- 등수에 따라 이벤트 가능
랜덤 이벤트 진행 시
- 실시간 방송에 제시간에 입장한 회원 대상으로 랜덤 선정 이벤트 가능
- 예시) 실시간 동영상 오픈 후 10분 내 들어온 회원 대상으로 랜덤 이벤트 가능
머릿속에 동작이 모두 상상했던 기획자 당사자라면 이 설명만으로도 충분히 무슨 말을 하는지 알 수 있다. 하지만 이 설명으로 비주얼 디자이너와 개발자 등과 리뷰를 하는 순간 질문이 쏟아지게 될 것이다.
간단히 생각해봐도 이 1번 디스크립션에 대해서만도 예상되는 질문들은 아래와 같다.
비주얼 디자이너의 예상 질문
5초 후 롤링되어서 뭘로 바뀌는 거죠? 바뀐 뒤의 모습을 알려주세요.
등수에 따른 이벤트에 해당하면 어떤 표시를 해주나요? 옆의 공간은 그냥 비어있나요?
등수 딱지는 몇 등까지 표시되나요? 자릿수가 몇 등까지 노출되나요?
가로모드에서도 동일하게 1줄 전체에 차지하게 나오면 되나요?
랜덤 이벤트 시에는 '랜덤'이라는 딱지명으로만 고정되나요?
개발자 예상 질문
5초 후 롤링될 때 동작은 아래로 가나요? 위로 가나요?
동시에 입장할 경우 입장 등수는 어떤 기준으로 산정하나요?
등수에 따른 이벤트는 어느 back office 화면에서 컨트롤하나요? 이것도 개발해야 하나요?
실시간 방송 전에 인입 시에는 어떻게 처리하나요?
실시간 방송 시간 이후에도 나가지 않고 있는 경우에도 이벤트 진입이 가능하도록 할 건가요?
랜덤 선정 이벤트는 로그인 회원 대상인가요? 회원 중 제외대상은 없나요?
랜덤 이벤트 진행 시 링크 시 뭔가 액션이 있나요?
시작 후 10분은 서버시간인가요? 디바이스 시간인가요? 동영상 시작 시점부터인가요? 실시간 방송이지만 디바이스에 따라 로딩 속도는 다를 수 있어요.
지금은 저 영역 하나만 생각한 거지만, 전체 서비스의 연결 속에서 이밖에도 무수히 많은 질문이 나올 수 있다. 질문이 많다는 건 개발의 알고리즘을 완성할만한 자세한 설명이 부족하다는 뜻이 된다.
기획자가 떠올릴 수 있을만한 질문이라면 정확한 서비스를 위해 미리 고민해보는 것이 모두에게 편리한 길이다. 목표는 정확한 서비스의 전달이다. 물론 틀릴 수 있다. 그러나 기획자가 생각한 로직이 구현 불가능한 수준이라면 개발자가 다시 이슈 제기를 해줄 것이다. 그럼 그때 커뮤니케이션을 통해 더 나은 서비스를 만들 기회가 찾아오는 것이다.
근데 린 UX면 간단히 구상하고
빨리 개발하는 게 디스크립션 작성보다 중요한 거 아닌가요?
요즘 린 UX나 스타트업이 많아지면서 이런 질문들이 많아지고 있다. 디스크립션 작성보다 모양을 만들어서 빠르게 구현하는 게 중요하지 않냐는 것. 틀린 소린 아니지만 포커스가 잘 못 됐다.
린 UX에서 MVP에 집중하라는 것은 디테일에 신경 쓰지 말란 소리가 아니다. 잡다한 기능과 확장 요소보다 딱 핵심적인 기능에 집중하라는 뜻이다.
디스크립션이란 구현을 위한 디테일이고 구상한 서비스를 정확하게 전달하는 것은 MVP에 대한 기획자와 개발자 간의 원활한 커뮤니케이션을 위해서도 중요하다.
SKETCH 같은 목업 툴 사용이 많아지는데 이런 디스크립션이 있는 스토리보드가 필요할까요?
애자일 방법론이 대두되면서 디스크립션이 있는 SB대신 바로 목업 툴을 사용하는 경우도 많아지고 있다. 목업 툴의 사용은 2차원 문서로 설명하기 어려운 동작과 인터렉션들을 직관적으로 전달하고 껍데기만 있는 상태에서 서비스 품질을 검증하는 것에 있다.
처음 아이데이션 단계에서 바로 목업을 하는 것은 얼마든지 좋다. 하지만 제대로 된 산출믈을 만들어야할 시점이 되면 상황이 다르다. 아무리 목업이 디테일하게 돼도 실제 데이터를 불러오고 작성시키고 예외 케이스에 대한 분기 처리를 정의하려면 어떤 방식으로든 로직에 대한 세부적인 디스크립션이 필요하다. 애자일 방법론에서도 '백로그(backlog)'라고 하는 정책만 가득 담긴 정책문서가 있다. 이 백로그라는 것은 거의 디스크립션과 많은 역할을 공유한다. 결국 최초에 기획한 사람은 무언가를 작성해야만 한다.
새로 나온 목업 툴이 기획자의 상상을 정확하게 보여줄 수 있고 그것을 위해 약간의 코딩 기술을 활용할 정도까지 발전했지만 그래도 이것은 실제 제품을 위한 코딩이라고 하기는 어렵다. 실제 앱은 목업이 아니라 개발자의 손에서 창조된다. 때문에 우리는 정확하고 일관성 있게 서비스 로직과 정책, 예외 케이스들을 정의할 영역은 필요하다.
스케치를 도입한 현업에서도 아직도 많은 사람들이 디스크립션에 대한 정의 문서를 별도로 작성하고 있는 이유가 바로 이것이다. 다만 PPT든 AXURE든 아니면 목업 위 메모든 양식은 그것은 중요치 않다. 어쨌든 디스크립션을 쓰고 있는 것이다.
개발언어를 배우는 것만 풀 스택 기획자가 아니다.
디스크립션을 개발과 디자인할 수 있도록 쓸 수 있어야 풀 스택 기획자다.
종종 개발과 커뮤니케이션이 원활한 'full-stack 기획자'를 찾는다는 말을 볼 수 있다. 디스크립션에 대한 수준은 자신이 서비스에 대해 어느 정도의 커버리지를 가진 기획자인지 보여주는 바로미터가 된다. 역지사지의 마음으로 개발자와 디자이너가 필요한 지점을 함께 고민해야만 가능한 것이다.
우리 서비스에 어떤 데이터들을 가지고 있는지 아는 것과 어떤 제약조건과 정책이 있는지 아는 것, 그리고 이것을 충분히 고민해서 디스크립션에 넣는다면 디자인을 모르고 개발언어를 모른다고 해도 풀 스택 기획자에 한걸음 가까워지지 않을까!
P.S. UX 기획에서 작성하는 디스크립션 수준이 낮은데도 서비스가 별문제 없이 나왔다면 그건 누군가가 이 역할을 대신하고 있다는 뜻이라고 생각합니다. 가끔 IT기획 직무와 UX 기획 직무가 모두 존재하는 곳이나 UX직무가 사업부처럼 진행되는 경우 세부적인 로직 기획을 IT에서 하기도 하죠. R&R 문제일 뿐, 누군가는 상세한 디스크립션을 작성하고 여기에 대해서 합의하는 커뮤니이션을 진행한다는 점에서는 일맥상통하는 부분이 있다고 생각합니다.
