UI / UX を考えるときに「やりがちな落とし穴」をまとめておきます。

ここに書いてあることは、

• 個々のメンバーを責めるためのチェックリストではなく、
• *未来の自分たちが同じ失敗を繰り返さないためのメモ**

として扱ってもらえればと思います。

• 「どの立場から見てもそこそこ使いやすくしたい」
• 「誰が使っても困らないようにしたい」

という発想で UI を決めていくと、

結果的に **「誰にとっても中途半端で、尖っていない UI」** になりがちです。

• *なぜ問題か**
• 主体とするユーザー視点が複数重なると、デザイン上の矛盾が生まれやすくなります。

例：

• A さんにとって見やすい並びが、B さんには邪魔になる
• A さんにとって必要な情報が、B さんにとってはノイズになる

「この機能は結局、誰のために存在しているのか？」が曖昧になると、  仕様変更や改修のたびに判断がブレます。

• 「誰のための UI か」をはっきりさせる
• 他のロール（現場担当、管理職など）は
  • 「将来どう対応するか」
  • 「今はどこまで割り切るか」

を別途メモしておく。

• 「営業としてはこの画面でオプションの宣伝も出したい」
• 「サポート的には、問い合わせを減らしたいから全部説明を詰め込みたい」
• 「社内の組織図どおりに画面も分けたい」

といった、**社内の事情を優先して UI を組み始めるパターン**です。

• プロダクトの「テーマ」（何を解決したいのか）から外れやすくなります。
• 一度「社内都合ベース」で作り込んでしまうと、
• ユーザーの声を受けて方向性を戻すコストが非常に高くなります。
  • 結果として、「ユーザーのためのツール」から「社内の事情説明ツール」に変質します。

社内都合の要望が出たときは、まず

• 「ユーザー側の価値にどうつながるのか？」
• 「テーマに沿っているか？」

を一度整理する。

どうしても社内都合を反映せざるを得ないときは、

• 「ユーザー体験のどこを犠牲にしているか」を明文化しておく
  • → 後で見直すときのきっかけになる。

• 「このボタン、分かりにくいけどヘルプテキストを書いておけばいいか」
• 「とりあえず注意書きを1文足しておこう」
• 「マニュアルに書いたから大丈夫でしょ」

という形で、**UI の分かりにくさを文章で補おうとするパターン**です。

• 実際の利用シーンで、ユーザーはそこまで丁寧に文を読みません。
• 説明文を足せば足すほど、画面は情報過多になり、 結果として「どこを見ればいいか分からない」状態になります。
• 「文章で何とかする」クセが付くと、本質的なUI改善が後回しになりがちです。

• 説明文・注意書きを足す前に、
  • ラベルを変える
  • ボタンの位置を変える
  • 選択肢を減らす
  • 操作フローを分ける

などの UI 側の工夫で解決できないかを先に検討する。

それでも必要な注意や説明がある場合のみ、最小限のテキストを足す。

• 「このパターンも対応しておいたほうがよさそう」
• 「設定で ON / OFF 切り替えられるようにしておこう」
• 「使用頻度は低いけど、一応チェックボックスを用意しておくか」

といった形で、**レアケースのために機能やオプションをどんどん足していくパターン**です。

• ジャムの法則・Hick の法則（別途記載）のとおり、選択肢が増えるほどユーザーは「決められない／迷う」ようになります。
• 画面上は「配慮している感」が出ますが、 実際の利用頻度が低い設定は **ほとんど触れられないノイズ**になりがちです。
• 開発・テスト・保守のコストだけが増えていきます。

• 「この設定は、本当に UI 上に出す必要があるか？」を自問する。
  • デフォルト値を賢く決めるだけで十分な場合も多い。
• 使用頻度が極端に低い機能は、
  • 管理画面に逃がす
  • 一部ユーザーだけが使う隠し設定にする

など、**日常の視界からは外す**選択肢も検討する。

• 「一度リリースした UI を変えるとユーザーが混乱するから、なるべく触らないでおこう」
• 「前任者がこう決めたから、変えないほうが無難」

という形で、過去の決定を必要以上に神格化してしまうパターンです。

• ユーザーの使い方やプロダクトの位置づけは時間とともに変わっていきます。
• 初期の前提条件のまま UI を固定してしまうと、
  • 新しいニーズに応えられなくなる
  • 技術的負債・設計負債が溜まっていく
• 「変えないこと」が目的化すると、 本来やるべき改善も止まってしまいます。

• 「変えない」のではなく、「変えるときの基準」を決める。
  • 例：
    • テーマに沿っていない場合
    • 一貫性を崩している場合
    • ユーザーの誤操作を招いている場合 など
• 変えたときは、
  • なぜ変えたのか
  • ユーザーにとってどう良くなるのか

をチーム内で共有しておく。

最後に、この章の使い方について。

ここに書いていることを「絶対にやってはいけないNGリスト」にすると、チームは身動きが取りづらくなります。

そうではなく、

• 何か違和感があるときに立ち返る“セルフチェック用リスト”
• レビューのときに「これは7-2っぽいね」と軽くラベルを貼るための共通言語

として使ってもらえるとちょうどいいと思っています。

大事なのは、「この UI / 仕様は、どのアンチパターンに近いか？」を一度疑ってみること

であって、完璧に守ることではありません。

アンチパターンを意識しつつも、その時々の制約や優先順位の中で、ベターな選択を積み重ねていくための「目安」として活用してください。