brunch

You can make anything
by writing

C.S.Lewis

by 망치 Oct 14. 2018

삽질하며 배운 웹 서비스 기획과 활용 툴_02

STEP2 UI/UX기획 및 스토리보드 작성 단계

(2탄을 너무 늦게 올려서 대단히 송구합니다...)


 3번 이상 기획서 전체를 뒤엎고, 수 번의 수정을 거쳤던 본 프로젝트. 깨달음을 반영해 이상적인 프로세스로 정리해 봅니다. 3번 이상 기획서를 뒤엎었던 배경에 대해서는 최하단에 기술하였으니 참고해 주세요. :) 스타트업에서 처음 서비스 기획을 한다면 겪을 수 있는 상황일 것 같습니다.


이전 글 : STEP1 사전 기획 단계

https://brunch.co.kr/@mmmangchi/17




STEP2 스토리보드 작성 단계

UI/UX 기획부터 스토리보드 작성까지

 상위 전략과 맨먼스에 맞추어 우선순위에 따라 기능을 정의하고, 최적의 UI/UX를 기획해 그려내고, 개발자와 디자이너와 협의하며 스토리보드를 업데이트하는 과정을 끊임없이 반복하는 단계인 것 같습니다.


CONTENTS

2-1/ 유저 태스크 분석

2-2/ 기능 요구 사항 협의

2-3/ 러프 스토리보드 작성

2-4/ 스토리보드 작성

※ 스크롤 압박 주의





2-1/ 사용자 유형별 태스크 분석

  마인드맵을 이용해 여러 기준별로 '유저 유형'을 나누었습니다. 그리고 각 유저 유형별로 '고객여정지도'를 그려 필요한 기능을 도출했습니다. 생각치 못한 유저와 그에 따른 기능들을 발견할 수 있었고, 내부에서 유저와 기능의 우선순위를 논의하기에 매우 유용했습니다. 이후 마케팅 타겟팅에도 좋은 참고 자료가 되었습니다.




2-2/ 기능 요구 사항 기획&개발 협의

 화면을 멋지게 기획하는 것보다 더 중요한 건 이 단계인 것 같습니다. 커뮤니케이션 미스로 인해 공들여 기획한 기능과 화면을 모두 포기해야 할 때, 얼마나 속상하던지요 (ㅠ_ㅠ) 제 경험을 기반으로, 서비스 기획 내내 지속적으로 논의하고 협의해야 하는 대상은 두 유형입니다.


협의 대상1) 내부 각 파트별 담당자들

 서비스 기획자는 서비스의 콘텐츠, 기능에 연계된 팀들의 변화를 꾸준히 업데이트 받아 파악해야 하는 것 같습니다. 서비스 기획자가 미처 놓친 부분에서 변수가 발생하고, 단 하나의 변수가 주문 프로세스 전체를 뒤엎을 수도 있거든요. (생각만 해도 혈압...)

 저도 실제로 스토리보드 작성 80% 단계에서, 상품기획팀에서 새로운 주문 프로세스가 필요한 상품 유형을 기획하고 있었고, 운영 파트에서는 배송과 결제 정책을 변경하고 있다는 걸 뒤늦게 발견했습니다. 그리고 새로운 상품과 변경된 배송, 결제 정책에 맞게 주문/조회 관련 페이지를 모두 보완하고 개발자와 다시 협의해야만 했습니다.

 특히 당시 담당자들은 모두 서비스 기획이 처음인 주니어급들이었기 때문에, 상품, 운영, CS 정책의 사소한 변화가 사이트의 버튼, 옵션, 문구의 변경을 요구할 수 있다는 걸 차마 인지하지 못한 게 화근이었습니다. 때문에 이러한 문제를 사전에 내부의 모든 정책 변경 사항은 서비스 기획자가 알 수 있도록 체계를 만드는 건 매우 중요한 것 같습니다.


<체크리스트>

상품 포트폴리오

시나리오별 서비스 정책 (가입, 상품, 결제, 배송, CS 등)

마케팅 콘텐츠 유형 (후기, 이벤트 배너, 기획전, 쿠폰 유형 등)


협의 대상2) 개발자

 개발자는 글쓰기 버튼 하나, 배너 하나도 코딩해야 하는 '기능'으로 보기 때문에, 기능 요구서를 매우 구체적으로 기술해야 명확한 커뮤니케이션이 가능한 것 같습니다. 기획자 입장에서 개발자에게 '게시판'이 필요하다고 러프하게 협의해 놓고, 이후에 갤러리 형태의 UI, 회원별 글쓰기 권한 기능들이 추가된 게시판 기획안을 내놓으면 개발자는 당황합니다.


기획자 曰 "버튼 하나 추가하는 거, 간단한 거 아닌가요?" vs. 개발자 曰 "네? (빠직)"


<체크리스트>

전체 메뉴 구조를 파악할 수 있는 IA(Information Architecture)

버튼 하나까지 모두 포함한 기능 요구 정의서

UI 스토리보드까지 있으면 완벽


IA 중간 단계


2-3/ 러프 스토리보드 - 프리핸드 스케치

- 목적 : 브레인스토밍, 내부 회의용, 스토리보드 작성하기 전 사전 스케치 (개발자 있다면 함께 기능 논의)

- 방법 : 시나리오별로 화면마다 종이에 UI를 그린 후, 관계자 회의 통해 수정/보완

- 비고 : 필요에 따라 레퍼런스 조사, 스터디, 벤치마킹 병행하며 발전 (버튼, 프레임, 옵션 등등)


좌측부터 첫번째, 두번째 이미지는 UI디자이너가 스케치한 그림



2-4/ 스토리보드 작성

- 목적 : 실제 디자인과 개발에 사용되는 문서로, 개발자, 디자이너 커뮤니케이션용

- 내용 : 아래 참고

- 비고 : GUI 디자인의 경우, 브랜드 정책과 함께 디자인 가이드라인 구축도 함께 병행 필요


스토리보드의 꽃은.. '디벨롭'인 것 같습니다.. ^^..

내부 관계자들과 개발자와 논의하며 끊임없는 기능, UI 업데이트의 반복.

당시엔 개발사 매니저와 협업하며 스토리보드를 계속 업데이트 해나가며 기능을 협의했습니다.

삽질의 흔적. 쥬륵.


[스토리보드 목차별 상세 내용]


1. AI

일종의 Index 역할이며, 각 화면에 해당되는 스토리보드 페이지 번호 기입


2. 공통 레이아웃

헤더, 푸터 포함 반복되어 사용되는 화면 레이아웃


3. 플로우챠트

주요 태스크별로 각 화면과 버튼이 어떻게 상호작용 하는지 상세 프로세스 안내


[예시1. 회원가입 프로세스]

.


[예시2. 구매 프로세스]

[예시3. 백엔드에서 구현될 어드민 스토리보드]



4. 상세 화면 기획



5. 콘텐츠 기획

 에러 페이지 포함하여 전환 포인트마다 우리 서비스만의 아이덴티티를 녹이고 싶어서 기획한 페이지.

당시 유저가 다소 특수한 '농부'였으므로, 관련 컨셉을 녹였습니다. (귀엽지 않나요 헤헤)


[회원가입 시]


[검색 결과 없을 시]


2-5/ 스토리보드 디벨롭

 

[Ver1.01~1.99] 기능 협의 단계용

 프리핸드 스케치와 피드백을 끊임없이 거치는 과정이며,

동시에 개발자와 커뮤니케이션하면서 Default/Save/Write/View/Edit 모든 기능과 API를 단계


[Ver2.01~2.99] 개발 착수 전 최종 협의용

  최종 기능은 확정된 상태로, GUI 디자인 착수/병행 가능할 수 있는 수준으로 UI 설계 완성도가 높아야 한다. 대부분의 의사 결정 사항이 정해진 상황이므로, 콘텐츠/배너 제작, 상세 운영 솔루션 기획 등이 함께 병행될 수 있다.


[Ver3.0] 최종 산출물

 GUI 디자인 확정과 함께 퍼블리싱 및 개발 착수

(저희 프로젝트는 마감 일정을 맞추기 위해 GUI디자인/퍼블리싱/개발을 섹션별로 나누어 동시에 진행했어요)



※스토리보드 작성 시 사용한 툴

- UI : Oven(https://ovenapp.io/) ; 개인적으로 무료라서 좋았어요.

- 플로우챠트 : draw.io (https://www.draw.io/)



끝나고 나서 깨닫다.


1. 프로젝트 계약서의 중요성

 외주 개발을 진행하는 스타트업은 멍청한 것이라는 글을 프로젝트 적이 있다. 애석하게도 우리는 외부 개발사를 통해 개발을 진행했다. 때문에 커뮤니케이션 비용은 어마어마했고, 가장 문제는 계약 조건에 대한 미스 커뮤니케이션에서 터졌다.

 계약서에 명시된 맨먼스가 아니라, 개발사 총책임자가 영업형 멘트로 던진 "다 해드릴게요 걱정마세요"를 믿어버렸던 순진한 우리. 총책임자와 대표님만 믿고 풀스펙으로 기획을 달리다가 3개월 후 결국 전부 다 뒤집어야 했다. 물론 킥오프 미팅 나름의 사전 기획서를 들고 갔다. 그런데 지금 와서 보니, 그림만 그리고 구체적인 기능 요구 사항을 들고 가지 않았던 문제였던 같다. 킥오프 미팅 구체적인 기능 협의를 먼저 거칠 수만 있었다면, 추후 실무자와 기능 협의 문제를 초래하지 않았을지도 모른다.

 외주 업체를 통해 개발할 경우, 기획자도 계약서 내용을 꼼꼼히 챙길 필요성이 있을 수 있다는 생각이 든다. 기획자가 외주 업체와의 계약 조건을 잘 알고 있어야 커뮤니케이션을 문제 없이 할테니까.


2. 서비스 기획은 UI 설계가 아니다.

 서비스 기획은 처음이었으므로, 이해도가 낮았다. 초기엔 눈에 보이는 UI/UX 디자인에 많은 시간을 투여하느라 정작 백엔드의 데이터 구조와 프론트의 상세 기능들을 더 꼼꼼히 챙기지 못했다. 개발자와의 효율적인 커뮤케이션은 UI 보다 기능 요구 정의서가 더 중요한데 말이다.



이상 끝.

여기까지 읽어주셨다면 대단히 감사함을 표합니다.

많이 서툴게 진행한 프로젝트였던만큼, 홀로 많이 고군분투하며 시행착오를 겪었어요.

마무리하고 나니 많이 성장했음을 느꼈습니다. (비록 건강은 잃었으나.....쥬륵)


모든 스타트업의 주니어 기획자 분들, 밤샘 많이 하시지 마시고! 끼니 거르지 마시고!

부디 건강히 일 하세요. (진심 10304982957982kg)


매거진의 이전글 삽질하며 배운 웹 서비스 기획과 활용 툴_01

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari