야메의 이상한 생각과 공감

오랜만에 웹기획 가이드를 남기는 야메군 입니다. 넘쳐나는 소재에도 불구하고 산적한 업무를 처리하느라 잠시 게으름 아닌 게으름을 피웠던 거 같은데요, 오늘부터 가열차게 웹기획 가이드를 채워보도록 하겠습니다. (물론.. 한가해졌다는 건 아닙니다만..=_=;) 오늘의 주제는, 같은 회사 임에도 서비스의 특성이나 아이덴티티에 따라 나눠진 수 많은 웹사이트를 관리의 용이성과 산재된 인프라를 하나로 묶기 위해... 웹사이트마다 각기 다른 아이디와 하나의 비밀번호, 그리고 회원정보 등을 하나로 통합하는 패밀리 사이트 개념의 웹사이트를 작업할 일들이 한 번쯤은 생기게 되는데 이미 경험이 있다면 그리 어렵게 생각할 건 없지만 그에 대한 경험이 부족하다면 도대체 어디서부터 손대야 할지 난감한 경우들이 생기게 되는데, 오늘..

얼마 전, 미국법원에서 애플과 삼성간의 특허소송에 대한 배심원 평결이 있었습니다. 그 결과, 배심원들이 애플의 손을 들어주었고 삼성은 예상을 뛰어넘는 수조원 대의 천문학적인 금액을 배상해야 할 위기에 처해있습니다. 여기서 누가 이겼고 졌는지에 대한 논란은 잠시 접어두고, 이번 재판에서 자신들의 보유한 특허가 어떻게 침해 당했는지를 풀어가는 과정에서, 두 회사의 접근방식을 눈여겨 볼 필요가 있습니다. 먼저 삼성은 자신들의 특허를 사용하지 않고는 3G 기술이 적용된 스마트폰을 만들 수 없다는 독점적이고도 유니크한 펙트 중심의 기술기반 변론을 했습니다. 그에 반해 애플은 각각의 증거에 스토리텔링을 적용하여, 배심원들에게 삼성이 애플의 디자인 특허를 침해했다는 것을 자연스럽게 전달하여, 유리한 평결을 이끌어 내..

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

여러분들은, 회사에서의 발언권이나 업무의 주도적인 역할로 구분했을 때, 갑(甲)과 을(乙)에서 어디에 해당되시나요.. 아마도 대부분의 기획자들은 갑보다는 을에 가까운 위치에서 디자이너나 개발자.. 혹은 그 이외의 내부 구성원들과 커뮤니케이션을 진행할 겁니다. 설마... 갑과 을이 아닌 병이나 정의 위치에 계신가요?^^; 이유야 어찌되었건 간에.. 대체적으로 프로젝트를 리딩하는 위치가 아닌 디자이너나 개발자의 눈치를 보고, 비위를 맞춰가면서 일하고 있는 빈도가 높을 것으로 생각 됩니다. 이러한 이유에 대해 아마도.. 대부분은 프로젝트를 잘 마무리하기 위핸 어쩔 수 없는 선택이란 이야기를 할텐데.. 뭐 틀린 말은 아닙니다만, 그렇다고 저자세로 협업 대상자들에 '이거 될까요..' 혹은, '이것 좀 해주시면 안..

지난 주 스토리보드 작성방법에 대한 내용을 설명하다가 마무리를 짓지 못했는데요, 앞서 개요 및 정의에 대한 항목을 이야기했었는데.. 이 같이 기획의 목적과 정책적인 요소를 정리한 후, 사이트의 메뉴나 페이지 구성을 도식화한 사이트맵 페이지를 작성해야 합니다. 사이트맵은 식당의 메뉴판과도 유사한 구조와 개념을 가지고 있는데, 식당 메뉴판을 보면 탕 류라는 최상위 분류에 해물탕, 알탕, 설렁탕, 갈비탕과 같은 하위 분류가 구성되어 있는 경우를 많이 보셨을텐데, 이런 카테고리 분류없이 탕과 찌게, 주류를 마구잡이로 섞어 놓는다면 손님은 자신이 원하는 음식을 찾기 위해 많은 시간을 들일 수 밖에 없으며, 결과적으로 클레임이 유발될 수 밖에 없는데, 스토리보드 상에서의 사이트 맵 역시도 별반 차이가 없습니다.. ..

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

오늘은 기획자가 알아야 할 데이터베이스 구조에 대해서 설명 드릴텐데요. 웹기획자가 직접 DB 서버를 설계하거나 혹은 DB 프로그래밍을 하는 경우는 사실상 없다고 볼 수 있습니다. 하지만 기획자 역시도 데이터베이스에 대한 기본적인 이해도는 갖추고 있어야 하며... 개발자들이 주로 사용하는 DB 스키마(Schema), 즉 DB 설계도의 전반적인 흐름 정도는 이해할 수 있는 지식을 갖추셔야 합니다. 하지만, 대부분의 주니어 기획자들이 그러하듯이, 전문적인 개발 용어들이 나오면 자연스레 위축되곤 하는데, 실상 그 의미를 따져보면 그리 어렵지 않습니다. 이는 데이터베이스 역시도 마찬가지 인데, 데이터베이스란 용어 자체가 명확하지 않을 뿐이지, 이미 여러분들은 데이터베이스의 기본이라 할 수 있는 데이터를 매일같이 ..

오늘은 프로세스에 대한 내용을 살펴볼까 합니다. 웹 관련 직종에서 일하다보면 프로세스란 용어를 많이 접하곤 하는데요, 대략적으로는 하나의 과정 정도로 이해할 수 있는데, 조금 더 내용을 명확히 정리하면, 하나의 과정에서 시작과 종료까지 발생할 수 있는 다양한 경우의 수가 포함된 일련의 과정으로 이해하시면 될 듯 합니다. 웹 뿐만 아니라 모든 분야에서 사용되는 프로세스는 대부분 동일한 의미를 내포하고 있는데, 이러한 프로세스가 필요한 이유는 서비스를 구체화 하기에 앞서, 전반적인 흐름을 파악하고 점검하기 위한 목적과 함께 서비스에 문제가 생겼을 경우 어떠한 부분에서 문제가 생겼는지를 되짚기 위한 목적도 있습니다. 이러한 프로세스의 의미를 자세히 뜯어보면.. 이 세상의 모든 인과관계가 프로세스라는 흐름에 따..

앞선 포스트에서 웹 기획의 정의에서 웹 기획자가 해야할 일에 대해 대략적으로 말씀 드렸는데요. 회사의 성격이나 세분화된 업무의 포지션에 따라, 약간씩의 차이가 있을 수 있겠지만 대체적으로 웹기획자의 역할은 크게 다르지 않습니다. 웹기획자는 기본적으로 웹사이트나 서비스를 구축하고 개선하는 과정에서 서비스가 나가야 할 방향을 결정하고 정책을 수립하는 사업 기획적인 업무를 시작으로 웹 사이트 내에 담아야 할 여러 서비스적인 구성요소를 도출하는 작업을 진행합니다. 이를 바탕으로 서비스의 사이트 맵 및 각 서비스 요소의 프로세스를 구성하게 됩니다. 이 과정을 거친 후, 유저인터페이스(User Interface)와 사용성(User experience)을 고려한 화면 설계 과정을 통해, 기획서를 완성하게 되고 디자이..

지난 2009년 즈음에, 작성한 포스트에서 웹기획자가 하는 일에 대해 개략적으로 설명했는데, 웹기획 능력을 향상시키는 방법과 기획 업무에 대해 좀 더 보완설명을 해볼까 합니다. 웹 기획이라는 분야, 어떻게 정의 내릴 수 있을까요?? 너무 복잡하고 어렵게 생각하지 맙시다. 웹 기획은 한마디로 지랄 같은 분야 입니다..ㅋㅋ 농담이고요.. 웹 기획이란 웹이라는 공간에 서비스를 만들기 위해 필요한 큰 고민들과 작은 고민들을 하고 이를 도식화하는 과정을 거쳐 다양한 분야의 사람들이 이해할 수 있는 언어와 그림으로 만들어내고 이를 바탕으로 커뮤니케이션을 진행하고 결과물을 만들어내는 업무를 수행하는 직종이라 할 수 있습니다. 물론 부가적으로 프로젝트의 스케줄을 관리하고 클라이언트를 만나는 일도 있겠지만 이는 어디까지..