[신입PM] 와이어프레임보다 어드민 구조화가 먼저입니다
신입 기획자가 실무에서 배운 화면설계의 본질
기획자로 첫 화면설계를 맡았을 때, 저는 와이어프레임을 그리는 게 전부라고 생각했습니다. 그저 예쁜 화면을 만들면 되는 줄 알았죠. 실제로 저는 도서 커머스 플랫폼을 기획하면서 네이버 쇼핑의 프로세스를 참고해, ‘주문~배달 단계’를 직접 따라 그렸던 기억이 있습니다.
실제 하투크의 신입 시절 그렸던 어드민 스토리보드 페이지입니다.참고로만 활용 부탁드립니다.하지만 운영팀의 질문이 쏟아지고, 개발팀은 기능 정의가 불명확하다며 수정을 요구했을 때 비로소 알게 됐습니다. 제가 놓친 건 ‘정보 구조화’였습니다. 화면이 아닌 흐름을 먼저 설계했어야 한다는 것, 그 시작이 바로 어드민 구조화였습니다.
이 흐름이 없었다면, 사용자 화면은 단지 보기 좋은 UI에 불과했을 겁니다.
① 어드민은 서비스의 ‘흐름’을 설계하는 도구입니다
어드민은 단순히 데이터를 관리하는 화면이 아닙니다. 서비스의 흐름을 뒤에서 제어하는 설계도이자, 기획자의 사고가 가장 선명하게 드러나는 공간입니다.
TIP: 도서 커머스 플랫폼에서 사용자가 주문을 완료한 뒤 어떤 상태값이 생성되는지
(결제 대기/결제 완료/포장 중/배송 중/배송 완료), 각 단계에 따라 어떤 알림이 발송되고 어떤 문제가 발생할 수 있는지를 먼저 정의했습니다.
예를 들어, 주문 완료 이후 프로세스를 구조화해보겠습니다.
주문 완료 이후 프로세스 구조화상태 흐름을 기획 키워드로 구조화한 이유
도서 커머스 플랫폼에서 주문이 완료된 이후의 흐름은 단순히 기능의 나열로 끝나지 않습니다. 결제 이후의 각 단계는 사용자의 기대와 불안을 동시에 동반하며, 그 경험의 질이 서비스 전반의 만족도를 결정하게 됩니다. 그래서 저는 ‘주문 완료 이후 프로세스’를 단순한 상태의 나열이 아닌, 기획자가 반드시 고려해야 할 키워드 중심의 구조로 접근했습니다.
먼저, 전체 흐름을 다섯 가지 상태로 나누었습니다.
결제 대기, 결제 완료, 포장 중, 배송 중, 배송 완료.
이 다섯 개의 상태는 시간 순서대로 진행되는 사용자 여정이며, 각 상태는 서비스 내부적으로도 별도의 로직과 트리거를 갖고 있어야 합니다. 하지만 상태값만 정의해서는 실질적인 서비스 설계가 되지 않습니다. 각 단계마다 "무엇을 고려해야 하는가?", "어떤 문제가 발생할 수 있는가?", "어떻게 대응할 것인가?"라는 질문을 기준으로, 세 가지 기획 키워드를 설정하였습니다.
사용자에게 어떤 알림이 언제 발송되어야 하는가
사용자가 겪을 수 있는 UX 이슈는 무엇인가
시스템 또는 운영 측면에서 필요한 처리 로직은 무엇인가
이 세 가지 기준을 기반으로, 각 상태별로 다음과 같은 항목들을 도출했습니다.
결제 대기 단계에서는
알림 트리거: 결제 요청 메시지의 타이밍과 방식
UX: 결제 실패 시 사용자가 재시도하기 쉬운 구조인지
시스템 조건: 미결제 상태가 지속될 경우 자동 취소 처리 방식
결제 완료 단계에서는
신뢰 확보: 결제 완료 메시지가 실시간으로 도달하는지
에러 대응: 중복 결제나 환불 요청과 같은 예외 처리 프로세스
후속 연결: 포장 단계로의 자연스러운 상태 전환
포장 중 단계에서는
재고 확인: 실시간 재고 여부 체크가 가능한지
물류 연동: 포장 지연 발생 시 사용자에게 사전 안내가 가능한지
CS 시나리오: 누락이나 지연 발생 시 CS 대응 메시지가 준비되어 있는지
배송 중 단계에서는
택배 연동: 실시간 배송 상태를 사용자에게 제공할 수 있는지
정보 제공: 배송 추적 정보를 어느 시점에 제공할 것인지
예외 처리: 배송 지연 또는 오배송 발생 시 대응 방안
배송 완료 단계에서는
수령 확인: 실제로 사용자가 상품을 수령했는지 확인하는 방법
후속 액션: 리뷰나 별점을 유도하는 타이밍과 방식
문제 발생 시: 미수령, 반품, A/S 요청 등 사용자 불만에 대한 응답 구조
이처럼 각 단계마다 구조화된 질문을 통해 기획 키워드를 도출하면, 단순한 업무 목록이 아닌 실행 가능한 설계 항목으로 전환됩니다. 또한 디자이너, 개발자, 운영자와의 협업 시에도 커뮤니케이션이 훨씬 명확해집니다.
기획자는 흐름을 설계하는 사람입니다.
흐름을 정의할 때 ‘상태값’만 나열할 것이 아니라, 그 상태 안에서 벌어질 수 있는 사용자 경험과 시스템 반응까지 구조화하는 것이 진정한 기획의 역할이라고 생각합니다.
해당 부분에 대해서는 다음 시간에 좀 더 자세하게 다뤄보겠습니다.
② 어드민은 협업을 위한 공용 언어입니다
화면 하나에도 수많은 팀원들이 관여합니다. 디자이너, 개발자, QA, 운영팀까지. 어드민 설계서는 이들이 같은 이해를 가질 수 있도록 만드는 공용 언어입니다.
TIP: 단순히 "필터 기능 있음"이 아니라
“CS팀이 문제 주문을 빠르게 찾기 위한 필터”라고 적는 것.
이 한 줄이 개발자에겐 개발 맥락이 되고, QA팀에겐 시나리오가 되며, 디자이너에겐 틀이 됩니다.
③ 보이지 않는 어드민이 사용자 경험을 결정합니다.
빙산을 떠올려보세요. 사용자 화면은 수면 위에 떠 있는 작은 일각일 뿐, 그 아래 어드민이라는 거대한 구조가 사용자 경험을 떠받치고 있습니다.
TIP: 품절 임박' 배지를 기획할 때, 단순히 UI만 고민했다면 기능은 실패했을 겁니다.
어드민에서 ‘재고가 몇 개 이하일 때 품절 임박으로 표시할지’ 조건을 설계했고,
재입고 알림 여부, 대체 상품 노출 방식까지 정의했기에 완성도 높은 기능이 될 수 있었습니다.
④ 어드민은 기획자의 '문제 해결 능력'을 보여주는 구조입니다
기획자에게 어드민 설계는 곧 문제 해결의 무대입니다.
어떤 데이터가 가장 중요할까?
어떤 예외 상황이 생길 수 있을까?
운영팀이 자주 보는 정보는 무엇일까?
이 모든 질문에 대한 답을 구조화하는 것이 바로 어드민입니다. 단순히 '기능을 나열'하는 것이 아니라, 문제를 정의하고 예측하며 설계의 레이어를 쌓는 일입니다.
⑤ 어드민에서 사용자 화면으로 ‘연결’하는 힘
이제야 사용자 화면 설계가 시작됩니다. 어드민에서 설정한 기능과 데이터가 사용자 화면에서 어떻게 표현될지를 하나하나 연결해 나가는 작업입니다.
어드민의 ‘할인율’ 설정 → 사용자 화면의 ‘세일 배지’
어드민의 ‘배송비 정책’ → 사용자 장바구니의 ‘무료배송까지 얼마 남았습니다’ 안내
어드민의 ‘배너 노출 설정’ → 메인 화면 상단의 이벤트 배너
이런 연결고리를 명확하게 문서화해 두면, 협업 속도가 빨라지고, 서비스 품질도 올라갑니다.
⑥ 실무에선 Description이 ‘설계의 꽃’입니다
화면 설계서에서 가장 많이 읽히는 영역은 바로 Description입니다. 이곳에 기획자의 의도, 사용자 니즈, 기술적 맥락까지 담아야 진짜 설계가 됩니다.
Before: “검색창에서 상품을 검색할 수 있다.”
After:
“검색창은 상품명, 브랜드, 카테고리 키워드로 검색이 가능합니다. 입력 시 자동완성 기능이 제공되며, 인기
검색어 상위 5개를 노출합니다. 검색 결과는 관련도순으로 정렬되며, 사용자가 가격·평점·신상품 기준으로
재정렬할 수 있습니다.”
이 한 문단에 사용자 경험, 개발 요구사항, 운영 기준이 모두 담겨 있죠.
⑦ 실무 꿀팁: 어드민-사용자 화면 연결 문서 만들기
가장 실무적인 꿀팁 하나. ‘어드민-사용자 화면 연결 문서’를 만드세요.
실제 해당 문서 하나로 개발팀의 질문이 70% 줄고, QA 오류가 40% 감소했던 경험이 있습니다.
최고의 가성비 문서 아닐까요?
어드민 구조화는 단순한 백오피스 기획이 아닙니다.
그것은 기획자의 사고가 드러나는 설계이고, 사용자 경험을 설계하는 첫걸음입니다.
와이어프레임을 그리기 전에, 한 번 더 멈춰서 생각해 보세요.
“이 데이터는 어디서 오고, 어떻게 관리되며, 어떤 흐름으로 사용자에게 전달될까?”
그 순간부터, 우리는 단순한 화면 설계자가 아닌 서비스를 설계하는 기획자가 됩니다.
참고) 서비스기획자라면 꼭 알아야 하는 서비스 IA 활용 방법!
https://zero-base.co.kr/event/media_insight_contents_PM_IA
참고) 정보구조 설계(IA), 와이어프레임(Wire-frame) 작성법/그리는 법
https://blog.naver.com/soomichip_/223127062784
참고) UX 디자인과 정보구조 설계: 1 정보구조(IA)의 개념과 종류
https://yozm.wishket.com/magazine/detail/1421/
참고) IA, 메뉴구조도, 화면목록이 헷갈린다면?
https://yozm.wishket.com/magazine/detail/1606/
참고) 서비스기획자에게 information Architecture란?
https://basicplan.tistory.com/entry/서비스기획자에게-information-Architecture란
