Communitygithub.com

mickzijdel/data-before-design

데이터 뷰(카드, 패널, 테이블, 대시보드, 보고서, 프로필 페이지)를 구축하기 전에, 이해관계자가 보여줄 내용을 말하거나, 필드가 분명히 유용해 보이거나, 동일한 레코드에 대한 레이아웃이 경쟁하거나, 여러 카드나 차트가 동일한 범주를 다룰 때 사용합니다. 순수한 디자인 프로세스나 게시된 차트의 가독성(practical-charts)을 위한 것이 아닙니다.

data-before-design란 무엇인가요?

이 스킬은 데이터 기반 뷰를 구축하기 전에 반드시 수행해야 하는 3가지 핵심 단계를 정의합니다: 뷰가 지원할 결정을 명명하고, 각 필드의 실제 데이터 프로필을 분석한 후 디자인하며, 여러 레이아웃 옵션을 목업으로 제시하여 선택하게 합니다. 스킬은 Stephen Few의 대시보드 디자인 원칙, Scott Hurff의 UI 스택, Eric Meyer와 Sara Wachter-Boettcher의 실제 사례 연구 등에서 비롯된 통찰을 포함합니다. 주로 Claude Code, Cursor, Codex 등 AI 에이전트와 함께 사용되며, 마크업을 작성하기 전에 데이터의 품질과 맥락을 검증함으로써 '완성되었지만 틀린' 뷰를 방지합니다. 또한, 각 숫자에 비교 대상을 제공하고, 6가지 상태(이상적, 빈, 부분, 로딩, 오류, 완료)를 목업하며, 여러 카드가 있는 페이지에서 통일된 색상 및 레이블 체계를 유지하는 것과 같은 구체적인 렌더링 규칙을 제공합니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mickzijdel/dev-hooks/tree/HEAD/plugins/dev-hooks/skills/data-before-design

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

데이터 우선 디자인

데이터 뷰의 품질을 결정하는 세 가지 요소는 모두 마크업을 작성하기 전에 결정됩니다: 뷰가 지원하는 결정, 필드에 실제로 포함된 내용, 사용자가 원하는 레이아웃. 이 중 하나라도 건너뛰면 완성된 것처럼 보이지만 실제로는 잘못된 뷰가 만들어집니다.

사용 시기

  • 자신이 작성하지 않은 레코드에 대한 카드, 패널, 테이블, 대시보드 또는 세부 뷰
  • 이해관계자가 "X를 보여줘"라고 말하고 X가 컬럼 이름인 경우
  • 필드를 요약, 자르기, 배지, 정렬, 색상 또는 카운트하려는 경우
  • 동일한 정보를 배치하는 두 가지 방법 중에서 선택하려는 경우

데이터가 자신의 테스트 데이터이거나 이미 출력한 단일 값인 경우 건너뜁니다.

게시, 공유되거나 보고서에 포함될 차트나 테이블도 자신이 작성하지 않은 레코드를 표시하는 경우 여기서 시작합니다. 데이터가 확정되면 practical-charts에서 가독성을 다룹니다: 제목, 정직한 축, 하나의 강조된 시리즈, 이미지 내 출처.

단계 0: 결정 명명하기

데이터를 건드리기 전에 한 문장을 작성하세요: "이것을 보는 사람은 ___을(를) 결정하고 있습니다." 문장을 완성할 수 없다면 데이터 덤프를 구축하고 있는 것이며 레이아웃 질문에 대한 답이 없습니다.

  • 모든 필드는 해당 결정을 변경함으로써 그 위치를 얻습니다. 흥미롭지만 결정에 영향을 주지 않는 정보는 카드가 아닌 세부 뷰에 속합니다.
  • 중요성은 결정 가중치를 따르며, 쿼리 편의성을 따르지 않습니다. 가장 가져오기 쉬운 필드가 가장 큰 글꼴을 받을 자격이 있는 것은 아닙니다.
  • 이해관계자가 컬럼을 언급했다면 원하는 데이터를 말한 것이지 결정이 아닙니다. 값에 따라 어떻게 다르게 행동할지 물어보세요.

단계 1: 필드 프로파일링 후 디자인

디자인하기 전에 쿼리하세요. 뷰가 표시할 모든 필드에 대해:

확인 사항디자인이 변경되는 이유
Null이 아닌 개수모든 행에서 NULL인 필드는 카드가 필요 없으며 버그 보고서가 필요합니다
고유 값 수4개의 값은 칩 세트이고, 4000개는 검색 상자입니다
길이: 최소 / 평균 / p95 / 최대평균은 오버플로를 숨깁니다 - p95에 맞게 컨테이너 크기를 조정하고 나머지를 어떻게 처리할지 의도적으로 결정하세요
레코드별 적용 범위레코드의 1.6%에만 표시되는 카드는 드문 예외를 가진 빈 상태입니다
상위 항목당 카디널리티사람당 하나의 메모는 문단이고, 20개는 자체 기능이 있는 목록입니다
날짜 존재 여부날짜가 없는 필드에는 지연 표시를 할 수 없습니다
어휘8가지 표현 방식이 있는 자유 텍스트는 렌더링이 아닌 정규화가 필요합니다
비교 대상 존재맨 숫자는 읽을 수 없습니다 - 아래 참조

디자인을 제안하기 전에 발견한 사항을 숫자로 명시하세요.

화면의 모든 숫자는 비교 대상을 필요로 합니다

52개의 노트는 독자에게 아무것도 알려주지 않습니다: 많은지 알 수 없습니다. 52개의 노트 (중앙값 4)는 발견입니다. 개수, 합계 또는 점수를 표시하기 전에 비교 대상(중앙값, 목표, 이전 기간 또는 나머지 집합)을 찾아 함께 표시하세요. 비교 대상이 없으면 해당 숫자가 화면에 표시되지 말아야 한다는 증거입니다.

극단적인 경우는 절대 변하지 않는 숫자입니다: 모든 레코드에 적용되는 개수는 발견처럼 읽히며 노이즈입니다.

단계 2: 옵션 목업 후 구축

카드 형태의 무엇이든, 실제 레코드에서 여러 정적 목업을 만들어 사용자가 선택하게 하세요. 그 후에만 구축하세요.

  • 각 옵션이 무엇을 최적화하고 무엇을 희생하는지 한 줄로 말하세요
  • 목업은 일회용 HTML이며 컴포넌트가 아닙니다 - 연결하지 마세요

6가지 상태 목업, 하나가 아닌

뷰가 있을 수 있는 모든 상태를 디자인하세요. 각각 실제 레코드에서 가져옵니다:

상태그리기 출처
이상적일반적인 레코드 - 사용자가 선택한 것이 아닌 중앙값에 있는 레코드
빈필드에 아무것도 없는 레코드, 그리고 레코드가 전혀 없는 새 계정
부분일부 필드는 채워지고 일부는 채워지지 않음 - 실제 데이터에서는 예외가 아닌 일반적인 경우
로딩데이터가 도착하기 전에 공간을 차지하는 것, 데이터 크기로
오류가져오기 실패 또는 값이 잘못되어 렌더링할 수 없음
완료뷰가 제공하는 작업이 실제로 발생했음을 확인

그 다음 스트레스 케이스

볼륨 극단(가장 바쁜, 일반적인, 빈)만이 유일한 극단은 아닙니다. 스트레스 케이스는 존재하고, 잘 형성되었으며, 고통스러운 데이터입니다: 필드가 망치는 이름, 상태가 쾌활한 배지를 잘못 만드는 레코드, 요약이 여전히 계산하는 삭제된 계정의 사람입니다. 이 뷰를 가장 당황하게 할 하나의 레코드를 선택하여 렌더링하세요.

한 페이지의 여러 카드: 모두를 위한 하나의 키

독자는 첫 번째 카드에서 색상의 의미를 배우고 이후의 모든 카드에 적용합니다. 따라서 여러 카드가 있는 페이지를 그리기 전에 전체 페이지에 대한 하나의 범주 테이블을 작성하세요: 표준 이름, 고정된 순서, 각 범주에 대한 하나의 색상. 모든 카드, 범례 및 툴팁에서 이를 사용합니다.

  • 하나의 범주, 하나의 색상; 하나의 색상, 하나의 범주. 색상은 해당 범주가 없는 카드에서도 범주에 속합니다. 원래 범주를 표시하지 않는 카드에서도 다른 용도로 다시 사용하면 독자는 둘이 동일한 것이라고 생각합니다.
  • 범주당 하나의 이름. 한 카드에서 "글로벌 보건 및 개발"이고 다음 카드에서 "글로벌 개발 및 보건"이면 독자가 두 개의 범주인지 의문을 품게 합니다.
  • 카드가 동일한 레코드를 자르는 하나의 분류. 카드가 자체 버킷을 추가하기 전에 페이지에 이미 있는 범주로 병합되는지 확인하세요. 카드가 더 세분화된 분할이 정말로 필요한 경우 새 색상이 아닌 부모 색상의 음영을 하위 범주에 제공하세요.
  • 정말로 다른 범주는 사용되지 않은 색상을 얻습니다 (분할이 다르다는 부제와 함께). 페이지가 이미 다른 범주에 할당한 색상을 재사용하지 마세요.
  • 모든 범례에서 동일한 순서, "기타"는 항상 마지막이고 항상 동일한 중립 회색입니다.

완료 조건 페이지 전체의 모든 (레이블, 색상) 쌍을 나열하면 일대일 매핑이 제공됩니다. 렌더링된 스크린샷이 아닌 마크업 또는 스타일시트에서 색상 값을 grep하세요.

데이터에서 나오는 렌더링 규칙

  • 빈 상태는 일을 합니다. "아직 노트가 없습니다"는 막다른 길입니다. 왜 비어 있는지와 무엇이 채우는지 말하세요. 사용자가 첫날에 만나는 빈 상태는 온보딩이며 디자인할 가치가 있습니다.
  • 테이블의 숫자: 오른쪽 정렬, 표 형식 숫자(font-variant-numeric: tabular-nums), 전체 열에 하나의 정밀도, 각 셀에 반복하지 않고 헤더에 단위. practical-charts 규칙 13에 나머지가 있습니다: 그리드 없음, 색조가 있는 키 행, 인라인 막대.
  • 기본 정렬은 디자인 결정입니다. 기본 키 순서로 도착하는 레코드는 정렬이 없는 것입니다.

일반적인 실수

실수결과
스키마에서 디자인컬럼은 존재하지만 데이터는 없음
결정 명명 없이 구축모든 것이 동일한 가중치를 받음, 더 커질 이유가 없기 때문
가장 쉬운 필드에 가장 큰 중요성 부여레이아웃이 작업이 아닌 스키마를 설명
비교 대상 없는 숫자 표시독자가 좋은지 알 수 없어서 보지 않음
항상 참인 것을 카운트절대 변하지 않는 카운트는 발견처럼 읽히며 노이즈
데이터를 보기 전에 작성된 계획 신뢰데이터가 지원하는 것이 아닌 계획이 명명한 것을 구축
이상적 상태만 목업아무것도 없거나 절반만 있는 레코드에서 디자인 붕괴
볼륨 극단만 테스트가장 큰 레코드에서는 버티지만 일반적인 레코드에서 누군가를 당황시킴
먼저 설명된 하나의 옵션만 구축사용자는 보여주지 않은 것을 선택할 수 없음
카드별로 색상과 레이블 선택동일한 파란색이 한 페이지에서 두 가지를 의미하며 독자가 존재하지 않는 연결을 만듦

비직관적인 부분의 출처

  • 결정 우선, 결정 가중치에 따른 중요성 - Stephen Few, Information Dashboard Design
  • 숫자는 비교 대상이 필요함 - Few, 숫자가 의미를 갖게 하는 맥락에 대해
  • 6가지 상태 - Scott Hurff의 UI Stack
  • 스트레스 케이스 - Eric Meyer & Sara Wachter-Boettcher, Design for Real Life

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

관련 스킬