refactoring-ui
WebサイトやアプリのUIにおける視覚的な階層構造、余白、カラー、奥行きを診断・改善します。「UIがなんかおかしい」「デザインを直したい」「Tailwindのスタイリング」「カラーパレット」「デザインシステム」「コンポーネントのスタイル調整」といった場面や、デザイントークンの整備・ダークモードテーマの作成・ローンチ前のUI仕上げ時に活用してください。グレースケールファーストのワークフロー、制約付きデザインスケール、シャドウ設定なども対象です。
description の原文を見る
Audit and fix visual hierarchy, spacing, color, and depth in web UIs. Use when the user mentions "my UI looks off", "fix the design", "Tailwind styling", "color palette", "visual hierarchy", "design system", "spacing scale", or "component styling". Also trigger when building consistent design tokens, creating dark mode themes, improving data visualization clarity, or polishing UI details before launch. Covers grayscale-first workflow, constrained design scales, shadows, and component styling. For typeface selection, see web-typography. For usability audits, see ux-heuristics.
SKILL.md 本文
Refactoring UI デザインシステム
実践的で体系的なUIデザインアプローチです。フロントエンドコードの生成、デザインレビュー、ビジュアル改善のアドバイスの際に、これらの原則を適用してください。
コア原則
グレースケールで設計を開始する。色は最後に追加する。 これにより、色を頼る前に、スペーシング、コントラスト、タイポグラフィを通じて適切な階層を強制します。
基盤: 優れたUIは創造性や才能についてではありません。システムについてです。スペーシング、タイプ、カラー、シャドウの制限されたスケールは、一貫して専門的な結果を生み出します。最初は余白が多すぎるくらいから始めて、削除していきます。詳細は後から対応してください。レイアウトと階層が機能するまでは、アイコン、シャドウ、マイクロインタラクションに夢中にならないでください。
スコアリング
目標: 10/10。 UIデザインやフロントエンドコードを確認または作成する際は、以下の原則への準拠に基づいて0〜10で評価します。10/10は全ガイドラインとの完全な一致を意味し、低いスコアは対応すべきギャップを示しています。常に現在のスコアと、10/10に到達するために必要な具体的な改善を提供してください。
Refactoring UIフレームワーク
デザイナーなしに専門的なインターフェースを構築するための7つの原則:
1. ビジュアル階層
コア概念: すべてが重要であるとは限りません。3つのレバー(サイズ、ウェイト、カラー)で階層を作成します。
なぜ機能するか: すべての要素が注意を引くために競い合う場合、何も目立ちません。二次コンテンツの意図的な強調解除により、対比によって一次コンテンツが強力になります。
重要なインサイト:
- レバーを組み合わせ、乗算しない -- 一次テキスト = 大きい、または太い、または暗い(すべてではなく)
- 「3つすべて」をページの最も重要な要素にのみ保存
- ラベルは二次的 -- フォームラベル、テーブルヘッダー、メタデータラベルはデータを支援し、競争しない
- セマンティックカラーは視覚的ウェイトと等しくない -- 淡い赤の二次ボタンは日常的なアクションの危険を大声で叫ぶより機能することが多い
- ラベルを小さく、軽く、または大文字の小文字にしてラベルを強調解除
プロダクト応用:
| コンテキスト | 階層テクニック | 例 |
|---|---|---|
| フォームフィールド | ラベルを強調解除、値を強調 | 大きな値テキストの上に小さな大文字ラベル |
| ナビゲーション | 一次ナビゲーションは太字、二次ナビゲーションは軽い | アクティブなリンクは濃いグレー-900、非アクティブはグレー-500 |
| カード | タイトルは大きく、メタデータは小さく軽い | カードタイトル20px太字、日付12px灰色-400 |
| ダッシュボード | 主要メトリクスは大きく、コンテキストは小さい | 売上「$42,300」大きく、「先月比」小さく |
| テーブル | ヘッダーを強調解除、セルデータを強調 | ヘッダーは大文字小グレー、データは通常のウェイト |
デザインパターン:
- 3レベル階層テーブル: サイズ(大/基本/小)、ウェイト(太字/中/標準)、カラー(暗/中/薄いグレー)
- ラベル-値パターン: 強調されたラベル上に強調された値
- ボタン階層: 一次(塗りつぶし)、二次(アウトライン または 淡色)、三次(テキストのみ)
倫理的境界線: 価格設定、利用規約、キャンセルオプションなどの重要な情報を非表示にするために階層トリックを使用しないでください。
参照: references/advanced-patterns.md インタラクション状態と高度なコンポーネントパターン
2. スペーシングとサイジング
コア概念: 任意の値ではなく、制限されたスペーシングスケールを使用します。スペーシングは関係を定義します。より近くにある要素がより関連しています。
なぜ機能するか: 任意のスペーシング(padding: 13px)は不整合を作成します。固定スケールは意図的な決定を強制し、調和したレイアウトを生成します。寛大なスペーシングは上質に感じられ、密なスペーシングは圧倒されるように感じます。
重要なインサイト:
- 線形またはほぼ線形スケールを使用: 4、8、16、24、32、48、64px
- 余白が多すぎるところから始めて、削除します。ほぼ削除されることはありません
- グループ間のスペーシングはグループ内のスペーシングより大きいべき
- テキストブロックは45〜75文字に制限すべき(
max-w-proseまたは ~65ch) - フォームは最大300〜500px幅
- フルウィッドはコンテンツではほぼ正しくない
プロダクト応用:
| コンテキスト | スペーシング戦略 | 例 |
|---|---|---|
| アイコン + ラベル | タイト結合(4px) | 小さなギャップが視覚的につながりを保つ |
| フォームフィールド | 関連要素(8-16px) | 入力とそのラベルはタイトに結合 |
| カードセクション | セクション分離(24px) | タイトルブロック、コンテンツブロック、フッターブロック |
| ページセクション | メインセクション(48-64px) | ヒーロー、機能、推薦文、フッター |
| コンテナ幅 | コンテンツに制限 | テキスト用max-w-prose、フォーム用max-w-md |
CSSパターン:
p-1(4px)p-2(8px)p-4(16px)p-6(24px)p-8(32px)p-12(48px)p-16(64px)max-w-prose(65ch)max-w-md(28rem)max-w-lg(32rem)max-w-xl(36rem)gap-2関連アイテム用、gap-6セクション分離用
倫理的境界線: スペーシングを使用して登録解除ボタンやプライバシーコントロールなどの重要なUI要素を埋めないでください。
参照: references/advanced-patterns.md レスポンシブブレークポイント戦略
3. タイポグラフィ
コア概念: モジュラータイプスケールを使用し、コンテキストごとに行の高さを制限し、最大2つのフォントファミリーに制限します。
なぜ機能するか: モジュラースケール(例: 1.25比率)は自然なビジュアルリズムを作成します。見出しの厳しい行の高さと本文のリラックスした行の高さにより、コンテキスト全体で読みやすさが向上します。
重要なインサイト:
- モジュラースケールを使用: 12、14、16、20、24、30、36px(1.25比率)
- 見出しは厳しい行の高さ(1.0-1.25)が必要。本文はリラックス(1.5-1.75)
- 広いテキストはより多くの行の高さが必要
- 本文の400未満のフォントウェイトを避ける。読めなくなる
- 強調には太字(600-700)を使用。すべてに使用しない
- 最大2フォント: 見出し用1つ、本文用1つ(またはウェイト変動を持つ1つファミリー)
プロダクト応用:
| コンテキスト | タイポグラフィルール | 例 |
|---|---|---|
| ヒーロー見出し | 36px、厳しい行の高さ(1.1)、太字 | 大きなインパクトのあるステートメント |
| セクションタイトル | 24px、行の高さ1.25、セミボールド | 明確なセクション区分 |
| 本文テキスト | 16px、行の高さ1.75、標準ウェイト | 快適な読書 |
| キャプション/ラベル | 12-14px、行の高さ1.5、中程度のグレー | 二次情報 |
| コード/データ | 等幅フォント、14px、一貫した幅 | 表形式データの配置 |
CSSパターン:
text-xs(12px)text-sm(14px)text-base(16px)text-lg(18px)text-xl(20px)font-normal(400)font-medium(500)font-semibold(600)font-bold(700)leading-tight(1.25)leading-normal(1.5)leading-relaxed(1.75)
倫理的境界線: 小さいタイプサイズを使用して、利用規約、条件、または手数料をユーザーから非表示にしないでください。
参照: references/advanced-patterns.md テキスト切り詰めとレスポンシブタイポグラフィ
4. カラー
コア概念: カラーごと5〜9個のシェードを持つシステマティックなパレットを構築し、グレーに細かい彩度を追加し、グレースケールで最初に設計します。
なぜ機能するか: ランダムな色は衝突します。定義済みのシェードを持つシステマティックなパレットにより、インターフェース全体の一貫性が確保されます。HSL調整は自然に見える明るい変動と暗い変動を作成します。
重要なインサイト:
- 各カラーは近い白から近い黒(50から900)まで5〜9個のシェードが必要
- 最も暗いシェードは黒ではない。純粋な
#000000の代わりに900レベルの暗いグレー(例:#111827)を使用 - 純粋なグレーは生気がない。細かい彩度を追加(クールUI:
#64748bのような青のティント。暖かいUI:#78716cのような黄/茶色のティント) - HSL調整: より明るい = より高いライトネス、より低い彩度、60度に向けて色相をシフト。より暗い = より低いライトネス、より高い彩度、0/240度に向けて色相をシフト
- 本文テキスト最小4.5:1コントラスト比。大きいテキスト(18px以上)最小3:1
- 明確なテキストには軽いグレーではなく
#374151(グレー-700)を白で使用
プロダクト応用:
| コンテキスト | カラー戦略 | 例 |
|---|---|---|
| 一次パレット | メインブランドカラーの9個のシェード(50-900) | ボタン用ブルー-500、背景用ブルー-100 |
| グレーパレット | UI温度に一致する彩度のあるグレー | テック製品用の青のティントを持つクールグレー |
| セマンティックカラー | 成功、警告、エラーは各シェード範囲 | 成功用グリーン-500、エラー用レッド-500 |
| テキストカラー | 3レベル: 暗、中、薄い | text-gray-900、text-gray-600、text-gray-400 |
| アクセシブルコントラスト | すべてのテキスト/背景の組み合わせをテスト | 白上#374151 = 10.5:1比率 |
CSSパターン:
text-gray-900(暗)text-gray-600(中)text-gray-400(薄い)bg-blue-50微妙な背景用、bg-blue-500一次アクション用border-gray-200微妙なボーダー用、border-gray-300より強い用
倫理的境界線: 情報を伝達するために色だけを使用しないでください。アクセシビリティのため、常にテキストまたはアイコンとペアにしてください。
参照: references/theming-dark-mode.md ダークパレット作成とテーム実装
5. 奥行きとシャドウ
コア概念: シャドウスケールを使用して標高を表現します。わずかに浮き上がった要素には小さいシャドウ。浮いている要素には大きいシャドウ。
なぜ機能するか: シャドウは物理的な深さ感を作成し、ユーザーがどの要素がインタラクティブ、どれが表面上浮いている、どれが背景の一部かを理解するのに役立ちます。
重要なインサイト:
- 小さいシャドウ = わずかに浮き上がる(ボタン、カード)。大きいシャドウ = 浮く(モーダル、ドロップダウン)
- シャドウは2つの部分: クリスプネス用の厳しい暗いシャドウとムード用のより大きなソフトシャドウ
- シャドウなしの奥行き: 微妙な上部ボーダー + より暗い下部ボーダー、微妙なグラデーション背景、オフセットを持つ重なる要素
- シャドウを過度に使用しないでください。すべてが浮いている場合、何も深さがありません
- シャドウカラーは不透明なグレーではなく透明な暗いべき
プロダクト応用:
| コンテキスト | シャドウレベル | 例 |
|---|---|---|
| ボタン | shadow-sm(微妙な浮き上がり) | ページ表面のわずかに上に浮き上がり |
| カード | shadow-md(明確な分離) | グループ化されコンテンツが背景から浮き上がり |
| ドロップダウン | shadow-lg(浮く) | メニューが明確にコンテンツ上に浮く |
| モーダル | shadow-xl(最高標高) | オーバーレイが明確にページから分離 |
| フラット代替 | ボーダー + 背景シフト | より明るい上部ボーダー、より暗い下部ボーダー |
CSSパターン:
shadow-sm:0 1px 2px rgba(0,0,0,0.05)shadow-md:0 4px 6px rgba(0,0,0,0.1)shadow-lg:0 10px 15px rgba(0,0,0,0.1)shadow-xl:0 20px 25px rgba(0,0,0,0.15)
倫理的境界線: 詐欺的なUI要素(ダークパターン)に注意を引くために過度なシャドウまたはビジュアル強調を使用しないでください。
参照: references/advanced-patterns.md インタラクション状態と標高階層
6. 画像とアイコン
コア概念: 画像をアフターソートではなくデザイン要素として扱います。意図的にアイコンをサイズし、オーバーレイを使用してテキストの読みやすさを確保します。
なぜ機能するか: 低品質のサイズのアイコンは不適切に見えます。スタイルなしの画像は視覚的な一貫性を損なります。意図的な画像処理(オーバーレイ、object-fit、ボーダー半径)はインターフェースをポリッシュに見せます。
重要なインサイト:
- アイコンはコンテキストに対して相対的にサイズすべき。すべての場所で同じサイズを使用しない
- 一貫したストロークの幅とスタイルを持つアイコンセットを使用
- 画像には処理が必要: object-fit cover、一貫したアスペクト比、テキスト用オーバーレイ
- 画像を拡張または歪めないでください。
object-fit: coverを使用し、意図的にクロップ - 空の状態は機会。テキストだけでなく、イラストを使用
プロダクト応用:
| コンテキスト | 画像/アイコンテクニック | 例 |
|---|---|---|
| ヒーロー画像 | 半透明グラデーションでオーバーレイ | テキストは任意の写真で読み取り可能 |
| アバター | 一貫したサイズ、丸い、フォールバック頭文字 | 40px円形とobject-fit cover |
| フィーチャーアイコン | 一貫したサイズ、ウェイト、カラー | 24pxストロークアイコン(グレー-500) |
| 空の状態 | カスタムイラスト + 明確なCTA | 優しいイラスト「始める」ボタン付き |
| サムネイル | 固定アスペクト比とobject-fit cover | 歪みなしの16:9カード |
CSSパターン:
object-fit: cover固定aspect-ratioによる一貫した画像表示- アイコンサイズ: インライン用
w-4 h-4、ナビゲーション用w-6 h-6、フィーチャーアイコン用w-8 h-8 - 画像オーバーレイ: テキスト画像用
bg-gradient-to-t from-black/60 to-transparent
倫理的境界線: 誤解を招く画像やアイコンを使用して機能性または製品機能を誤表現しないでください。
参照: references/advanced-patterns.md 画像処理、アイコン使用、空の状態
7. レイアウトと構成
コア概念: すべてをセンタリングしないでください。配置、重なり、強調のバリエーションを使用してエンゲージングな構成を作成します。
なぜ機能するか: 左配置テキストは読みやすい。バリエーションのあるレイアウトはユーザーをエンゲージします。厳密なボックスから脱出すると、デザインは動的で意図的に感じられます。
重要なインサイト:
- デフォルトで左配置テキスト。短い見出し、ヒーロセクション、単一アクションCTA、空の状態のみセンター
- カードはすべてを含む必要がない。画像をエッジまでブリード、コンテナを重ねる、またはボウンダリーを超える
- リストとフィードでは、ビジュアル処理をバリエーション。いくつかのアイテムを機能させ、他をミニマイズ
- 配置を使用して、無関係な要素間のビジュアル関係を作成
- 代替強調: リスト内のすべてのカードが同じレイアウトを必要としない
プロダクト応用:
| コンテキスト | レイアウト戦略 | 例 |
|---|---|---|
| ヒーロセクション | センタータイトル、寛大なスペーシング | 短い見出し + サブテキスト + 単一CTA |
| フィーチャーグリッド | 左配置テキスト、一貫したカードサイズ | 3カラムグリッドとアイコン + タイトル + 説明 |
| ブログフィード | 強調用のバリエーションカードサイズ | 最初のポスト大きく、次のポストを2カラムグリッドで |
| サイドバー | メインコンテンツより狭い、より軽い背景 | 240-320px幅のナビゲーションまたはフィルター |
| コンテンツページ | 制限された幅、左配置 | max-w-prose センタリングコンテナと左テキスト |
CSSパターン:
- デフォルト
text-left、ヒーロと短い見出しのみtext-center - フィーチャーグリッド用
grid grid-cols-3 gap-6 - ページコンテナ用
max-w-4xl mx-auto - エッジをブリードする
overflow-hiddenカード上のobject-fit: cover画像
倫理的境界線: レイアウトトリックを使用して、オプトアウトやデータパーミッションなどの重要なユーザー選択を非表示または隠さないでください。
参照: references/advanced-patterns.md レスポンシブブレークポイントと複雑なレイアウトパターン
よくある間違い
| 間違い | なぜ失敗するか | 修正 |
|---|---|---|
| 「素人っぽく見える」 | スペーシングが不十分、制限されていない幅 | より多くの空白を追加、コンテンツ幅を制限 |
| 「平べったく感じる」 | 要素間の深さの差別化なし | 微妙なシャドウを追加、セクション上部にボーダーを追加 |
| 「テキストが読みにくい」 | 悪い行の高さ、幅が広すぎ、低コントラスト | 行の高さを増加、幅を制限、コントラストを向上 |
| 「すべてが同じに見える」 | 要素間の視覚的階層なし | 一次と二次の間でサイズ/ウェイト/カラーをバリエーション |
| 「クラッタリングに感じる」 | 至る所に同じスペーシング、グループ化なし | 関連アイテムをグループ化、グループ間のスペーシングを増加 |
| 「色が衝突する」 | システムなしのランダムなカラー選択 | 彩度を低減、より多くのグレーを使用、パレットをシステムに制限 |
| 「ボタンが目立たない」 | 周辺要素とのコントラストが低い | 周辺とのコントラストを増加、シャドウを追加 |
| 任意の値を使用 | 13、17、23などのpx値は矛盾を作成 | スペーシングとタイプスケールに固執 |
クイック診断
UIデザインを監査:
| 質問 | ノーの場合 | アクション |
|---|---|---|
| ぼかしテスト(目を細める)で階層を読むか? | 要素が注意をめぐって競い合う | 一次と二次間のコントラストを増加 |
| グレースケールで機能するか? | 階層にカラーに依存 | サイズ/ウェイト/スペーシング階層を強化 |
| 十分な空白があるか? | おそらくない。ほとんどのデザインが密すぎる | スペーシングを増加、特にグループ間 |
| ラベルが値に対して強調解除されているか? | ラベルがデータと競い合う | ラベルを小さく、軽く、または大文字の小文字に |
| スペーシングが一貫したスケールに従うか? | 任意のスペーシングは視覚的なノイズを作成 | 4/8/16/24/32/48/64スケールのみを使用 |
| テキスト幅は読みやすさに制限されているか? | 長い行は読者疲れを引き起こす | テキストブロックにmax-w-prose(~65ch)を適用 |
| カラーには十分なコントラストがあるか? | アクセシビリティ障害、読みにくい | WCAGコントラストチェッカーでテスト、白上グレー-700+を使用 |
| シャドウは標高に適切か? | 要素が誤った視覚レベルで浮く | シャドウスケールを要素目的に一致させ |
リファレンスファイル
advanced-patterns.md: 空の状態、フォーム設計、画像処理、アイコンサイズ、インタラクション状態、カラー心理学、ボーダー半径システム、テキスト切り詰め、レスポンシブブレークポイントanimation-microinteractions.md: アニメーション時、イージング関数、期間、読み込み状態、アニメーションパフォーマンスaccessibility-depth.md: WCAG 2.1 AAチェックリスト、フォーカス管理、スクリーンリーダーサポート、キーボードナビゲーションdata-visualization.md: チャート選択、チャートのカラー、テーブル設計、ダッシュボードレイアウトtheming-dark-mode.md: ダークパレット作成、ダークモードの標高、テーム実装戦略
さらに学ぶ
このスキルはAdam WathanとSteve Schogerの実践的なデザインガイドに基づいています。視覚的な例を持つ完全なシステムについては:
- 「Refactoring UI」 Adam WathanとSteve Schoger著(数百のビジュアル前後の例を持つ完全な本)
- 「日常のモノのデザイン」 Don Norman著(基盤となるデザイン思想とユーザビリティ)
- 「考えさせるな」 Steve Krug著(Refactoring UIを補足するウェブユーザビリティ原則)
- Refactoring UI -- リソースと例を持つ公式サイト
著者について
Adam Wathan はフルスタック開発者でTailwind CSSの作成者です。最も人気のあるユーティリティファーストCSSフレームワークの1つです。Steve Schoger は実践的なデザインティップとイラストで知られるビジュアルデザイナーです。一緒に彼らは Refactoring UI を作成し、固有の芸術的才能に頼るのではなく、システマティック、反復可能なテクニックを使用してより良いインターフェースをデザインする方法を開発者に教えています。彼らのアプローチはデザインの背景を必要としない専門的な結果を生成するスペーシング、タイポグラフィ、カラー、シャドウの固定スケール(制限されたデザインシステム)を強調しています。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- wondelai
- リポジトリ
- wondelai/skills
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/wondelai/skills / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。