스타일 갤러리뿐 아니라 결정을 정의하세요
디자인 시스템은 스크린샷 그 이상입니다. 섹션 간 간격, 주요 액션 처리 방식, 폼 오류 동작, 성공 또는 실패 후 사용되는 언어 등 반복되는 결정을 기록합니다. USWDS는 타이포그래피, 간격, 색상, 행간, 불투명도 등 값에 대한 개별 팔레트로서 디자인 토큰을 설명합니다. 규칙, 목적, 승인된 변형, 소유자를 문서화하세요. 기초(foundation)와 중요한 여정에서 사용되는 다섯에서 여덟 개의 컴포넌트부터 시작하세요. 모든 페이지를 한 번에 표준화하려 하면 명확성보다 잡음이 생깁니다.
실제로 사이트에서 사용하는 승인된 색상 역할, 서체, 간격, 테두리, 반경, 브레이크포인트, 모션 선택을 기록하세요.
계정 생성이나 검색 결과처럼 반복 가능한 작업 배열에 대해 패턴을 사용하고, 단일 시각적 장식에 대해 패턴을 만들지 마세요.
반복 값 관리를 위해 토큰을 사용하세요
디자인 토큰은 값과 연관된 사람이 읽을 수 있는 이름입니다. Design Tokens Community Group은 토큰을 플랫폼에 구애받지 않는 방식으로 디자인 결정을 표현하는 수단으로 설명합니다. 최소한 토큰은 이름과 값입니다. 템플릿에 원시 값을 흩뿌리는 대신 color-action-primary나 space-section 같은 목적 이름을 사용하세요. 목적 토큰과 기본 값 간의 문서화된 매핑을 유지하세요. 토큰은 조정된 변경을 쉽게 하지만 대비, 브랜딩, 좋은 계층 구조를 자동으로 보장하지 않습니다. 렌더된 조합과 각 페이지 상태를 검증하세요.
모든 예외에 대해 토큰을 만들지 말고 반복되는 선택에 대해 토큰을 만드세요. 그렇지 않으면 토큰 목록이 단지 불일치를 유지하게 됩니다.
널리 사용되는 토큰의 경우 영향을 받는 페이지 목록, 대표 스크린 테스트, 필요 시 마이그레이션 또는 롤백 지침을 기재하세요.
동작과 경계를 가진 컴포넌트를 만드세요
컴포넌트는 시각적 모양만이 아니라 동작을 가진 재사용 가능한 인터페이스 부분입니다. 의미적 구조, 필수 및 선택 입력, 변형, 반응형 동작, 로딩, 비활성, 오류, 비어 있음, 성공 등 모든 관련 상태를 문서화하세요. 키보드 동작과 콘텐츠 가이드도 포함하세요. 모든 레이아웃을 컴포넌트로 강제하지 마세요. GOV.UK는 공유 컴포넌트를 유용성, 고유성, 사용성, 일관성, 다재다능성으로 평가하는데, 이는 어떤 것이 공유 유지 관리를 받을 가치가 있는지를 결정하는 유용한 규율입니다. 널리 재사용되는 컴포넌트는 결함을 널리 확산시킬 수 있으므로 사람들이 실제로 사용하는 페이지에서 테스트하세요.
사용자에게 보이는 각 상태를 나열하고, 실제 레이블, 긴 텍스트, 오류를 보여 구현 한계를 명확히 하세요.
오래된 변형을 명확히 표시하고 교체 항목을 명명하며 영향을 받는 여정을 검토한 후에만 제거하세요.
접근성을 릴리스 조건으로 만드세요
접근성은 반복되는 선택이 장벽을 반복적으로 만들 수 있기 때문에 시스템에 내장되어야 합니다. WCAG 2.2는 Level A에서, 동작 경로가 고유하지 않은 경우를 제외하고 키보드 조작을 요구하며, 순서가 중요할 때 의미 있는 포커스 순서를 요구합니다. 컴포넌트 가이드에 의미론적 컨트롤, 보이는 포커스, 레이블, 논리적 포커스 이동, 오류 식별, 포인터가 아닌 방식의 작업 완료를 포함하세요. 자동 검사 도구를 초기에 사용하고 이후 키보드, 확대, 반응형 및 페이지 테스트로 이어가세요. USWDS는 접근성 있는 컴포넌트가 서비스 전반의 접근성을 보장하지 않음을 경고합니다; 맞춤 코드, 카피, 통합 및 문맥은 여전히 검토가 필요합니다.
사용자가 마우스 없이 컨트롤에 도달, 조작, 이해, 이탈할 수 있는지, 키보드 트랩이 없는지를 확인하세요.
법적 의무는 관할권과 계약에 따라 다릅니다. 준수가 중요한 경우 자격 있는 접근성 및 법률 검토를 받으세요.
콘텐츠 기준을 인터페이스 기준처럼 다루세요
단어는 디자인 후에 덧붙이는 장식이 아니라 컴포넌트의 입력입니다. 액션 레이블, 폼 레이블, 오류, 제목, 링크, 용어, 날짜, 숫자, 약어에 대한 규칙을 설정하세요. GOV.UK 지침은 가능한 경우 능동태와 사용자를 'you'로 직접 지칭하는 것을 선호합니다; 명확하고 일관된 언어 원칙을 사용하되 대상에 맞게 보이스를 조정하세요. 규칙에는 어떤 필드가 필수인지, 합리적 길이 지침, 정보가 없을 때의 동작 등 콘텐츠 모델을 짝지어 두세요. 지침을 컴포넌트 문서와 CMS 워크플로에 두어 편집자가 이를 활용할 수 있게 하세요.
무엇이 실패했는지, 어디에서 발생했는지, 안전하고 유용할 때 다음 행동이 무엇인지 알려주세요.
길이 제한은 재설계나 재작성의 신호이지 필수 의미를 제거해도 된다는 허가가 아닙니다.
시스템이 신뢰보다 빨리 성장하지 않도록 거버넌스하세요
거버넌스는 소유권, 요청, 검토, 릴리스, 폐기를 위한 경량 프로세스입니다. 책임 있는 소유자와 디자인, 엔지니어링, 콘텐츠, 접근성 전문 지식을 가진 검토 그룹을 명명하세요. 증거를 영향 반경(blast radius)에 맞추세요. 로컬 패턴은 문제 진술과 페이지 테스트가 필요할 수 있습니다. 공유 버튼이나 토큰 변경은 영향을 받는 여정, 접근성 검사, 시각적 비교, 마이그레이션 노트, 롤백 지침을 포함해야 합니다. GOV.UK는 기여자에게 컴포넌트가 많은 팀에 유용하고, 중복이 아니며, 대표 사용자로 테스트되었음을 보여 달라고 요구합니다; 이는 보편적 규칙이라기보다 실용적 모델로 사용하세요.
문제, 옵션, 결정, 소유자, 영향 버전, 검토 날짜를 팀이 검색할 수 있는 곳에 저장하세요.
패치, 추가, 호환성 파괴(브레이킹)로 라벨을 붙여 소비자가 마이그레이션과 호환성 기간이 필요한지 알게 하세요.
릴리스 전에 회귀를 방지하세요
시스템을 전달 파이프라인과 연결하세요. 변경 사항이 영향을 미치는 토큰과 컴포넌트를 식별하도록 요구하고, 영향을 받는 상태와 대표 페이지를 테스트하세요. 시각 비교, 상호작용 테스트, 콘텐츠 검토, 접근성 검사는 서로 다른 결함을 찾아냅니다. 트래픽이 많지 않더라도 계정 접근과 문의 양식 같은 영향력이 큰 여정과 트래픽이 많은 여정을 우선하세요. 이것은 Status Is UP의 사전적 가동시간(uptime) 최적화 및 수정 작업을 지원하여 결함 범위를 좁히고 승인된 수정을 검증하기 쉽게 만듭니다. 이는 다운타임 모니터링이나 사고 계획의 대체가 아닙니다.
컴포넌트 버전, 테스트 결과, 발견 사항, 승인 및 수용된 위험을 릴리스 기록에 보관하세요.
이전의 안정된 버전을 보존하고, 저위험 유지관리 중에 복원과 검증 절차를 문서로 테스트하세요.