야메의 이상(理想)한 생각과 공감(共感)

안녕하세요? 웹(WWW)만드는 사람들 운영진, 야메군 입니다.

2012년 상반기에 마지막으로 진행하는 '5주 빡세게 공부하고 5년차 기획마인드 갖기 강좌' 19시즌 강좌를 오는 2012년 6월 19일(화)부터 진행합니다.. 이번 19시즌을 마지막으로 약 두 달 간의 휴강기간을 거칠 예정이오니, 조기 마감으로 인해 강좌에 참석하지 못하셨던 회원님들께서는 늦지않게 서둘러 주시기 바라며 강좌모집 마감일로 갈수록 신청자가 몰리어 조기 마감되는 경우가 많으니, 가급적 여유있게 신청 부탁 드립니다.

지난 2011년 2월 15일부터 진행 중인 웹기획 초급 강좌가 벌써 열 아홉번 째 시즌을 맞이하게 되었습니다. 십여 번의 강좌를 진행하는 동안 어느 덧 2012년이 되었네요.  바쁘신 중 중에도 뜨거운 성원을 보내주신 600여 분의 참가자 분들께 감사드리며 새해의 시작을 웹기획 마인드 강좌와 함께 기초를 탄탄히 다지는 한 해로 만들어 가시기 바랍니다.

이번 강좌는... 기획에 관심이 있는 예비 기획자 및 5년차 이내의 주니어 기획자를 대상으로 진행하는 기획적인 마인드와 기획능력의 중/장기 향상을 목적으로 한 강좌로써 웹 기획 및 사업기획에 대한 기초실무 강좌 입니다..

* 본 강좌는 입금자 우선으로 신청접수를 받습니다.
* 30명 정원이 초과되면 즉시 마감처리 됩니다.
* 매 회차 강의자료는 N드라이브를 통해 강의 전날 공개 됩니다.
* 본 강좌는 매 회차 리포트가 있으며, 수강회원의 노력을 요하는 강좌 입니다.

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

■ 강좌를 시작하며...

제가 웹 기획 관련 업무를 처음 접한 시기는, 대략 2001년 여름 즈음으로 벌써 11년째가 되어가고 있습니다. 당시만 하더라도, 웹 기획이란 포지션이 막 정의되기 시작한 시점으로, 지금과 달리 마땅히 배울만한 교육기관이나 커뮤니티가 없었고 사수 역시도 그에 대한 이해가 부족했기에 웹 기획에 대한 고민은 혼자의 몫이었으며 오히려 직속사수 보다는 개발자나 디자이너를 통해 더 많은 부분을 배우던 상황 이었습니다.

그로부터 11 년이 지난 2012년의 지금...
안타깝게도 그때의 환경과 별반 차이가 없는 듯 보이고 다소 나아졌다고는 하지만 여전히 웹기획을 배우기 위한 문턱은 높은 편이며.. 극히 일부의 회사를 제외하고는 웹 기획자를 육성할 수 있는 환경은 마련되어 있지 않고 있습니다.. 물론, 웹 기획이라는 부분이 개인의 역량과 투자에 많이 좌우되는것은 사실입니다만.. 그렇다고 해서 배움이란 과정이 빠져서는 안되며, 배움이란 과정을 통해, 불필요한 허송세월 없이 빠른 시간 내에 업무를 소화해내고, 더 많은 기획적인 재능을 꽃 피울 수 있다라고 생각합니다.

이번 '웹 기획 5주 빡세게 공부하고 5년차 마인드 갖추기' 강좌는 그간 경험했던 다양한 업무들을 바탕으로 웹 기획에 대한 좀 더 체계화된 가이드라인을 제시하고자 하며, 이를 통해, 새로운 타입의 기획자로써 성장해 나갈 수 있는 기반을 마련해드리고자 합니다.

■ 웹 기획 강좌 진행 안내

[강좌명칭] 웹 기획 빡세게 공부하고 5년차 기획마인드 갖추기 시즌 19
[진행기간] 2012년 6월 19일(화)부터 2012월 7월 17일(화)까지. (매주 화요일, 총 5회 진행)
* 강의 장소 예약 상황에 따라 세부일정이 약간 조정 될 수도 있습니다.
* 일정 변경 시, 사전에 안내해 드립니다.

[참가자격] 웹 기획에 관심있는 예비기획자부터 5년차 이하의 주니어 기획자 대상.
[진행시간] PM 10:00 부터 10:00까지 약 2시간 진행.
[진행장소] 신촌 토즈 비즈센터 (2호선 신촌 역 인근에 위치)(http://toz.co.kr/company/company_servicecenter.asp?parm=contact&idx=14)

[커리큘럼]
■ 1주차) 웹 기획자가 꼭 갖춰야 할 마인드와 지식
- 웹 기획이 뭔가요?
- 웹 기획자가 갖춰야 할 능력과 역할.
- 웹 기획자가 다루어야 할 툴과 지식들.
- 기획용어 이해하기.

■ 2주차) 탄탄한 웹 기획을 위해 필요한 과정 익히기
- 벤치마킹 하기
- 프로세스 구성하기
- DB구조 이해하기
- 스토리보드 구성하기

■ 3주차) 웹 기획의 심층지식 익히기
- Event
- WebLog Analysis
- Service
- Back Office

■ 4주차) 사업기획의 기본 따라잡기 (신규 커리큘럼!!)
- 사업기획의 목적
- 사업기획과 스토리텔링
- 사업기획을 위한 Warming-up
- 사업기획의 7가지 조건
- 사업기획의 접근방법
- 좋은 사업기획서의 요건
- 기획서의 초안 작성
- 사업기획서의 세부내용

■ 5주차) 5년 차를 뛰어넘는 아이디어와 프리젠테이션 노하우
- 아이디어 머신으로 거듭나기
- 나만의 웹 기획 포지셔닝 구축하기
- 능력있는 프리젠터/커뮤니케이터가 되어보기
- 강좌를 마치며

[신청기간] 2012년 6월 18일(월)까지.
[참가인원] 선착순 30명.
* 참가인원이 10명 미만일 경우, 강좌는 진행되지 않습니다.
* 강좌 미 진행 시, 사전 입금된 금액은 환불처리 해 드립니다.
* 강좌 진행 후, 불참에 따른 환불은 없습니다.
* 참가인원에 따라 강의장소를 예약하므로 강의 시작일 기준, 일주일 이전까지만 환불 가능합니다.

[참가방법] 다음의 항목을 기재하여, 네이버에서 아이디 live56 으로 쪽지 발송. 
* 참가자 평균 정보(성별/연령/직군 등)에 따라 강좌의 내용이 약간씩 달라지므로 꼭 보내주세요.
- 이름 :
- 성별 :
- 나이 :
- 전화 :
- 직장 :
- 업무연차 :
- 네이버 이메일 : (N드라이브 공유가 가능한 계정으로 알려주세요!!)
- 참가비 입금여부 :
- 강좌에 바라는점 :

[참가회비] 100,000원 (각 회당 20,000원, 강의장소 대여와 자료 및 경품제공 등의 비용으로 사용)

* 사업자가 아닌 관계로, 별도의 세금계산서/간이영수증은 제공하지 않습니다.
* 원하시는 경우, 강좌 참가확인증은 발급해드릴 수 있습니다.

[회비납부] 강좌참석을 쪽지로 신청한 후, 본인의 실명으로 온라인 입금
[입금계좌] 시티은행 187-00329-266
예금주 : 최준호 (010-5183-8272 / NATE ON live55@lycos.co.kr)
* 강좌 진행과 관련해 궁금하신 점은 네이트 온을 통해 문의해 주세요.

이번 강좌는 짧은 시간 내에 참가자의 기획적인 역량을 극대화시키고자 하는 목적을 가지고 있기 때문에 제 노력뿐만 아니라 수강 회원들의 많은 노력이 뒤따르는 강좌 일 뿐만 아니라.. 적지않은 비용이 소요되는 강좌이므로, 강좌신청 전에 참석에 대한 충분한 고민을 해 주시기 바랍니다.  그럼 6월 09일에 뵙겠습니다. 기대해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

PS.
참고로 "S*S 아카데미"와 같은 학원에서도 웹기획 강좌가 개설되어 있으나 강의의 질이나 수준이 상당히 떨어지는 편입니다...(실제로 해당 강좌를 참석했던 수강생들의 이야기들이 동일하며, 강의자료 역시도 조악한 수준입니다.)단지 학원이라는 공신력에 절대 현혹되지 마시고, 제가 아니더라도 현업의 웹 기획을 전문 포지션으로 활동하는 선배 기획자가 알려주는 생생한 노하우를 익혀보시기 바랍니다..^^ 

 

지금까지 이벤트기획을 주제로 세 번에 걸쳐 포스팅을 했는데, 이벤트기획의 핵심을 잘 캐치하셨는지요, 오늘은 이벤트기획에서 가장 중요하지만.. 가장 간과되고 있는 이벤트기획 이후에 대해 정리함으로서, 이벤트기획 편을 마무리 지을까 합니다. (사실 2회 즈음에서 마무리 질 계획이었으나, 글을 정리하다보니 양이 점점 늘어나더군요..=_=;)

앞에서 이벤트기획을 잘 하기 위해서는 네 가지의 법칙이 이벤트에 잘 녹아있어야 하고... 이에 따른 세부요건을 잘 정리해야 이벤트의 성공을 담보할 수 있다고 말씀드렸는데요... 하지만 실질적으로 이벤트기획의 가장 중요한 부분은 바로 이벤트를 진행한 이후가 되겠습니다. 하지만 대부분의 기획자들은 이벤트를 통해 유저들의 많은 참여를 이끌어내기 위한 부분에 업무 역량의 100%를 소진하고 있으며, 이 때문인지 이벤트가 종료된 이후 다음 번 기획을 진행하기 위한 분석과 방향성 수립에는 다소 인색한 듯 합니다.

[그림. 1] 이벤트의 기대효과 분석은 로그분석 툴을 활용해야 한다.

여기서의 분석은, 이벤트 진행을 통해 얻어진 결과가 애초의 목적과 부합하는지를 따져보고, 기대효과 측면에서 방향으로 내세웠던 예측치.. 즉, 얼마나 많은 매출을 올릴 것인지 혹은 얼마나 많은 회원가입을 기대하는지와 같은 구체적인 예측수치와 결과수치간의 데이터 비교가 그 것인데.. 이 비교를 통해 이벤트의 성과가 기대효과를 초과했다면 어떤 요소로 인해 예측수치를 넘어섰는지.. 그와 반대로 성과가 기대이하였거나 혹은 예상하지 못했던 다른요소가 증감을 했는지를 따져봄으로서 다음 번 이벤트를 진행할 때 플러스 요소를 더욱 강화하고 마이너스 요소를 배제하는 등의 조치가 취해져야만 합니다.



이러한 후속조치를 취하는 이유는 크게 세 가지 정도를 생각해 볼 수 있는데, 첫 번째의 이유가 위에서 언급한 이벤트의 명확한 성공여부를 가리는데 있다면 두 번째 이유는 기획자 본인의 스킬누적에 있겠습니다. 이는 야신이라 불리는 김성근 감독의 팀 운용 스타일과 일맥상통하는 부분이 있는데 바로 데이터를 바탕으로 한 이벤트 운용이며 일정시간 동안 누적된 데이터는 이벤트의 기대효과를 근접하게 예측 함으로서, 이벤트 진행의 효율을 극대화 시킬 수 있습니다.

[그림. 2] 웹로그 분석툴 '로거'의 분석화면.

마지막 세 번째는 기획자 본인의 성과 입니다..  사실 기획이란 포지션 자체가 업무의 성과지표를 뽑기엔 다소 난해한 포지션입니다.  MD의 경우엔 '얼마만큼의 매출을 올렸느냐'는 지표를... CS의 경우엔 '얼마만큼 많은 콜을 소화해 냈느냐' 같은 비교적 명확한 지표수립이 가능하지만, '기획은 리뉴얼을 했다..', '서비스를 새로 만들었다..'와 같은 두루뭉실한 지표 덕택에 제대로 된 업무평가를 받기 힘든 경우가 많습니다.  이 때문에 이벤트 종료 이후의 기대효과에 대한 달성여부 및 달성 수치를 기록함으로서, 객관적인 업무성과를 통해 연봉인상 근거를 확보하는 것도 이벤트 성과지표를 남기는 이유라 할 수 있겠습니다.

지금까지 이벤트 종료 이후, 기대효과에 대한 히스토리화의 필요성 세 가지를 살펴보았는데요, 아마 백이면 백.. 회사에 이러한 근거데이터가 남아있는 경우는 없으리라 생각되며, 사수나 팀장 역시도 이 기대효과의 지표로 삼을 수 있는 데이터를 가지고 있지 않은 경우가 대부분일 겁니다..  때문에 회사 내에 이러한 히스토리를 남기는 것은 향후 회사의 서비스 운영에 보이지 않는 긍정적인 영향력을 제공하며, 기획자 본인도 기획의 스킬을 한 단계 업그레이드 시킬 수 있는 분석적인 사고방식을 갖을 수 있다는 점에서 이러한 분석과정을 선택이 아닌 필수적으로 따라야 한다는 점을 강조하며, 이벤트기획에 대한 웹기획가이드를 마칠까 합니다..

앞서 두 번에 걸쳐 이벤트기획을 주제로 포스팅 했는데 이제 조금은 이벤트기획에 대한 큰 그림이 잡히셨으리라 생각하며, 오늘은 이벤트기획 시 필요한 세부요건을 항목 별로 정리해보도록 하겠습니다.

앞에서 즉시성, 지속성, 단순성, 인지성 등 네 가지의 이벤트 필요법칙과 예시를 정리해봤는데, 이러한 이벤트의 법칙을 적절히 배치하면 '어떻게'에 대한 명확한 해답을 찾을 수 있으며.. 이벤트를 진행하고자 하는 목적과 방향성을 어느정도 일치시킬 수 있습니다. 이 정도를 정리하고도 여전히 '과연' 이 이벤트가 성공할 수 있을 것인지를 정확하게 예측하기엔 다소 모자란 부분이 있으며, 이러한 부족분을 충족시키기 위해서 바로 이벤트 진행을 위한 세부요건을 정리하셔야 합니다.

[그림. 1] 이벤트의 세부요건이 고민되어야 한다.

여기서의 세부요건은.. '이 이벤트를 왜 진행하는가'와 같은 목적과 이벤트를 진행하는데에 있어, 필요한 각종 규칙과 정책 등이 그것인데, 웹기획가이드를 정리하면서 누누히 강조하는 부분이 바로 목적성 입니다. 어떠한 기획이던 간에, 그에 대한 목적을 가장 먼저 정리하는 습관을 길러야 하며 목적이 불분명할 경우 절대 성공을 담보할 수 없다는 점을 다시 한 번 강조 합니다.

[그림. 2] 이벤트의 세부요건 정의

이벤트의 세부 내용을 하나씩 살펴보면 다음과 같습니다.

01. 실제로 사용할 프로모션의 타이틀 명
02. 이벤트의 진행목적
03. 기대효과
04. 진행일정
05. 이벤트의 참여 대상
06. 내용/진행방식
07. 사용자 Benefit
08. 진행요건
09. 이벤트 페이지의 구성 요약

이벤트의 타이틀 명은 가칭이 아닌, 실제 사용할 이벤트의 타이틀을 정리해야만 이후의 내용을 정리할 때 일관성있는 정리 및 기획이 가능하므로, 명확하게 정리하는 것이 중요합니다. 그 다음 이벤트의 진행목적은, 왜 이 이벤트를 진행해야 하는지에 대한 현재의 상황과 배경을 요약하고.. 이벤트를 진행했을 때 개략적으로 어떠한 결과를 얻고자하는지에 대해 정리하게 됩니다.

기대효과는 보다 구체적인 수치여야 한다.

그 다음 이벤트기획의 가장 핵심이 되는 내용 중 하나인, 기대효과를 정리해야 하는데.. 간혹 목적과 기대효과를 혼동하는 분들이 계십니다만, 목적과 기대효과는 엄연히 다른 부분 입니다.  즉, 목적은 이벤트를 진행하는데에 있어, 개략적인 방향성을 제시하는 부분이라면, 기대효과는 보다 구체적으로 '그럼 얼만큼 성과를 낼꺼냐'를 판단하는 구체적인 목표 데이터가 표기되는 영역으로 아래의 예시를 보시면 좀 더 쉽게 이해하실 수 있을 겁니다.

+ 진행목적 | 서비스 내 회원이 회원활동이 부족하므로 이벤트를 통해 회원의 활성화를 도모하고자 함.
+ 기대효과 | 전년도 동일 월 대비 20%의 페이지뷰 증가. / 동일 기준 대비 게시글의 15% 증가.

진행목적과 기대효과의 차이를 분명히 느끼시는지요. 진행목적 상에서 이벤트를 통해 회원의 활성화를 도모하고자 한다고 했을 때, 기대효과에서는 '그럼 얼마만큼 활성화를 할 지'를 정리해주셔야 하는데 이 때 명확한 숫자가 아닌 퍼센트로 기준을 제시하는 것이 바람직 합니다 . 그 이유는 딱 떨어지는 수치를 목표로 삼았을 때, 어느정도의 갭이 발생할 수 있다는 점이며, 보는 관점에서도 수치로 기록되어 있으면, 한 눈에 '어느정도나 상승하는지.'를 체크하기 어려운 부분이 있습니다.

[그림. 3] 이벤트 기획 개요정리 화면.

이 때문에.. '페이지뷰 12,350회 증가' 보다는 '페이지뷰 20% 상승'이 기대효과를 어필하는데 효과적이라는 점을 인지하시기 바랍니다.  아울러 강의를 진행하다보면 비교할 기준점을 어디서 잡아야 할 지를 질문하시는 분들이 많은데, 이 기준점은 전 달 보다는 전년도 동일 기간을 기준점으로 잡는 것이 정확한 포인트라 할 수 있습니다.

그 이유는, 서비스에 따라서 시즌을 타는 서비스들이 있기 마련이고, 이 경우, 특정 월에 진행하는 이벤트의 기준점을 전달의 동일 기간으로 잡게 될 경우.. 데이터 간극이 크게 벌어질 수 있으며 이벤트의 성과가 불 분명해 질 수 있으며, 전년도와 현재의 데이터 자체는 큰 차이가 있을 수 있겠지만.. 퍼센트 자체는 크게 변화되는 부분이 없으므로 '전년도 동일기간 대비 몇 퍼센트'로 기준점을 잡는 것이 바람직 합니다.

그 다음, 진행일정과 타깃유저의 범위를 설정해야 하는데, 타깃유저의 경우 물론 전체 회원을 대상으로 진행한다손 치더라도, 좀 더 구체적인 가이드라인 설정을 통해, 실제로는 '어떤 성별의 어떤 연령대를 가진 유저가 대상이다'와 같은 구체적인 설정을 해주시고 그에 맞는 이벤트 상품 선정 및 진행방식을 수립할 필요가 있습니다.



이벤트의 정책으로 뒷 문을 단속하자!!

이 과정을 거쳐, 전반적인 이벤트 진행방식을 정리하고 사용자에게 주어질 혜택을 정리한 후, 진행요건을 정리하게 되는데, 여기서의 진행요건은 이벤트의 '정책'으로도 설명될 수 있습니다..  여기서의 정책이란 참여의 제한 기준이나 혹은 참여 시 고려요소를 의미하는데... 이러한 정책적인 요소가 제대로 고민되지 못할 경우 이벤트에 구멍이 생길 수 있으며, 이 구멍으로 인해 매우 큰 문제를 야기시킬 수 있습니다.

예를 들어, 이벤트를 진행하는 중에 우연하게 접근하던 아니던 특정 사용자가 정해지지 않은 경로로 이벤트에 접근해서 불법적인 이득을 얻었을 경우, 이미 이벤트를 릴리즈한 상태라면 내리거나 수정하기가 쉽지 않을 것이며 이는 곧 상당한 클레임 요소로 남게 될 가능성이 크며, 이를 방지하기 위해서는 이벤트 기획 시, 이벤트를 진행하기 위한 구체적이고도 디테일한 정책을 수립해야 하고 릴리즈 전에 꼼꼼한 테스트를 통해, 문제요소를 사전에 체크할 수 있어야 합니다.

이러한 과정을 거쳐.. 최종적으로 이벤트를 진행에 필요한 웹 페이지나 팝업, 기술 또는 기능 등을 정의해 줌으로써 이벤트기획의 개요와 정책정리를 마무리하게 되는데.. 이에 대한 세부적인 사항은 본 포스트에 첨부된 웹 프로모션 진행양식을 참조하시면 실질적인 이해해 도움이 되시시라 생각하며, 다음 번 웹기획가이드를 통해, 이벤트 종료 후 기획자가 해야 할 주요 업무에 대해 정리하는 것으로 이벤트기획에 대해 마무리 짓도록 하겠습니다.

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 '웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기' 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

오늘은 앞서 정의했던 이벤트기획의 법칙과 이벤트를 구성하는데 필요한 필수항목들을 정리해보도록 하겠습니다.. 이벤트를 잘 진행하기 위해서는 네 가지의 방향성, 즉시성과 지속성, 단순성과 인지성이 있다고 말씀 드렸고, 이 중 즉시성과 지속성에 대해 예시와 함께 설명 드렸는데요.

이벤트의 세 번째 법칙인 단순성은 사용자의 이벤트 참여를 최대한 단순, 간결화 하는 것을 의미하는데... 사용자가 이벤트를 참여하는데 있어 참여 과정이 복잡하거나 혹은 이벤트를 참여를 위한 학습이 필요할 경우, 이벤트의 참여율은 마니아 중심적인 형태로 전락하게 됩니다.  사실, 마니아 고객이라는 게 어떻게 보면 충성고객으로 분류 될 수 있고 그 존재의 가치가 매우 긍정적일 수 있지만... 이벤트에서의 마니아 고객이란 실제 사이트의 이윤활동에 큰 도움이 안되는... 속된 말로.. '불필요한 회원'이 될 가능성이 큽니다...

이벤트 열성회원을 배제하라!!

일반적으로 이벤트를 진행할 때, 특정 고객층을 대상으로 진행하는 경우도 있겠지만 대체적으로 사이트 내 회원 전체를 대상으로 하는 경우가 대부분이며 이벤트를 기획한 기획자 역시도 이벤트 자체를 위한 활동이 많은 것 보다는 일상적으로 많은 활동을 한 회원에게 경품이 돌아가기를 내심 기대합니다. 하지만, 극히 일부... 경품만을 목적으로 이벤트에 참여하는 이벤트族으로 인해 실제 경품이 돌아가야 할 회원... 즉, 사이트의 이윤활동에 도움이 되는 회원이 아닌.. 실제로 도움이 되지 않는 이벤트 열성 회원들이 경품을 받아가게 되며, 결과적으로 이벤트의 효과가 반감되는 결과를 낳게 됩니다.

[그림. 1] 성공하는 이벤트의 일반회원과 열성회원의 기간대비 참여율.

물론 이벤트의 활성화 측면에서 봤을 때, 전혀 무의미한 회원은 아니겠지만 애초의 목적성과 방향성을 고려했을 때는 그리 바람직한 결과는 아니라고 볼 수 있겠습니다.

위의 그림은 성공하는 이벤트의 회원성향 별 참여율을 비교한 그래프인데... 일반회원의 참여율이 높아지면 높아질 수록 이벤트의 성공율이 높아지며.. 열성회원은 42.195km를 달리는 마라톤에서 선수들의 기록향상을 위한 '페이스메이커'의 역할을 수행하는 것처럼 일반회원의 관심도를 불러 일으키고.. 이들의 관심도가 상승하는 시점에서 열성회원의 참여율을 낮추는 것이 성공적인 이벤트의 조건이라 할 수 있으며, 이러한 조건을 충족시키기 위해서는 일반회원과 열성회원의 참여를 분리시킬 수 있는 별도의 프로세스가 필요합니다.



이러한 부분을 고려하여.. 일반적인 회원들이 참여하기 어려운 복잡하거나 번거로운 형태의 이벤트가 아닌, 단순한 형태의 이벤트를 만듦으로서, 회원이라면 누구나 쉽게 이벤트에 참여할 수 있는 프로세스를 구성해야 하며, 여기에 마니아 회원 중심이 아닌.. 마니아 회원들이 밑 밥을 깔아주는 형태로 진행되어야, 비로서 이상적인 이벤트라 할 수 있으며, 이에 대한 대표적인 케이스로 괄호 채우기 이벤트나 여러 페이지에 불규칙적으로 노출된 풍선 레이어를 클릭해서 많이 모으는 이벤트 등이 있는데... 괄호 채우기 이벤트에서 '정답은 어느어느 페이지에 나와있다..' 같은 형태의 학습형 프로세스로 진행될 경우.. 대다수의 사용자들은 아마도 귀찮아서 괄호 채우기를 포기할 가능성이 높습니다. 

이 때문에, 이벤트 페이지 내에 노골적으로 정답을 보여주는 것이 일반적이며 기획자의 애초 의도인 광범위한 학습효과를 가지게 하기 보단, 특정한 키워드를 인지시키는 방향으로 이벤트를 진행하는 것이 더 바람직한 방향이라 볼 수 있겠습니다.

이벤트 타이틀이 중요한 이유?!

마지막 네 번째 법칙은 인지성 입니다.  이 인지성은 이벤트를 참여하는 데에 있어 이벤트 타이틀이나 형상화 된 이미지 등으로 어떤 종류의 이벤트인가를 명확히 인지시킬 수 있어야 한다는 것이 핵심 키워드인데, 보통의 이벤트를 살펴보면 사용자들은 이벤트의 내용.. 즉.. 참여방법이나 규칙에 대해 제대로 숙지하지 않는 경우가 대부분 입니다. 아무리 굵은 박스로 눈에 띄게 '이벤트 참여안내'를 만들어놔도 잘 안읽는다는 것이죠.

이 때문에, 이 같은 인지성을 높이기 위해서는 이벤트 타이틀에서부터 충분한 고민이 수반되어야 하며 타이틀을 통해 사용자에게 최소한의.. 그리고 핵심적인 이벤트 진행방법을 인지시켜 줌으로써 이벤트의 참여율을 높이고, 이벤트로 인해 발생하는 사용자 클레임을 최소화 시킬 수 있습니다.  예를 들어...

EX 01. 추석맞이 빅3 대박 이벤트!!
EX 02. 친구 추천하고 유럽여행가자!!

이 두 가지 형태의 타이틀을 비교했을 때... 대부분의 사용자들은 두 번째 타이틀을 통해 이벤트의 형태나 진행방식의 인지가 쉬울 겁니다.  뿐만 아니라 타이틀로 인한 호감도를 느끼는 사용자라면 이벤트를 참여하기 위해 좀 더 집중해서 전반적인 진행 프로세스를 익히게 될 가능성이 높으며.. 이러한 작은 차이는 결과적으로 이벤트의 실질적인 성과로 이어지게 됩니다.

[그림. 2] 카툰을 활용하면, 사용자는 흥미요소로 받아들인다.

여기에, 사용자에게 이벤트 진행방식의 인지율을 높일 수 있도록.. 카툰이나 픽토그램 형태의 가이드를 배치함으로써 텍스트 중심의 설명보다 더 나은 효과를 얻을 수 있다는 점도 참고하시기 바랍니다.

아울러, 인지성의 범위는 이벤트 자체의 인지 뿐만 아니라, 이벤트에 참여한 사용자들에게 이벤트에 참여했음을 알리는 부분도 해당되는데, 이벤트 참여를 완료한 사용자에게 SMS 또는 이메일을 통해 이벤트에 참여했음을 알려주고.. 당첨자 발표날에 SMS를 통해 이벤트 당첨 발표일이 오늘이라는 점을 고지시키는 것도 인지의 범위를 넓힐 수 있는 좋은 수단이라는 점도 참고하시기 바랍니다.

지금까지 즉시성, 지속성, 단순성, 인지성 등 네 가지의 성공적인 이벤트법칙을 예시와 함께 간략하게 설명했는데.. 앞선 글에서도 언급했지만, 두 가지 이상의 복합적인 법칙이 포함되어야 사용자들이 절대 빠져나갈 수 없는 천라지망을 만들 수 있다는 점. 이벤트기획을 해야하는 분들이라면 꼭 잊지 마시기 바랍니다.

다음 번 웹기획가이드에서는 이벤트기획에 들어갈 세부적인 요소와 함께 가장 중요한 이벤트의 마무리를 다뤄보도록 하겠습니다. 

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 '웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기' 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

한동안 잠시 웹기획가이드를 등한시하고, 디지털기기 리뷰 외도를 하고 돌아온 야메군 입니다.  오늘은 이벤트기획에 대한 내용을 정리해볼까 하는데요,  이벤트라는 용어 자체만 놓고 보면 일상생활에서 흔히 접하고 경험하게되는 용어가 아닐까 생각됩니다.  이성과의 기념일 이벤트나 온 오프라인을 막론하고 진행되는 각종 경품이벤트 등 여러분들이 웹 분야에 종사하건 아니건간에 이미 수 많은 이벤트를 직, 간접적으로 접하고 있는데, 이 이벤트 들 중에서 실제로 이벤트의 본질적인 진행목적이라 할 수 있는 성공적인 프로모션을 달성한 이벤트는 그리 많지 않으며, 목적을 제대로 충족시키지 못한 경우가 대부분 입니다.

그렇다면, 어떤 이벤트가 목적을 충족할 수 있고.. 또 어떻게 기획해야 성공적인 이벤트로 남을 수 있는지를 지금부터 살펴보도록 할텐데요. 먼저... 이벤트를 진행하는 목적.. 어떤 것들이 있을까요?

[그림. 1] 이벤트의 진행목적 네 가지.

위와 같이, 수 많은 이벤트들도 그 목적은 위의 네 가지 범주, 매출의 향상. 웹 사이트의 트래픽을 높이고자 하는 목적. 회원가입을 독려나 이탈방지. 그리고 서비스 또는 상품의 홍보 정도가 그 것인데, 대부분의 이벤트들은 이 정도의 진행목적을 가지고 있으며, 이벤트를 기획할 때 가장 먼저 생각해봐야 할 것은 '이 이벤트를 진행하고자 하는 목적이 무엇일까.' 이며, 목적을 수립한 후, 그 목적에 맞는 방향성과 프로세스가 내포된 이벤트를 기획했을 때.. 결과적으로 성공적인 프로모션을 수행할 수 있습니다.

목적과 방향성이 일치하지 않으면...

하지만, 대부분의 사례들은 왜 이벤트를 진행하는지에 대한 명확한 목적이 없는 경우가 많으며, 혹여.. 목적을 가지고 있다손 치더라도 구체적인 개념이 아닌 막연한 느낌으로만 접근하고 있다보니.. 이벤트의 목적이 흔들리고 방향성이나 방법 마저도 흔들리게 되는데, 이를 방지하기 위해서는 먼저 어떤 목적으로 이벤트를 진행할 지를 결정하는 것이 좋습니다.

[그림. 2] 이벤트의 목적수립 프로세스

가령.. 매출 지향형 이벤트를 진행한다고 가정해 봅시다.  이때.. 대부분의 사람들은 매출을 높일 수 있는 구매를 높일 수 있는 이벤트를 만들면 된다고까지는 생각하지만 '어떻게 만들 것인가..'의 단계에 이르면 대부분은 상품을 구매했을 때 줄 수 있는 매리트를 생각하곤 합니다.

문제는 어떻게 만들 것인가를 고민하는 시점에서 이벤트의 방향성을 고민해야 하며, 이 방향성이 고민되었을 때 비로써, 이벤트의 성공가능성.. 즉, 과연 이벤트가 성공할 것인가... 성공한다면 얼마만큼 성공할 수 있을 것인가를 판단할 수 있는데, 여기서 '어떻게' 를 고민하는 시점에서 적용되어야 할 네 가지의 법칙을 적용함으로서 이벤트를 보다 빈틈없이 구성할 수 있습니다.

[그림. 3] 이벤트의 네 가지 성공법칙.

일반적으로 이벤트를 잘 구성하기 위해서는.. 크게 즉시성, 지속성, 단순성, 인지성 등의 네 가지 법칙 중 서로를 보완할 수 있는 두 개 이상의 법칙을 적절히 버무려야 하며, 각 항목은 세부적으로 풀어보면...

이벤트의 네 가지 법칙을 녹여내라!!

즉시성은 이벤트 참여 후 사용자는 즉시 결과를 인지 할 수 있어야 하는 것을 의미합니다.. 사용자는 이벤트의 참여 이후, 결과 확인까지 일정기간의 공백이 존재할 경우 이벤트의 참여 자체를 망각하게 되며 결과적으로 이벤트로 인해 얻고자 하는 목표를 달성하지 못하게 될 가능성이 큽니다.  물론 단지 이슈를 만들겠다는 목표 하나 만을 가지고 있다면, 즉시성이 좀 떨어지더라도 상관 없겠지만.. 충반한 이슈를 만들기 위해, 사용자에게 어필할 수 있는 경품의 질이나 양적인 충족성은 갖춰야 합니다.



지속성은 이벤트의 회원참여가 일회성에 그치게 되는 프로세스를 지양해야 하며, 지속적인 참여 유도를 통해, 이벤트 자체에 대한 인지도를 높여야 하고, 이를 통해 트래픽을 확보하는 등의 양적, 질적인 이벤트 기대효과를 얻을 수 있어야 합니다.  이 법칙의 핵심 키워드는 '지속적인 참여 유도'에 있으며 여기에 해당되는 대표적인 이벤트는 출석체크 이벤트가 아닐까 생각됩니다.

일반적인 출석체크 이벤트의 프로세스를 살펴보면...

01. 매월 1일에 시작하며 말일에 종료.
02. 말일까지 출석체크를 다 한 참여자를 선정하여 이벤트 경품 지급.

대략적으로 이 정도의 프로세스를 바탕으로 만들어지는 경우가 많습니다만, 이 경우 몇 가지 사소한 문제가 발생할 수 있습니다. 우선 사용자가 이벤트를 참여하기 위한 진입장벽이 높아집니다.  즉, 사용자는 매월 초가 아니면 이벤트에 참여할 수 없다는 문제점이 있으며.. 또 말일까지 모두 출석체크를 하지 않으면 이벤트 경품을 받을 수 없다는 점이 그 것인데, 이러한 진입장벽으로 인해, 아래와 같은 기간 대비 참여율 그래프가 형성 됩니다.

[그림, 4] 출석체크 이벤트의 일반적 참여율과 이상적 참여율

위의 그래프를 보시면 일반적인 출석체크 이벤트의 참여율과 이상적인 참여율을 보실 수 있는데, 두 데이터의 차이는 바로, 급격한 참여율 저하와 완만한 참여율 저하로 볼 수 있습니다.  이 차이는 이벤트를 하나 오픈 했을 때 얼마만큼 롱런 할 수 있느냐를 판단할 수 있는 척도로 사용되기도 하는데, 이상적인 참여율에서 보시는 것과 같이, 완만한 참여율 저하는 곧 이벤트가 지속적으로 사용자들의 관심을 받는다는 의미이며.. 출석체크 이벤트에서 이러한 이상적인 참여율을 갖기 위해서는 프로세스 상에 다음의 조건이 성립되어야 합니다.

01. 월 초가 아니더라도 회원의 참여가 가능해야 한다.
02. 월 말까지 모두 출석체크를 하지 않더라도 이벤트 경품을 받을 수 있어야 한다.
03. 이벤트 기간 내 '출석체크' 라는 단조로운 패턴을 상쇄시킬 수 있는 환기장치를 마련해야 한다.

이 조건을 충족시키기 위해서는 '경품을 받기 위해서는 기간을 모두 채워야 한다.' 라는 전제를 과감히 제외해야 합니다.  즉.. 30일을 기준으로 다섯 번을 출석체크 했을 때와 열 번을 체크했을 때, 그리고 20번.. 30번과 같이 횟수를 베이스로 각각의 경품의 매리트가 바뀌거나 뭔가를 응모할 수 있는 응모권 갯수를 차등 지급하는 등의 차이를 둠으로써 월 초가 아니더라도 언제든지 참여할 수 있는 여지가 마련되어야 합니다.

또한.. 출석체크 이벤트라는 것이 로그인하고 출석체크하는 단조로운 패턴으로 구성되어 있다보니, 쉽게 질리는 경향이 있는데, 이를 보완하기 위해 돌발 이벤트 형식의 프로세스를 첨가하는 것도 고려해 볼 필요가 있습니다.  어느날 하루 출석체크를 했는데.. 생각치도 못했던 경품이 당첨되었다거나 등의 사용자가 미처 인지하지 못했던 프로세스가 있다면, 단조로운 분위기를 상쇄시킬 수 있습니다.

이렇게 이중 삼중의 촘촘한 그물망을 구성함으로서, 동일한 출석체크 이벤트라도 전혀 다른 결과가 나올 수 있다는 것을 머릿 속에 담아두시기 바라며 다음 번 웹기획 가이드를 통해 미처 정리하지 못했던 이벤트기획 편을 전개하도록 하겠습니다.

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 "웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기" 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

앞서 스토리보드 작성방법에 대한 기획가이드를 올렸는데요.. 기획강좌를 진행하면서 느끼는 거지만 주니어기획자분들의 경우, 스토리보드 작성과정에서 간혹 스토리보드의 목적을 망각하시는 경우가 간간히 있는 듯 합니다. 이야기를 하기 전에, 질문 하나를 해 보죠. "스토리보드.. 왜 만들까요?"

뭐 여러가지 생각하시는 이유가 있겠지만 스토리보드를 만드는 기본적인 이유는 기획하고자 하는 서비스에 기획자의 생각과 의도를 적절히 녹이고, 디자이너와 개발자가 실제 웹 사이트 작업과정에 참고하기 위하여 작성하는 문서로 정의를 내리는 게 일반적인 개념이라 할 수 있는데.. 오늘은 이 스토리보드에 대해 가지고 있는 실무자들의 진실과 오해에 대한 내용을 주제로 이야기를 풀어가 볼까 합니다.  보통 기획자로 첫 발을 내딛게 된 후, 가장 먼저 접하게 되는 업무가 바로 스토리보드 작업인데..  부족한 경험과 일천한 지식 탓에, 자신의 스타일을 갖고 스토리보드를 만들기 보다는 사수나 다른 기획자가 작업한 작업물을 참고해 진행되는 게 일반적인 모습입니다.

[그림. 1] 스토리보드 작업화면의 일부.

상황이 이러하다 보니, 기획자의 스토리보드 작업 내용은 대체적으로 선배 기획자의 스타일에 영향을 직, 간접적으로 받게 되며, '세 살 버릇이 여든간다.' 라는 속담처럼, 주니어 기획자 시절에 형성된 스타일은 시니어 기획자가 되더라도 쭉 이어지는 게 일반적이기 때문에.. 처음 접하게 되는 스토리보드의 역할이 매우 중요한 편인데, 간혹 좋지 못한 참고자료로 인해 잘못된 스타일을 갖게 되는 안타까운 경우를 종종 볼 수 있습니다..  그렇다면 어떤 스토리보드가 올바른 작업물이고, 어떤 스토리보드가 좋지않은 작업물일까요?

스토리보드는 누구나 이해 할 수 있어야 한다.

스토리보드는 전문지식을 갖춘 제한된 사람들만이 보는 문서가 아닙니다. 다시 말해, 전문적인 지식을 갖추지 않은 사람이라도 스토리보드를 보고, '아.. 이렇게 만들어지는구나..'를 알 수 있을만큼.. 혹은 '이건 왜 이렇게 될까..' 하는 의문점을 제시할 수 있을 만큼, 쉽게 만들어야 합니다.  여기서 '쉽다.' 라는 부분은 스토리보드 상에서 일반적으로 쓰이는 전문적인 용어를 최대한 배제하고.. 좀 더 쉬운 용어들로 구성하는 것을 의미하며, 여기에 프로세스의 명확한 도식화도 필요합니다.

뿐만 아니라, 스토리보드의 레이아웃 역시도 보는 사람들로 하여금, '이렇게 만들어지겠구나..' 하는 이해도를 전달해 줄 수 있어야하는데, 이런 이해도 측면의 편의제공을 위해, 스토리보드 작성방법에서 언급한 전체화면 구성이라는 레이아웃 중심의 페이지도 필요 합니다.

하지만, 간혹 이러한 편의성에 대해 잘못 해석하는 경우가 있는데, 바로 스토리보드의 그래픽적인 디테일과 완성도에 매달리는 것 입니다.

절대로 스토리보드의 퀄리티에 목숨걸지 말아야 한다.

강의를 진행하며 늘 강조하는 부분 중 하나가 바로.. '스토리보드에 디자인을 하듯 디테일하게 작업하면 안된다.'는 것입니다.  이 '디테일'은 두 가지의 문제를 야기하게 되는데, 첫 번째는 바로 시간 입니다.  디테일한 스토리보드는 보기엔 깔끔하고 이쁠지는 모르지만 작업시간이 많이 소요 됩니다.  흔히 '기획을 위한 기획을 하지 말아라'라는 말이 있는데, 스토리보드를 너무 이쁘게 꾸미다보면 기획의 기본인 오히려 생각해야 할 시간을 잡아먹게 됨으로 인해 기획 자체에 대한 부실을 초래할 수 있습니다.

[그림. 2] 비교적 단순한 형태의 스토리보드.

하지만 이보다 더 큰 문제는 바로 디자이너와의 커뮤니케이션 부분입니다.  충분한 경험을 가진 시니어 디자이너의 경우, 스토리보드 작업물에 구애받지 않고 자신의 생각을 디자인에 적극 반영함으로써 좋은 결과물을 만들어 낼 수 있습니다만.. 주니어 디자이너의 경우엔 경험의 부족으로 인해, 스토리보드에 구현된 레이아웃을 그대로 따라 함으로써 디자인적인 역량이 죽게되는 결과로 이어지며.. 이는 기획자가 작성한 스토리보드 내 화면설계보다도 못한 결과물이 만들어질 가능성이 큽니다.

물론, 그간 예시화면으로 보여드렸던 제 기획물의 경우, 상당히 디테일한 레이아웃이나 구성을 가진 화면설계 입니다만.. 이는 기획을 처음 시작한 십수년 전부터 그렇게 작업했기 때문이며, 현 시점에서 누구보다도 빠르게 그와 같은 작업이 가능하기 때문에 적어도 시간적인 제약은 가지지 않습니다.  또한.. 디테일한 레이아웃도 오랜 경험에 기반한 커뮤니케이션을 통해, 주니어 디자이너에게 디자인적인 제약을 주지 않도록 노력하기 때문에, 앞서 제기한 문제는 겪지는 않습니다.



하지만, 기획 경험이 오래되지 않은 기획자에게는 절대로 추천하지 않는 좋지 않은 습관이며, 가급적이면 박스형태의 단순한 레이아웃만으로 화면설계 작업을 하시기 바라며... 될 수 있으면 색상도 배제하고 선과 면 위주의 구성으로 스토리보드 작업을 해야 합니다.

화면설계 보다 인포메이션 아키텍처(Information architecture)다!!

인포메이션 아키텍처는 IA라는 약자로 불리기도 하는데 말 그대로 정보설계 입니다. 이 정보설계는 웹 사이트를 구성하는 다양한 내용의 도식화 등을 통해 구조화하는 과정을 통칭하는데 서비스와 서비스와의 상호관계를 정의하거나, 사이트맵의 정리, 혹은 각 메뉴에 대한 요약해 설명하는 것 등의 정보 기반의 설계가 모두 인포메이션 아키텍처에 해당합니다. (IA에 대한 자세한 사항은, 다음 번 웹기획 가이드를 통해 자세히 다루겠습니다.)

기획자는 레이아웃 중심의 스토리보드 보다는 인포메이션 아키텍처가 잘 정의된 스토리보드를 만듦으로써, 단순작업 위주의 스토리보드를 탈피해야 하며, 좁은 생각의 범위를 점차 넓혀나가야만 진정한 기획자로 거듭날 수 있다는 점을 가슴 깊숙히 담아놓으시기 바랍니다.

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 "웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기" 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

여러분들은, 회사에서의 발언권이나 업무의 주도적인 역할로 구분했을 때, 갑(甲)과 을(乙)에서 어디에 해당되시나요.. 아마도 대부분의 기획자들은 갑보다는 을에 가까운 위치에서 디자이너나 개발자.. 혹은 그 이외의 내부 구성원들과 커뮤니케이션을 진행할 겁니다. 설마... 갑과 을이 아닌 병이나 정의 위치에 계신가요?^^;

이유야 어찌되었건 간에.. 대체적으로 프로젝트를 리딩하는 위치가 아닌 디자이너나 개발자의 눈치를 보고, 비위를 맞춰가면서 일하고 있는 빈도가 높을 것으로 생각 됩니다. 이러한 이유에 대해 아마도.. 대부분은 프로젝트를 잘 마무리하기 위핸 어쩔 수 없는 선택이란 이야기를 할텐데.. 뭐 틀린 말은 아닙니다만, 그렇다고 저자세로 협업 대상자들에 '이거 될까요..' 혹은, '이것 좀 해주시면 안될까요..' 같이 과하다 싶을 정도의 저자세는 기획자 본인을 위축시킬 뿐만 아니라, 기획자가 가진 의도를 제대로 펼쳐내지 못하게 되는 연쇄적인 결과를 갖게 됩니다.

제가 이런 말을 하면, '아니, 그렇다면 성질이라도 내야 하나요.' 라고 반문하시는 분도 간혹 계시는데, 기획자가 주도적인 위치에서 프로젝트를 리딩하기 위해서는 '성질'이라는 스킬이 아닌, '신뢰'라는 스킬을 얻어야 하며, 무언가를 만드는 과정에서 기획자 혼자가 아닌 디자이너나 개발자가 모두 공감하는.. 즉.. '왜 그것을 만들어야 하는가.'에 대한 공통의 의견이 성립되고, 기획자 혼자만이 기획을 떠맡는 것이 아닌, 참여인력 모두가 같이 기획할 수 있는 환경이 만들어져야만 기대효과에 상응하는 결과물을 얻을 수 있습니다.

상대의 업무를 이해하는 신뢰...

너무 이상적인 소리로 들리실 거 같아 조금 더 풀어서 이야기 하겠습니다. 여기서 제가 언급한 신뢰란, 여러가지 의미가 있는데요, 첫 번째로 업무에 대한 신뢰 입니다. 기획자의 기획 결과에 대해, 디자이너와 개발자가 얼마만큼 신뢰도를 가지고 있느냐가 '신뢰'라는 의미에 포함되어 있습니다.  이는 단순히 기획을 잘하면 된다.. 로 함축할 수 없는 복잡 다단한 내용을 담고 있습니다. 기획만 잘 해서 신뢰를 얻을 수 있다면 누구나 어느정도 연차만 쌓이면 신뢰를 얻을 수 있어야 하지만 어느정도 연차를 쌓인 기획자들 중에서도 이러한 신뢰관계가 형성되지 않는 경우를 많이 보아왔습니다.

물론 신뢰라는 것의 기본 전제는 기획과정에서 다양한 범위를 고려함으로서 빈틈없는 기획을 해내고, 그 기획을 바탕으로 디자인과 개발 진행 시.. 기획적인 문제로 인해 시행착오가 발생하는 빈도가 현저히 적음과 동시에, 더 나아가 성공적인 결과로 이어질 수 있는... 한마디로 기획을 잘 하는 것이 되겠습니다만.. 그 보다도 우선되는 것은 바로 협업 대상자들의 업무를 이해하는 부분이 선행되어야 하며, 여기에 기획에 대한 조언을 얻음으로써, 기획자에게 부족한 업무영역을 커버하고 덤으로 디자이너나 개발자에게 기획참여의 롤을 만들어 줘야 합니다.



예를 들어, 하나의 서비스에 대한 효율적인 프로세스를 고민할 때 기획자에 비해 상대적으로 프로세스에 대한 이해가 높은 개발자에게 프로세스 구성의 효율적인 방안을 물어본다면, 늘 대하기 힘들기만 했던 개발자와의 접점이 형성되고 이를 통해 신뢰에 대한 기본 바탕이 생기게 됩니다..  물론 이 경우에 간혹 질문에 대해 짜증을 내는 등의 트러블이 발생 할 수도 있지만, 이럴 때 일수록 주눅이 들기보다는 더 적극적으로 어필함으로써, 협업 대상자에게 '뭔가 노력하려는 기획자구나.' 하는 마인드를 심어줄 수 있으며, 점차 상호보완적인 관계로 발전하게 됩니다.

좀 더 동료들의 업무를 이해하려고 노력하고, 기획적인 고민을 허심탄회하게 이야기를 나눌 수 있는 시점.. 바로 그 시점이 '갑'과 '을'의 관계가 뒤바뀌는 시점이며 기획자가 주도적으로 프로젝트를 이끌어 갈 수 있는 원동력이 생기게 됩니다.  가장 중요한 것 하나.. 단지 전문용어를 모른다고 해서.. 혹은 디자인이나 개발적인 지식이 없다는 이유로 주눅들지 말고 배운다는 자세로 끈질기게 상대의 의견을 얻고자 노력하세요. 나머지는 시간이 해결해 줍니다..

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 "웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기" 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

지난 주 스토리보드 작성방법에 대한 내용을 설명하다가 마무리를 짓지 못했는데요, 오늘 그 마무리를 지어볼까 합니다.  앞서 개요 및 정의에 대한 항목을 이야기했었는데.. 이 같이 기획의 목적과 정책적인 요소를 정리한 후, 사이트의 메뉴나 페이지 구성을 도식화한 사이트맵 페이지를 작성해야 합니다.

사이트맵은 식당의 메뉴판과도 유사한 구조와 개념을 가지고 있는데, 식당 메뉴판을 보면 탕 류라는 최상위 분류에 해물탕, 알탕, 설렁탕, 갈비탕과 같은 하위 분류가 구성되어 있는 경우를 많이 보셨을텐데, 이런 카테고리 분류없이 탕과 찌게, 주류를 마구잡이로 섞어 놓는다면 손님은 자신이 원하는 음식을 찾기 위해 많은 시간을 들일 수 밖에 없으며, 결과적으로 클레임이 유발될 수 밖에 없는데, 스토리보드 상에서의 사이트 맵 역시도 별반 차이가 없습니다..

즉, 사이트맵 작성을 통해, 만들고자 하는 서비스의 메뉴 구성을 생각해봐야 하고, 최상위 메뉴와 그 메뉴에 귀속된 하위 메뉴 간의 유사성을 판단하여 적절한 배치를 함으로써.. 메뉴와 메뉴간의 이동과정에서 유저의 이용 편의성을 높여야 합니다.  또한 이 과정에서 메뉴의 레이블도 충분히 고려해줌으로써 메뉴의 유사성을 보완해줘야 합니다.

[그림. 1] 사이트맵 화면의 예시.

참고로, 사이트맵을 작성 시 메뉴 간의 유사성을 판단할 때에 다음의 두 가지를 고려해야 하는데, 첫 번째는 기능적인 유사성. 두 번째는 사용자의 이용패턴에 따른 연계성 입니다. 예를 들어, 마이페이지에 대한 사이트 맵을 작성한다고 가정할 때.. 우선 기능적인 측면에서 어떠한 메뉴들을 마이페이지에 둘 것인가를 따져 본 후, 로그분석 데이터 등을 통해 사용자의 이동패턴을 고려하여, 개인정보 수정메뉴를 상단에 배치할 지 혹은 구매내역으로 이동할 수 있는 메뉴를 상단에 배치할 지 등을 고민해봐야 합니다.  여기에 회사에서 밀고자 하는 혹은 서비스 측면에서 더 중요하다고 판단되는 부분까지 고려한다면 더할 나위없이 좋은 사이트 맵에 될 듯 합니다.

사이트 맵은 기능적 유사성과 이용패턴을 고려해야...

이렇게 사이트맵을 작성한 후 프로세스를 작성해야 하는데 여기서의 프로세스는 디테일한 기능적인 프로세스가 아닌, 전반적인 흐름이 담긴 플로우 차트의 개념으로 이해하시면 될 듯 합니다.



예를 들어... 회원 가입을 하나의 서비스로 보고 대한 프로세스를 구성한다고 가정할 때, 일반적으로 개인정보 이용에 따른 동의절차및 실명인증 영역과, 아이디나 비밀번호 및 기타 정보를 입력을 받는 영역.. 그리고 회원가입 완료안내 영역 등으로 구성되어 있는데.. 이 세 단계의 영역을 간단하게 도식화 한 내용이 이 프로세스 영역에 포함되어야 하며, 보다 디테일한 프로세스. 즉, 개인정보이용 동의 체크박스에 체크를 했는가, 안했는가에 따라 어떤 경고창을 보여줘야 하는가 등과 같은 내용은 각 기능을 상세하게 설명하는 상세설명 영역에 포함시키면 됩니다..  이 프로세스에 대해서는 이 전에 작성했던 웹 기획자가 알아야 할 프로세스 편을 참고하시면 이해가 빠르실 듯 합니다.

[그림. 2] 전체화면 구성 작업물의 일부 페이지.

그 다음, 각 페이지 별 화면 레이아웃을 그리게 되는데, 이를 통해서 해당 페이지에 들어갈 컨텐츠적인 요소나 서비스의 전반적인 레이아웃을 정리하게 됩니다.  한 개의 웹 페이지 별로 이와 같은 전체화면 구성을 미리 정리해 놓으면 각 기능 별 상세설명을 정리할 때 보다 빠르게 정리할 수 있다는 장점이 있는데 스토리보드에 꼭 들어가야 할 표준 구성은 아니니, 작성여부에 대해서는 작업자가 판단하시면 되겠습니다.  참고로 제 경우엔, 파워포인트 세 장 정도에 걸친 한 페이지의 레이아웃을 출력해서 풀로 붙인 후 책상 파티션에 붙여놓곤 하는데, 전시효과로는 그것만큼 뛰어난 것도 없는 듯 합니다.  왠지 열심히 일하고 있다는 느낌이랄까?^^;

잠시 쓸데없는 사담이었구요.  이렇게 전체화면 구성을 마친 후, 전체화면 구성 내용을 근간으로 각 영역 별로 상세한 설명을 기술하면 되는데, 이 때 디자인적인 이슈나 개발적으로 전달할 이슈를 정리하면 되겠습니다..  참고로 필요할 경우 상세설명을 하는 시점에 디테일한 프로세스도 첨부해주시면 개발작업 진행 시, 수월하게 진행할 수 있습니다.

[그림. 3] 상세설명 작업 페이지.

대략 이 정도의 과정을 거치면 기본적인 스토리보드의 구성이 완료되었다고 할 수 있는데, 이렇게 작업한 결과물을 바탕으로 실무자들과의 작업 스케줄을 정리해야 합니다.

작업스케줄은 실무자들과의 커뮤니케이션으로..

작업스케줄은 기획/디자인/개발 등의 각 영역을 타임라인으로 쪼개어 정리하면 되는데, 예를 들어.. 기획파트 부분에서 컨셉 기획에 얼마. IA 설계에 몇 주 간의 시간이 걸릴거고, 스토리보드 작업에 얼마만큼의 시간이 걸릴 것이라는 내용이 수록되어야 합니다..  이런 식으로 기획과 디자인 및 개발의 세부 항목을 타임라인으로 정리하고, 알파나 베타 테스트 일정, 그리고 최종 런칭일정을 확정 지으면 스토리보드에 포함된 모든 내용이 완료됩니다.

여기서 스케줄을 정리할 때 기획자 임의대로 정리하는 것이 아니라 디자이너와 개발자간의 협의를 거쳐야 하며, 기획자는 프로젝트 시작일과 종료일자 정도를 확정짓고, 그 범위 내에서 협의를 통해 세부적인 일정을 조율하면 되겠습니다.

[그림. 4] 개략적인 진행스케줄의 예시.

지금까지, 스토리보드 작성하는 방법을 대략적으로나마 정리해 보았는데요. 그간의 경험에 미루어 봤을 때, 스토리보드를 능숙하고 빠르게 작성하기 위한 유일무이한 방법은 바로... '많이 해보는 것' 그리고 '어떤 것을 작업할 지에 대한 명확한 정의' 이며, 이 두 가지가 충족되지 않으면 절대로 능숙한 스토리보드 작업을 할 수가 없습니다.. 이 스토리보드를 통해 기획자는 자신이 기획하고자 하는 내용을 상대에게 명확히 전달 할 수 있어야 하며, 이 '명확한 전달' 이라는 화두를 위해서는 어떻게 작업하고 어떤 방식으로 내용을 전개해야 하는가를 충분히 고민해야 합니다.

물론, 웹 기획을 처음 시작한 기획자에게 이러한 내용을 모두 감당하게 하는 것은 너무나도 가혹한 일이기 때문에.. 사수나 혹은, 주위의 다른 선배 기획자들이 작업한 스토리보드를 살펴봄으로써, 웹 스토리보드에 대한 사전적인 이해를 높일 수 있도록 끊임없는 공부를 하셔야 한다는 것으로 스토리보드 작성방법 정리를 마칠까 합니다.

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 "웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기" 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

"View On 버튼 꾹!! 블로거에게 큰 힘이 됩니다."

'똘끼의 웹기획론. > 웹 플래닝 초보강좌' 카테고리의 다른 글

[웹기획가이드] 스토리보드에 대한 진실과 오해..  (4)	2012/04/08
[웹기획가이드] 기획자가 '갑' 이 되는 방법?!  (2)	2012/04/05
[웹기획가이드] 스토리보드, 어떻게 작성하나요? 1-2  (0)	2012/04/02
[웹기획가이드] 스토리보드, 어떻게 작성하나요? 1-1  (4)	2012/03/27
[웹기획가이드] 데이터베이스(DB), 어렵지 않아요~!!  (4)	2012/02/17
[웹기획가이드] 웹기획자가 꼭 알아야 할 프로세스(Process)!!  (0)	2012/02/09

스토리보드.. 화면설계라고도 하는 이 하위기획서는 웹사이트를 구축하는데에 있어, 꼭 거쳐야 할 필수요소이자, 기획자라면 누구나 빈번하게 작성하게 되는 작업물 입니다만..  회사나 작성목적 혹은 기획자의 스타일에 따라 약간씩 다른 형태의 스토리보드가 작성 됩니다.

물론.. 기획의 개념이 그러한 것처럼 스토리보드의 형식이나 내용 역시도 정답은 없으며, 내용이 어떻든간에 최종적인 결과물인 웹사이트가 잘 개발 되었다면, 그것이 곧 잘 만들어진 스토리보드라 할 수 있는데요.  처음 웹기획을 시작하면 가장 먼저 접하게 되는 업무가 바로 파워포인트를 이용해 스토리보드를 작성하는 업무일텐데... 완전히 맨땅에 헤딩하다 싶히 만드는 경우는 거의 없으며, 대부분 리소스로 삼을만한 선배 기획자의 기획서를 받아볼 수 있습니다.

하지만... 그 마저도 여의치 않은 경우 네이버 웹을 만드는 사람들과 같은 전문 기획자 커뮤니티를 통해서도 샘플 자료를 얻으실 수 있는데, 이런 샘플자료들이 어떤 목차로 구성되어 있고, 각각의 페이지에 담긴 내용들을 살펴보다보면, 자연스럽게 스토리보드의 작성방법을 익히실 수 있습니다.  다만..  스토리보드 자체를 작성하는 것은 그리 어려운 일이 아닙니다만, 단지 들여다보는 것과 직접 따라해보는 것과는 분명한 차이가 있는 만큼.. 단순히 보고 끝낼 것이 아니라 파워포인트의 각 기능들도 익힐 겸.. 만들어진 스토리보드를 그대로 따라 만들어보는 것이 매우 효과적입니다...  이러한 과정은 대략 3개월에서 6개월 쯤 반복하다보면, 어느새 능숙한 솜씨로 스토리보드 작업을 하는 자신을 발견할 수 있는데요,

[그림. 1] 스토리보드(화면설계)의 상세설명 중 일부.

문제는, 단순히 스토리보드를 그대로 베끼는 것이 아닌, 스토리보드 내에 자신의 생각을 담아야 한다는 점인데 이를 간과하는 경우, 절대로 그 다음 스텝을 밟을 수가 없습니다..  때문에 스토리보드를 볼 때나 직접 만들어 나갈 때 '왜 이 버튼이 여기에 있는가?' 혹은 '왜 정보를 이렇게 배치했을까?' 와 같은 고민이 따라야 합니다..  단지 능숙하게 베끼는 수준의 작업물들이 많아서인지 흔히 아무나 데려다놔도 기획은 굴러간다는 소리가 있는데, 기획자로써 이러한 비아냥에 가까운 소리를 듣지 않기 위해서는 한 번 더 생각하고 '웹환경에 대한 경험과 지식'을 쌓아야하고 또 '사용자 환경'을 이해해야 합니다.

타인의 스토리보드는 독이 될 뿐이다.

앞서 올렸던 '웹기획자의 커뮤니케이션 능력 향상방법' 편에서 좋은 기획자가 되기 위해서는, 자신이 기획할 내용의 이해도가 높아야 한다고 설명했는데.. 이러한 이유는 스토리보드 작업 자체가 단순한 노가다 성 업무이기 때문이 아닌 사용자가 접하게 되는 화면을 그려나가고.. 이를 디자이너와 개발자를 통해 구현하는 과정을 거쳐야 하는 종합적이고도 최종적인 업무이기 때문입니다..  즉, 다시 말해서 자신이 기획해야 할 내용에 대해 이해도를 갖추지 않은 채 기획안을 작업할 경우, 왜 이런 기획이 나왔는지에 대해 디자이너나 개발자에게 올바로 설명할 수가 없으며, 그것은 곧 실패할 가능성이 높은 웹사이트나 서비스로 이어질 수 밖에 없으며.. 이를 방지하기 위해서는 별 것 아닌 것 처럼 느껴질 수 있는 버튼의 배치나 정보 노출순서 조차도, 왜 거기 있는가를 이해해야 합니다.

 

우선, 스토리보드의 디테일한 구성을 살펴보기에 앞서 스토리보드 페이지의 영역을 살펴보겠는데요.. 스토리보드는 크게 페이지의 제목을 기재하는 01번 영역과 페이지의 수를 표기하는 02번 영역, 그리고 실제 화면의 레이아웃을 정리하는 영역과 이 영역들의 각 요소를 디자인, 개발적인 측면에서 설명하는 상세설명 영역(Description)으로 구분됩니다.

 

각 페이지 별로 위의 네 가지 항목은 대부분 들어가야 하지만.. 이 영역들의 배치는 정형화된 것이 아니며, 스토리보드의 형태나 내용에 따라 가변적일 수 있으니, 너무 형식에 얽매일 필요는 없습니다.

 

[그림. 2] 스토리보드의 기본적인 영역.

대략 이와 같은 내용들을 기반으로 스토리보드를 작성하면 되는데, 어느정도의 이해도를 갖게되면 자연스럽게 스토리보드 내에 포함될 요소가 정리되게 되는데.. 그 순서는 회사의 업무양식이나 기획자의 특성에 따라 다소간의 차이는 있겠지만 대체적으로 이와 같은 내용의 항목들이 들어가게 됩니다.

[그림. 2] 스토리보드에 들어가야 할 내용.

스토리보드에 들어갈 항목은 대략 목차를 시작으로 작업 스케줄까지 모두 여덟가지 항목으로 구성되는데 내용을 살펴보면 다음과 같습니다. 

 

01. 목차 : 각 페이지 별 제목을 기재.

02. 업데이트 기록 : 언제 어떤 페이지에 어떤 내용이 수정되었으며, 해당 수정이슈의 작업을 진행할 포지션 기재.

03. 개요 및 정의 : 기획의 목적을 정의하고, 만들고자 하는 서비스의 운용정책을 기재.

04. 사이트맵 : 각 페이지의 메인 메뉴와 그 메뉴에 귀속된 하위 메뉴를 시각화해서 기재.

05. 프로세스 : 여기서 프로세스는 특정 서비스의 기본 흐름도와 세부 흐름도로 구분되며, 주로 기본 흐름도를 기재.

06. 전체화면 구성 : 만들고자 하는 페이지의 전체화면 레이아웃을 정리.

07. 영역 별 상세설명 : 06번에서 정리한 레이아웃을 바탕으로 영역 별로 디자인/기술적 상세설명을 기재.

08. 작업 스케줄 구성 : 해당 기획안의 기획부터 개발완료까지의 스케줄을 정리.

 

위의 내용을 좀 더 디테일하게 풀어보면, 보통 스토리보드를 만들 때 딱 만들어놓고 더 이상 수정할 것이 없을 듯 하지만.. 디자이너나 개발자 혹은 다른 연관 담당자들과 커뮤니케이션을 진행하다 보면, 수정해야 할 사항들이 빈번하게 발생합니다.  이 때, 수정사항의 명확한 전달을 위해 언제 어떤 페이지의 내용이 수정되었으며, 이 수정을 담당할 포지션이 디자인 파트인지, 혹은 개발 파트인지를 명시해줘야 합니다.

 

업데이트의 관리는 기획서 작성의 기본!!

 

만일 이와 같은 업데이트 기록이 잘 관리되지 않는다면 기획자 본인이 기획서를 수정해놓고도 어디서 수정했는지를 알 길이 없으며 수정사항이 명시되지 않음으로써 디자이너나 개발자 역시도 수정사항을 반영하기 위해 기획서 전체를 다 읽어야 하는 문제가 발생하게 됩니다.  이런 문제는 자칫 작업진행의 트러블 요소로 남을 수 있으니, 업데이트기록은 철저히 관리하는 것이 중요합니다.

 

[그림. 3] 개요와 사이트맵이 혼합된 형태의 정의자료.

 

그 다음 개요와 요소 별 정의는 어떤 기획서이던지 꼭 들어가야 하는 핵심적인 내용 입니다.  즉, '이 기획을 왜 해야 해는지' 를 정의함으로써 기획자 본인이 일관성 있는 기획을 할 수 있는 기본정의가 됩니다. 뿐만 아니라, 작업을 같이 진행하는 디자이너, 개발자, 마케터, MD 등 협업 대상자들과 공통된 정의를 공유함으로써 하나의 목표에 도달하기 위한 가이드의 역할을 가지고 있습니다. 

 

만일 기획의 목적이 정의되지 않은 상태에서 사이트 개편을 한다고 가정했을 때... 기획자는 A라는 방향으로 기획을 했는데, 디자이너는 B를 목표로 삼고 있고, 개발자는 C를 목표로 삼고 있다면 그 개편작업은 실패할 확률이 높아 집니다.  이러한 부분을 사전에 예방하기 위해서는 왜 개편을 해야하고 개편의 범위는 무엇인지.. 혹은 이 개편을 통해 얻고자 하는 기대효과는 무엇인지를 잘 정의함으로써 모두가 하나의 방향을 가지고 작업을 진행해야 프로젝트의 성공을 담보 할 수 있다는 점을 잊지 마시기 바라구요.. 다음 편에서는 오늘 마무리 하지 못한 스토리보드 작업의 세부적인 구성요소 더 이야기 하도록 하겠습니다.

 

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 "웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기" 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

 

 

오늘은 기획자가 알아야 할 데이터베이스 구조에 대해서 설명 드릴텐데요. 웹기획자가 직접 DB 서버를 설계하거나 혹은 DB 프로그래밍을 하는 경우는 사실상 없다고 볼 수 있습니다.  하지만 기획자 역시도 데이터베이스에 대한 기본적인 이해도는 갖추고 있어야 하며... 개발자들이 주로 사용하는 DB 스키마(Schema), 즉 DB 설계도의 전반적인 흐름 정도는 이해할 수 있는 지식을 갖추셔야 합니다. 

하지만, 대부분의 주니어 기획자들이 그러하듯이, 전문적인 개발 용어들이 나오면 자연스레 위축되곤 하는데, 실상 그 의미를 따져보면 그리 어렵지 않습니다. 이는 데이터베이스 역시도 마찬가지 인데, 데이터베이스란 용어 자체가 명확하지 않을 뿐이지, 이미 여러분들은 데이터베이스의 기본이라 할 수 있는 데이터를 매일같이 접하고 있습니다.

게시판에서 볼 수 있는 여러 정보나, 회원정보들.. 상품 정보들... 이 모든 것들이 데이터베이스를 이루고 있는 기반이라 할 수 있는데 이를 좀 더 정의해본다면 논리적으로 연관된 하나 이상의 자료 모음으로, 그 내용을 고도로 구조화함으로써 검색과 갱신의 효율화를 꾀한 것이며 몇 개의 자료 파일을 조직적으로 통합하여 자료 항목의 중복을 없애고 자료를 구조화하여 기억시켜놓은 자료의 집합체라고 설명할 수 있는데요,


[그림. 1] 데이터베이스를 이루고 있는 요소들..



이러한 설명에서 데이터베이스에 대해 기획자가 알아야 할 포인트는 딱 두 가지!!!  바로 검색과 갱신의 효율화 입니다.  이 함축된 내용을 좀 더 풀어 설명해보면, 검색을 했을 때나 페이지 새로고침을 했을 때, 보다 빠르게 페이지가 노출되게 하기 위한 기획자의 역할을 의미하는데요.  여기서 '아니.. 그건 DB 프로그래밍이 잘 되어 있거나, 좋은서버를 구매하면 되는 일이 아닐까?' 하고 생각하실 분들도 있을 겁니다.

DB의 효율화를 꾀하기 위한 기획자의 참여범위는?

물론, 그 부분은 부정할 수 없는 사실이나, 그 와중에도 기획자에 역할은 분명히 있기 마련이며, 이 역할에 따라 DB의 효율화를 꾀하는 부분에 있어 꽤 중요한 비중을 차지한다는 것을 인식하셔야 합니다.

그럼 여기서 기획자가 DB의 효율화를 꾀하기 위해 필요한 기획적인 참여범위... 어떤 것들이 있을까요? 

제 관점에서는 크게 두 가지를 보고 있습니다. 첫 번째는 효율적인 데이터베이스의 설계를 위한 데이터의 수집범위를 정의하는 것.. 두 번째는 이렇게 수집한 데이터를 어떻게 운용할 것인가에 대한 운용, 관리정책의 수립이 그것인데, 일반적으로 DB를 설계하는 과정에서 기획자가 할 일이 없다는 통념과 달리, 이 부분에서 기획자의 역할은 절대적이라 할 수 있습니다.


[그림. 2] DB를 접하는 기획자의 역할정의.



이러한 과정에서.. 기획자의 참여가 필요한 이유는 바로 개발자와의 원활한 커뮤니케이션을 위한 첫 번째 접근이기 때문이며, 이 같은 접근시도는 기획자와 개발자간의 업무의 공유를 위해서도... 더 나은 기획을 하기 위해서도 반드시 필요한 과정이기도 합니다.  하지만, 앞서 이야기 한 바와 같이, DB의 개발은 개발자의 몫이라는 통념이 있기 때문에.. 기획자 본인이 이러한 롤을 만들어나갈 수 있도록 노력해야 하며, 이를 위해 기획자는 데이터 베이스의 기본 개념을 이해하고 갈 필요가 있습니다.

개념이라고 하면 어렵게 생각하실 수도 있겠지만, 아래의 그림을 보시면 아주 간단하게 이해하실 수 있습니다..  데이터베이스의 운용은 쓰기/저장/읽기/수정 이렇게 네 단계로 구성되어 있습니다.


[그림. 4] 데이터 베이스의 운용단계

 
이 같은 네 단계에서 쓰기에서 저장하는 과정과 저장한 데이터를 불러들이는 과정, 그리고 저장된 데이터를 수정하고 이를 다시 저장하는 과정에서 기획자가 판단하고 참여해야 할 부분이 생기게 되는데 예를 들어 데이터를 작성해서 저장하는 과정에서 고민해야 할 정책적인 내용을 살펴보면,

1. 서비스를 구성하는데 있어, 저장해야 할 데이터가 필요한 데이터인가? 필요하지 않은 데이터인가?
2. 1번과 동일한 관점에서 지금 받아야만 하는 데이터인가? 나중에 받아도 되는 데이터인가?

이런 두 가지의 정책이 나올 수 있는데 이 정책은 DB 설계자도.. 개발자도 아닌 기획자가 잡아야 하는 사항이며, 어떤 정책을 선택하느냐에 따라 서비스의 전반적인 운용 프로세스가 좌우되며, 이에 따라 기획 방향이나 개발의 포인트까지도 상당한 영향을 받게되며, 궁극적으로 사용자의 편의성까지도 영향을 받게되는데... 이에 대한 부연설명은 앞선 웹기획가이드인 웹기획자가 알아야 할 프로세스편을 참고하시면 되겠습니다.



만일 이 과정에서 기획자의 참여 없이 DB 설계가 진행된다면, 기획적인 의도가 반영되지 않는 서비스가 나올 수 밖에 없으며, 기획자의 역할은 단지 스토리보드를 그려주는.. 속된 말로 '시다바리'로 전락할 수 밖에 없는거죠.

DB정책의 수립은 기획자의 몫이다.

이러한 우를 범하지 않기 위해 기획자는 정책에 대한 이해도를 높여야 하며 데이터를 성격이나 목적성에 맞게끔 명확히 분류할 수 있는 카테고라이징(Categorizing)에 대한 개념을 가지고 있어야 합니다. 카테고라이징에 대한 부분은 다시 한 번 언급할 기회가 있을테니.. 그 때 다시 말씀드리도록 하겠구요... 데이터 베이스와 관련된 정책의 이해도에 대해 먼저 설명드리면, 데이터 베이스는 간단히 보면 수많은 데이터의 베이스캠프와도 같다고 보시면 되는데, 이 중에서 데이터는 여러분들이 일상적으로 보는 모든 정보가 여기에 해당된다고 앞서 말씀 드렸습니다.

이러한 정보들을 어떻게 사용하느냐에 대한 정책을 수립하는 부분이 바로 기획자의 범주인데.. 예를 들어 게시판에 새 글이 작성되면 보통 N 아이콘이 제목에 붙게 되는데 이 아이콘을 몇 일이나 노출시키느냐도 하나의 정책이라 할 수 있으며, 글 목록 페이지에 몇 자까지의 제목을 노출하고, 몇 자 이상 되면 '...' 으로 표기할 지, 혹은 모든 제목을 다 보여줄지와 같은 부분들이 모두 하나의 정책이라 보시면 되겠습니다.  아주 간단하죠?^^

이런 정책들은 스토리보드라고 하는 화면설계 과정 이전에 모두 정의되어야 하는 부분이며, 그래야만 DB 설계시에 기획적인 정책이 반영될 수 있습니다.  물론 주니어 기획자의 경우, 웹 사이트나 서비스의 모든 정책을 완벽하게 정리하는데에는 분명 한계가 있을 수 있지만... 대부분은 조금만 더 생각해보면 나올 수 있는 지극히 상식적인 범주에 해당되는 만큼.. 기획 시에 생각의 깊이를 가져가신다면 그리 어렵지 않게 데이터베이스의 정책적인 설계를 이끌어 가실 수 있을 겁니다...

본 내용은, 네이버 웹을 만드는 사람들 커뮤니티 내 "웹 기획 5주 빡세게 배우고, 5년차 기획마인드 갖기" 강좌에 수록된 내용이며, 기획에 대한 보다 자세한 교육을 원하시는 분들은 아래의 링크를 클릭해주세요..^^

[웹기획 마인드 갖추기 시즌 19(2012년 6월 19일, 화) 안내!!]

"View On 버튼 꾹!! 블로거에게 큰 힘이 됩니다."