정보 위계

목적

정보 위계는 사용자가 모든 내용을 읽지 않아도 현재 맥락, 중요한 변화, 필요한 행동을 빠르게 찾게 한다. Dot은 정보량을 무조건 줄이지 않는다. 판단 순서에 맞게 묶고, 이름 붙이고, 강약을 정해 복잡함을 읽을 수 있게 만든다.

기본 읽기 순서

대부분의 업무 화면은 다음 흐름을 따른다.

1. 맥락: 어디에 있고 어떤 대상을 보고 있는가?
2. 현재 상태: 정상, 변경 중, 검증 필요, 실패 중 무엇인가?
3. 판단 정보: 지금 결정을 내리는 데 필요한 값과 조건은 무엇인가?
4. 주 행동: 다음에 무엇을 해야 하는가?
5. 세부와 이력: 더 확인하려는 사용자를 위한 근거는 무엇인가?

모든 화면이 같은 모양일 필요는 없지만 이 순서를 역전하려면 명확한 이유가 있어야 한다. 예를 들어 장애 현황에서는 예외 상태가 페이지 설명보다 먼저 읽힐 수 있다.

정보 계층

한 영역에서 1차 계층이 둘 이상 경쟁하면 사용자가 무엇부터 봐야 하는지 알 수 없다. 크고 진한 텍스트, 색, 카드, 아이콘을 동시에 남용하지 않는다.

그룹을 만드는 기준

정보는 데이터 타입이 아니라 사용자 질문으로 묶는다.

• “이 학습 과정은 지금 운영 가능한가?”에 답하는 상태, 일정, 검증 결과는 가까이 둔다.
• “누가 조치해야 하는가?”에 답하는 담당자, 실패 원인, 재시도 행동은 같은 영역에 둔다.
• “무엇을 수정해야 하는가?”에 답하는 필드, 도움말, 오류는 하나의 form section으로 묶는다.
• “왜 이 결과가 나왔는가?”에 답하는 입력, 생성 기준, 검토 이력은 결과와 연결한다.

같은 저장 객체에 속한다는 이유만으로 서로 다른 질문을 한 카드에 넣지 않는다. 반대로 기술적으로 다른 API에서 온 정보라도 하나의 판단에 필요하면 같은 시각 그룹에 둔다.

제목과 레이블

• 페이지에는 하나의 명확한 h1이 있다.
• 섹션 제목은 내용을 나열하지 않고 사용자가 그 영역에서 확인할 질문을 압축한다.
• 레이블은 값의 단위와 의미를 말한다. 상태, 최근 발송, 검증 결과처럼 사용자의 용어를 쓴다.
• 설명은 제목을 반복하지 않고 범위, 영향 또는 판단 기준을 추가한다.
• 제목만으로 구조가 충분하면 구분선과 카드를 추가하지 않는다.
• 제목 계층을 시각 크기만으로 흉내 내지 않고 h1 → h2 → h3 순서를 지킨다.

근접성과 여백

가까운 항목은 같은 의미 그룹으로 인식된다.

• 아이콘과 레이블처럼 강하게 연결된 요소는 4–8px을 사용한다.
• 한 컴포넌트 안의 필드·행은 12–16px을 사용한다.
• 관련 콘텐츠 그룹은 20–24px로 구분한다.
• 페이지 섹션은 32–40px로 분리한다.
• 구분을 위해 border, 배경, 여백을 모두 적용하지 않는다. 여백만으로 충분한지 먼저 확인한다.

목록과 표

반복 데이터는 사용자가 비교하는 축을 먼저 정한다.

• 이름·설명은 왼쪽에 두고 읽기 시작점을 고정한다.
• 상태와 수치는 열 정렬을 유지해 수직 비교를 돕는다.
• 숫자는 단위와 소수점 규칙을 통일하고 tabular-nums를 사용한다.
• 다음 행동은 오른쪽 끝의 안정된 위치에 둔다.
• 가장 중요한 열은 텍스트를 충분히 보여주고, 덜 중요한 메타데이터를 먼저 축약한다.
• 행 전체가 한 상세 화면으로 이동하면 클릭 목적지를 하나로 유지한다. 행 안에 여러 강한 링크를 만들지 않는다.

목록에서 모든 값을 같은 굵기와 색으로 보여주지 않는다. 기본 식별자, 판단 값, 메타데이터의 계층을 분리한다.

폼과 편집 화면

• 한 form section은 하나의 개념만 편집한다.
• label은 control 바로 앞에 두고 description은 입력 전에 필요한 판단 기준을 제공한다.
• 오류는 필드 가까이에 원인과 복구 방법을 함께 제공한다.
• 필수 여부, 단위, 허용 범위를 입력 전에 알 수 있게 한다.
• 자주 수정하지 않는 고급 설정은 기본 흐름 뒤에 둔다.
• 미리보기는 입력과 결과의 관계를 이해하는 데 필요할 때만 병렬 배치한다.

긴 폼에서 모든 섹션을 동일한 카드로 만들지 않는다. 제목, 설명, 여백만으로 구조를 만들고 독립적인 표면이 필요한 영역에만 Section의 surface 표현을 사용한다.

현황과 지표

• 첫 영역은 서비스 상태를 판단하는 최소 지표를 제공한다.
• 정상 수치보다 조치가 필요한 예외를 더 높은 행동 우선순위로 둔다.
• 여러 지표는 독립 카드 묶음보다 MetricStrip처럼 정렬된 셀로 비교한다.
• 지표에는 값뿐 아니라 기간, 기준, 마지막 갱신 시각을 제공한다.
• 차트는 추세나 관계를 판단해야 할 때만 사용한다. 정확한 값 비교가 핵심이면 표나 숫자 목록이 우선이다.

단계적 세부 정보

첫 화면에는 행동을 결정하는 정보만 둔다. 다음 정보는 요청 시 공개할 수 있다.

• 긴 변경 이력
• 시스템 식별자와 원시 값
• 드물게 쓰는 고급 옵션
• 반복되는 설명과 계산 근거
• 지원 담당자를 위한 진단 정보

단, 오류 원인, 위험, 비용, 되돌릴 수 없음처럼 행동을 바꾸는 정보는 접힌 영역에 숨기지 않는다.

Flexible, Link, Glow의 적용

• Flexible: 비교, 작성, 검토처럼 작업이 바뀌면 같은 정보도 표, section, 순차 흐름으로 조정하되 핵심 의미는 유지한다.
• Link: 사람, 데이터, 학습 상태와 이전·다음 행동의 관계를 proximity, 정렬, 일관된 위치로 연결한다.
• Glow: 사용자가 다음 판단을 잃기 쉬운 순간에만 제한된 안내로 사용한다. 정보 계층을 색 효과로 대신하지 않는다.

예외와 피해야 할 사용

• 모든 콘텐츠를 Card로 감싸지 않는다. Card는 독립된 표면이나 경계가 실제 의미를 가질 때만 쓴다.
• 정보마다 아이콘을 붙여 위계를 만들지 않는다. 아이콘은 종류나 상태를 빠르게 식별할 때만 쓴다.
• 작은 회색 글씨에 중요한 조건을 몰아넣지 않는다.
• 색을 텍스트 계층의 유일한 수단으로 사용하지 않는다.
• 페이지 상단에 지표, 공지, 배너, 탭, 필터, 행동을 모두 쌓아 실제 콘텐츠를 밀어내지 않는다.
• 긴 설명으로 구조 문제를 보완하지 않는다. 묶음과 순서를 먼저 고친다.
• 모바일에서 열을 무작정 숨겨 판단 근거를 잃게 하지 않는다.

상태와 접근성

• DOM 순서는 시각적 읽기 순서와 일치해야 한다. CSS로 순서만 뒤집지 않는다.
• 제목을 landmark와 연결하고 반복 영역에는 접근 가능한 이름을 제공한다.
• StatusPill이나 상태 아이콘 옆에는 상태를 설명하는 텍스트가 있어야 한다.
• 표는 열·행 header 관계를 유지한다. 작은 화면에서 목록으로 바꿀 때 레이블을 함께 표시한다.
• 새 오류나 결과가 나타나면 적절한 live region을 사용하되 페이지 전체를 반복해서 읽게 하지 않는다.
• focus 이동은 새로 열린 dialog, 상세 panel, 페이지 제목처럼 맥락이 실제로 바뀔 때만 수행한다.
• truncation된 필수 정보는 키보드와 터치에서도 전체 내용을 확인할 수 있어야 한다.

검토 질문

• 화면을 훑을 때 맥락 → 상태 → 판단 정보 → 행동 순서가 보이는가?
• 가장 강한 제목과 값이 사용자의 핵심 결정에 해당하는가?
• 각 섹션이 하나의 사용자 질문에 답하는가?
• 같은 데이터 객체라는 이유만으로 무관한 정보를 묶지 않았는가?
• 비교해야 하는 값이 같은 축과 형식으로 정렬됐는가?
• 카드·구분선·배경 없이 여백만으로 충분한 곳은 없는가?
• 중요한 조건이 작은 글씨나 접힌 영역에 숨겨져 있지 않은가?
• 제목 계층과 DOM 순서가 보조 기술에서도 의미를 유지하는가?
• narrow layout에서도 핵심 판단 정보가 보존되는가?
• 사용자가 세부 정보를 읽지 않아도 다음 행동을 선택할 수 있는가?
• 정보 구조가 한 학습 고리의 완료와 다음 배움을 연결하는가?