Communitygithub.com

ShortArrow/interface-design

画面の見た目と振る舞いを、既存の標準や測定可能な基準に照らして決定するスキル。色、サイズ、配置などを「好み」としてユーザーに問う前に使用します。

interface-design とは?

このスキルは、UIデザインの意思決定を主観や「好み」ではなく、WCAG 2.2などの公開された標準と測定値に基づいて行うためのものです。開発者が「このレイアウトはどう見えますか?」と尋ねる前に、コントラスト比、ターゲットサイズ、リフロー幅、情報順序などを自動的にチェックし、基準を満たしているかどうかを報告します。対応プラットフォームは、Claude CodeやClaude in Chrome(ブラウザ操作機能を含む)などのAIエージェント環境です。スキルは、axe-coreやLighthouseを使ってアクセシビリティを評価し、その結果(約57%の自動検出率であることなど)を正確に伝えます。最終的にユーザーに問い合わせるのは、(1) まだ未確定の市場や視聴者、(2) ブランドの制約、(3) 密度と読みやすさなど、測定済みの両面のトレードオフ、の3種類だけです。これにより、エージェントが自ら決定できる範囲を広げ、ユーザーの注意を真に価値のある判断に集中させます。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ShortArrow/skills/tree/HEAD/skills/interface-design

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

インターフェースデザイン

画面に関する質問は、好みに関する質問ではありません。 コントラストには比率があり、ターゲットにはサイズがあり、 リフローにはまだ機能しなければならない幅があり、 レイアウトには、読者が最初に何をするかによって決まる情報順序があります。 これらは測定と公開された標準によって決定されるため、 「どちらが好みですか」とユーザーに委ねることは、エージェントの仕事であったはずのことにユーザーの注意力を費やさせることになります。

測定後に残るのは真の質問であり、 このスキルはその残りを小さくし、それに証拠を添付するために存在します。 own-the-call は、それがどのように質問されるかを規定します。

このスキルが置き換える場面

しようとしていたこと…代わりに…
色、サイズ、間隔、配置のうちどれが好みかをユーザーに尋ねる以下の標準に照らして測定する。どの閾値も決定できない場合のみ尋ねる
視覚的な選択を主観的だと決めつけるそれが不合格または合格となる基準(コントラスト、ターゲットサイズ、リフロー幅、フォーカスの可視性、情報順序)を挙げる
「見た目は問題ない」と言うそれを開き、スクリーンショットを撮り、どのビューポートで何を測定したかを述べる
コントロールのサイズを目視で決める24×24 CSS px はWCAG AAの最低基準。デザインシステムがより厳しい値を設定している場合もある(Material: 48dp)
パレットから色を外見で選ぶ比率を計算する: 本文テキストは4.5:1、大きいテキストと非テキストは3:1
1つのウィンドウサイズで確認したレイアウトをリリースする幅320 CSS px、高さ256 CSS pxでもリフローが機能することを確認する
axeの実行結果がグリーンだからアクセシブルだと読むaxeが見つけられるのは約57%。残りはキーボード操作、フォーカス順序、意味
デザインシステムで既に定義されているコンポーネントを設計するそちらを採用し、どのコンポーネントかを明示する
図の描き方を尋ねる読者が最初に何をたどるかから決定し、次に1つのレンダリングを示す

質問する前に標準から決定する

大半の回答は4つの団体が提供しており、 それらは完全には一致しません。異なる場合は、より厳しい数値を満たすべきです。 なぜなら、それを満たせば両方を満たすことになるからです。

WCAG 2.2 は最低基準であり、規範的です。W3C勧告であり、ISO/IEC 40500でもあります。 目標レベルはAA。AAAはすべてのコンテンツで達成可能ではなく、W3Cもそう述べています。

基準レベル閾値
1.4.3 コントラスト(最小)AAテキスト4.5:1、大きいテキスト(18pt以上、または14pt太字)は3:1
1.4.11 非テキストのコントラストAA隣接する色に対して3:1
1.4.4 テキストのサイズ変更AA200%で使用可能
1.4.10 リフローAA幅320 pxまたは高さ256 pxで2軸スクロールがないこと
1.4.12 テキストの間隔AA行間1.5倍以上、段落間2倍以上、文字間0.12倍以上、単語間0.16倍以上のフォントサイズ
2.4.7 フォーカスの可視性AAフォーカスインジケーターが表示されるモードがあること
2.4.11 フォーカスの非隠蔽AAフォーカスされたコントロールが完全に隠れていないこと
2.5.8 ターゲットサイズ(最小)AA24×24 CSS px、または24 pxの間隔
2.4.13 フォーカスの外観AAA2px以上の外周、フォーカス時と非フォーカス時で3:1
2.5.5 ターゲットサイズ(拡張)AAA44×44 CSS px

デザインシステム は、WCAGが未確定のままにしているものを決定します。スペーシングスケール、タイプスケール、コンポーネントの構造、色の役割などです。 そのコンポーネントを採用することは近道ではなく、決定そのものです。そして、それはすでに行われたアクセシビリティ作業を引き継ぎます。 Material Design 3 は48×48 dpのタッチターゲットを設定しており、WCAGの24 pxより厳しく、 色は固定の16進数ではなく役割(primary、on-primary、surface)として選択するよう求めています。 これにより、テーマ変更やダークモードが追加の決定なしに機能します。 日本の公開向け業務では、デジタル庁デザインシステム(design.digital.go.jp、β版としての生きた標準)がコンポーネント、 ガイダンス、トークンを提供しており、トークンとサンプルコンポーネントはGitHubでMITライセンスで公開されています。

axe-core は測定可能なものを測定し、自身の限界を明示しています。 平均でWCAG問題の約57%です。 したがって、グリーンの実行結果は質問の57%に関する証拠であり、 その数値なしに「axeに合格した」と言うのは誇張です。measured-claims は他の数値と同様にこの57%にも適用されます。

npx @axe-core/cli http://localhost:5173 --tags wcag2a,wcag2aa,wcag22aa
npx lighthouse http://localhost:5173 --only-categories=accessibility --quiet

Lighthouseのアクセシビリティスコアは、同じエンジンに数字を付けたものです。 その監査はaxe-coreのルールであり、それぞれがDequeのルールページにリンクしているため、57%の制限を継承します。 そして、スコアは誤読される2つの方法を追加します。 それは加重平均であり、 axeのユーザー影響評価に基づいて重みは3から10、 手動監査とベストプラクティス監査はスコアから完全に除外されるため、 演算では人間が確認しなければならない部分に到達できません。 各監査も二値的です。 ラベルがないボタン1つで「ボタンにはアクセシブルな名前が必要」が即座に不合格になり、部分点はありません。 したがって、100は「加重された自動サブセットに合格した」ことを意味し、 完璧なスコアの正直な報告はそう述べるべきであり、「アクセシブル」とは言うべきではありません。 修正すべき項目のランク付けされたリストにはこれを使用し、 発見事項がランキングよりも重要な場合はaxeのJSONを使用してください。 Lighthouseのパフォーマンスカテゴリはweb-perfの管轄であり、このスキルの管轄ではありません。

どちらも見ることができないもの: フォーカス順序が読み取り順序に従っているか、ラベルがそれが示すものを正しく命名しているか、 アイコンの意味が色なしでも残るか、レイアウトの情報順序がタスクと一致しているか。 これらは人間が読み取るものであり、その人間はエージェントであり得ます。

見てから、見たものを伝える

観察を伴わないインターフェースの主張は、measured-claims の噂が別のメディアで語られているようなものです。 ホストにはブラウザがあるため、観察は可能です:

mcp__claude-in-chrome__navigate      → ページへ移動
mcp__claude-in-chrome__read_page     → 構造、見出し、ラベルを読み取る
mcp__claude-in-chrome__computer      → 指定されたビューポートでスクリーンショット
mcp__claude-in-chrome__resize_window → 320 pxにリサイズしてリフローをテスト

発見結果とともにビューポートを報告してください。 「見た目は問題ない」は幅も測定も示していません。 「320 pxで2列目が1列目の下に回り込み、横スクロールは発生しない」は、誰かが確認できる読み物です。 キーボード順序はTabキーで移動して観察された順序として報告します。 それがaxeがカバーしない半分だからです。

情報順序は導出されるものであり、選択されるものではない

何がどこに行くかは、読者がそれをどう扱うかによって決まります。 これはreader-mapの質問を画面に適用したものです。誰が来るのか、何をしに来たのか、最初に何が必要なのか。 セットアップ時に一度だけ使うコントロールと、毎分使うコントロールは、同じ場所を争いません。

したがって、「これはどこに置くべきか」という質問には、3つの位置を列挙するのではなく、タスクを指定することで答えます。 2つのタスクが本当に競合し、どちらも支配的でない場合、 それが尋ねる価値のある残りの部分であり、競合するタスクを名前付きで、 隅の選択肢としてではなく尋ねられます。

同じことが図にも当てはまります。 読者が最初に何をたどるかがフローの方向を決定し、 形状はそのたどりに従い、 1つのレンダリングが3つの記述ではなく示されます。

本当にユーザーのもの

測定を生き残る3つのもの:

  • インターフェースが提供する対象者または市場(まだ確定していない場合) — どの標準を適用するかを決定します(規制市場の場合はregulated-claims)。
  • ブランドの制約 — 必須の色、書体、またはマーク。 制約はユーザーのものですが、それが4.5:1を満たすかどうかは依然として測定され、 不合格のブランドカラーは比率と最も近い合格バリアントとともに報告されます。
  • 両側で既に測定されたトレードオフで、証拠が決定しないもの。密度とスキャン容易性、 1画面と2画面など。 両方の測定結果を添付して尋ねる場合、それはown-the-callが認める質問です。

それ以外のすべて — コントラスト、間隔、ターゲットサイズ、フォーカス、リフロー、 コンポーネントの選択、図の形状、 タスクに従った配置 — は決定され報告されます。

チェックリスト

  • コントラストは目視ではなく計算: テキスト4.5:1、大きいテキストと非テキスト3:1
  • インタラクティブターゲットは24×24 CSS px以上、 またはデザインシステムのより厳しい値
  • 幅320 px、高さ256 pxで2軸スクロールがないことを確認
  • すべてのインタラクティブ要素にフォーカスが可視であり、隠蔽されていない
  • Tab順序を実際に操作して観察された順序で報告
  • コンポーネントはデザインシステムで定義されている場合はそれを採用し、名前を明示
  • axeまたはLighthouseを実行し、57%の限界を暗黙的ではなく明示的に記載
  • Lighthouseのアクセシビリティスコアは「加重された自動サブセット」として報告し、決して「アクセシブル」としては報告しない
  • すべての外観に関する主張は、それが観察されたビューポートを伴う
  • ユーザーに残す質問は上記の3種類のみで、証拠を添付する

他のスキルとの関係

own-the-call はこのスキルを生き残った質問の形状を決定します。 画面に関する質問のほとんどはそこに到達すべきではありません。 reader-map は、このスキルが配置に適用するタスク順序を提供します。 measured-claims はここでのすべての比率とパーセンテージ(57%を含む)を規定します。 document-structure と cognitive-rhythm はページ上の散文を担当します。 このスキルはその周囲のフレームを担当します。 any-screenshot はブラウザ外で画面をキャプチャする方法です。 読み込みと操作速度、Core Web Vitals、Lighthouseのパフォーマンススコアは、cloudflare プラグイン内の web-perf に属します。 このスキルはLighthouseのアクセシビリティカテゴリのみを扱います。

出典

  • W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C勧告、2024年12月12日付 (www.w3.org/TR/WCAG22/): 4原則、A/AA/AAAレベル、 および4.1.1 構文解析の廃止。
  • W3C, "How to Meet WCAG 2.2 (Quick Reference)" (www.w3.org/WAI/WCAG22/quickref/): 上の表のすべての閾値、 レベルAAAで読み、2.4.13と2.5.5を含む。
  • Deque Labs, axe-core README (github.com/dequelabs/axe-core): MPL-2.0; WCAG 2.0、2.1、2.2のA、AA、AAAにマッピングされたルール; 「平均してWCAG問題の57%を自動的に発見できる」。
  • Chrome for Developers, "Accessibility scoring in Lighthouse" (developer.chrome.com/docs/lighthouse/accessibility/scoring): スコアは加重平均、重み3から10、 「axeのユーザー影響評価に基づく」、 各監査はDeque Universityのaxe-core 4.11ルールページにリンク; 各監査は二値的; 手動監査と影響の少ない監査はスコアから除外されます。 このページ自体は、完璧なスコアがページがアクセシブルであることを意味すると述べていません — その逆も述べていませんので、 上記の警告はこのスキルのものです。
  • デジタル庁デザインシステム (design.digital.go.jp): v2.18.2、 生きた標準という意味でβ版と表示されています。 サイトにはWCAGレベルもJIS X 8341-3の目標も記載されていません。 digital-go-jp/design-tokens、 design-system-example-components-react、-html はGitHubでMITライセンスです。
  • Material Design 3の48×48 dpのタッチターゲットと色の役割に関するガイダンスは、m3.material.ioを引用する二次情報源から取得したものであり、 そのサイトから直接取得したものではありません。同サイトのページはスクリプトでレンダリングされるため、ここでは読み取れませんでした。 48 dpという数値はデザインの推奨事項であり、 プラットフォームによって強制される最低基準ではありません。

これらの出典が一致せず、より厳しい数値を満たすべきであるという主張は、 公開されたいずれの立場ではなく、このカタログ所有者の読み解きです。

上記のコマンドは、このスキルの作成中には実行されていません。 どちらも初回使用時にパッケージを取得し、 ここでのサンドボックスは新しくダウンロードされたコードの実行を拒否します。 フラグは実行結果ではなく各ツールのドキュメントから来ているため、 プロジェクトでの初回使用は呼び出しの最初のテストでもあります。

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

ShortArrow/library-design

Designing a library — a published package, or an in-app module from the moment it has a second consumer. The implementation stays editable forever, while the public API, the dependency set, the performance characteristics and every observable behaviour freeze at first external use (Hyrum's law). Five duties to the caller: take no control, add no hidden cost (zero-cost abstraction as the bar), hold no hidden state, hide no failure, block no escape. Use when designing or reviewing a public API, when extracting shared code into a module, when asked to "make this reusable", when a signature-compatible change alters an observable behaviour, and when an application is being shaped around a framework's types and lifecycle.

ShortArrow/test-design

Deriving test cases, triggered by the moments that produce weak ones: about to write a test list that is the happy path restated, about to derive tests by reading the implementation they check, about to test the bound the specification names and not the other one, about to enumerate the roles the specification lists and skip the caller it forgot, about to vary one condition at a time from the happy path, about to draw a state or decision table without tying each row to a test, about to write an expected result with "or" in it, about to skip the error paths as unlikely, about to leave a path unimplemented and untested, or about to grade a suite as adequate by reading it. A test derived from the implementation passes by construction; coverage counts classes, not tests. Use when writing a test plan or list, when a use case is the specification in hand, when adding tests to existing code, when reviewing a suite for gaps, and when a suite is all green and proves little.

関連スキル