BO 디스크립션(Description) 작성 가이드“디자인 설명이 아닌, 구현 설명 문서” 1. BO 디스크립션의 본질✔️ 프론트 설명과의 근본적 차이프론트디자인 설명 많음배너 사이즈, 여백, 색상, UI 표현 방식백오피스❌ 디자인 설명 거의 없음⭕ 데이터, 로직, 기본값, 제약 조건 중심BO 설명의 80%는 ‘개발자에게 하는 설명’이다PM: 거의 안 봄디자이너: 안 봄개발자: 이 문서로 구현함 2. BO는 “레고 블록 조립”이다백오피스는 보통:조회 모듈컨트롤 모듈테이블 모듈폼 모듈👉 이미 개발팀이 가진 컴포넌트로 조합그래서:“이 버튼은 둥글고 파란색입니다” ❌“조회 버튼 클릭 시 아래 조건으로 데이터 호출” ⭕ 3. 목록 페이지 디스크립션 핵심 ①조회 기본값(Default Value)왜 중요한가?무..
실제 BO 화면설계 실습① 공통 레이아웃 → 조회 → 목록 → 상세 설계 기준 1. 백오피스 공통 레이아웃의 현실적인 범위프론트 vs 백오피스 차이프론트공통 내비게이션공통 모듈공통 컴포넌트공통 페이지 / 팝업 다수백오피스공통으로 그릴 것 거의 없음핵심은 헤더 내비게이션 형태 1회 정의 ✔️ 백오피스 공통 레이아웃에서 “딱 하나” 중요한 것헤더 내비게이션 형태를 한 번은 합의해서 잡아두는 것PC 전용모바일처럼 변형 없음고정 구조이후 작업자들이 “이 구조를 기준”으로 따라가게 됨- 그려도 되고, 생략도 가능- 다만 한 번 정의해두면 협업이 쉬워짐 용어 정리공통 내비게이션: 가능하면 1회 정의공통 컴포넌트: 템플릿 사용공통 모듈 / 공통 페이지 / 공통 팝업→ BO에서는 거의 없음 (이론만 인지)문장이 짧다...
자주 하는 실수와 대안> BO 화면설계 실무 기준 정리 1. 버전 / 규정 이력 관리 미흡❌ 자주 하는 실수버전 번호만 있고 변경 내용이 불명확수정 이력이 문서 어딘가에 흩어져 있음“최신본”이 무엇인지 한눈에 알 수 없음작업자마다 다른 버전을 보고 작업⚠️ 발생하는 문제잘못된 화면 기준으로 개발이미 수정된 내용을 다시 구현“이거 언제 바뀐 거예요?” 반복 질문책임 소재 불명확⭕ 대안 (필수 원칙)버전 규칙 고정v0.1 / v0.2 / v1.0 처럼 명확하게이력 카드 필수버전 / 변경일 / 변경자 / 변경 요약검색 가능해야 함변경 키워드로 Ctrl + F 시 바로 발견배포 기준 명확화내부 작업 중 변경 ❌외부 공유 / 공식 배포 이후 변경 ⭕ 이력 기록✔️ “이 버전에서 무엇이 바뀌었는지문서만 봐도 바로..
정보구조에서의 권한 관리 설계1. 정보구조 단계에서 권한을 설계할 수 있다권한 관리는 화면 설계서 단계에서만 다루는 것이 아니라, 정보구조 단계에서부터 구조적으로 분리해 설계할 수 있다. 즉, 정보구조 안에👉 권한 그룹이라는 개념 자체를 하나의 구조 요소로 포함시키는 방식이다. 2. 권한 그룹 개념 정의정보구조에서는 보통 다음과 같은 권한 그룹 단위를 설정한다.슈퍼 어드민어드민 1어드민 2(필요 시) 운영자, CS 전용, 조회 전용 등이 단계에서는“어떤 사람이 누구인가” 를 정의하지 않는다. 대신“어떤 역할이 어떤 권한을 가진다” 를 정의한다. 3. 권한 그룹과 사용자 매핑 구조권한 관리 구조는 크게 두 단계로 나뉜다. ① 권한 그룹 정의슈퍼 어드민어드민 1어드민 2② 사용자 매핑홍길동 → 어드민 1..
최초 시작은 정보구조부터1. 정보구조부터 시작해야 하는 이유백오피스(BO) 화면설계를 시작하기 전에 반드시 선행되어야 하는 작업은 정보구조 정의다.화면을 먼저 그리는 것이 아니라, 어떤 정보들이 어떤 단위로 존재하는지를 먼저 정리해야 한다. 정보구조가 없는 상태에서 화면 설계를 시작하면화면 범위가 계속 늘어나고메뉴가 뒤엉키며작업 공수 산정이 불가능해진다그래서 BO 설계의 출발점은 항상 정보구조다. 2. 정보구조를 만드는 첫 번째 방법: 마인드맵정보구조를 만드는 방법은 여러 가지가 있지만,그중 초기 설계 단계에서 가장 효율적인 도구는 마인드맵이다. 마인드맵은 아이디어 발산용 도구로 많이 알려져 있지만, 실제로는 정보를 덩어리 단위로 구조화하는 데 매우 적합하다. 예시전시 관리배너 관리목록 페이지등록 / 수..
기획전 구성 시 화면설계 원칙 정리1. 기획전 상품 호출 구조의 기본 전제기획전은 새로운 상품을 만드는 기능이 아니다.이미 존재하는 상품을 불러와서 조합·배치하는 기능이다.따라서 기획전 생성 시 흐름은 항상 다음과 같다.기획전 생성 페이지 진입상품 추가 버튼 클릭상품 목록 페이지 호출 (팝업)체크 → 체크 → 등록기획전 구성 완료 2. 이미 존재하는 페이지는 다시 그리지 않는다중요한 원칙이 하나 있다.이미 존재하는 페이지는 화면설계서에서 다시 그리지 않는다. 왜냐하면상품 목록 페이지는 이미 상품 관리 메뉴에 존재UI, 검색 조건, 테이블 구조가 이미 정의되어 있음동일한 화면을 또 그리는 것은 중복 설계 3. 올바른 설계 표현 방식기획전 생성 화면에서 상품을 불러올 때는다음 표현만으로 충분하다. ❌ 잘못된..
공통 코드 기반 드롭다운 데이터정렬 · 세부 설정을 어디까지 해야 하는가?1. 질문의 핵심 다시 정리질문의 본질은 이거야.“공통 코드에서 불러오는 드롭다운 데이터라면이 화면에서도 순서나 세부 속성까지 다시 정의해야 하나요?” 예시로 들면숙소 / 리조트 목록지역 목록법인 목록유형 코드이런 것들이 공통 코드 관리에서 이미 정의되어 있을 때,각 화면에서 다시:정렬 기준표시 순서활성/비활성 여부노출 우선순위같은 걸 또 적어야 하느냐는 거지. 2. 결론부터 명확히 말하면👉 기본적으로는: 안 한다.그리고 이 판단의 근거는 명확하다. 3. 설계 의도의 핵심3.1 공통 코드의 역할 정의공통 코드는여러 화면에서동일한 의미로반복 사용되는 데이터다시 말해,“정의와 관리의 단일 진실 소스(Single Source of Tr..
백오피스 상품 옵션 관리 화면 설계1. 상품 옵션 관리의 개념부터 정리- 상품 옵션은 상품을 더 잘게 쪼개는 수단이다.상품이 하나라도,판매 단위는 여러 개가 될 수 있다.1.1 대표적인 옵션 사례패션티셔츠→ 색상(화이트/블랙)→ 사이즈(S/M/L)식음료햄버거 세트→ 단품 / 세트→ 감자 변경 / 음료 변경서비스숙박→ 룸 타입→ 조식 포함 여부이때 중요한 질문이 생긴다.“이건 상품이 여러 개인 건가요?”→ 아니다. 상품은 하나고, 옵션이 여러 개다. 2. 상품 옵션 관리의 기본 원칙2.1 기본값은 “옵션 없음”모든 상품의 기본 상태는 다음이다.상품 1개옵션 없음단일 가격 / 단일 재고옵션은 필요할 때만 추가한다. 2.2 옵션은 상품 상세에서 만드는 것이 아니다실무에서 많이 실수하는 지점이 있다.❌ 상품 상..