모바일 대시보드는 사용자가 지금 내려야 하는 판단부터 배치해야 한다. 데스크톱의 네 열을 한 열로 바꾸면 화면은 좁아지지만 정보의 우선순위는 그대로 남는다. 상단의 요약 카드가 길게 쌓이는 동안 실제로 확인할 위험과 다음 행동은 몇 번의 스크롤 뒤로 밀릴 수 있다.
먼저 “이동 중인 담당자가 오늘 지연될 출고를 찾는다”처럼 한 문장으로 과업을 정한다. 모바일 이용자는 항상 급하거나 모든 작업을 한 손으로 한다고 가정하지 않는다. 다만 지금 설계하는 화면에서 가장 중요한 판단 하나를 정해야 무엇을 앞에 두고 무엇을 상세로 보낼지 결정할 수 있다.
가상 예시: 전체 실적보다 부족한 출고를 먼저 찾는다
아래는 9월 27일 14:00에 조회한 가상의 당일 출고 현황이다. 숫자는 주문 건수가 아니라 출고할 상자 수다. 준비율은 준비 수량 ÷ 예정 수량이며, 부분 출고 허용 여부나 고객 중요도는 주어지지 않았다. 따라서 부족 수량만으로 최종 우선순위를 자동 확정하지 않는다.
| 출고처 | 예정 상자 | 준비 상자 | 부족 상자 | 마감 |
|---|---|---|---|---|
| A | 40 | 38 | 2 | 15:00 |
| B | 30 | 20 | 10 | 14:30 |
| C | 30 | 30 | 0 | 16:00 |
전체 준비량은 38 + 20 + 30 = 88상자, 예정량은 100상자다. 준비율은 88%이고 부족량은 12상자다. 그러나 담당자가 먼저 볼 것은 큰 “88%” 하나가 아니다. 이 예시에서 B는 부족량 10상자와 가장 가까운 마감 14:30을 함께 갖는다. B의 준비율은 약 66.7%이고 남은 시간은 30분이다. 이것을 첫 판단 대상으로 제시하되 예상 완료 시각이 없으므로 지연 확정이라고 쓰지 않는다.
작은 화면의 순서를 먼저 고정한다
다음 표는 실제 기기 캡처가 아닌 정보 순서 도식이다. 픽셀 높이나 특정 기기의 첫 화면 노출을 보장하지 않는다. 상위 영역은 “왜 확인해야 하는가”, 다음 영역은 “다른 출고와 비교하면 어떤가”에 답한다. 모든 수치를 같은 크기의 카드로 만들어 시선의 무게를 나누지 않는다.
| 화면 순서 | 표시할 내용 | 사용자가 하는 판단 |
|---|---|---|
| 1 · 조회 조건 | 9월 27일 / 당일 출고 / 14:00 갱신 | 지금 보고 있는 범위 확인 |
| 2 · 먼저 확인 | B · 10상자 부족 · 14:30 마감 | 어느 출고를 먼저 볼지 선택 |
| 3 · 비교 | A 2상자 / B 10상자 / C 0상자 부족 | 동일 기준으로 비교 |
| 4 · 상세 근거 | B의 준비 현황·예상 완료·담당 상태 | 실행 가능한 대응인지 확인 |
| 5 · 다음 행동 | 담당 확인 또는 대응 기록 | 권한 내에서 처리 |
첫 영역의 높이를 황금비율이나 고정 숫자에 맞추기보다 실제 문장 길이와 필요한 상태를 먼저 수용한다. 중요한 기준은 좁은 폭에서도 대상, 부족량, 마감이 함께 읽히는지다. 글자를 작게 만들어 한 줄을 지키면 수치 위계가 좋아 보여도 사용자는 핵심 문장을 읽기 어려워질 수 있다.
같은 출고 데이터의 화면 전후 비교
9월 27일 14:00 · 당일 출고 · 전체 출고처
BEFORE · 전체 요약부터
전체 준비율
88%
준비 88 / 예정 100상자
전체 출고 예정
100상자
전체 부족 수량
12상자
요약 아래에서 출고처별 근거 확인 ↓
| 출고처 | 준비/예정 | 부족 | 마감 |
|---|---|---|---|
| A | 38/40 | 2 | 15:00 |
| B | 20/30 | 10 | 14:30 |
| C | 30/30 | 0 | 16:00 |
AFTER · 확인 대상과 기한부터
먼저 확인 · 지연 확정 아님
B 출고
10상자 부족
마감까지 30분
준비 20 / 예정 30상자 · 마감 14:30
상세 확인 →
전체 준비 88% · 88/100상자 · 부족 12
| 출고처 | 준비/예정 | 부족 | 마감 |
|---|---|---|---|
| A | 38/40 | 2 | 15:00 |
| B | 20/30 | 10 | 14:30 |
| C | 30/30 | 0 | 16:00 |
상세에서 목록으로 복귀할 때 조회 조건을 유지하도록 설계한다.
같은 A·B·C 데이터를 두고 요약 중심과 확인 대상 중심의 읽기 순서를 비교한다. 이 본문 도해는 독자의 화면 폭에 맞춰 나란히 또는 위아래로 표시된다. 가상 데이터를 사용한 정적 설계 도해다. 브라우저 동작·실제 기기·사용자 성과 시험은 수행하지 않았다.
왼쪽은 전체 준비율 88%, 예정 100상자, 부족 12상자를 각각 크게 보여준다. 숫자는 맞지만 어느 출고를 먼저 확인해야 하는지 알려면 요약 카드 아래의 표까지 내려가야 한다. 오른쪽은 B의 부족 10상자와 마감 14:30을 하나의 영역에 묶었다. 기준 시각이 14:00이므로 남은 시간은 30분이다.
B의 준비율은 20 ÷ 30 × 100 ≈ 66.7%다. 예상 완료 시각이나 작업 속도는 제공되지 않았으므로 ‘지연 확정’ 대신 ‘먼저 확인’이라고 표시했다. 준비율이 낮다는 사실과 기한을 넘길 것이라는 예측은 서로 다른 주장이다.
강조의 대가: 전체 준비율 88%의 시각적 비중은 작아진다. 전체 실적을 보고하는 회의라면 이 순서가 최선이 아닐 수 있다. 여기서는 먼저 확인할 출고를 찾는 과제가 있으므로 대상과 기한을 앞세웠다. A와 C는 같은 열 구조의 표에 남겨 다른 출고와의 비교를 유지했다.
다음 화면에 필요한 것: B 상세에는 준비 20상자·예정 30상자·부족 10상자·마감 14:30을 같은 기준으로 보여주고, 알 수 없는 예상 완료 시각은 ‘제공되지 않음’으로 남겨야 한다. 목록 복귀 시 날짜·당일 출고·전체 출고처 조건과 초점 위치를 유지하는 것이 설계 요구사항이다.
이 본문 도해는 정보 순서를 비교하는 정적 설계안이다. 도해의 버튼 표시는 조작할 수 없으며, 상세 진입과 복귀의 실제 동작은 검증하지 않았다. 검증할 때는 같은 과제에서 B의 수량과 마감을 찾는지, 상세를 확인한 뒤 같은 조건의 목록으로 돌아오는지 살펴본다. 판단 시간이나 실제 출고 지연의 개선 효과는 아직 측정하지 않았다.
표를 유지할 때와 카드로 바꿀 때
여러 출고를 같은 열 기준으로 비교한다면 표가 유리하다. 출고처, 부족량, 마감처럼 판단에 필요한 열을 먼저 보이고 부가 항목은 상세로 연결한다. 부족량 정렬과 마감 정렬은 서로 다른 질문이므로 현재 정렬 기준을 표시한다. 열을 숨길 때는 값을 버리는 것이 아니라 접근 경로를 남긴다.
반면 한 출고의 주소·담당·진행 메모처럼 속성 묶음을 읽는다면 세로 상세나 카드가 자연스럽다. 모든 행을 카드로 바꾸면 같은 수치가 서로 다른 위치에 놓이고 상자 하나를 비교할 때마다 긴 설명을 건너뛰게 된다. 비교 화면과 읽기 화면의 목적을 분리해야 한다.
꼭 넓은 표가 필요하면 표 영역 안에서 가로 이동을 제공하고 어떤 열이 더 있는지 알 수 있게 한다. W3C의 리플로우 설명은 세로 콘텐츠를 320 CSS 픽셀에 해당하는 폭에서 정보·기능 손실과 양방향 스크롤 없이 제시하도록 설명하며, 의미상 2차원 배치가 필요한 데이터 표 등에는 예외를 둔다. 그 예외가 주변 설명과 화면 전체에 자동 적용되지는 않는다.
필터와 돌아오기 동작도 같은 화면의 일부다
B를 열었다가 목록으로 돌아왔을 때 날짜가 오늘로 초기화되거나 정렬이 바뀌면 사용자는 방금 본 값의 맥락을 잃는다. 선택한 기간, 필터, 정렬, 필요한 경우 목록 위치를 복원하는 조건을 명세에 적는다. 새로고침이나 공유 링크에서는 무엇을 유지할지도 구별한다. 특정 저장 방식 하나가 모든 상황의 정답은 아니다.
필터 결과가 0건이면 “출고 없음”과 “현재 조건에 맞는 출고 없음”을 구분한다. 데이터를 가져오지 못했다면 빈 목록 대신 오류와 재시도 경로를 제공한다. 조건을 바꾸는 동안 과거 수치를 유지할 경우 조회 중 상태와 이전 값이라는 사실을 표시해 새 기간의 결과로 오해하지 않게 한다.
터치 크기와 고정 영역은 실제로 확인한다
WCAG 2.2의 최소 타깃 크기 설명에는 포인터 타깃의 24 × 24 CSS 픽셀 기준과 간격·인라인 등 예외가 있다. 이 숫자가 모든 상황에서 충분한 사용성을 보장하지는 않는다. 핵심 버튼은 더 넉넉한 영역으로 설계하고, 아이콘 그림 크기와 실제 눌리는 영역을 구분해 검사한다.
상단 필터와 하단 행동 버튼을 모두 고정하면 작은 화면의 읽기 영역이 사라질 수 있다. 긴 한글 라벨, 글자 확대, 가상 키보드가 열린 상태에서 본문과 포커스가 가려지는지 확인한다. 작업 완료 후 피드백과 실패 시 재시도도 필요하다. 단순히 버튼이 보인다는 사실과 업무가 완료된다는 사실은 다르다.
개발 전에 합의할 5가지 체크리스트
- 첫 번째 판단을 한 문장으로 적고, 그에 필요한 대상·수치·기한을 앞에 배치했는가?
- 비교가 필요한 곳은 표를 유지하고 상세 읽기와 분리했는가?
- 필터·정렬·상세 진입·뒤로가기·새로고침의 상태 유지 규칙이 있는가?
- 320 CSS 픽셀 상당 폭, 글자 확대, 긴 라벨, 터치 타깃을 확인할 계획이 있는가?
- 빈 결과·로딩·오류·권한 부족에서도 다음 행동을 알 수 있는가?
위 표와 정적 비교 도해는 설계 논의를 위한 예시다. 실제 모바일 기기, 상세 열기·복귀 동작, 키보드, 보조 기술로 검증한 결과가 아니다. 구현 후에는 ‘B 출고를 찾아 부족량을 확인하고 목록으로 돌아오기’라는 과업으로 수치, 조회 조건, 읽기 순서와 초점 복귀를 확인해야 한다. 다른 제품에는 그 사용자의 과업을 기준으로 순서를 다시 정한다.
과업과 KPI부터 정하려면 KPI 대시보드 설계 전 결정할 다섯 가지를, 주의·선택·초점의 표시를 나누려면 대시보드 색상의 역할 구분을 함께 읽을 수 있다.