스토리보드와 개발의 친밀한 관계

최근 우리회사는 운영중인 웹서비스를 한층 더 업그레이드 하고자 현재의 시스템을 완전히 뒤엎고 있다. DB의 ERD도 새로 구성했으며 서버쪽은 물론이고 프론트엔드 쪽도 새로운 디자인으로 작업을 진행중이다. 따라서 기획자인 나도 처음부터 다시 기획서를 작성하고 있다.

 

기존 기획서에서는 시스템의 구조와 비즈니스로직에 집중을 했다면 이번에는 UI에 많이 집중했다. 그 과정에서 문득, 스토리보드를 작성하는 것과 코딩을 하는 것이 많이 닮았다는 생각을 했다. 개발을 할 때 중요한 것 중에 하나가 중복된 코드가 없도록 자주사용하는 부분은 상속을 하거나 혹은 함수를 만들어놓고 필요할 때마다 끌어다 사용하는 것인데 기획서 작성에서도 그런 부분이 필요하다는 것이다. 즉, 개발에서 중복된 소스를 최소화 해야하듯이 기획서에서도 중복된 문장을 최소화하면 좋다는 것이다.

 

 

*아래 내용은 스토리보드를 파워포인트(MS Office)로 작성한다고 가정하고 작성한 글이다. 그리고 지극히 내 개인적인 생각이다.

스토리보드에서 중복된 문장 또는 중복된 화면을 최소화하는 것이 왜 좋은가?

1. 잦은 변경에도 신속하게 대처할 수 있으며 오타의 위험이 줄어든다.

만약 여러분이 100페이지 분량의 웹어플리케이션 스토리보드를 작성했다고 생각해보자. 그런데 어플리케이션의 메뉴가 갑작스럽게 대폭 변경되었다. 그러면 여러분은 100페이지에 들어간 메뉴를 모두 변경해야 할 것이다. 만약 아래 스토리보드처럼 메뉴부분을 예쁘게 작성했다면 수정하는 시간도 많이 걸릴 것이다.

 

storyboard_menu

그래서 나는 아래와 같이 스토리보드를 작성한다. 공통적으로 들어가는 Menu와 Top 부분은 별도로 슬라이드를 작성하여 자세하게 description을 작성하고 그 뒤에 나오는 페이지부터는 아래처럼 메뉴부분에 제목만 넣는다. 이렇게 하면 보기에 예쁘진 않겠지만 Menu에 대한 수정사항이 발생했을 경우 모든 페이지를 수정할 필요없이 Menu 부분의 슬라이드만 수정하면 되기 때문에 효율적으로 프로젝트를 진행할 수 있다.

mystoryboard

2. 개발자가 시스템을 설계하는데 도움이 된다.

일반적인 개발자라면 시스템 설계를 할 때 공통적으로 들어가는 부분이 무엇인지를 파악한다. 그래야 중복코드를 최소화 할 수 있으며 그로 인해 유지보수가 용이하기 때문이다. 그런데 기획서에 이미 공통된 부분을 언급하고 그에 맞춰서 기획을 했다면 개발자입장에서는 시스템을 설계하는데 많은 도움이 될 것이다.

 

 

어떻게 스토리보드에서 중복된 문장 또는 화면을 최소화 할 수 있을까?

위에서도 언급을 했지만 일단, 시스템 전반에 걸쳐 공통적으로 사용되는 기능이 무엇인지를 파악해야 한다. 상황마다 다르겠지만 일반적으로 검색과 파일첨부 기능은 공통적으로 쓰일 확률이 높다.

아래 화면은 PODIO라는 업무관리 시스템에서 공통적으로 사용되는 검색 UI이다. 시스템 전반에 걸쳐 아래 검색UI가 나오기 때문에 이런 시스템에 대한 기획서를 작성할 경우 ‘검색UI 섹션’에 대한 슬라이드를 별도로 작성하는 것이 좋다. 이렇게하면 해당 검색UI를 또 작성해야 하는 상황이 발생했을 때 앞에서 언급한 ‘검색UI 섹션’을 참고하라고 한 줄만 작성하면 된다. ‘검색UI 섹션’에서 화면도 이미 그렸기 때문에 다시 그릴 필요도 없다. 따라서 나중에 변경할 일이 있으면 ‘검색UI 섹션’만 변경하면 되기 때문에 기획서를 효율적으로 관리할 수 있다.

podio 검색

 

나의 경우 이번에 업데이트 되는 Docswave 기획서를 작성하면서 ‘공통UI’라는 섹션을 별도로 만들고 검색기능, 파일첨부, 결재선 지정기능 등 자주사용되는 기능들에 대한 부분을 작성하였다. 아래 화면은 Docswave에서 사용되는 검색기능들을 정리해 놓은 ‘검색UI 섹션’이다.

검색기능

 

디자인 공부 혹은 개발공부가 기획서 작성에 큰 도움이 될 수 있다.

사실 스토리보드를 가장 많이 보는 사람은 디자이너나 개발자이다. 따라서 좋은 기획서를 작성한다는 것은 그들이 이해하기 쉬운 기획서를 작성하는 것이다. 그렇다면 기획자는 고객을 이해하는 것도 중요하지만 디자이너와 개발자를 이해하는 것도 중요하다고 할 수 있는데 내 경험상 그들을 이해하기 가장 좋은 방법은 그들의 분야를 공부하는 것이다. 실제로 내가 개발공부를 하기 전과 후의 기획서는 많은 부분에서 차이가 난다. 사람마다 다르겠지만 나의 경우, 개발공부를 하게되면서 기능에 대한 예외상황을 더 잘 찾아낼 수 있었고 그런 예외처리에 대한 것도 기획서에 작성함으로써 그 전보다 더욱 디테일한 기획서를 작성할 수 있었다.(*물론 내가 개발을 잘하는 것은 절대 아니다.)

 

개발자들의 코딩스타일이 다 다르고, 디자이너의 디자인 스타일이 다 다르듯이 기획자도 스타일이 다양하기 때문에 위에서 언급한 내용들이 모든 기획자에게 맞을 순 없을 것이다. 다만, 기획을 이제 막 시작해서 스토리보드를 작성하는데 익숙하지 않은 기획자에겐 도움이 될 수도 있을 것 같다. 웹서비스 기획자에겐 스토리보드를 잘 작성하는 것이 중요한데(하지만 절대로 전부는 아니다.) 모두 각자만의 방식으로 좋은 스토리보드를 작성하길 바란다.

0 Shares:
답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

You May Also Like
Read More

기획자와 스토아철학

기획자로서 일을 하다보면 생각보다 많은 부분에서 우울할 때가 있다. 그 우울함이 심해지면 '나는 과연 필요한 존재가 맞는가?'라는 생각까지 들곤 한다. 문제는 이런 경험을 자주 할수록 자존감이 낮아진다는 것이다. 내가 겪어온 경험을 토대로 이 문제를 어떻게 극복했는지 이야기하고자 한다.
Read More

내 리더가 회사를 떠났다.

어떤 한 사람이 있다. 그 사람을 보면서 나는 이런 생각을 했다. "저 분의 인성과 역량을 닮고 싶다. 내 아들이 커서 어른이 된다면 나의 모습보다는 저 분의 모습을 닮았으면 좋겠다." 그 분은 내가 현재 재직중인 회사의 CTO이자 나의 리더였다. 아이러니하게도 그 분과 나는 전혀 다른 성격의 소유자이고 업무 스타일도 많이 달랐다. 하지만 난 정말로 그분을 닮고 싶었다.
2021년 회고
Read More

2021년 회고(Product Owner, 가족, 성장)

회사에는 동료와 일이 있다. 가정에는 아내와 애들, 육아업무가 있다. 그러나 그 어디에도 나는 없었다. 원래 나 본연의 내가 존재할 수 있는 시간과 장소는 없었다. 단지, 의무로서의 나만 존재했다. 언뜻 생각해보면 참 서글프기도 하지만 잘 생각해보면 꼭 그렇지도 않다. 현재 나의 상황, 역할, 가족, 일.....그 모든 것이 결국은 나를 구성한다. 원래 나 본연의 나는 처음부터 없는 것인지도 모르겠다.