필사 모드: 画面は十文字で書かれます — カスタムウィジェットを作る前に問うべきひとつのこと

• デザインレビューで出たひとつの文
• 二十六文字と十個の要素
• 順位そのものが情報です
• ウィジェットを新しく作るとき実際に捨てるもの
• 契約を破るよくあるやり方四つ
• ウィンドウとポインタが一覧から外れた理由
• 根拠のある規則とはどんな形か
• 今週できること — コンポーネント一覧に文字をつける
• まとめと出典

デザインレビューで出たひとつの文

新しい画面の案に、見たことのない操作単位がひとつ入っています。カードのような見た目で、クリックすると選択され、選択されると枠線がつき、複数選べます。作った人にこれは何かと聞くと、答えはたいていこうです。選択カードです。

このとき出るべき質問はきれいかどうかではなく、これです。これはチェックボックスですか、それともタブですか、それともそれ以外の何かですか。 この質問がなぜ有用なのかがこの記事の内容です。

二十六文字と十個の要素

ヤコブ・ニールセンが2026年7月29日に公開したGUI要素についての記事は、ひとつのたとえから始まります。二十六個のアルファベットがあればすべての英単語を書けるように、十個ほどの要素があればこれまでに出てきたほぼすべてのユーザーインターフェースを組み立てられる、というものです。そしてその十個を、根拠に基づく指針86個とともに整理します。

一覧はこうです。ボタン、入力フィールドとフォーム、メニュー、リンク、ダイアログボックス、通知とエラーメッセージ、アイコン、チェックボックスとラジオボタン、タブ、検索。

最初に見ると平凡です。ここに無いものを作った経験がないから平凡に見えるのです。ところが自分たちのデザインシステムのコンポーネント一覧を出して数えると、たいてい四十から八十が出てきます。十文字のアルファベットで書いた文章になぜ八十個の文字が必要だったのかを説明できなければなりません。

順位そのものが情報です

ニールセンはこの十個をただ並べるのではなく、順序をつけました。基準は利用者の日常的な相互作用がそれぞれにどれだけ懸かっているかです。だから1位がボタンで10位が検索です。

この順序は実務で優先順位表として使えます。チームの時間は有限で、たいてい新しいコンポーネントに偏ります。ところが利用者が一日のうちにもっとも多く触るのは、いつでもボタンと入力フィールドです。ボタンの状態表現、無効である理由の案内、タッチ領域の大きさ、フォームのエラーメッセージの位置といったものが、順位1位と2位に当たる作業です。

逆に言えばこうです。新しく作ったカード型の選択ウィジェットを整えるのに三日を使っているあいだ、ボタンの無効状態がなぜ無効なのかがどこにも書かれていないなら、その三日は順位表の下のほうに使われたことになります。

ウィジェットを新しく作るとき実際に捨てるもの

新しいウィジェットのコストは実装時間ではありません。実装はたいてい一日で終わります。本当のコストは利用者がすでに知っていた契約を捨てることです。

チェックボックスには、利用者が学習を終えた契約がついています。複数選べて、もう一度押すと解除され、ラベルを押してもトグルされ、キーボードでタブ移動したあとスペースでオンになり、スクリーンリーダーが選択状態を読み上げます。この契約は私たちが作ったものではなく、数十年のあいだ数千の製品が同じように動いてきた結果として生まれたものです。

カード型の選択ウィジェットを新しく作ると、この契約が全部リセットされます。もう一度押すと解除されるのかを利用者は知りません。キーボードでアクセスできるかは私たちが別に作らなければなりません。そして作らなければ静かに存在しません。つまり新しいウィジェットの原価は実装一日ではなく、捨てた契約を自分たちの手で建て直すコストの全部です。

だから前の質問が重要です。これがチェックボックスなら、チェックボックスとして実装して見た目だけをカードに変えればよいのです。契約はそのまま残ります。

契約を破るよくあるやり方四つ

一覧の十文字のうちどれなのかを決めたあとでも、その文字の契約を半分だけ破ってしまうことがよくあります。よく見かける形はこうです。

• リンクのように見えてボタンである場合: 下線つきの青い文字を新しいタブで開こうと中クリックしても何も起きません。リンクとボタンの違いは見た目ではなく、移動なのか実行なのかです。
• ボタンのように見えてラジオである場合: 横に並んだボタン三つのうちひとつを押すと残りが消えます。これはラジオボタンの動作であり、押したら何かが実行されると期待した利用者は一拍止まります。
• タブなのにページが変わる場合: タブは同じ文脈のなかで見えている面を変える装置です。タブを押したのに戻るの履歴が積み上がると利用者のモデルが壊れます。
• 通知なのに操作を要求する場合: 通知は通り過ぎてよいもので、ダイアログボックスは答えなければならないものです。数秒後に消えるトーストのなかに取り消しボタンだけがあるなら、その取り消しは見逃されるために作られたものに近いです。

四つには共通の構造があります。見た目でひとつを約束し、動作で別のものを渡します。利用者は見た目を信じます。

ウィンドウとポインタが一覧から外れた理由

ニールセンはウィンドウとポインタを本文の十個に入れず、ボーナスとして別に扱います。理由は、この二つが今ではおおむねオペレーティングシステムの担当になったからだと述べています。

この区別が実務で有用な理由は、私たちが作るべきでないものを教えてくれるからです。ウェブアプリのなかにウィンドウ管理機能を自前で実装した瞬間、そのウィンドウはオペレーティングシステムのウィンドウと違う動きをし始めます。最小化が無かったり、ドラッグ領域が違ったり、重なり順が違ったりします。利用者はオペレーティングシステム側の契約を基準に期待します。

ポインタも同じです。カーソルの形を変えることは状態を伝える強力な手段ですが、カーソルそのものを絵に置き換えた瞬間に遅延が目に見えます。プラットフォームがすでに担っている層を作り直すときは、その層の既存の契約すべてに勝たなければなりません。

根拠のある規則とはどんな形か

ニールセンの記事が根拠に基づくと言うときの根拠がどういうものかを、一例で見ましょう。記事が引用しているもののひとつが1954年のフィッツの法則です。ある対象を指すのにかかる時間は、その対象までの距離と対象の大きさで決まるという実験結果です。遠いほど時間がかかり、大きいほど速くなります。

だからボタンを大きく描けという話は好みではなく、測定された事実の帰結です。ここから実務的にもっと使える系が出てきます。画面の角と縁は無限に大きい目標のように動きます。マウスをどれだけ強く投げても画面の外には出ないからです。よく使う操作を縁につければ、同じ大きさでも速く届きます。

この記事は別の種類の根拠も引用します。男性のおよそ12人に1人が赤緑の色覚異常を持つという数値がそれです。色だけで状態を区別した画面がなぜ危険なのかの答えがここにあります。そしてフォームのフィールドをひとつ無くしただけで年間1200万ドル規模の改善があったという事例も紹介します。この事例は私が原資料まで確認しておらず、ニールセンの記事が伝える内容として書きます。

今週できること — コンポーネント一覧に文字をつける

一時間あればできる作業があります。

1. デザインシステムのコンポーネント一覧をそのまま表に移します。
2. 各項目の横に、十個のうちどの文字なのかを書きます。ボタン、入力、メニュー、リンク、ダイアログボックス、通知、アイコン、チェックボックスとラジオ、タブ、検索。
3. 文字を書けない項目に印をつけます。
4. 印のついた項目ごとに一行で答えます。これはどんな契約を新しく作ったもので、その契約を文書とアクセシビリティ実装で実際に守れているか。

ほとんどのチームで3番に残る項目は二つか三つです。その二つか三つはたいてい本当に必要なもので、残りは既存の文字の別の服です。別の服だという事実をコードに反映した瞬間、アクセシビリティとキーボード操作がただでついてきます。

まとめと出典

一覧の価値は何を作るべきかを教えるところにはありません。新しく作ったものがアルファベットに無い文字なら、その文字を最初から全部教えなければならないという事実を教えるところにあります。

• 10 GUI Design Elements Build Every User Interface — ヤコブ・ニールセン、2026年7月29日。十個の一覧と順位の基準、指針86個、ウィンドウとポインタを別に扱った理由、フィッツの法則と色覚異常の数値、フォームフィールドの事例はすべてこの記事から出たものです。
• 十個の順序と順位の基準、アルファベットのたとえ、指針の個数は上の記事で直接確認しました。本文の契約違反の四つの例とコンポーネントのラベリング作業はこの記事が提示するものではなく、私がその観点を実務に移してみたものです。