この記事の内容
あやね
「Frame 184」や「Button Copy」は見た目を整えても意図を隠します。PixsoのUIデザインメーカーでレイヤー、コンポーネント、variantとhandoffを同じ語彙で確認します。
1. 命名で達成すること
名前はアセットを探し、役割を予測し、別の画面でも意味を保ち、コードとの対応を説明できる必要があります。カテゴリと目的を名前に、サイズや状態の差をvariantに置きます。
詳細を一つの長い文字列に詰めず、説明、ドキュメント、使用例を使い分けます。検索、変更議論、handoffの3場面を実画面でテストします。
2. 小さな命名文法を作る
Category / Component / Subcomponentのようなカテゴリ先頭は、Navigation / Tabs / ItemやInput / Select / Optionを探しやすくします。大文字、区切り、単数形、略語を一度決めます。
Blue Buttonのような外観名を避け、Primary Buttonのように役割を示します。Pixsoのスラッシュ検索と衝突しない区切りも確認します。
3. 意味でコンポーネントとvariantを命名する
コンポーネントは最初に使った画面ではなくシステム上の役割で名付けます。variantはsize、emphasis、state、icon positionなど予測できる質問に答えます。
type=oneやversion=newのような履歴名を避け、components、styles、variables、assetsに同じ用語を適用します。
4. レイヤー名で構造と動作を示す
構造・操作レイヤーは目的を示します。label、supporting text、dismiss actionのような意味名は、フォントや色が変わっても会話に使えます。
- 外観より目的を先に置く。
- 同じ役割には同じ語を使う。
- slotとproperty名をドキュメントに合わせる。
- 内部の作業履歴を公開名に残さない。
- 非推奨パターンは移行記録とともに扱う。
5. token、asset、説明をそろえる
gray-700やblue-500は値であり役割ではありません。semantic tokenは用途を示し、アイコン名はsearch、download、warningのように内容と文脈を表します。
使う場面、避ける場面、property、受け入れるコンテンツ、必要なstateをコンポーネントの近くに記録します。
6. 既存ライブラリを安全に移行する
成熟したライブラリを一度に改名しません。使用数、owner、重複、依存を棚卸しし、使用頻度の高い一つのfamilyで新旧名を対応させます。
PixsoはFigma、Sketch、Axureのファイルやライブラリを取り込めます。variant、font、prototype trigger、Auto Layoutを検証し、Smart Renameの候補も限定してレビューします。
7. Pixsoで共同レビューする
命名規則は用語会議だけで決めず、designerが探す、variantを作る、画面を組む、developerが対応を読むというタスクで確認します。コメントの決定をドキュメントへ移します。
8. handoffに意味を持ち込む
production componentでdesign name、code counterpart、properties、tokens、states、content constraints、responsive rulesを示します。D2Cコードは検査を助けますが、本番実装と同一ではありません。
最終監査
- 名前が画面や色ではなく安定した役割を表す。
- variantが有効な選択肢を表す。
- レイヤー名が構造と操作を説明する。
- tokenが意味を示し、primitive値を保持する。
- 検索、説明、コードの用語集が共通である。
- 移行にowner、テスト、deprecation案内がある。
結論
良い命名規則は検索、拡張、レビュー、移行、実装を容易にします。文法を小さく保ち、目的で名付け、variantで差を管理し、Pixsoのレイヤーからhandoffまで語彙をそろえてください。
