코드그라데이션

화면 설계 개요 및 필요성 1. 실제 구현될 화면의 구성요소/기능에 대한 가이드 제공2. 요구사항 및 개선사항이 반영되었는지를 사전 체크3. 시뮬레이션을 통한 사용자 불편 요소를 미리 찾아냄 => 대부분의 모바일 패턴은 좌측에서 우측으로 이어지는 흐름을 가지며, 긴 형태의 슬라이드로 구성되어 있다.   화면 설계서 제작 방식 : PPT vs Figma / XD- 피그마(Figma) 또는 XD(Xperience Design)로 UI를 설계한 후, PDF로 출력하여 제공- 또는 PPT(파워포인트) 도형을 활용하여 설계 후 PDF로 변환⇒ 결국, 최종적으로 하나의 PDF 파일로 출력하는 방식을 가장 많이 사용한다.PPT 사용 시: 인수인계가 쉽고 도형 수정이 간편함피그마 / XD 사용 시: UI 설계가 직관적..

프론트와 백엔드의 정보 구조 정리정보 구조를 정리할 때 프론트(Front)와 백엔드(Back Office)를 함께 고려하는 것이 중요하다.예를 들어, 프론트 페이지만 보고 "이제 백엔드를 만들어보세요."라고 하면, 구체적인 흐름이 잘 보이지 않을 수도 있다.- 그러나 백엔드에서도 결국 동일한 정보 그룹(메인, 프로덕트, 검색, 유틸리티, 컴퍼니)을 적용할 수 있기 때문에 이를 기준으로 정리하면 보다 쉽게 구조를 파악할 수 있다. 백오피스도 메인 그룹에 속하지만, 기능적으로 프론트엔드와 차이가 있다.>> 예를 들어, 프론트에는 로그인하지 않고도 볼 수 있는 페이지가 있지만, 백오피스는 인증 없이 접근할 수 있는 페이지가 없다.=> 따라서, 백오피스에서는 로그인 페이지가 필수적으로 필요. 1. 백오피스 메인..

정보 구조 정리 및 전시 카테고리 관리As-Is와 To-Be 구조를 만들면서 요구사항 아이디를 함께 적어두면, 나중에 엑셀로 정리할 때 쉽게 기입할 수 있다.- 이처럼 외부 시스템과 연계되는 항목도 미리 정리해 두는 것이 중요하다.- 그래야 이후에 마인드맵을 다시 열어보지 않고도, 필요한 정보를 바로 엑셀에서 확인할 수 있다. Q : 모든 전시 카테고리를 정보 구조에서 전부 정리해야 하느냐?A : "아니오, 하나의 샘플만 정리하면 됩니다."전시 카테고리는 별도의 정책 문서에서 관리되며, JIRA 같은 협업 도구를 통해 운영 방식에 따라 변경된다. 그래서정보 구조에서는 최대 몇 뎁스(Depth)까지 보여줄 것인지, 해당 분류에서 페이지는 몇 개가 필요한지를 정리하는 것이 핵심.예를 들어, 여행 카테고리 안..

요구사항 합의와 그 이후 요구사항 합의는 어렵다.- 요구사항은 포괄적이고 추상적일 수 있기에, 이를 최대한 구체적으로 다시 풀어서 설명하는 과정이 필요하다.정기적으로 한 번씩 → 3개월의 한 번씩 / 100일에 한 번씩인지 정확하게 판단- 페이지가 명확히 지정되지 않았거나, 장바구니처럼 목록 페이지에서 누락될 수 있는 아이콘 등의 요소가 있을 경우, 요구사항 발의자가 미처 생각하지 못한 부분을 체크하고 반영하는 과정이 필요.예를 들어 "6개 상품을 2단 배열로 보여줄지, 1단 배열로 보여줄지"와 같은 표현 방식을 확인하거나, "인기 상품에 어떤 카테고리가 포함될지" 등을 질문하여 요구사항을 구체화할 수 있다.- 요구사항을 정확히 인지하는 것과 해석하는 것은 다르다.=> 해석을 통해 전문성을 발휘할 수 있..

설계의 전제가 되는 사항들  설계란?화면 설계를 통해 기획자들이 상품을 납품하는 과정 이다.>> 설계서의 가치는 기획자의 가치와 맞먹을 정도로 중요하다. 그러나 이 설계를 구현하기 위해서는 IT 인프라에 대한 이해가 필요하다.IT 인프라는 하드웨어와 소프트웨어 모두를 포함하며, 이 위에 서비스 정책, 요구사항, 사용성이 토대로 올라간다. 정책에는 회원 정책, 상품 정책, 주문 정책, 할인 정책 등이 포함된다.요구사항은 앞서 이야기한 여러 가지 요구사항을 기록한 것이고, 사용성은 UX 가이드에 대한 내용을 담고 있다. 이 모든 것들이 기초가 되어 정보 설계와 정보 구조도가 만들어지고, 그 위에 화면 설계서가 지붕처럼 얹혀지는 구조다. => 이 기반이 튼튼할수록 더 안정적인 설계를 할 수 있다.  IT 인프..

서비스 정책- 인하우스에서는 서비스 정책서를 기준으로 프로덕트를 운영하는 경우가 많다.- 외주 프로젝트에 참여할 때는 최신 정책을 요청하거나, 신규 프로젝트라면 정책을 먼저 요청해야 설계를 원활하게 진행할 수 있다. >> 인프라 위에 정책이라는 기둥이 있고, 이 정책이 기울어지면 정보 설계나 화면 설계서가 제대로 세워질 수 없다. 정책의 의의정책은 일종의 법률과 같다.- 서비스가 작동할 수 있는 원리를 담고 있는 법률과 같은 역할. 서비스 정책에는 회원 정책, 상품 정책, 주문 정책, 프로모션 정책 등이 포함된다.예를 들어, 회원 정책에는 회원 가입과 탈퇴, 로그인 시 필요한 정보, 회원이 마이페이지에서 사용할 수 있는 서비스 등이 명시된다.회원 정책에서 중요한 항목은 회원 가입, 로그인 후 이용 가능한..

요구사항 정의서앞선 내용을 바탕으로 프로젝트가 시작되면, 착수 단계에서 수행 계획서가 리뷰되고, 기획자들은 요구사항 수집 단계에서 요구사항 정의서를 작성한다. 요구 내용클라이언트나 현업에서 발의된 요구사항을 정리한 것이며, 이를 어떻게 해결할지에 대한 해결 방법을 사전에 1차 협의한다.- 이 과정이 원활하지 않으면 설계 시간이 길어지고, 오해가 생길 수 있기 때문에, 해당 요구사항에 대해 "이렇게 해결하겠습니다"라는 식으로 합의점을 도출해야 한다.- 이 요구사항이 수용될지 여부는 PM이 결정하며, 계약 범위에 포함되면 수용, 그렇지 않으면 제외되는 방식이다. 구성 요소등록일과 요구사항 근거구현이 1차, 2차로 나누어지는 경우에는 요구사항을 구분하여 관리할 수 있고, 필터링을 통해 잘 확인할 수 있다. -..

오픈 시기 - 운영 매뉴얼 작성오픈 시기가 확정되면 운영 매뉴얼'을 작성하여 인수인계 준비(개발팀 -> 운영팀)를 한다.- 운영 매뉴얼은 담당 기획자가 작성하며, 운영팀의 막내가 새로 들어와도 이해할 수 있을 정도로 상세하게 기록해야 한다. - 문서만으로도 운영이 가능하도록 작성하는 것이 중요하다.예를 들어, 관리 포인트가 있으면 그 관리 방법을 상세하게 설명하고, 각 영역의 이미지와 텍스트가 어떻게 관리되는지를 구체적으로 기록해야 한다.=> 이러한 운영 매뉴얼을 바탕으로 운영팀에 인수인계가 이루어진다.  - 운영 매뉴얼 작성이 완료되면, 대면 교육을 통해 운영팀에게 인수인계가 이루어진다.- 인수인계가 완료되면, 기획자는 프로젝트에서 철수하고, 인하우스라면 직접 운영에 참여하게 된다.- 운영에 참여하게 ..