UX 기획을 공부할 때와
실무에서 UX 기획 업무를 진행할 때
가장 크게 느껴지는 차이 중 하나는 바로 'Back-Office(약칭 BO)'의 존재입니다.
대부분의 UX 관련 강의나 책에서는
사용자의 여정, 사용성 테스트 같은 UX 디자인 방법론이나
실제 UI가 구성되는 프론트엔드 화면에 초점이 맞춰집니다.
하지만
실제 서비스가 돌아가려면
일반적인 사용자가 보는 화면 뒤편에서 데이터를 입력하고 관리하는 중심이되는 곳
즉, Back-Office 기획이 아주 중요합니다.
그렇다면 이 Back-Office는 구체적으로 어떤 것일까요?
Back-Office에 대해 구체적으로 알아보기 전
우리가 기획하고, 사용하는 서비스의 가장 기본적인 논리를 다시 한번 확인해 보겠습니다.
바로
'모든 서비스는 데이터를 만든다'는 것입니다.
조금 더 상세하게는 데이터를 생성하고(Create), 출력하고(Read), 수정하고(Update), 삭제하게(Delete)되는
CRUD 원칙이 모든 서비스의 기본이 된다는 의미입니다.
[IT 서비스와 CRUD 원칙] 참고
IT 서비스와 CRUD 원칙
이번 포스팅에서는 디자이너(기획자를 포함하여)가 알아야 하나 싶지만 웹과 앱을 포함하여 모든 UI 디자인에서, 능력자라면 꼭 알아야 하는 CRUD 원칙과 친해져보려 합니다. (사실 제가 업무를
blog.hohakdang.com
이 단순한 논리에서부터 우리는
한 가지 질문을 떠올일 수 있는데,
바로
"서비스가 제공하는 데이터들은 어디서 오는 걸까?"라는 질문입니다.
예를 들어 배달앱을 보겠습니다.
일반 사용자가 보는 화면에는 다수의 음식점과 메뉴,
그리고 가격, 평점, 배달 예상 시간 등의 데이터를 제공하는데
이 데이터는 어디서 오는 걸까요?
여기에서 Back-Office가 등장하게 됩니다.
(Back-Office의 사전적 정의는 지원업무를 통칭하는 것으로 설명하고 있습니다.)
일반적인 배달 플랫폼에서는
사장님의 앱이 이러한 데이터를 입력받는 Back-Office라 할 수 있습니다.
(물론 식당 사장님 입장에서는 사장님 앱은 BO가 아니고 메인 앱이겠지만)
(+ 플랫폼 입장에서는 앱 회원이나 거래 정보 등을 관리하는 admin 시스템이 진짜 BO일 것입니다)
이렇듯
BO는 우리가 사용하는 서비스에 콘텐츠(그리고 그 속 데이터)를 제공하기 위한
하나의 채널로, 실제 운영 시 BO(또는 admin 시스템)를 활용하여 운영자가 데이터를 입력/관리하게 됩니다.
그리고
이러한 데이터의 입력(BO)과 출력(Front), 즉 데이터 바인딩, 플로우 및 권한을 정의하는 것이
UX 기획에서의 가장 중요한 업무중 하나라 할 수 있습니다.
다시 위 배달 플랫폼 사례로 돌아가서
메인 페이지 내 관련 데이터 일부를 구체적으로 살펴보도록 하겠습니다.
# 배달 플랫폼 내 주요 데이터
그렇다면,
위의 각 데이터가 어디에서 왔을지를 한번 생각해보겠습니다.
메뉴명 | ⇒ 식당 사장님이 입력 |
메뉴 가격 | ⇒ 식당 사장님이 입력 |
메뉴 사진 | ⇒ 식당 사장님이 입력 |
식당명 | ⇒ 식당 사장님이 입력 |
평점 | ⇒ 고객이 입력(?) |
배달 예상시간 | ⇒ 식당 사장님이 입력(?) |
배달팁 | ⇒ 플랫폼에서 자동 생성(?) |
최소주문금액 | ⇒ 식당 사장님이 입력 |
주요 데이터를 살펴보면,
메뉴 명, 가격, 사진, 식당명 같은 정보는
단순히 식당 사장님이 사장님 앱(BO)에서 작성한 데이터이므로 정의하는 것이 크게 어렵지 않습니다.
정의 예시) "사장님 앱에서 입력한 메뉴명 출력"
그러나 평점, 배달 예상시간, 배달팁 같은 정보는
살짝 당황스럽습니다.
평점 같은 경우는 "주문 고객이 입력한 리뷰 평점의 산술평균"을 제공하는 것이 일반적이겠으나
상세하게는 리뷰 작성의 기준부터 상세하게 정의가 필요합니다.
또한, 배달 예상시간의 경우
식당 사장님이 입력한 "배달 예상시간의 최소~최대값 출력"한다면,
실제 식당과 배송지의 거리, 점심/저녁 러시아워, 배달원/매칭 수가 제대로 반영되기 어려울 것입니다.
따라서 실제 정의를 할 때에는 플랫폼 시스템에서 접근 가능(가져올 수 있는)한 정보들을 확인하고,
이러한 정보들을 기준으로 실제 사용자 화면에 보여줄 데이터를 출력하는 논리식을 구체적으로 정의해야 합니다.
(그렇지 않고, 모호하게 정의한다면 개발팀에서 해당 값을 어떻게 계산하는 것인지 물어 볼 것입니다)
이렇듯 UX 기획 실무에서는
BO의 개념을 이해하고, 각 데이터가 어디(특히 BO)에서 등록되고,
또 어떻게 출력되는지를 구체적이고 명확하게 정의하는 것이 정말 중요합니다.
와이어프레임의 80%는 List, Detail, Form으로 정리된다. (0) | 2025.04.27 |
---|---|
혁신이 아닌 모방으로 설계되는 UX (3) | 2024.12.31 |
Figma로 정리하는 UXUI 협업 프로세스 (5) | 2024.10.28 |
Figma로 시작하는 UI 디자인 실무 (0) | 2022.06.17 |
Atomic Design Pattern과 UI 디자인 실무 (0) | 2022.05.20 |
댓글 영역