백오피스 화면설계 심화 (14)

실제 BO 화면설계 실습

① 공통 레이아웃 → 조회 → 목록 → 상세 설계 기준

 

1. 백오피스 공통 레이아웃의 현실적인 범위

프론트 vs 백오피스 차이

• 프론트
  • 공통 내비게이션
  • 공통 모듈
  • 공통 컴포넌트
  • 공통 페이지 / 팝업 다수
• 백오피스
  • 공통으로 그릴 것 거의 없음
  • 핵심은 헤더 내비게이션 형태 1회 정의

 

✔️ 백오피스 공통 레이아웃에서 “딱 하나” 중요한 것

헤더 내비게이션 형태를 한 번은 합의해서 잡아두는 것

• PC 전용
• 모바일처럼 변형 없음
• 고정 구조
• 이후 작업자들이 “이 구조를 기준”으로 따라가게 됨

- 그려도 되고, 생략도 가능
- 다만 한 번 정의해두면 협업이 쉬워짐

 

용어 정리

• 공통 내비게이션: 가능하면 1회 정의
• 공통 컴포넌트: 템플릿 사용
• 공통 모듈 / 공통 페이지 / 공통 팝업
  → BO에서는 거의 없음 (이론만 인지)

문장이 짧다. 일단은 이 내비게이션의 형태, 헤더 내비게이션의 형태는 한번 같이 잡아주는 게 필요합니다.**

그래서 이것을 앞으로 우리가 헤더라고 하는 박스로 쓸 건데 이게 어떻게 될 거지라고 하는 것은
한번 상의해가지고 정리를 하시면 되고요.

다행히도 이런 모바일처럼 헤더나 탭 바가 변화하지는 않아요.

어드민의 특성상 PC 버전이고 이 PC 버전의 특성상 공간이 넓다 보니까
헤더 영역을 충분히 고정적으로 활용할 수 있고 그런 이유에서 보시는 이 모바일 샘플처럼
뭔가 변화가 있지는 않지만 그래도 한 번 잡아주게 되면 이후에 하시는 분들이 잘 이해하고 따라갈 수 있겠죠

 

 

2. 백오피스 기본 화면 설계 공식

상단 조회 → 목록(테이블) → 컨트롤 → 상세

이 구조만 지켜도  욕 안 먹는 BO는 만든다.

 

3. 조회 영역 설계 원칙

❓ 조회 항목은 무엇을 기준으로 정하나?

👉 목록에 있는 항목 기준

 

❌ 잘못된 설계

• 목록에 없는 항목을 조회 조건에 넣음
• 상세에만 있는 정보를 조회에 사용

예시 (틀린 사례)

• 목록에 가격 없음
• 조회 조건에 “가격 범위(0~100만 원)” 있음
  → 의미 없는 조회

 

올바른 설계 원칙

1. 조회 = 목록 필드 필터
2. 목록에 없는 항목은 조회 불가
3. 조회가 필요하면 → 목록에 추가

🔑 조회 ↔ 목록은 반드시 싱크가 맞아야 한다

 

✔️ 키워드 검색은 예외

• 드롭다운 불가
• 텍스트 입력 필요

하지만 조건은 동일:

입력한 키워드는 목록에 존재하는 필드 중 하나여야 한다

 

조회 항목 우선순위 기준

• 해당 메뉴에서 가장 자주 쓰는 값
• 관리자가 “제일 먼저 찾는 값”

예시:

• 주문 관리 → 주문번호
• 회원 관리 → 회원명 / 전화번호
• 전시 관리 → 활성 / 비활성

어떤 것을 어떤 순서로 자주 쓰는 거. 일단은 해당 메뉴마다 자주 쓰는 것들이 있어요.
주문 관리 페이지에서는 주문 번호가 우선 보여야 돼.

그리고 회원명이나 아니면 전화번호 같은 것들
이 메뉴를 자주 쓰는 사람들이 선호하는 것들이 있단 말이죠.
그런 것들을 써주고 이 목록에서 보여주는 것들을 조회 항목으로 넣는 거죠.

목록이 안 나오는데 조회 영역에 그게 있으면 틀린 거라는 거예요

 

4. 조회 결과 페이지 = 데이터 테이블

기본 구조

1. 데이터 컨트롤 영역 (상단)
2. 데이터 테이블
3. 페이징

 

데이터 컨트롤 영역에 들어가는 것들

• 정렬 (최신순 / 인기순 / 구매순 등)
• 필터 (유형 / 상태)
• 페이징 개수 (20 / 50 / 100)
• 엑셀 다운로드
• 일괄 액션 버튼

 

왜 중요한가?

• 컨트롤이 부족하면:
  • 상세 페이지 지옥
  • 100건을 100번 클릭

❗ 주문 관리에서 “일괄 처리” 없으면
❗ 그 시스템은 실무에서 실패한 시스템

 

이 테이블 위에 컨트롤 영역이 배치되는 게 일반적인 구조죠.
보여드린사례도 이렇게 데이터 테이블 위에 선택 삭제라든지 검색 개수라든지 페이징 개수라든지
엑셀 다운로드나 액션 버튼 같은 것들이 있었고 카페 24도 동일하게 있었죠

진열, 판매 같은 버튼 같은 것들. 이게 데이터 컨트롤인데
데이터 컨트롤을 보통 이 위치를 이 위에 두고 이 데이터를 필터링하거나 재조합해보거나
변경할 수 있도록 하는 편입니다.

 

컨트롤은 일단 정렬을 변경할 수 있죠.
신규 순위냐 인기 순위냐 구매 순이냐 같은 것들로 변경할 수 있는 정렬 기능이 있고요.
필터링도 가능해요. 그래서 유형을 패키지 유형만 보겠다 이렇게 이제 필터링할 수도 있죠.

엑셀 다운로드를 할 수도 있고 내가 페이징을 20개씩 할 건지 100개씩 할 건지도 결정할 수 있습니다.

컨트롤 영역을 잘 만들어 두게 되면 사용성이 좋아져요.
반대로 이 컨트롤이 부족하게 되면 개별적으로 그 상세 페이지에 진입해서 처리를 할 수밖에 없다는 거죠

5. 상세 페이지 설계 – 형태보다 기준이 중요

상세 페이지 형태는 두 가지

1. 페이지 전환형
2. 우측 패널(아웃룩/Gmail 형태)

중요한 메시지

UI 형태와 관계없이
상세 페이지는 항상 ‘별도의 페이지’로 카운팅

• 오른쪽에 나와도 페이지
• 팝업이어도 페이지
• 탭이어도 페이지

=> 정보 단위 기준으로 판단

 

기존 사례에서는 페이지가 변경돼서 목록에서 상세로 변환된 것을 보여드렸다고 한다면 
해당 사례는 페이지가 오른쪽에 나오는 사례인데요.
기획서적으로는 이제 비슷한데 어떤 차이가 있는지 볼게요.
LNB를 약식으로 처리한 이유가 이 사례는 아까랑 똑같은 페이지예요.
배너 목록이라고 하는 걸 만든 건데 이 상세 수정이 오른쪽에 있어요.
이랬을 때 이 페이지를 둘 다 그리기는 어렵고 적합하지도 않다 보니까
이렇게 모듈화 처리하고 화면을 아예 달아둡니다.

 

그런데 이렇게 하든 아니면 페이지 바뀌든 간에 우리는 다 별도의 페이지로 간주하고 작업을 하면 된다.

 

 

6. 목록 + 상세를 동시에 보여주는 케이스 설계법

❌ 실수

• 목록 페이지 + 상세 페이지를 따로따로 그림
• 중복 설계

⭕ 올바른 방식 (모듈화)

• 좌측: 목록 (간략)
• 우측: 상세
• LNB / 헤더는 모듈 처리
• 한 화면에 “좌우 구조”로 표현

📌 목적:

• “이 화면은 좌우 분할 구조다”를 보여주는 것

 

7. 페이지 카운팅 기준 (아주 중요)

정보의 단위가 다르면 페이지다

• 좌우 분할 ❯ 페이지
• 탭 ❯ 페이지
• 팝업 ❯ 페이지

📌 UI에 속지 말 것
📌 정보 구조 기준으로 판단

 

8. “합칠 수 있지만 분리한 이유”를 설명할 수 있어야 한다

기획자의 판단 영역

• 합쳐도 틀린 건 아니다
• 하지만 더 적합한 방식을 선택한 것

판단 기준 3가지

1. 사용성
2. 업무 흐름
3. 정책 / 운영 요구사항

 

설명 공식

“정보 단위가 독립적이기 때문에 분리했습니다.”

이게 가장 강력한 논리다.

 

핵심 요약

• ☐ 공통 레이아웃: 헤더 1회 정의면 충분
• ☐ 조회 항목 = 목록 필드
• ☐ 조회 ↔ 목록 싱크 필수
• ☐ 컨트롤 영역 반드시 설계
• ☐ 상세는 형태 무관, 항상 페이지
• ☐ 탭 / 팝업 / 우측 패널 = 페이지
• ☐ 페이지 분리는 “정보 단위” 기준