設定ページ問題

設定ページは、プロダクトの中で最も正直な画面です。ひとスクロールで、チームがどの決断を拒んだかが丸見えになります。トグルの一つひとつが、化石になった議論です。入れ子になったタブの一つひとつが、誰も解決しなかった「あとで考えよう」です。

ほとんどの設定ページはゴミ捨て場です。断れなかったエンジニア、オプトアウトが必要だったマーケター、「決める」の代わりに「設定可能にする」を使ったPM。3年分のトグルが積み上がった結果、チームはデモを恥ずかしがり、ユーザーは触るのを怖がる画面になります。

これは、設定を第一級のプロダクト面として扱うための主張です。5つの原型、6つのルール、普段使っているプロダクトの実例、そして出荷前に回す監査をまとめました。

設定はチームの正体を暴く画面

設定の肥大化は、組織の機能不全を示す先行指標です。 チームがデフォルトで合意できないとき、トグルが出荷されます。顧客が文句を言い、誰も押し返したくないとき、トグルが出荷されます。PMが2つのフローで決められないとき、両方が設定の裏に出荷されます。

半年後、半数のトグルがなぜ存在するのか誰も覚えていません。設定を削除するには、最初に避けたのと同じ決断が必要になるので、設定は積もっていきます。3年以上出荷されているプロダクトなら、設定ツリーの中に未決の決断を数えられるはずです。

ダメな設定ページの5つの原型

ダメな設定ページはランダムには生まれません。5つのパターンに分類でき、それぞれが特定の種類の組織的怠慢の行き着く先です。

1. ダンプ

時系列での堆積。設定は追加された順に並び、グループ化されません。最新のフィーチャーフラグが2019年の通知設定の隣にあり、その隣には2年前に正式版になるはずだったベータ用トグルがいます。Cursorはここに滑り込みつつあります。リリースのたびに一般タブへトグルが3つ増え、今や一般タブは無関係な決断が40行も続くスクロールです。ダンプは、誰も積極的にデザインしていない設定ページのデフォルト状態です。

2. スプレッドシート

アルファベット順の設定項目。チームは階層化を諦め、並び替えをOSに任せました。すべてのトグルが同じ重みで、すべての行が同じ見た目です。Slackの通知設定はここにあります。サウンド、バッジ、モバイル、チャンネル、キーワード、おやすみモード、スケジュール、カスタム。すべてが平らな壁になり、どれが重要かという物語がありません。

3. 行き止まり

目に見える変化を何も起こさない設定。ユーザーが「コンパクトモード」を切り替えても、画面はまったく同じ。「高度な機能を有効にする」を切り替えても、何も現れません。macOSのApple「システム設定」リデザインは、この種の設定を一世代分出荷しました。他の設定に黙って上書きされる設定、画面のどこにも書かれていない再起動が必要な設定。行き止まりは、設定は効かないとユーザーに教え込み、プロダクトの残りまで信用されなくなります。

4. 迷宮

10階層の入れ子タブ。カテゴリ、サブカテゴリ、「詳細設定」の開閉、モーダルの下に埋もれた設定。トグルがあることは知っていて、以前に切り替えたこともあるのに、見つけられません。昔のJiraはこれで一時代を築きました。プロジェクト、ボード、ワークフロー、スキーム、権限スキーム、通知スキーム、すべてが別々のツリーです。

5. 博物館

3年間誰も触っていない設定。削除するのが怖いから残っています。2023年に終了した機能を参照しています。レガシーなSaaSプロダクトにはどれも博物館の展示室があり、そのコストは、2回前のリファクタリングで消すべきだったコードパスを保守し続けるというチームの約束です。

設定は納戸ではなくプロダクトの面

ほとんどのチームは、設定をプロダクトの残りを片付ける場所として扱います。その捉え方こそがバグです。設定はプロダクトの中でも最もレバレッジの高い面の一つで、強いチームはそのようにデザインします。

設定は、ユーザーに対するプロダクトの世界観を表します。同時に4つのことを伝えます。チームがユーザーをどれだけ信頼しているか。どれだけのコントロールを共有する気があるか。正しいデフォルトは何だとチームが考えているか。そして、デフォルトを変える5%のためにデザインしつつ、変えない95%を罰しないほど、ユーザーの時間を尊重しているか。

Linearは設定を、command-K主導の単一の検索面としてデザインしました。入れ子のタブはほぼありません。暗黙のメッセージはこうです。ユーザーは有能で、検索は速く、階層化の仕事はチームがやったからユーザーはやらなくていい。Notionは逆方向に進み、同じように勝ちました。設定は影響を受けるものの隣にあります。ページの設定はページに。データベースの設定はデータベースに。コンテキスト設定は作業の中に溶け込みます。

Vercelはスコープ付きの階層を使います。プロジェクト、チーム、アカウントが明確にラベル付けされ、それぞれが管轄するリソースにスコープされています。Stripe Dashboardはアクション志向で、すべての画面が「これをやる」であり、「この好みを設定する」ではありません。GitHubのリポジトリ設定は、リポジトリ、組織、アカウントの所有をきれいに分けて、スコープを完璧に決めています。

すべての設定ページを決める6つのルール

これらのルールは複利で効きます。6つ中5つを満たせば、そのページはプロダクトの面として読まれます。3つなら、1年以内にどれかの原型へ滑り落ちます。

ルール1:検索ファースト

階層は主役ではなく、フォールバックです。ユーザーは、どのタブにあるかより先に、設定の名前を知っています。Linearのcommand-Kは、設定を第一級の結果タイプとして扱っています。Figmaは設定検索を追加し、トグルに到達するまでの時間はすぐに短縮されました。設定ページに検索バーがないなら、ユーザーが情報設計を暗記してくれることに賭けているわけです。彼らは暗記しません。

ルール2:中央レジストリよりコンテキスト配置

設定は影響を受けるものの隣に置きます。通知設定は通知パネルに。ページ設定はページに。中央の設定ページは、プロフィール、請求、セッションのようなアカウントレベルの事柄にはよくても、それ以外にはほぼ向きません。Notionは金字塔です。Figmaの右レールも、レイヤー、フレーム、コンポーネントのプロパティで同じ役目を果たしています。

ルール3:信頼を勝ち取る適切なデフォルト

すべてのデフォルトはプロダクトの決断です。ユーザーの80%にとっての正解はこれだとチームが信じていることを表します。デフォルトが間違っていれば、トグルは絆創膏です。Slackの通知デフォルトは、あなたが静かではなく連絡可能でいたいと想定しています。この賭けは、中央値のユーザーにとっては正解です。多くのチームはトグルを先にデザインし、デフォルトは成り行きに任せます。その順番は間違っています。

ルール4:フラットな肥大化より段階的開示

ユーザーには、90%のユーザーが気にする5つの設定を見せます。残りの50は、明確な「詳細設定」の入口の奥、あと1クリック深いところに置きます。Vercelのプロジェクト設定はこれを完璧にやっています。最初の画面には、ドメイン、環境変数、デプロイ保護が出ます。ビルドの上書き、関数の設定、リライトは詳細設定の中です。

ルール5:孤児を作らない

すべての設定はグループに属します。すべてのグループには名前があります。孤児テスト:前後の文脈なしで、ラベルを声に出して読んでみます。チームのデザイナーがそのトグルの機能を説明できないなら、それは孤児です。孤児は博物館の苗木です。

ルール6:すべての設定は存在意義を示す

設定は契約です。チームは、それを維持し、文書化し、テストし、他のすべての設定との相互作用を永遠に考え続けると約束します。ほとんどの設定は、その家賃を払えません。新しい設定へのデフォルトの姿勢は「ノー」であるべきです。良いチームは、出荷する数より多くの設定を殺します。

もっと深い問題を示すアンチパターン

3つのパターンが、残りすべてを合わせたより多くの設定ページを殺します。それぞれが、問題は画面ではなく、その背後にいるチームにあるという症状です。

プロダクトの決断の代用品としての設定。 チームはオプトインかオプトアウトかで合意できず、トグルとして出荷しました。未解決の議論は、ユーザーが引き継ぎます。朝会で「設定可能にしよう」と聞こえたら、このアンチパターンが形成される現場を目撃しています。さらに深い読み物は意図的に摩擦をデザインするにあります。

悪いデザインを補う設定。 デフォルトの密度が緩すぎるから「コンパクトモード」のトグル。ブランドカラーがアクセシビリティを満たさないから「ハイコントラスト」のトグル。リデザインが拒否されたから「クラシックビュー」のトグル。どれも、本物の修正がオプションの顔をしているだけです。修正とは、密度、コントラスト、ビューを最初から正しくデザインすることです。

誰も一文で説明できない設定。 デザイナーが、その設定が何をするのか、切り替えると何が変わるのか、誰のためのものかを説明できないなら、その設定は出荷すべきではありません。新しいトグルがコードベースに入る前に、このテストを実行してください。

設定ページ監査

すべての設定ページを、次の7つの質問に通してください。6つで自信を持って「はい」と言えなければ、そのページは未完成です。

1. ユーザーは5秒以内に任意の設定を見つけられるか? 見つけられないなら、検索がないか、階層が壊れています。
2. すべての設定に、非エンジニアが理解できる一文の説明があるか? ラベルの説明にエンジニアが必要なら、それはプロダクトの面にふさわしくありません。
3. トグルを切り替えると、目に見える即時の効果があるか? 隠れた状態変化は、信頼を殺します。
4. 設定は、機能チームごとではなく、ユーザーのタスクごとにグループ化されているか? 機能の担当チームで整理されたページは、内部の成果物がプロダクトに漏れ出たものです。ユーザーのゴールでグループ化してください。
5. デフォルトは、どこかに文書で擁護されているか? チームは、ドキュメント、ビジュアルヒエラルキーの判断、ブランド原則のいずれかを示せるべきです。デフォルトが「スプリント中にエンジニアが設定したもの」なら、そのページは完成していません。
6. ユーザーに気づかれずに設定の半分を削除できるか? できるなら、やりましょう。博物館は、チームが思うより重いです。
7. ページの見た目と使い心地は、プロダクトの他の部分と同じか? ランディングページのデザイン原則と並べて読んでみてください。ブランドが崩れているなら、その設定ページはブランドから外れています。

この監査を年に2回回すチームは、ユーザーがたじろがない設定の面を出荷します。回さないチームは、競合の採用ツールになるような設定ページを出荷します。

原則を選び、それからページを剪定する

設定は、トグルに凍りついたチームの世界観です。良いチームは、オンボーディング、ダッシュボード、マーケティングサイトに注ぐのと同じ職人技で、このページを第一級のフローとして扱います。

設定ページを直す最速の方法は、リデザインではありません。半分を削除することです。孤児テスト、一文テスト、存在意義テストに落ちる設定をすべて取り除いてください。残ったものが、本物の設定面の背骨です。

空の状態とのつながりは偶然ではありません。どちらの画面も、気を散らすものが何もないときにチームが何を信じているかを明らかにします。同じ規律はWebデザインの原則にも現れます。

よくある質問

プロダクトにはいくつの設定があるべきですか?

できるだけ少なく。すべての設定は、チームが永遠に維持する契約です。新しい設定へのデフォルトの姿勢は「ノー」であるべきです。チームがその設定を一文で擁護でき、それが誰のためのものかを挙げ、切り替えたときに目に見えて何が変わるかを説明できないなら、その設定は出荷すべきではありません。

設定はプロダクトのどこに置くべきですか?

影響を受けるものの隣です。中央の設定の別棟ではありません。ページの設定はページに。ワークスペースの設定はワークスペースに。通知の設定は通知パネルに。中央の設定ページは、請求、プロフィール、セッションのようなアカウントレベルの事柄にはよくても、それ以外にはほぼ向きません。

何年分ものトグルが積み上がった設定ページを、どう片付けますか?

監査を回し、それから削除します。すべての設定をユーザーのタスクごとにグループ化します。孤児、行き止まり、博物館の展示品を特定します。最初の一巡で下位30%を取り除き、サポートチケットを観察します。何も苦情が来なければ、さらに20%を取り除きます。

設定ページはホームページのようにデザインする

設定ページは地下室ではありません。パワーユーザーが住み、新規ユーザーがあなたを判断する部屋です。ホームページ、オンボーディング、ダッシュボードと同じように扱ってください。同じ職人技を注ぎ、同じ確信を持って出荷してください。

設定ページをバックログから引き継ぐのではなく、プロダクトの他の部分と同じようにデザインするチームが欲しいなら、Brainyに依頼してください。私たちは設定を第一級のフローとしてデザインします。ページを小さく保ち、トグルに家賃を払わせる規律とともに。