코드그라데이션

디스크립션 작성의 필요성1. 요소/속성에 대한 정의를 통해 누락의 방지요소(Element): 개별 항목(예: 주문 상태, 기간 조회, 회원 구분 등)속성(Attribute): 해당 요소에 포함되는 값(예: "결제 대기", "결제 완료", "배송 중" 등)ex. 주문일 순위기준이 기본 값이지만 인기 순위나 아니면 신청 순으로도 볼 수 있어야 된다라는 것이 설명이 되어 있지 않으면 구현자가 어려워한다. 예시주문 상태 항목: "결제 대기", "결제 완료", "배송 중"기간 조회 항목: "주문일", "출고일" (사용자가 선택 가능)회원 구분 항목: "일반 회원", "VIP 회원" 2. 오버/클릭 등에 따른 화면변화에 대한 움직임 정의사용자의 행동에 따라 변화하는 부분을 명확하게 설명해야 한다.- 터치 오버 마우..

레이아웃레이아웃 작성 Step 1. 거시적 관점에서 미시적 관점으로 접근하라 레이아웃과 디스크립션을 구분하여 화면 설계서를 작성해야 한다.레이아웃: UI 요소를 배치하는 영역디스크립션: UI 요소의 역할과 기능을 설명하는 영역레이아웃 설계 시 고려할 점거시적인 관점에서 접근 후, 미시적인 디테일을 정리해야 한다.- 상품 상세 페이지를 설계할 때, 먼저 사용자의 이동 흐름을 고려해야 함.- 예) 사용자가 메인 > 상품 목록 > 상세 페이지로 이동한다면, 그 흐름.>> 상세 페이지에서는 메인과 목록에서 이미 확인한 정보는 강조할 필요 없음.>> 정말 상세에서 중요한 것은? 장바구니 추가, 주문 버튼 등의 핵심 기능을 부각해야 함. 예시ex 1. 여행 상품 상세 페이지 설계예를 들어, 여행 상품 상세 페이지에..

화면설계서는 어떤 역할을 수행하는가? 화면 설계서는 단순한 문서가 아니라, 프로젝트의 품질을 높이는 중요한 요소다.  1) 구현 기준 제공- 개발자가 구현할 때 기능 정의와 구성 요소를 정확히 이해할 수 있도록 가이드 제공- 설계서가 없으면, 개발자가 임의로 UI를 구성할 가능성이 있음 2) 요구사항 및 개선사항 반영 체크- 설계서를 통해 요구사항이 제대로 반영되었는지 사전 점검 가능- 인하우스 팀에서는 논의했던 사항이 설계서에 포함되었는지 확인해야 함=> 설계 단계에서 수정하면 시간이 절약되지만, 개발 단계에서 수정하면 두 배의 시간이 소요됨 3) 사용자 경험(UX) 시뮬레이션- 화면을 넘겨보면서 사용자 경험(UX)이 직관적인지 확인- 프로타이핑을 통해서 이 화면의 연계성이 사용자 경험에 도움이 되는지..

화면 설계 개요 및 필요성 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)까지 보여줄 것인지, 해당 분류에서 페이지는 몇 개가 필요한지를 정리하는 것이 핵심.예를 들어, 여행 카테고리 안..

구조상단에는 뎁스(Depth) 라는 개념이 있다. 뎁스에는 메뉴와 페이지가 포함된다.뎁스란 특정 페이지에 도달하기까지 몇 단계(몇 번의 선택)를 거쳐야 하는지를 의미하는 개념이다.예를 들어, 어떤 페이지에 도달하는 데 7~8번의 클릭(또는 터치)이 필요하다면, 이는 사용자 경험(UX) 측면에서 좋지 않을 것.그래서 뎁스의 깊이는 굉장히 중요한 문제.실제로 사용자가 원하는 페이지에 3번의 클릭 이내로 도달하지 못하면 이탈할 가능성이 높다는 통계가 있다.따라서 세 번 이내의 선택(클릭)으로 원하는 페이지에 도달할 수 있도록 구성해야 한다. 뎁스가 깊을수록 사용자가 원하는 정보를 찾기 어려워지고, 이탈률이 높아질 가능성이 크다.  사용자가 원하는 페이지로 이동하는 방법에는 두 가지가 있다 : 1. 메뉴(Men..

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