Digital Agency Design System (DADS) DESIGN.md

Design System Inspiration of Digital Agency Design System (DADS)

Overview

Visual Theme & Atmosphere

The Digital Agency Design System (デジタル庁デザインシステム, DADS) brings together design language, UI components and usability/accessibility guidance for public websites and services. Its publisher, Japan's Digital Agency (デジタル庁), makes the system available to both public and private users. The agency's stated mission is digitalization that leaves nobody behind. Official overview, DADS introduction.

The live documentation site gives that work a clear visual expression: a white canvas (#ffffff), dark prose (#333333), underlined deep-blue resource links (#00118f), and rounded cards bounded by grey hairlines (#949494). The compact blue search button (#0017c1) stands beside a white search field in the fixed left sidebar. At the measured desktop size, the button and input are 48px high; the introduction card has a 16px radius and 24px padding. Black-and-yellow keyboard focus is a prominent part of the visual language. These observations describe the documentation site captured on 2026-11-02.

The current guidance describes DADS as a platform design system: adopters define a local design system around their own organization or service. The supplied colors, sizes, spacing and corner shapes are starting values based on the Digital Agency website, and can be edited while preserving the accessibility structure. This makes the reference useful both for reproducing the documentation site's appearance and for understanding which choices the platform leaves to its adopters. Platform guidance, local design-system guidance.

The live title carries v2.18.2. The homepage records Figma v2.18.2 and documentation updates on 2026-10-21, and explains “β版” as a living standard. Its visible structure combines an introduction, system resources, content cards and dated release information. Homepage, document updates.

Primary tasks supported by the opened pages are finding guidance through navigation or search, reading component overview/usage/accessibility pages, and locating Figma data or HTML/React examples. The guidance also describes the system as shared material for communication among designers, developers and other stakeholders. Resources, platform guidance.

Brand Narrative

The Digital Agency was established on 2021-09-01, as its site policy states. It describes its work as advancing digital transformation and creating services from the public's perspective. Its contact address is in Tokyo. Site policy, organization.

The design-system history records the first Figma publication in November 2022. A dedicated DADS site launched on 2024-05-30 to make the guidelines easier to consult. In October 2026, the documentation expanded its account of platform and local design systems, then added usage guidance to multiple components on 2026-10-21. The visible beta label expresses continuing improvement and research/practice in the system's own description. History, launch notice, updates, platform guidance.

The published materials have distinct licensing arrangements. The notices direct documentation users to attribution/editing instructions and the agency's copyright policy. They identify CC BY 4.0 for Figma Community design data and MIT for GitHub code snippets, with separate treatment of included assets. The resources page links plain HTML/CSS/JavaScript examples and React/Tailwind CSS examples, plus a token-based Tailwind plugin. Notices, resources.

Principles

The first-party guidance names three aims: accessibility first, broad applicability and usefulness for administrative organizations, and continuous, sustainable improvement through research and practice. It explains that reusable primitive information elements support customization and that beta labeling carries the intention to keep improving. Platform guidance.

The local-system guidance turns those aims into constraints on adaptation: retain semantic color meanings, preserve focus indicators and accessibility implementation, maintain the specified contrast requirements, and keep reading-text line height at least 1.5. Colors, spacing and shapes can then express the adopting service's own design policy. Local design systems.

Personas

No first-party individual personas were verified. The opened material addresses public-service organizations and their design/development stakeholders; the resources page also points administrative officers and businesses beginning accessibility work to an introductory guide. Platform guidance, resources.

Colors

The homepage census contains 178 computed root properties and 190 declared custom properties. Its palette is first-party: ten primitive hue ramps, neutral ramps and semantic aliases. The values below distinguish observed uses from palette availability. The full raw list is retained in the research report.

The general palette supports more than the blue used by this documentation site. The color guidance defines key, common and semantic colors; semantic hue/meaning relationships must be preserved when adapting a service. The local-system guidance permits changing key colors and using link hues other than blue while preserving its accessibility requirements. Color guidance, palette, local design systems.

The paragraph census is mixed: #333333 appears five times, black five times and #666666 once. The measured introduction card makes the distinction concrete: its link inherits #333333, its heading is #00118f, and its visible description is black. Preserve these roles when reproducing that card.

Typography

Official product use. The typography guidance adopts Noto Sans JP for proportional text and Noto Sans Mono for monospaced text. It identifies the fonts as open source under SIL Open Font License 1.1 and supplies CSS and Google Fonts examples. It explicitly allows OS/device-native fonts and acknowledges that user agents can change the displayed face. Typography guidance.

Live-loaded. Both surveys list Noto Sans JP 100 900 normal and Noto Sans 100 900 normal in loaded faces. Body, H1 and button declarations use "Noto Sans", "Noto Sans JP", sans-serif. The page links a Google Fonts stylesheet requesting Noto Sans JP and Noto Sans Mono. The census could not read that cross-origin stylesheet's rules, so the exact font file selected by the capture browser is unresolved.

Official distributed assets. The opened first-party stylesheet embeds a variable Noto Sans WOFF2 data URL restricted to unicode-range: U+3B2 (the beta character). The site's notices identify subsetted Noto Sans data and its SIL license. This is a narrowly scoped distributed font asset. Live stylesheet, notices.

Declared-only on these surfaces. Noto Sans Mono is named in --font-family-mono and officially documented for pre/code, but neither survey reports it loaded. Its documented role is retained here without a live specimen. The capture's per-control family field reports the first stack member, Noto Sans; it does not establish a face separately for every glyph.

Unresolved. Exact per-glyph font selection and consistent rendering across other government devices were not measured. Substitute: none chosen.

The official scale distinguishes regular 400 and bold 700, normally uses at least 16 CSS px for body/UI, and recommends at least 1.5 line height for reading text. It includes display sizes as well as standard, dense, oneline and mono styles. It also defines letter spacing rather than prohibiting it; measured values include 0.32px on the 16px buttons and 0.34px on the 17px card/link. Typography guidance.

Layout

At 1440×1000 the documentation homepage has a fixed left sidebar, measured at 289px including its boundary, with the site title, search and vertical navigation. Main content begins to its right. The introduction and guidance cards share a row, followed by further content cards. On the button overview, a separate sticky table of contents sits beside the document. Both layouts are visible in the captures; they are not a horizontal desktop header.

The stylesheet defines the card grid as repeat(auto-fit,minmax(min(22rem,100%),1fr)) with a 2rem gap. Its card padding is 1.5rem at the measured desktop width. Main-content and table-of-contents dimensions have their own --common-* properties. Live stylesheet.

The prior spacing values remain useful as observed or declared values, rather than a mandatory global scale:

Rem equivalents use the 16px UI reference corroborated by the captures. The spacing guidance presents 8 CSS px as a commonly used base and gives an 8/24/64 example. It says absolute spacing values are not prescribed and tokenization is optional. Consistency and expressing relationships between content are the stated concerns.

Measured corner values are 0px for the sidebar/resource links, 8px for the filled/outline/input controls, 16px for the card, and 4px on the focused resource link. The corner-shape guidance provides five broad styles and calls for component-specific adjustment according to size and proportion.

Responsive Behavior

Browser captures cover desktop 1440×1000 only. The following responsive facts are first-party documentation or stylesheet declarations, rather than measurements at additional widths:

The measured 48–56px action heights, 8px control radii and 16px card radius are desktop observations. The card's 1rem radius is declared outside a breakpoint. Layout guidance, live stylesheet.

Elevation & Depth

The measured controls have box-shadow: none at rest. Borders and white/grey surfaces do much of the visible grouping on these documentation pages. Keyboard focus adds a yellow shadow to these controls; it is part of their focus indicator.

The wider system documents eight elevation shadow variables. For example, --elevation-1 is 0 2px 8px 1px #0000001a, 0 1px 5px 0 #0000004d. These alpha colors belong to the shadow definition. The elevation guidance explains both drop shadows and overlay shading, treats level 0 as the default, and assigns higher levels to overlay components. It also requires sufficient boundary contrast independently of the shadow. Use its elevation model when the UI's structure benefits from it; a flat rest-state card does not establish a system-wide prohibition.

Values kept in prose

Measured values the DESIGN.md token grammar cannot carry, kept verbatim:

• shadow.none: none

Motion & Easing

All six measured controls report the exact computed transition all 0s ease 0s. Their captured style changes therefore provide no nonzero transition duration or authored timing curve to reuse. Disclosure expansion, page transitions and dialog motion were not measured.

The opened stylesheet includes a prefers-reduced-motion:reduce rule that disables animations on progress-indicator spinner/linear elements and their descendants. This is a scoped declaration; a universal transition-collapse rule was not established. Live stylesheet.

Components

Six specific controls were measured at 1440×1000 with real pointer hover/press and keyboard Tab focus. All have authored changes; none of the recorded focus changes persisted after blur. Navigation and resource controls below are links.

The filled search control darkens and gains an underline on hover. The outline link changes its fill, text, border and arrow together. The Figma resource link keeps an underline and changes color through rest, hover and press. The card changes background and underlines its description. Full state values appear in §14.

Published roster. The opened component index still has 49 unique component destinations. The names are retained in the Japanese used by the index; this roster does not supply measured specifications for those components:

アコーディオン, イメージスライダー, インプットテキスト, カルーセル, カード, コンボボックス, スイッチ, スクロールトップボタン, ステップナビゲーション, セレクトボックス, タブ, チェックボックス, チップタグ, チップラベル, テキストエリア, テーブルコントロール, テーブル／データテーブル, ディスクロージャー, ディバイダー, ドロワー, ノティフィケーションバナー, ハンバーガーメニューボタン, パンくずナビゲーション, ファイルアップロード／ドロップエリア, プログレスインジケーター, ヘッダーコンテナ, ページナビゲーション, ボタン, ボトムナビゲーション, メガメニュー, メニューリスト, メニューリストボックス, モバイルメニュー, モーダルダイアログ, ユーティリティリンク, ラジオボタン, ランゲージセレクター, リソースリスト, 引用ブロック, 日付ピッカー／カレンダー, 検索ボックス, 水平メニュー, 注釈ブロック, 画像, 目次, 箇条書きリスト, 緊急時バナー, 見出し, 説明リスト

No informational-chip or field-error specimen was measured.

States

Standard exterior focus indicator, measured on the filled button, outline link, input and card: outline: 4px solid #000000, offset 2px, plus box-shadow: 0 0 0 2px #ffd43d. Each is an authored solid outline, and its focus changes clear after blur.

All pointer captures actually matched :hover; pressed captures also matched :active. The probe compared the controls, pseudo-elements, descendants and three ancestor levels, including the navigation/outline SVGs. This is a DOM/computed-style scope; it does not prove absence of changes in canvas, inaccessible frames, closed shadow roots or sibling elements.

The stylesheet additionally declares a hover underline-thickness change from .0625rem to .1875rem for prose resource links and card titles. The probe's decoration string does not measure thickness; these are declared values from the live stylesheet.

Empty, loading, request-error, form-validation, success, skeleton and disabled presentations were not measured.

Do's and Don'ts

• Use the measured blue pair for this site's filled actions and resource links, including the darker pressed fill and orange resource-link press.
• Preserve underlines and the black/yellow keyboard indicators. The local-system guidance explicitly says the supplied focus indicator must not be changed.
• Keep 17px/1.7 reading text separate from the denser one-line control and navigation metrics.
• Reproduce the measured 8px control and 16px card radii when recreating these documentation controls.
• Preserve semantic hue/meaning relationships and the local guidance's text/background and non-text contrast requirements when adapting the palette.
• Define an adopter's local design system before customizing components; the guidance permits changing key color, spacing and corners within its accessibility requirements.

These directions follow the six controls and local design-system guidance. Avoid treating a homepage color, font choice, corner range or flat rest state as a universal rule for every adopting service.

Voice & Tone

The sampled copy uses descriptive Japanese section names and short action labels. Navigation includes “はじめに”, “ガイダンス”, “基本デザイン”, “コンポーネント” and “リソース”; the measured submit label is “検索”. The homepage's “デジタル庁デザインシステムの構成” and “本ウェブサイトのコンテンツ” introduce explanatory sections. Its title openly includes the beta status, while the sidebar adds v2.18.2. Homepage.

The component overview distinguishes overview, usage and accessibility content. Release notes attach dates and revisions to changes. This supports a functional, explanatory reading of the sampled voice. The platform guidance leaves organization-specific brand and communication policy to the adopter; no official forbidden-register list was verified. Button overview, updates, platform guidance.

Agent Prompt Guide

For a documentation page based on the measured surface:

• “Use a white canvas with #333333 prose, the officially adopted Noto Sans JP, and 17px/1.7 reading text. Place title, search and 16px/400 navigation in a fixed desktop left sidebar.”
• “Build the 56×48px search button in #0017c1, white 16px/700 text and an 8px radius. Hover uses #00118f with an underline; press uses #000060. Keyboard focus adds a 4px black outline, 2px offset and 2px yellow shadow.”
• “Make a white introduction-card link with a 1px #949494 border, 16px radius and 24px padding. Use a 20px/700 underlined #00118f title and 17px/1.7 black description. Hover and press use #f2f2f2 and underline the description.”
• “Make the previous-page outline link 56px high with 12px 16px padding. Start with #0017c1 text/border on white; hover uses #c5d7fb and #00118f; press uses #9db7f9 and #000060.”

For an adopting service, follow the platform's local-system process and preserve its accessibility structure. Noto Sans Mono retains its official code role without a live specimen in this capture. Substitute: none chosen.