웹기획 이해하기 - 강좌4, 문제를 찾고 개선하기 위한 방법!

웹기획 이해하기 - 강좌4, 문제를 찾고 개선하기 위한 방법!

웹기획 이해하기 - 강좌4, 문제를 찾고 개선하기 위한 방법!

지난 강좌는 웹사이트 운영의 전반적인 부분을 살펴 보았다. 평소에 웹사이트 운영이 얼마만큼 짜임새 있게 치밀하게 계획되어 있는지, 또 그 계획이 제대로 실행되는지를 관리하는 것 또한 웹기획자의 중요한 임무라는 이야기를 했었다.

이번강좌에는 웹사이트 운영 도중, 문제점을 발견해내고 그것을 개선하기 위해 어떠한 절차를 거치는지 그리고 그 절차의 일반적인 방법론은 무엇이 있는지 알아보겠다. 문제점을 발견해 내는 것부터 굉장히 큰 문제라 할 수 있다. 일단 개선해야 될 문제점이 발견 되었다면 어떤 프로세스가 우리 팀에 적절한지, 선택도 웹기획자(팀장)의 중요한 임무라 할 수 있겠다.



#문제가 무엇인가? 문제점을 찾아내는 방법

웹사이트는 지속적으로 개선 되어져야 한다. 완벽한 시스템은 존재하지 않는다. 또는 그 순간 완벽했다 할지라도 시간의 영향을 받는 e비즈니스, IT업계에서는 시간이 흐름에 따라 전략과 전술일 달라져야하기에 완벽에 가까워 지기위해서는 끊임없이 문제점을 찾아내고 개선해야 한다.

그렇다면 문제점을 어떻게 찾아 낼것인가?

기획자의 머리속으로 구상하여 "이것이 문제점이겠지!!" 라는 것을 개선점으로 잡을 것인가? 아니면 옆부서사람의 의견을 듣고? 그것도 아니면 상사의 의견? 또는 고위직 상사의 지시로? 누가 봐도 이런 방법은을 합리적이고 논리적이지 못하고 주먹구구식의 웹사이트 운영이라고 밖엔 볼수 없다. 단순히 회사의 브로셔 기능을 하는 홈페이지라면 그렇게 해라! 그러나 웹사이트를 통해 무엇인가 고객이 가치를 창출하고 가길 원한다면 이런방법은 백번 지양해야 함이 옮은 것이다.

가장 일반적인 문제점을 찾아내는 방법은

- 설문(Research)을 통한 문제발견과

- 사용자 입장에서 바라보는 기획자의 발견

일것이다. 물론 로그분석도있고 기타 방법들도있지만 가장 손쉽게 정보를 얻을 수있다는 점에서 이 두가지 방법을 우선 선택하였다. 우선 두번째 방법은 "기획자의 통찰력"에 의존하는 방법인다. 이 방법은 얼마나 기획자가 유능하냐에 따라 문제를 발견할 수 있는 정확도가 높아진다. 그러므로 변수가 많다고 할 수있다. 첫번째 문제는 가장 대표적인 문제 발견 방법으로써 설문지를 어떻게 개발하느냐에 관건이 있다. 사회조사 방법론의 이론을 바탕으로 설문지를 잘 개발하는것도 쉽지 많은 않은 문제 이다.

설문과 기획자의 통찰력과 더불어 문제점을 발견할 수 있는 방법이 몇가지가 더 있다.

- FGI, 포커스 그룹 인터뷰를 통한 문제발견

- VOC, 고객의 소리를 분석하여 문제를 발견

- VOB, 회사 내부 경영진 및 비즈니스 전략에 따른 전략적 문제 발견

- Usability TEST, 유저빌리티 테스트를 통한 문제 발견

- log 분석, 로그분석을 통한 문제발견

포커스그룹인터뷰경우는 웹사이트 이용자과 같은 부류의 인원을 4~5명 선정하여 상세한 질문으로 된 질문지로 문제점을 찾아내며 기타 구두로 여러가지 논의를 통해 문제점을 발견해 낸다. VOC기법은 6시그마에서 가장 중요하게 사용되는 방법으로써 평소에 고객의 소리를 데이터베이스화 하여 가장많고 Critical한 VOC를 골라내는 방법이다. VOB는 회사내부의 의견으로써 중장기적인 전략과 관련된 전략적의견으로써 개선점을 찾는 방법으로써 이는 VOC와 함께 쓰인다. 유저빌리티 테스트는 사용자의 사용형태를 여러가지 방법을 통해 지켜봄으로써 사용자가 이용하기 어려워 하는 부분을 직접적으로 묻거나 설문하지 않고 찾을수 있는 방법이다. 또한 로그분석을 통하여 문제점을 발견 할 수도 있다.

# 문제를 찾았다면. 동일한 문제를 잘 해결한 곳을 벤치마킹 하라.

사실 문제의 해결점을 찾기위한 방법에 벤치마킹만큼 좋은 방법이 없다.

"벤치마킹이란 내가 가지고 있는 것들을 토대로 다른것들의 일류요소를 접목시켜 새로운 구성을 만들어내는것"이라 정의 할 수 있다." 이를 제대로 수행하기 위해서는 1)평가기준이 명확해야 하며 2)객관적인 데이터를 수집할수 있어야 한다. 또한 3)어떻게 벤치마킹해야 한다는 구체적인 방안이 제시되어야 하며 4)철저하게 외부적인 관점에서 진행 되어야 한다.

데밍 "벤치마킹 4단계" 를 살펴 보겠다.

계획 -> 수행 -> 전략 수립 -> 리모델링의 4단계로 이루어져 있다.

계획, 현존하는 시스템의 프로세스를 분석하고 수행절차에 대한 계획수립,평가모델개발, 대략적인 벤치마킹 영역을 설계하고

수행, 벤치마킹 대상, 벤치마킹 영역, 벤치마킹항목, 벤치마킹기준을 시트로 작성하여 수행 하도록 한다.

전략수립, 수행된 시트를 기준으로 사이트를 분석하여 경쟁력확보를 위한 방법을 수립하고 차별화된 전략수립, 성과차이와 동인분석을 실시한다.

리모델링, 앞의 결과를 기준으로 재 설계를 실시한다.

# 문제 해결 방법을 구체화 하라

문제가 정의 되었다면 해결 방법 찾아야 한다. 일단 벤치마킹을 통하여 몇가지 해결 방안을 찾을 수 있을 것이다. 그 이후에는 기획자의 "통찰력"을 많이 필요로 하는 부분이다. 여러가지 리서치, 로그분석, 유저빌리티 테스트 등을 통하여 나온 정보들을 기준으로 해결방법을 구체화 시켜야 한다. 이는 웹기획자의 직관에 의해 바로 "해결방법"이 나오는 경우도 많이있고 여러가지 사고를 통하여 해결 방법을 찾기도 한다.(가장 일반적인 방법이다. 기획자가 모두 컨설턴트는 아니므로)

체계적으로 해결방법을 찾는 방법론도 존재 한다. 간단하게 도식화 하면

"생각하고 -> 정리하고 -> 분석한다."라고 표현할 수 있는데

생각하는 법은 제로베이스사고, 프레임워크사고 등이 존재한다.

정리하는 법은 커미트먼트, 스트럭쳐,컨셉의 방법 등이 존재한다.

분석하는 법은 로직트리(what,why,how), 매트릭스, 프로세스방법이 존재한다.

이들 내용에 대한 상세내용은 차후에 다루기로 하겠으니 "웹기획 기초" 부분인 이 단계에서는 이쯤에서 넘어가도록 하자.

# 설계하라 어떻게? 제대로!!

이제 드디어 눈에 보이는 웹기획자의 작업영역에 들어간다. 초보 기획자는 이것으로 능력의 유무가 판단될 만큼 겉으로 보이는 유일한 부분이다. 많은 설계문서를 접해보고 자신만의 설계방법을 찾아 나가도록 하자(웹기획 커뮤니티에 보면 관련문서들이 많이 보이므로 많이 벤치마킹하여 자신만의 설계방법을 만들어 나가자)

IA설계

새로 구축하는 것이 아니고 개선하는 것이기 때문에 기존의 IA에 대한 전반적인 이해를 필요로 한다. 개선될 사항에 대하여 정보구조를 재설계 하는데 이는 정보를 분류하는 분류법에 대한 기준과 매뉴의 분류등을 포함한다. 네비게이션 설계는 방향성이 존재하는 아이콘, 텍스트, 메뉴 등에 대해 어떻게 표현할 것인지를 설계하는 것이다. 레이블링 설계는 각 메뉴 및 텍스트의 명명법이며 사용자의 언어로 사용자가 직과적으로 알수 있도록 네이밍 하는 것이다. (차후 구체적으로 논의 하자)

관련 문서로는 IA설계서를 작성하여 각 데이터간의 관계를 명시해주고 네이밍을 명시해 준다. 메뉴 구조도 같은것도 첨부 할 수 있다.

UI설계

드디어 나왔다. 스토리보드를 설계하는 것을 말한다. 화면이 어떻게 구성되어지고 어떤항목이 어떻게 나열되며 IA설계된 항목들이 어떻게 유저빌러티가 증가하는 방법으로 배치될 것인가의 문제를 정의 하는 부분이다., 또한 그래픽 유저 인터페이스(GUI) 도 고려하여 시각적인 부분도 모두 기술하여 웹디자이너나 개발자들이 보고 쉽게 파악할 수 있도록 명시해야 한다.

내가 언젠가 이야기 한적이 있다. "스토리보드만 그리는 것이 웹기획자가 아니다." 스토리 보드를 제대로 설계하기 위해서는 이전에 배운 여러가지 웹기획자의 임무를 수행해야 하며 무수히 많은 노력을 기울여야 한다. 눈에 보이는것은 기획안과 스토리보드지만 거기에는 철학과 방법과 피땀이 녹아 있어야 하는 것이다.

프로그램의 로직컬 설계

개선되는 기능에프로그램 기능들이 늘어갈 경우에는 로직컬한 순서도를 그려줘야 한다. 예를들어 회원가입과 같은경우의 순서도, 채팅프로그램이라 한다면 채팅을 하기위한 로직컬한 순서도를 그려줘야 한다. 이런 부분을 개발자가 순간적으로 판단하여 본인들의 생각으로 그냥 개발을 진행해 버리는 경우가 많이 존재하는데 이렇게되면 사용자의 유용성은 현저하게 떨어지고 중장기적으로 사용자를 떨어뜨리게 하는 주요 요소 이므로 반드시 기획자가 사용자 입장에서 설계 해야 한다.

데이터베이스 모델링 및 설계

DBA 또는 개발PL이 한다. 개발자 출신의 경우 설계는 아니더라도 모델링 부분에 개입되어 관계형데이터베이스의 기초부분을 논의 할 수 있다면 금상첨화라 할 수 있다. 데이터베이스 모델링 분야만해도 굉장히 난해하고 어려운 분야이다. 여기서 모든걸 다 다룰 수 없으므로 간단하기 이야기 하고 넘어가도록 한다. 관계형 데이터베이스 구조로 만들기 위해 기초로 데이터 베이스 모델링을 한다. 논리적인 객체를 정의 하고 이들의 관계를 논리적으로 설정하여 기본윤곽을 만들어 나가는 단계이다. 이를 가지고 데이터베이스 설계자는 구체화 시켜 테이블과 칼럼들을 설계해 나가면 된다. 이 분야에 어느정도 안다면 웹기획자가 어느정도 모델링에 개입되어 의견을 전달하는것이 좋다. 데이터베이스 모델링은 사이트의 근본을 만드는 뼈대 작업이므로 매우 중요하다 할수 있다. (기회가 되면 차후에 관계형데이터 베이스에 대해 강의 하기로 하겠다.)

기술적인 설계

개발 PL과 상의 해야 하고 개발PL이 설계해야 하는 부분이다. 이것도 마찬가지로 웹기획자와 혐의 후에 진행 되어져야 한다. 어떤기능들을 어떤 기술로 구현할 것인지에 대한 협의가 이루어 져야 한다. 이부분에서 개발자들과의 마찰이 굉장히 많다. 우선 기술들에 대해 많이 아는 것이 중요하며 적제 적소에 제대로 쓰일 수 있도록 해야 한다. 어떤 기술들은 너무 고난이도라 구현하기 어려울 수도 있고 솔루션을 구입하려면 금액이 많은 경우도 다수 존재한다. 이러한 사항들을 어느정도 알고 있어야 개발자와의 커뮤니케이션에서 무시당하지 않고 리딩할 수 있는 것이다.

# 디자인과 개발 코딩

일반적으로 설계가 이루어지고 스토리보드가 나온 항목에 한해서 웹디자인 작업에 들어간다. 웹기획자와 구도로의 커뮤니케이션을 통해, 스토리보드의 문서화를 통해 의견을 전달하며 그것들이 원하는데로 제대로 이루어지고 있는지 수시 확인 해주어야 한다. 기획의도를 디자이너가 잘못 파악할 수도 있다.

또한 중요한 화면인 경우 시안1,시안2등과 같이 몇가지 대안을 제시하도록 요구해야 한다. 최종의사결정자에게는 2가지 정도의 디자인 안을 주어 선택하도록 한다. 3개 이상의 시안을 제시하지 않도록 한다. 시안이 많아지면 선택에 혼란이 가중되어 이도저도 아닌 또다른 디자인을 요구 할 때가 많아진다.

또한 디자인 작업이 어느정도 진행이 되면 개발 코딩이 들어가야 된다. 개발이 최초 시작되어야 할 부분이 있기

다운로드
20060503_1.jpg (0B)

20060503_2.jpg (0B)

의견 1 신규등록      목록