「設定画面って、簡単そうじゃないですか」
Google Stitch でいくつかの画面を設計してきて、最初にそう思っていたのが正直なところだ。ダッシュボードや一覧画面と違って、設定画面は複雑な視覚表現が少ない。トグル、テキスト入力、セレクトボックス——そういったシンプルな要素の組み合わせだから、難しくないだろうと。
実際に設計してみるまでは。
ある日、SaaSプロダクトのアカウント設定画面をStitchで設計しようとした。プロンプトを書いて、生成する。出てきた画面は確かにきれいだった。トグルが並んでいて、セクションごとに分かれていて、視覚的には整っている。
でも画面を見ていると、「この設定を変えたら何が起きるのか」が全然わからないということに気づいた。設定は「変更できる」けれど、「変更の意味」が見えない。そしてそれは、Stitch の問題ではなく、設定画面というUIの本質的な難しさだった。
結論から言うと——設定画面は、UIコンポーネントとしてはシンプルでも、「意思決定の支援」という観点では最も複雑な画面のひとつだ。Google Stitch でこれを設計するとき、「何を変えられるか」と同時に「変えた結果どうなるか」を伝える設計が必要になる。
設定画面の「見えていない複雑さ」とは何か
設定画面とは、ユーザーがプロダクトの動作をカスタマイズするための画面で、通知設定・アカウント管理・プライバシー設定・表示設定などを含みます。UIとしてはシンプルなコンポーネントで構成されますが、ユーザーの意思決定を適切にサポートする必要があるため、設計の難易度は高いとされています。
設定画面の難しさはいくつかの層に分かれている。
「何を変えられるか」だけでは足りない
設定画面の最も基本的な責務は「変更できる項目を列挙すること」だ。でもそれだけでは足りない。
ユーザーが設定画面を開く理由は「何かを変えたい」からではなく、「今の状態が自分の望む状態になっているか確認・調整したい」からであることが多い。つまり設定画面は「変更の場所」ではなく「現状確認と調整の場所」なのだ。
この違いは、UIの設計に大きく影響する。「変更の場所」として設計すると、現在の値が見づらく、変更前後の差分がわかりにくくなる。「確認と調整の場所」として設計すると、現在の状態が明確に見え、変更のインパクトが事前にわかる。
Stitch でこれを生成しようとすると、プロンプトに「各設定項目は現在の値をデフォルトで表示し、変更前後の差分が明示されるようにする」という指示を入れないと、前者のパターンになりやすかった。
情報の「重さ」の違いを視覚化する難しさ
設定画面には、さまざまな「重さ」の設定が混在する。
- 軽い設定：通知音の種類、表示テーマ（ダーク/ライト）——簡単に変えられて、影響範囲が小さい
- 中程度の設定：通知の頻度、デフォルトの表示件数——変えたら気づく変化があるが、元に戻せる
- 重い設定：アカウントの削除、データのエクスポート、支払い情報の変更——不可逆または重大な影響がある
この重さの違いを、UIが視覚的に伝えなければならない。「重い設定」が「軽い設定」と同じUIで並んでいると、ユーザーは誤って取り返しのつかない操作をしてしまうリスクがある。
Stitch でこれを設計するとき、「危険な操作にはredの警告色と確認ダイアログを必ず付ける」という指示を明示しないと、すべての設定が同じ見た目になってしまった。
Stitch で設定画面を設計するときの実践的なアプローチ
試行錯誤を重ねて、設定画面をStitchで設計するときの実践的なやり方がまとまってきた。
まず設定項目を「カテゴリ」と「重さ」に分類する
プロンプトを書く前に、設定項目の全リストを用意して「カテゴリ分け」と「重さ分類」をしておく。
カテゴリの例：アカウント情報 / セキュリティ / 通知 / プライバシー / 課金・プラン / データ管理
重さの分類：
- 軽（いつでも気軽に変えていい）
- 中（変えても元に戻せる）
- 重（不可逆または重大な影響）
この分類をプロンプトに含めると、Stitchが適切な視覚的重みを持った設定画面を生成しやすくなる。
「ヘルプテキスト」を全設定項目に入れる指示を忘れない
設定画面でユーザーが最も困るのは、「この設定を変えると何が起きるのか、わからない」という状況だ。
Stitch でプロンプトを書くとき、「各設定項目の下に説明テキスト（ヘルプテキスト）を12pxのグレーテキストで表示。この設定がどのような効果を持つかを1〜2文で説明する」という指示を加えるようにした。
このひと言で、生成される設定画面の「使いやすさ」が大きく変わった。ヘルプテキストがあると、ユーザーが設定を変えることへのためらいが減り、自分に合ったカスタマイズをしやすくなる。
設定画面のUI設計でよく使うパターン
設定画面を設計する中で、Stitch でよく使うようになったUIパターンをまとめます。
セクション分割とアコーディオンの使い分け
設定項目が多い場合、すべてを縦に並べると画面が長くなりすぎる。
項目数が少ない場合（カテゴリあたり3〜5項目）は、セクション見出しで区切った縦並びが見やすい。項目数が多い場合（カテゴリあたり6項目以上）は、アコーディオンで折りたたむ方がスキャンしやすくなる。
Stitch でこれを生成するとき、「Xの設定カテゴリはアコーディオン、Yはそのまま展開で表示」と明示する。両方を混在させた場合の見た目を複数パターン生成して比較するのも有効だった。
変更確認フローを設計に含める
設定変更後の「保存しました」「変更を適用しました」というフィードバックUIも、設定画面の一部として設計する必要がある。
Stitch でプロンプトに「変更後のsuccess toast通知を画面下部に表示（3秒後に消える）」という指示を入れると、このフィードバックUIも含めた完成形に近い画面が生成される。
実際に使ってみてわかったのは、「設定を変えたことへのフィードバック」がないと、ユーザーは「本当に変わったのか」が不安になるということだ。変更の確認は、設定画面設計における必須要素だ。
よくある失敗と対処法
- 失敗1：すべての設定を1画面に詰め込む——「設定はひとつの画面にまとまっているべき」という思い込みから、全設定を1ページに並べてしまうことがあります。設定項目が20を超えるなら、サブページに分割するか、アコーディオンで整理することを検討しましょう。
- 失敗2：危険な操作が他の設定と同列に見える——「アカウント削除」「全データリセット」などの不可逆操作が、通知設定のトグルと同じUIで並ぶのは危険です。危険な操作は別のセクション（「危険ゾーン」など）にまとめ、赤色と警告アイコンで視覚的に区別しましょう。
- 失敗3：設定の「現在の値」が見えない——ユーザーが設定画面を開いたとき、現在の状態が一目でわかることが必要です。特にトグルの「ON/OFFどちらが現在の状態か」「セレクトボックスで何が選択されているか」を明確に表示することを忘れずに。
- 失敗4：変更後のフィードバックがない——設定を変更しても「保存されました」などのフィードバックがないと、ユーザーは変更が反映されたかどうか不安になります。設定変更後のsuccess通知は必ず設計に含めましょう。
- 失敗5：モバイルで細かすぎるトグルやチェックボックス——スマートフォンで表示したとき、タップターゲットが小さすぎて誤操作が起きることがあります。トグルは最低でも高さ24px以上、タップ領域は44px以上を確保するよう、プロンプトに明示しましょう。
よくある質問（FAQ）
Q. Google Stitch で設定画面を生成するとき、どんなプロンプトが効果的ですか？
A. 「設定画面のカテゴリ（アカウント / セキュリティ / 通知など）と各カテゴリの主要項目を箇条書きで列挙し、項目ごとのUIコンポーネント（トグル / テキスト入力 / セレクトボックス）も指定する」という形式が効果的です。さらに「各項目にヘルプテキストを追加」「危険操作は別セクションで赤色表示」などの補足指示を加えると、使いやすい設定画面が生成されます。
Q. 設定画面のナビゲーション（サブページへの遷移）はStitchで設計できますか？
A. できます。「設定のトップページ → サブページ（通知設定詳細など）→ 確認ダイアログ」という多層構造もStitchで設計できます。各画面を個別に生成してからPlay機能でフローをつなぐか、5画面同時生成でフロー全体を一気に作成する方法があります。サブページへの遷移がある場合は「＞（シェブロン）アイコン付きのリストアイテム」パターンを指定すると自然なナビゲーションが生成されます。
Q. 設定画面でアクセシビリティを確保するために何に気をつければいいですか？
A. 主に以下の点をプロンプトに含めると効果的です。①ラベルとフォームコントロールの関連付け（スクリーンリーダー対応）、②タップターゲットサイズ44px以上確保、③エラー状態の色だけでなくテキストによる説明も追加、④コントラスト比4.5:1以上の文字色設定——これらをプロンプトで明示すると、Stitchがアクセシビリティを意識したUIを生成しやすくなります。ただし自動生成されたUIのアクセシビリティは必ず人間が確認してください。
Q. 設定項目が多すぎてまとめられない場合、どう整理すればいいですか？
A. 「ユーザーがどの設定を最もよく変えるか」を基準にして、頻繁に使う設定をトップに、めったに使わない設定をサブページや折りたたみセクションに移す「Progressive disclosure（段階的開示）」の考え方が有効です。Stitchに「よく使う設定5項目をクイックアクセスエリアに配置し、詳細設定は詳細タブ内に格納」というプロンプトを書くと、この設計パターンで生成してくれます。
Q. ダーク/ライトモード切り替えの設定UIはStitchで作れますか？
A. 作れます。「テーマ設定のセクションに、ライト / ダーク / システムに従う の3択セレクターを配置。現在の選択状態が明示されるデザイン」というプロンプトが効果的です。また「このボタンを押したときのプレビューをリアルタイムで表示するUI」という指示も可能で、設定変更のプレビュー機能を含んだUIが生成できます。
まとめ：設定画面は「決定の支援」のためにある
Google Stitch で設定画面を設計してみて、改めてわかったことがある。
設定画面は「何ができるかを並べる場所」ではない。ユーザーが「自分に合った状態に調整する」ための意思決定を支援する場所だ。
そのためには、「変えられること」を表示するだけでなく、「現在の状態」「変えた場合の影響」「危険な操作への注意」「変更後のフィードバック」——これらすべてを設計に組み込む必要がある。
Stitch はその一つひとつを素早く可視化してくれる。でも何を可視化すべきかを決めるのは、やはり人間だ。
設定画面の「見えていない複雑さ」に気づいてから、私はUIデザインに対する見方が少し変わった気がしている。シンプルに見える画面ほど、設計に込められた思想が深い——そういうことが、あちこちの画面に隠れているのかもしれない。
この記事で解説した主なポイント：
- 設定画面の「見えていない複雑さ」の本質（意思決定支援の問題）
- 設定項目の「重さ分類」と視覚的な差別化の必要性
- ヘルプテキスト・変更フィードバックを必ず含めるプロンプト設計
- セクション分割とアコーディオンの使い分け
- よくある失敗5パターンと対処法
次のステップ：設定画面を設計する前に、設定項目を「軽・中・重」の3段階に分類するシートを作ってみましょう。その分類をプロンプトに含めるだけで、生成されるUIの質が大きく変わります。
