베이직플랜

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

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

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

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

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

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

유저시나리오와 유저스토리는 고객(실이용자)의 관점에서 작성됩니다. 그리고 애자일 개발 방식의 스크럼에 따른 개발속에서 나왔습니다. 애자일 > 스크럼 개발이 아니더라도 웹기획 속에서 “문제인식”에 목표와 개선점, 고도화포인트, 고객의 니즈를 정의 할 수 있기에 간단히 다루어 봅니다. 유저 시나리오는 사용자의 상상 속 인물인 "유저"에 대한 이야기로, 어떤 문제를 해결하기 위해 실제로 여러 사건들을 잘 그린 그림으로 그려내어, 팀은 유저가 상황 속에서 어떻게 행동하는지 이해할 수 있게 도와줍니다. 그렇게 함으로써, 팀은 유저의 실제 필요와 행동을 이해하고, 그에 맞게 솔루션을 디자인할 수 있어요. 시나리오라는 용어와 개념은 유즈케이스(Use Case)에서 파생 되었습니다. 유즈케이스는 1980년대 중반 이후..

앱과 앱 개발을 위한 기획 방법이라고 이론적으로 정해진 것이 있는 것은 아닙니다. 이 글의 내용은 그동안 개발 프로젝트 경험을 통해 개인적으로 이렇게 기획하면 더 효과적이라 논리적으로 생각해 본 내용을 적은 것입니다. 간단하게 생각나는대로 그려 보았습니다. 가장 기본은 액션(요청)과 응답을 이해하는 것 입니다. 사용자가 원하는 액션을 할 경우 그것이 올바른 액션인지, 올바르다면 원하는 페이지나 처리를 한 결과를 보여주는 것이 가장 기본입니다. 이러한 기본을 가지고 화면설계를 하면서 작동이 될수 있는 화면설계를 위한 구성요소(서버, 데이터 조회/등록/수정/삭제)들이 움직이는 방식을 생각하여 추가 해 주는 것입니다. 이러한 기본사항으로부터 출발하면 서비스 개발 시 왜 기획을 하는가에 대한 정의는 세부적으로는..

프로젝트를 착수하고 스토리보드 제작 완료까지의 여정은 모든 프로젝트별로 일관되지 않고 다릅니다. 늘 프로젝트를 시작할때 어디서부터 해야할지 어떤게 필요한지 필요없는지는 프로젝트의 성격, 기간, 규모 그리고 참여인력, 분석설계 방법, 기획방법, 클라이언트와의 관계, 클라이언트의 마인드 등… 그때그때 마다 자연스럽게 다른 산출목록이 나왔습니다. 하지만 공통으로 프로젝트의 흐름 프레임은 분석 > 설계 > 구축 > 완료 속에서 이루어 집니다. 한번 개발이전까지의 분석 및 설계의 흐름을 볼까요? 앱/웹 개발 프로젝트에서 기획자의 작업을 정리하면 위 화면과 같습니다. 분석단계에서 문제인식, 각종 정의를 한 후 IA를 설계하고 최종으로 스토리보드까지 업무가 진행이 됩니다.착수단계는 기업 규모에 따라 또 제안요청서분석..

인터넷 비즈니스에 분류는 수익모델별, 수익형태별, 거래주체별 등 다양하게 있습니다. 인터넷 초기에는 분 류모델이라는것은 난잡할정도였고 너무 수시로 바뀌었다가 가장기본적인 분류로는 웹에 관심있으신 분들이 꼭 한번씩 들어보았을 B2C, B2B로 구분이되는 전자상거래형태 분류 모델이 있습니다. 가장 기본으로 생각 되는 모델이고 이후에 산업쪽에서 웹이 관심을 보이면서 학술적으로 분류모델이 산업별로 구성이 되었던 듯 합니다. 거래주체별(전자상거래형태) 기준의 인터넷 비즈니스 모델은 다음과 같습니다. 1. 기업간 거래 (B to B : Business to Business) 기업이 기업을 대상으로 각종 서비스나 물품을 판매하는 방식의 전자상거래를 말합니다. 기업간 거래이기에 도매형태 전자상거래로서 재화나 용역을 생..