じょん
センスより「ルール」が大事。Refactoring UIで学んだ10の原則
2026年04月06日
お役立ち情報
見出しはありません
要約を生成中...
ちょっと昔の話になります。
Webアプリ開発者として駆け出した時にある悩みがありました。
UIデザインとはどういうものか理解できない。
アプリ開発を始めた頃、UIをどのように考えればいいのか、デザイナーの方にどう伝えれば意図が共有できるのか、まったく言語化できていませんでした。
「余白などは8の倍数にしてフォントはnoto sans jpを使う」
こんな薄っぺらい知識しかありませんでした。
このままではいけない！自分でも基礎・初級知識を学ばなければ！と思っていた時に一冊の本と出会ったのです。
この本で教えてくれることは、UIの基礎・初級知識であり、デザインAIを使う時のプロンプトにも役に立っている知識です。
Refactoring UI は、TailwindCSSの作者たちが書いたデザイン実践書で、ターゲットは「デザイナーではない開発者」です。
この本を教えてくれたのは、NOT DESIGN SCHOOLの創設者・もちさんでした。受託開発を始めた頃にUIについての悩みを相談したところ、「この本はいいよ〜」と勧めてもらいました。218ページのPDFとビデオチュートリアルがセットで$99。正直、少し躊躇いました。
でも、自分から質問して薦めてもらったものは必ず試すと決めていたので、迷わず購入しました。当時はまだAIも今ほど発達していなかったので、翻訳ツールを使いながら毎日1セクションずつ読み解いていったことを今でも覚えています。
この本を読むまでデザインの勉強とは、カリキュラムを読み込んで学術的な感じでデザインを覚えていくものだと思っていました。
しかし、守るべきポイントを押さえながら、順序立ててUIを構築することで使いやすいデザインになる。デザインは才能ではない。再現可能な技術だ！と言うことがわかり、これなら自分も学んでいけそうだと感じたことを覚えています。
今日は、その中でも特に刺さった10の原則を、UIデザインの視点から書き直してみようと思います。
画面設計を始めるとき、私が最初にやりがちなことがあります。ヘッダーを置いて、サイドバーを置いて、フッターを置いて——。どんどん要素を置いていき、後からここの余白どうしよう。ちょっと広いから狭くしよう。そんな開発をしていました。
でもそれは間違いでした。
本が教えてくれたのは、最初に「一番コアな機能」だけをデザインすること。たとえば「投稿フォーム」「検索バー」「商品カード」など、アプリの中心にある要素から手をつける。
外側の殻ではなく、内側の要素から作る。
これを意識するだけで、デザインのブレがなくなりました。
開発での実践: いきなりページ全体のレイアウトを組もうとせず、最も重要なコンポーネント（カード、フォーム、ボタン）を1つだけ画面の中央に置いて始める。全体の枠は後から作れば十分。
アプリケーションを触っていて、「窮屈なUIだな」と感じたことはないでしょうか。日本のアプリに多いと思うんですが、情報量が多すぎて何をみたらいいのかわからなくなってしまう。
多くの場合、その原因は余白不足です。ところが面白いことに、余白を増やすことを「情報を削ってしまう」と感じる人は多い。自分もその一人でした。
本の教えはシンプルでした。最初からあえて大きめに余白を取り、そこから少し削っていく。この順番が、美しいUIとごちゃごちゃしたUIを分けます。
余白はUIの「空気」。空気を惜しんでいては、息のできるデザインにはなりません。
開発での実践: paddingは最低でも24px〜32pxから始め、窮屈に見えたら16pxに下げる方向で調整する。「なんか詰まってる」と感じたら、まず余白を疑う。
「どの色にしよう」「何pxにしよう」と毎回考えるのは、想像以上に消耗します。
本が提示した解決策は、最初から選択肢を決めてしまうこと。
フォントサイズは 12, 14, 16, 20, 24, 32, 48px の7つだけ
余白は 8px の倍数
カラーは各色に 100〜900 のスケールを定義
これを「デザインシステム」と呼びます。一度作ってしまえば、あとは「どれを選ぶか」ではなく「どれを使うか」の話になる。
「選ぶ」より「決まっている」ほうが、速くて美しい。キーワードは統一感でした。
開発での実践: プロジェクト開始時にカラー・フォントサイズ・余白のスケールをドキュメントに定義しておく。開発中に迷ったら「スケールに従う」だけにする。自由に決めない。
UIで最も重要な概念は、視覚的な階層（ヒエラルキー）
ユーザーがページを見た瞬間、「どこを見ればいいか」が直感的に伝わるのが良いUIです。そのためには、情報の「重さ」を視覚で表現する必要があります。
太字・大きいフォント・濃い色 → 重要な情報 細字・小さいフォント・薄い色 → 補助情報 これだけで、UIは劇的に読みやすくなります。
開発での実践: 1つのカードやブロック内に複数のテキストが存在するとき、必ず「主役（1つ）」と「脇役（残り）」を明確に分ける。全部同じスタイルにしない。
デザインの失敗の多くは、「全部同じ見た目にしてしまう」ことから来ます。
「日付: 2026-04-05」「作成者: じょん」——このラベルたち、本当に全部同じ色・同じサイズでいいでしょうか。
主役を決め、脇役は引き算する。それだけで「情報がすっきり整理されたUI」になります。04の視覚的な階層と似通った部分もありますね。
開発での実践: コンポーネントを設計するとき、メインの情報（タイトル等）と補足情報（日付・タグ等）のスタイルを必ず分けて定義する。重要度が違う情報を同じに見せない。
「Name:John」と書く必要はあるでしょうか。
「John」だけで、文脈から名前だとわかる場合がほとんどです。
本が言っていたのは、ラベルを省略できる場面を常に探すこと。テキスト単体で意味が伝わるなら、ラベルはノイズでしかありません。
必須項目ラベルなんかいい例だと思います。全て必須項目であれば一番最初にその旨を書き、全てのフォームから赤文字の必須項目を削除することでスッキリした見た目になります。
開発での実践: アイコン＋数値の組み合わせ（📅 2026-04-05）でラベルを代替できる場面を積極的に探す。ラベルが本当に必要かどうか、常に問い直す。
——フォントと行長のルール テキストデザインは地味に見えて、実はUIの印象を大きく左右します。
推奨していたのは、中立的なサンセリフ体（Inter、Noto Sans等）を選び、5つ以上のウェイトがあるフォントを使うこと。日本語であれば、1行の文字数は30〜40文字程度に抑えると読みやすい。
開発での実践: フォントは Regular・Medium・Bold の3ウェイトだけを使うと決める。ウェイトを増やすほど一貫性が崩れる。フォントファミリーも原則1種類に絞る。
色の選び方で、最も犯しやすいミスが2つあります。
#FF0000（純粋な赤）など、原色をそのまま使う その場その場で色を選び、統一感がなくなる 本が教えてくれたのは、HSL（色相・彩度・輝度）で考えること。そして各カラーに対して 100〜900 のスケールを定義し、常にそのスケールから選ぶこと。
色を「選ぶ」のではなく、「配置する」。
コントラストチェッカーを使うと迷いにくいと思います。
https://colorbase.app/ja/tools/contrast-checker
開発での実践: メインカラーを1色決めたら、HSL値を基準にlightnessだけを変えた7段階のバリエーションを事前に定義する。開発中は必ずそのスケールから選ぶ。
アプリを作っていると、つい忘れがちなのが「データがない状態」のデザインです。
一覧ページにデータがない時、真っ白な画面が出てくるのは最悪です。ユーザーはそれを「バグ」と感じます。
Empty Stateには、イラスト・説明文・アクションボタンの3点セットを用意する。「まだ何もありません。最初の○○を作ってみましょう！」というような案内が、ユーザーをその先へ導きます。
開発での実践: リスト表示画面を作るときは、データがある状態とない状態の両方を最初から設計する。Empty Stateは後回しにすると確実に忘れる。
——色はあとから加える
最後に、これが一番革命的だったかもしれません。
デザインの初期段階では、色を使わない。
グレースケールだけで設計することで、階層・構造・余白が「力」で決まります。色の魔法に頼らず、情報の重みで勝負する。
グレースケールで美しく見えるUIは、色をつけてもサイズを変えてもずっと美しい。逆に、グレースケールが崩れているなら、色で誤魔化しているだけかもしれません。
開発での実践: 新しい画面を設計するときは、最初にグレーだけで全体を組む。「色を足したい」という衝動をこらえ、構造が固まってから色を加える。
——デザインは「再現可能な技術」
『Refactoring UI』を読んで、私の中で何かが変わりました。
「センスがない自分には無理だ」は思い込みだった。
デザインは、学べば身につく。意識すれば変わる。10個のルールを知っているだけで、UIは一段階変わります。最初から完璧を目指さなくていいので、まず一つ——「余白を大きめに取る」だけでも、今日試してみてください。
要約
コメント
まだコメントはありません。
👇️NOTでの受講に興味がある方はこちら
👇️NOTでの受講に興味がある方はこちら
