노노니의 서비스 기획소

온라인 서비스를 만들기 위해서는 아이디어와 기획, 디자인, 개발이 있어야 합니다. 시작은 아이디어입니다. 창업자는 서비스 기획자에게 만들 서비스의 아이디어와 특정한 사용 방식의 의도를 설명합니다. ​ 서비스 기획자에게 아이디어를 이야기하는 이유는 아이디어만으로 디자인, 개발을 할 수 없기 때문입니다. 아이디어만 있으면 전문가들이 뚝딱 만들 것 같지만 전문가일수록 절차를 지켜 정확하게 만들어냅니다. 대충 이야기해도 알아서 멋지게 만들어주는 경우는 없습니다. 서비스 기획자는 설계도를 만들어 디자인, 개발 작업이 정확하게 진행되도록 가이드 합니다. 온라인 서비스의 이용 방식을 만들려면 시나리오가 있어야 합니다. ​ 시나리오는 6하 원칙에 의거해 누가(who) 왜(why) 언제(when) 어디서(where) 어떠한 것(what)을 어떻게(how) 할 것인가. 완성시키는 것입니다. 작성하는 것이 아니라 완성한다고 표현한 것은 서비스의 방식이 시나리오에 기초하기 때문입니다. ​ 시나리오는 실제 사용자의 행동을 감안한 가설입니다. 가설을 세우고 맞는지 검토, 불편하지 않은지 검토하여 사용자가 어려움 없이 자연스럽게 사용할 수 있는 수준까지 수정하여 완성시킵니다. ​ 자칫 서비스 제공자에게만 쉬운 서비스는 만든 자신에게는 쉬워도 사용자에게 어렵고 불편한 서비스가 될 수 있습니다. 시나리오는 작성은 여행이나 데이트 계획을 짜는 것과 같습니다. 무엇을 입고, 어디서 만나서, 어디를 가서, 어떤 걸 먹고 보고 올지 상상하고 기록해 놓는 것입니다. 늘 하던 것이라 어렵지는 않습니다. ​ 내가 만족하는 내 계획에서 다른 많은 사용자가 만족하는 공통된 좋은 계획을 세우는 것이 상품화입니다. 나 혼자 돌아다니는 여행 계획이 아닌 여행사의 유럽 5개국 테마 여행 상품 계획입니다. ​ 온라인 서비스를 만들려고 할 때 시나리오까지 작성해서 기획을 맡겨야 하는 것은 아닙니다. 서비스를 만들기 위한 설계는 서비스 기획의 과정에 '유저 시나리오' 단계가 있습니다. ​ 혹 ...

  최근 제1 금융권 컨설팅 기획에 화면 설계를 Figma로 제출해야 한다는 조건이 붙는 경우를 보았습니다. ​ 그래픽 툴을 다룰 줄 알고 있었기에 해야 한다면 하루 익혀서 하면 되나 Figma 작업은 기획이 아닌 디자인 작업일 것이라고 인력 소싱 하는 친구에게 이야기해 주었습니다. ​ Figma가 프로토타입과 웹, 앱 디자인 작업 툴의 독보적인 존재입니다. ​ ​ 스토리보드를 파워포인트로 작성하면 불편한 점도 있습니다. 스토리보드 분량이 많아질수록 간단한 수정도 수십 페이지를 차자 바꿔줘야 하고, 페이지가 변경되면 코드를 수정하고 영향을 받는 모든 페이지 코드를 일일이 바꿔줘야 합니다. ​ 파워포인트 스토리보드 작성의 불편함으로 해결하기 위해 Figma로 기획서를 작성하는 것은 아닙니다. 애자일, 스프린트의 서비스 제작 방식에서 기획문서, 디자인 작업의 이중 절차 없애기 위해 문서화된 기획서 없이 스케치 단계의 논의 후 디자인 작업을 시작합니다. ​ 기획이 디자인까지 하거나 디자이너가 기획까지 하는 형태가 됩니다. 기획과 디자인을 동시에 진행하고 실 서비스와 같은 그래픽 요소가 들어간 Hi-fi 와이어 프레임을 작성하면 발주자와 소통이 쉽습니다. 프로토타입 형태로 모바일 리뷰를 하면 실제감이 있습니다. ​ Figma 기획이 좋은 점만 있는 것은 아닙니다. 화면 설명과 서비스 프로세스를 설명할 수 없는 치명적 단점이 존재합니다. 문서 출력 제출이 필요한 프로젝트는 프린트를 위해 피그마 양식을 별도로 만들어야 합니다. ​ ​ Figma로 기존 스토리보드와 동일한 화면 설계를 하다 보니 디자인 작업 특유의 방식을 따르게 됩니다. 그래픽의 레이어를 정리해야만 수정 작업이 수월합니다. 공통 요소를 컴포넌트로 등록해 놓아 반복 사용하게 합니다. 버튼의 크기와 색상을 규격화합니다. 이 모든 작업은 화면 설계가 아닌 디자인 가이드 작업입니다. ​ 결국 Figma는 디자인 툴이므로 그래픽 툴을 다룰 수 있으며 내 생각을 실제와 같은 화면으로 보여주기 위한 목적일 때는...

 서비스 기획 포폴은 구체적 내용이 없습니다. 누군가 무엇을 했고, 어떤 결과물을 만들었는지를 보려면 포트폴리오(간략히 포폴)룰 봐야 합니다.  디자이너라면 Dribble, Behance에, 개발자라면 Github, Notion으로 포폴을 공개하기도 합니다. 기획자 포폴은 어디에 올리지? 기획자는 포폴을 올리지 않습니다. 올릴 수가 없습니다. 기획의 내용은 서비스의 목적과 사용 방식, 비즈니스 모델, 수익모델의 영업비밀과 경쟁포인트를 담고 있기에 절대 공개할 수 없습니다. 프로젝트에 들어갈 때 보안서약을 하며 심지어 프로젝트명 조차도 비공개 하거나, 서비스가 오픈 되기 전까지 공개를 제한하기도 합니다.  ​ 기획자의 경우 경력기술서에 있어 프로젝트명을 '교육 서비스' 또는 '부동산 플랫폼과 같이 서비스를 특정할 수 없도록 적기도 합니다. 기획자가 어떤 문서를 어떻게 작성하는지 제시하기 위해서는 개인 프로젝트 또는 샘플 문서를 만들어야 합니다. 또는 보안서약의 주체인 기업이 폐업하고 서비스가 없어진 경우 공개할 수 있습니다.   간혹 사이드프로젝트에 참여 후 공개하는 경우가 있는데 안됩니다. 같이 했다면 참여자의 동의를 득해야만 공개할 수 있는 것입니다.  서비스 기획자의 포폴은 기획자의 입이다.