베이직플랜

웹 스토리보드 스토리보드 양식은 정해진 것은 없습니다. 필요나 협의에 따라 적절한 양식을 정하여 작성하면 됩니다. 그러나 반드시 지켜야 할 것은 있습니다. 바로 기능과 화면의 구분이 표시되어야 한다는 점입니다. 이것은 기능 번호, 화면 번호라 할 수 있습니다. 이 내용은 요구 사항의 내용이 스토리보드에 모두 고려되었는지 확인하는 방법이 됩니다. 또한 스토리보드의 각 페이지의 내용이 앱/웹의 어느 부분을 설명하고 있는 것인지도 파악할 수 있어야 합니다. 기획 툴을 사용할 경우 기능 상으로 어느 정도 자동 파악이 가능할 수 있습니다. 그러나 PPT 또는 기타 문서 툴을 사용할 경우 표시를 해야 합니다. 기획 툴을 사용하는 기획자가 항상 생각하고 있어야 하는 것은 이 툴 또한 개발된 앱/웹이라는 점입니다. 기..

드래프트 와이어프레임과 스토리보드. 이 두개가 같을까요? 보통 프로젝트 진행단계에서는 “디자인시안”도 기획초기에 같이 시작을 하게 됩니다. 이때 “디자인시안”을 위한 화면설계서가 필요한데 이때 “드래프트 와이어프레임”이라고 통용됩니다. 이후 본격 적인 화면설계는 화면설계라고 하지요. 기획자는 취합된 요건정의서, 벤치마킹을 토대로 같이 시안 업무를 진행할 디자이너에게 가이드 해 줄 “시안용 스토리보드”를 작성 하게 됩니다. 시안용 스토리보드는 화면설계와 큰 차이는 없습니다만 기능을 설명하기위한 “Description”이 불필요합니다. 단 디자이너를 위한 레퍼런스 URL을 테마색상, 레이아웃 등을 설명 하면 되겠지요. 드래프트와이어프레임에 포함되는 컨텐츠는 가상의 컨텐츠이고 이미지 또한 시안을 위해서 모두 ..

스토리보드 중에서 화면상세설계 부분을 한번 간단하게 설명을 드려보겠습니다. 아래 기준은 PPT로 작성한 것을 기준으로 이야기 해 보겠습니다. 기본적인 프론트 화면설계의 형태 입니다. 여기에 와이어프레임을 작성하고 화면설명(Description) 기재하여 디자이너와 개발자에게 이해가 되는 형태로 설명을 하여야 합니다. 상단 개요 영역 상단개요는 스토리보드에서 프로젝트, 작성일자, 작성자, 단계, 페이지, 메뉴위치, 화면설명개요 등으로 구성되어 한장만 조회하고 있어도 어느 부분의 화면인지를 알 수 있어야 하고 어느기능을 필요로 하는것인지 간단한 가이드를 화면설명개요에 기재 해 줍니다. 드래프트 & Description 영역 해당 페이지를 와이어 프레임 형태로 UI를 고려하여 작성합니다. 여기에 링크, 버튼,..

프로덕트 매니저와 기획자의 메인 업무 중 하나는 UI 설계입니다. 이를 업계에서는 화면설계서, 화면정의서, 스토리보드, MMI(Man Machine Interface)등 다양한 이름으로 부르고 있는데요. 고놈이 고놈이라고 이해하시면 됩니다. 화면설계서는 대부분 파워포인트, 피그마등 상황에 맞추어 제작합니다. 스토리보드는 모든 분석 및 정의 한 내용들이 정리되고 요약되며, 와이어프레임과 같이 표현되는 부분이라 제일 중요한 부분이라 생각합니다. 따라서 자세하게 설명을 하고자 주니어 레벨을 목표로 작성해 봅니다. 에이전시를 위한 항목도 있으니 이부분은 에이전시가 아닌 기획자분은 패스 할 항목으로 생각 해 주세요. 스토리보드의 양과 질 설계 문서인 스토리보드가 보기 좋게 잘 정리되어 있어야 하는 것도 중요합니다..

웹기획에 사용되는 플로우차트를 간단히 소개 드리겠습니다. 플로우차트는 다른말로 워크플로우로 명칭하기도 합니다. 저는 소프트웨어 공학적인 플로우차트는 지양하고 있습니다. 웹기획자 입장에서 “흐름”을 가장 중요시 하는 이유도 있지만, 누락되는 예외 케이스를 놓치지 않기 위함이 제일 큰 이유이기도 합니다. 또 개발자님들로부터 지금까지 소프트웨어 공학적인 챠트를 요구받은적도 없습니다. 중요한 것은 흐름속에서 “유저액션”, “관리자액션”, “시스템처리” 가 되어야 합니다. 제 경우, 좀 더 자세하게 분류하면 아래와 같은 요소로 플로우차트를 작성 합니다. (개발방법론으로 정의된 입력 > 판정 > 출력 등의 플로우차트는 사용하지 않습니다.) 즉, 사용자구분, 시스템등의 이용대상을 기준으로 구분을 두어 플로우차트를 만..

스토리보드는 앱/웹을 사용하거나, 앱/웹을 관리하는 기준으로 작성되는 차이를 나타냅니다. 그리고 이 둘은 음과 양, 프런트 엔드와 백 엔드의 관계처럼 연결 관계를 가지고 있습니다. 이러한 연결 관계는 기능 정의와 화면 정의의 내용을 통해 표현됩니다. 이 때문에 일반적으로 사용자 관점의 화면을 규정하는 스토리보드를 작성한 후, 이를 관리하기 위한 관리자(admin) 스토리보드를 작성하는 것이 오류의 가능성을 줄일 수 있는 방법이 됩니다. 따라서 어드민 IA는 프론트 IA와 어드민 담당자의 업무분장 으로부터 출발 합니다. From 프론트 IA 아래와 같은 가상 서비스 프로덕트를 예로 들어보겠습니다. 여기에 포함되는 서비스는 포인트, 알림, 회원정보, 정기구독신청 등의 IA가 있습니다. 여기서 관리가 필요한 ..

IA(Information Architecture)란? IA는 정보 구조를 설계 및 관리하는 문서입니다. 쉬운말로는 서비스의 인덱스(목차)역할을 합ㄴ디ㅏ. 정보구조설계 및 정의 라고 하면 여러가지 구성 형식에 맞춰서 정보 시스템의 구조를 정리할 수 있겠지만, 일반적으로 사이트맵 형식을 IA설계라고 합니다. 하지만 사이트맵과 다릅니다. 예를 들어 쇼핑몰에서 중요한 메뉴는 “주문하기”, “결제하기” 입니다. 하지만, 사이트맵에서 없지요. 이는 제품상세페이지의 후속 메뉴로 정보설계에서 필요한 메뉴이지 사이트맵의 네비게이션을 위한 메뉴가 아니기 때문입니다. 모바일과 APP이 대세이기 전, 웹사이트의는 복잡한 구조의 사이트 틀을 짜고 콘텐츠를 구성하는 일 외에, WBS의 기준이 되는 IA를 기준으로 개발의 일정관..

WBS는 Work Breakdown Structure의 약어로 ‘작업분류구조체계’라고도 합니다. 이 문서는 프로젝트에서 수행할 작업을 단계적, 업무적으로 정의한 문서이고, 프로젝트의 진행상황과 진척도를 관리하는 관리체계를 잡아주는 역할을 합니다. 해당 문서는 기획자보다 프로젝트매니저 또는 프로덕트오너가 관리할 문서입니다. WBS는 보통 프로젝트의 진행사항을 체크하기 위해 작성하는데, 이를 위해서는 먼저 해당 프로젝트 진행을 위한 개발범위를 파악하고 주어진 일정을 체크해야 합니다. 그 다음으로 프로젝트 참여인원의 역량을 고려하여 일정과 개발범위의 조율이 필요한데, 통상적으로는 개발범위에 따라 일정이 늘어가기 보단 일정에 개발범위를 맞추는 게 일반적입니다. 물론 그 일정은 차츰 늘어나기 마련이고... 그 다..

기능정의의 배경 기능정의는 무엇을, 어떻게, 어디까지 구현 할지 결정해 줍니다. 개발해야 할 웹, 시스템의 수많은 기능들을 모든 팀원이 다 기억할 수 없을 뿐더러, 기능해야할 대상을 클라이언트, 기획자, 디자이너, 개발자 스스로 각각 사람이기에 다르게 이해할 수 있기 때문입니다. 이로인해 기능정의서라는 문서형태가 필요하게 되었으며, 이는 상호 협의 및 결정된 내용을 정리하여 문서화 한것입니다. 즉, 기능정의서는 개발되어야 앱/웹 시스템의 기능의 내용과 개발 방식 등을 설명한 문서입니다. 기능에 대한 정의만으로 사용자가 이용할 화면을 알 수는 없습니다. 사용자가 이용하게 될 서비스 기능에 대해 파악할 수는 있습니다. 그리고 기능이 어떻게 작동되고 어떤 프로세스에 의해 이루어지는지 설명되어 있습니다. MVP..

왜 요구사항정의가 필요 할까요? 기획은 과거와 현재를 기반으로 미래를 설계하고 만들어가는 작업이라고 생각합니다. 비즈니스를 운영중에 데이터화로 필요한 모든 노하우, 아이디어, 업무문서 등이 누적됩니다. 기획자는 눈에 보이지 않는 이러한 누적 데이터들의 상호관계를 이해하며 이 데이터들이 만들어낼 미래까지 나름대로 가늠하고 파악할 수 있어야 합니다. 따라서 기획자는 정보를 파악하고 이해하는 능력이 가장 기본이 되어야 합니다. 하지만 프로젝트를 진행하다 보면 정보파악 및 이해순의 능력이 아니라 회의 중 나온 기본적인 말과 의도조차 파악하지 못하는 기획자가 많습니다. 아니라는 말을 맞다고 받아 들이거나, 하지 말라는 말을 하라는 말로 이해하고, 심지어 화를 내고 회의 분위기가 험악했는데도 회의가 잘 끝났다고 업..