デザインを構造として組む

デザインは「再現できる構造」である

デザインが崩れる原因の多くは、見た目は決まっているが構造が決まっていないことにあります。
FHWでは、

• どの単位で再利用するのか
• どこまでが同じパーツなのか
• 何が変わってよい要素なのか

を整理し、再現できる構造としてデザインを扱います。

コンポーネントはUI部品とセクションの両方で考える

FHWでは、コンポーネントを一つの粒度に限定しません。

社内で共有されている基準

• ボタン、見出し、ラベルなどのUI部品
• 料金表、事例一覧、問い合わせ導線などのセクション

これらを組み合わせて、ページ全体を構成します。
UI部品だけでも、セクション単位だけでも不十分なため、両方を前提に構造を組み立てます。

状態（state）を最初から想定する

UIは、常に同じ状態で表示され続けるわけではありません。
FHWでは、

• hover
• focus
• active
• disabled
• error
• loading

といった 状態の存在を前提に設計します。
すべてを厳密に定義するわけではありませんが、必要な状態を最初から想定しておくことで、後から無理な追加が発生するのを防ぎます。

余白は「感覚」ではなくルールで管理する

余白が崩れると、UI全体の印象や可読性が大きく損なわれます。
FHWでは、余白を感覚的に調整するのではなく、一定のスケールで管理するという考え方を採用しています。
例えば、「4 / 8 / 16 / 24 …」といった基準をもとに、余白の大小関係を整理します。
これにより、デザイン・実装・改修のすべてで判断が揃います。

レスポンシブは「構造を保ったまま調整する」

FHWでは、SPとPCで別物のデザインを作るという考え方は取りません。
基本となる構造を保ったまま、

• 情報の優先度
• 余白
• 要素の並び

を調整することで、各デバイスに適した表示を実現します。
これにより、設計と実装の一貫性が保たれます。

デザイナーとの受け渡しは案件ごとに調整

Figmaでの受け渡しは、案件の性質や体制によって変わります。

• コンポーネントやバリアントを整理する場合
• レイアウト中心でルールを補足する場合

どちらもあり得ます。
重要なのは、実装側が構造を理解できる状態で受け取ることです。

コーディング前提のデザイン設計

CSS設計は、FLOCSSを厳密なルールではなく思想として採用しています。
その前提で、

• 命名が破綻しないか
• 構造として再利用できるか
• 将来の拡張に耐えられるか

といった点を意識して実装します。
デザインとコーディングを切り離さず、構造としてつなぐことを重視しています。