brunch

매거진 스타트업 노동자

라이킷 435 댓글 21

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 망치 Jul 10. 2017

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

STEP1. 서비스 리뉴얼 전략 수립부터 킥오프 미팅까지

지난 7개월 간, 몸담그고 있는 스타트업에서 별안간 한 번도 해본 적 없던 서비스 리뉴얼 기획을 떠맡게(?) 되었다. 심지어 노하우를 가진 상사 없이 프론트부터 어드민까지 150page 이상의 화면 기획과 10명의 사람들과 커뮤니케이션을 해나가야 했다. 독학에 의존하며 수십번의 밤샘과 삽질, 그리고 예상치 못한 변수에 이리 저리 깨져가며 배운 사항들을 정리해 보고자 한다. ㅡ 즉, 상사도 없이 혼자 맨땅에서 구르며 터득한 내용들이라 야매...라는 것입니다. 개인적으로 리뷰할 겸 저처럼 삽질해야 하는 스타트업 기획자 분들을 위해 이렇게 공개글로 정리해 봅니다. 피드백은 언제나 감사히 받아들입니다. 진짜루.

※ 참고로 특정 산업에 특화된 디자인 상품 판매몰(로고, 명함, 박스 등)로, 마켓플레이스와 전자상거래가 복합된 서비스를 담당했습니다.

HISTORY

대부분의 초기 스타트업 고충인 고급 전문가 부재와 외부 개발 업체 핸들링 노하우 부족은 정말 갖은 출혈들을 낳았다. 전문성 있는 분이 함께 했다면, 보다 더 위기 상황에 현명하게 대처하고 더 빠른 속도로 프로젝트를 완수할 수 있었을까? (아련...)

12월 : 내부 사용성 테스트 및 개발사 킥오프 미팅 진행

1월 : 어드민 포함 1.0 스토리보드 작성

2월 ~3월 : 외부 개발사와 협의를 거쳐 2.0 스토리보드 작성

4월 : 프론트 스토리보드 보완 및 GUI 디자인 본격 착수

5월 : 본격 퍼블리싱 및 개발 착수

6월 : 퍼블리싱 및 개발 마감

프로젝트 리뷰를 정리하다 보니 생각보다 양이 많아져 세 파트로 쪼갰다. 헉헉.

STEP1 사전 기획 단계 : 서비스 리뉴얼 전략 수립부터 킥오프 미팅까지

STEP2 스토리보드 작성 단계 : UI/UX기획부터 스토리보드 작성

STEP3 제작 단계 : GUI 디자인 및 퍼블리싱, 개발 착수

그럼, 그 첫 번째 이야기.

STEP1 사전 기획 단계

서비스 리뉴얼 전략 수립부터 킥오프 미팅까지

서비스 담당자인 나와 우리는 욕심이 너무 많다. 그래서 방향과 범위를 명확히 정하는 이 단계가 몹시 중요했다. 대표-기획자-디자이너-개발자 모두가 하나의 그림을 명확히 그리는 단계. 목표가 무엇인가! 앞으로 무엇을 하고 하지 않을 것인가! 그래야 추후 큰 트러블을 최소화하는 듯.

이 때 중요한 건 대표나 기획자의 열정이 아니라 개발자의 냉정함이다. 이 기능 들어가면 대박!!이라고 하면 뭐하나, 개발자가 NO! 하면 끝인 것을. 뜬구름 잡는 비즈니스모델, 기획자의 기발한 아이디어, 깔쌈한 페이퍼워크 다 필요없고 중요한 건,

[최종 핵심 결과물 : 개발자와의 킥오프 미팅 자료]

'개발자와의 성공적인 커뮤니케이션'을 목표로, 개발자와 개발 범위와 일정을 미리 약속하고 YES or NO를 명확히 할 수 있는 자료가 되어야 한다. (하지만 정작 제 자료는 시간 지나서 보니 그렇지 못했다는 거~~~ ^0^)

그리고 이 하나를 만들기 위한 총 5가지의 과업

1-1/ 내부 리뉴얼 전략 논의

1-2/ 기능&콘텐츠 요구 사항 도출

1-3/ 서비스 정책 수립

1-4/ IA 초안 작성

1-5/ 킥오프 미팅 자료 작성

1-1/ 내부 리뉴얼 전략

'구매 회원'을 위한 '친절한 가이드'가 되자!

기존 베타 버전은 서비스 특성(마켓 플레이스 + 판매몰)을 전혀 고려하지 않고 일반적인 쇼핑몰 형태로 구축하여 서비스 운영의 필수 기능이 다수 부재했다. 그로 인해 유저 뿐만 아니라 관리자의 운영 편의성이 상당히 저조한 상태였다. 서비스 기획 초기에 흔히 하는 여정 맵 분석 등이 무쓸모할 정도로 전 단계가 빈약했다. 서비스 활성화를 위해 가장 중요하게 고려해야 하는 유저를 먼저 살펴봤다.

1)회원A _디자인 구매자 (주로 4050 중장년층)

2)회원B _디자인 판매자 (주로 2030 젊은 층)

3)관리자A_상품 관리 : 판매 회원부터 내부 PB 상품까지 관리

4)관리자B_판매 관리 : 주문 접수된 디자인 시안 관리부터 실 제작까지 담당

"누구의 사용성을 가장 고려해야 하는가? 즉, 상대적으로 어떤 유저의 편의성을 잠시 포기할 수 있는가?"

당시 비즈니스 전략 상, 마켓플레이스 볼륨을 키우는 것보단 '내부 기획 상품 판매'에 주력하는 것이 우선 목표였기 때문에, 판매 회원보단 '구매 회원'에 초점을 맞추기로 했다. 따라서 모든 기능, UI/UX, 콘텐츠는 '구매' 태스크를 최우선으로 결정했다. 또한 타겟 연령 특성 상 인터넷 쇼핑에 다소 미숙할 수 있기 때문에, '친절한 쇼핑 가이드'처럼 사이트 곳곳에 가이드 콘텐츠를 배치하고 직관적인 UI로 구매 가이드를 제시해 주기로 방향을 잡았다.

마음 같으면 모든 유저의 사용성을 전부 고려해 풀스펙의 서비스로 업그레이드 하고 싶지만, 초기 서비스라는 점을 감안해 욕심을 버려야 했다. (실제로 풀스펙 업그레이드를 목표로 달리다가 추후 협의 과정에서 우선순위 단 하나를 빼고 모든 걸 버렸다. 주륵....)

1-2/ 기능&콘텐츠 요구 사항 도출

문제 해결 우선 순위 중심으로 '선택과 집중'

The way

기존에 베타 버전 사이트를 약 9개월 간 운영하였으므로, 내부 직원들의 자체 피드백을 모아 베타 버전의 문제점을 도출하고, 개선 방향을 수렴했다. 베스트는 실 고객에게 FGT를 진행하는 것이겠지만, 대표님께서 빠른 실행을 원하셔서 생략할 수밖에 없었다.

1차 : 유저 페르소나별 데일리 피드백 수집 on 구글독스

유저별 특정 페르소나를 설정한 후 각 직원들에게 부여하고, 데일리로 베타 버전 서비스를 이용하며 문제점들을 구글 독스에 마구 모았다. 문제점들이 아주 신명나게 쏟아졌다. 꺌꺌.

2차 : 1차 피드백 취합 및 화면 흐름별 분류 on 트렐로

1차 수집한 피드백들을 취합하여 화면 흐름별로 분류할 필요성을 느껴 '트렐로 Trello'를 활용했다. 아주 굿이였다.

유저의 서비스 이용 흐름에 따라 각 화면별로 피드백을 재분류하고, 이미지나 링크도 추가 메모 가능하다.

화면 외의 파트도 이렇게 수집 가능. (일반적인 내용은 블러 처리 하지 않았어요)

컬러 라벨링은 진행 상황 혹은 담당 팀을 구분짓기에도 용이했다.

Problem & Solution 도출 결과

구매회원/판매회원/관리자 모든 유저의 사용성을 높히기 위해 필요해 보이는 기능과 콘텐츠는 너~~~~무 많았지만, 우리는 분명 사전에 기준을 정했다. '구매회원' 중심으로 뽑은 우선순위 3가지 문제점과 해결책.

01 서비스 아이덴티티 전달력 미비 ⇒ '쇼핑몰 UI'와 '친근한 T&M'으로 직관성 UP

"뭐 하는 사이트여? 그냥 디자인 회사여?" 베타사이트를 처음 본 어르신(주요 타겟이 4050)들이 하시던 말씀.

쉽게 말해 디자인 구매 사이트, 쇼핑몰같은 곳이라는 것을 쉽게 자각하지 못하셨다. 서비스 초기 단계인만큼 '쇼핑몰'임을 '직관적'으로 전달하는 게 필요했고, 디자인의 큰 과제였다.

02 서비스에 특화된 구매 필수 기능 & 가이드 콘텐츠 부재 ⇒ 추가 기획

디자인 템플릿을 판매하는 서비스인데, 사이트 내에서 디자인 시안을 확인하고 수정 요청할 수 없다. 복수 주문을 하는 고객이 많은데 장바구니 기능도 없다. 심지어 구매에 대한 구체적인 안내 사항도 없어 전부 전화CS로 처리하고 있었다. ㅠㅠ 또한 제품 타입이 다양해지고 있어 그에 맞춘 주문 기능과 콘텐츠는 더욱 중요했다. 필수 기능과 콘텐츠만 더해져도 전화 CS 비용은 확 줄어들고 구매전환율은 올라갈 것이다.

03 모바일 최적화 부재 ⇒ 추가 기획

Only 모바일을 외치는 시대인데! 실제로 사이트 방문자의 40~50%가 모바일 기기 사용자인데! 모바일 최적화가 안 되어있다니. 맙소사였다. 그래서일까 홈에서 이탈율이 40%를 육박하고 있었다. 모바일 사이트는 필수로 개발해야 했고, 다만 일부 상품의 경우 모바일에서 주문을 완료하기엔 입력을 요구하는 정보가 많아 PC 주문 권장을 별도 안내 했다.

1-3/ 서비스 정책 수립

'내부 Rule'이 견고해야 기획이 흔들리지 않는다

위에서 사용자 입장에서 화면/태스크별 요구 사항을 도출했다면, 내부에서 사용자 요구 사항을 서비스에 어떻게 반영할 것인지 기준을 마련하는 것은 꼭 필요하다. 사전에 기준을 제대로 정리하지 않으면 추후 문제를 발견하고 수정이 발생하는데, 기능 단 하나 변형/추가가 전체 구조를 다 뒤엎어버릴 수 있다. 새로운 상품 타입 하나만 추가해도 새로운 주문 프로세스 구축, 새로운 UI 디자인 페이지, 사이트 메뉴 수정까지 다 건들어야 할 수 있기 때문이다. 실제로 서비스 기획 70%가 진행되었을 때 동시다발적으로 상품기획팀에선 새로운 상품 타입이 추가되고, 운영팀에서는 배송 정책이 바뀌고 있었다. (오마이갓....) 비즈니스 상 이미 진행된 일, 서비스 기획자는 묵념하고 모든 걸 다시 웹서비스에 기능과 콘텐츠, 디자인적으로 반영하느라 몇 날 밤을 더 샐 수 밖에. 때문에 초반에 전 부서 담당자와 소통하며 협업하는 것이 정말 중요하며 기획자는 중심에서 이를 이끌며 서비스의 핵을 만들어야 하는 막중한 임무를 지니고 있다.

서비스 기획을 본격 시작하기 전에 전 직원이 함께 정리해야 할 과제들. (서비스 모델에 따라 일부 상이)

Q. 브랜드 정책 : 브랜딩 전략과 그에 따른 슬로건, 톤앤매너 등은?

Q. 디자인 정책 : 디자인 아이덴티티(컬러, 아이콘, 이미지, 일러스트 등)는?

Q. 상품 정책 : (쇼핑몰이라면) 상품 전체 포트폴리오와 추가 기획될 상품 특성, 필요 이벤트는?

Q. 운영 정책 : 배송, 결제, 환불 등 기본적인 운영 방법은?

Q. CS 정책 : 고객 응대 채널, 규칙은?

Q. 게시물 관리 정책 : 지속적으로 발행 예정인 게시물 주제와 타입은?

▼ 정책 관리 문서

이런 식으로 정책 관리용 공유 문서를 만들어 내부 직원 전체와 공유했다.

1-4/ IA(Information Architecture) 초안 작성

하나의 IA로 전체 페이지 체크리스트부터 일정 관리까지

위 단계를 모두 밟았다면, 전략과 정책을 고려하며 필요한 기능/콘텐츠 요구 사항을 정의하고 메뉴 구조를 짤 수 있게 된다. 즉, IA를 작성할 수 있는 것이다. 맵으로 간소화된 형태의 메뉴구조를 작성한 후, 디테일한 메뉴 구조는 엑셀을 활용한다. 이 IA 초안을 기반으로 개발사와 킥오프시 총 페이지 수와 기능들을 먼저 협의하고, 스토리보드를 작성하고 개발자와 협의하면서 최종 IA로 꾸준히 업데이트하면 된다. 사이트 전체 메뉴와 페이지가 모두 IA에 들어가야 하며, 따라서 전체 페이지의 특이사항과 일정 등을 한번에 관리하기 매우 용이하다. 초짜인 나는 백오피스까지 IA를 처음 작성해 보는데다가, 다소 복잡한 서비스 모델때문에 계층 구조 정리에 애를 정말 많이 먹었다.

▼ 처음 작성했던 IA로, 필요한 페이지와 뎁스만 간략히 훑어볼 수 있는 정도였다.

▼ 최종 IA 양식. 모든 페이지를 뎁스별로 메뉴를 세세히 쪼개고, 각 페이지별로 타입, 회원 유형, 기획서 No, 기획/디자인/퍼블리싱의 진행상황과 일정을 관리했다. 진행상황의 경우, 색깔별(진행전/진행중/완료)로 표시하니 시각적으로 전체 진행상황을 관리하기에 굉장히 유용했다. 강추. 또한, 구글 공유 문서로 작성했기 때문에 팀원들에게 공유하고 실시간으로 업데이트하기에도 편리하고, 댓글 기능을 이용하여 페이지별 수정/요구 사항을 메모하고 히스토리를 관리하기에도 매우 좋았다.

1-5/ 개발자와의 '킥오프 미팅 자료' 작성

기획자를 위한 문서가 아니라 개발자를 위한 문서로

위 작성했던 IA 초안과 서비스 전체 배경과 전략, 요구 사항을 전달할 수 있는 킥오프 미팅 자료를 들고 만나는 날! 솔직히 6개월이 지나 킥오프 미팅 자료를 보니 정말 부끄럽다; 그간 마케팅 기획서에만 익숙해져 있어서인지 why와 큰 그림에 대한 내용이 쓸데없이 많다. 개발자는 당장 어떤 기능들을 얼마나 개발하면 되는지, what? how? 구체적인 내용을 궁금해 하는데. 나름 서비스/웹/UX기획 책들을 보고 공부했다고, 아는 것들을 적용해 보다가 정작 핵심을 간과했던 것 같다. 아래와 같은 뜬구름 잡는 소리는 짧게 하고, 당장 IA와 기능 요구 사항을 먼저 내밀어야 보다 빠른 협의가 진행되고, 결과적으로 개발 마감을 앞당길 수 있는 듯 하다. 그래야 스토리보드 작성 시 헛기획질 하느라 시간 낭비 하지 않는다.