UI/UXデザイン入門｜センスは要らない——デザイナー不在の個人開発が頼るべき10の原則

センスの代わりになる10の経験則——まず全体像

10原則は暗記するものではなく、リリース前に画面へ当てる点検表。1994年生まれだが、Web・モバイル・AIチャットまで通用する抽象度で書かれている。

UI/UXデザインの共通言語として最も使われているのが、ヤコブ・ニールセンの10ユーザビリティ原則です。原典は性格をこう説明します——“heuristics” because they are broad rules of thumb and not specific usability guidelines。細かい規則集ではなく幅広く効く経験則、つまり道具としてのチェックリストです。

10原則を実装の言葉で

最重要は1番——「今なにが起きているか」を見せる

原典の第1原則の定義を引きます。“keep users informed about what is going on, through appropriate feedback”。何が起きているかを、適切なフィードバックで知らせ続けること。ボタンを押した直後のローディング表示、保存完了のトースト、失敗の明示。ユーザーの不安と誤操作の大半は、この1原則の徹底だけで消えます。

個人開発の3大違反——エンジニアが作る画面はなぜ不親切になるのか

作った本人は仕様を知っているから困らない。違反は「知らない人が初めて触る」場面でだけ露呈する——だから自分では気づけない。

UI/UXデザインの原則違反には、個人開発特有の偏りがあります。作者は内部の仕組みを知っているため、説明がなくても・状態が見えなくても困らない——この非対称が、そのまま画面に焼き付きます。編集部が自分たちのマーケットプレイス開発で直してきた違反も、きれいにこの型でした。

違反1: 押しても無反応（状態の可視化）

非同期処理の間、画面が何も変わらない。ユーザーは壊れたと解釈してもう一度押し、二重送信が起きます。対策は機械的で、ボタンに「処理中」状態を持たせ、完了と失敗を必ず表示する。編集部の実例では、ローディング中の画面が真っ白になる問題を直すだけで、問い合わせの一角が消えました。

違反2: 戻れない・取り消せない（主導権）

削除が即時実行で確認もない。ウィザードの途中で戻るとデータが消える。ユーザーは間違える前提で設計するのが原則3で、確認ダイアログか取り消し（Undo）のどちらかを、破壊的操作の全てに付けます。

違反3: エラーが開発者向け（回復支援）

「Error: 500」「invalid input」——開発者のためのメッセージをユーザーに見せる違反です。原則9の型は「何が起きたか」＋「次に何をすべきか」の2部構成。「保存できませんでした。時間をおいて再度お試しください。続く場合はこちらへ」と書き直すだけで、同じエラーでも体験が変わります。なおエラー詳細を隠すのはセキュリティ（内部情報の漏えい防止）の要請でもあり、一石二鳥の修正です。

自分のUIを自分で点検する——30分の簡易ヒューリスティック評価

専門家がいなくても、10原則を質問文に変えて主要3画面に当てるだけで、致命的な違反は自分で拾える。

UI/UXデザインの点検は、本来は専門家によるヒューリスティック評価という手法ですが、個人開発では簡易版で十分に機能します。リリース前の30分でできる手順に落とします。

手順: 3画面×10問

1. ユーザーが最も使う画面を3つ選ぶ（トップ・入力・結果の3種が定番）
2. 各画面で、表1の10原則を質問文にして当てる（「処理中は見えるか？」「取り消せるか？」…）
3. 違反を見つけたら、画面名×原則番号でメモする（例: 決済画面×原則1）
4. 違反の修正は原則1→3→9の順に。見た目の調整はその後

可能なら「初見の1人」に触ってもらう

自己点検の限界は、作者が仕様を知っていることです。家族や友人に説明ゼロで触ってもらい、詰まった場所を黙って記録するだけで、自己点検では見えない違反が浮かびます。5人テストすれば大半の問題が見つかるという知見がこの分野にはありますが、個人開発なら1人でも収穫は十分です。