AI時代以前のとっととデザインデータを作る方法（前編）

このnoteは株式会社ログラスのデザイナーAdvent Calendar 2025の、12日目の記事です。

挨拶

株式会社ログラスでプロダクトデザイナーをやっています。打田です。
みなさんAI時代、生き抜いてますか？僕はもう生き抜けない方になりつつあるので、ギリギリで生きている方も、生き生きと新しい時代を生きている方もただただリスペクトです。

今回はアドベントカレンダーということで、AI時代にはもう古びてしまった道具の作り方と使い方を供養がてらに展開してしまおうかなと思います。大工のじいちゃんの昔話に付き合っておくれ🔨

この記事は誰向け？

全てのデザイナーに...と言いたいところですが僕がtoB SaaS経験に偏っているので、toB系のSaaSソフトウェアをデザインしているプロダクトデザイナーさんが一番メインターゲットになると思います。
ちなみに使用技術はFigmaになります。

二部構成です

短くまとめようと思ったんですが、小ネタをどんどんリストアップしたら結構な量になったので、前編後編に分けています。
前編では超簡単なコンポーネント集の作りかたを、後編ではそれらを組み合わせたページレイアウトとページの遷移構成パターンの紹介をします。

改めてAIの出現で古の老兵になってしまった👨‍🦳

AIの登場も相まって、もはや表面的なUIデザインはかなり精度高くAIが作ってくれるようになりました。これまでのハードスキルは以前ほどの威力もなく、老兵の古い知恵くらいになってしまった実感があります。
とはいえAIと組み合わせると便利な側面も多分にあると思っています。ということでデザインの特に手の地力を上げる方法を共有しようと思います。

昔はこうやって稽古したもんじゃよ💪

何はともあれ暗記じゃ

デザインにおけるセンスとは誤解を恐れず言うと「相性のいい最小単位の組み合わせ能力」です。
およそこの世の製造物は、例外なく小さな単位の組み合わせでできています。ギリシャ彫刻ですらそう。とするなら、UIの最小単位を暗記して身につけてしまうのは手っ取り早い稽古です。

ということで以下のデザインシステムの何個かを暗記してください。
なお暗記するのはコンポーネントの名前と役割と見た目です。デザインシステムには他にもいっぱいルールが書いていますが、まずはそこから学習してみてください。

Material Design 2

Carbon Design System

Atlassian Design System

大体同じ部品が出てくるので、共通部品は覚えた上で世の中のUIを改めて見てみると、大体それらでできていることに気が付きます。これができるようになると、世の中のUIの分解点が見えるようになるので、構造把握がしやすくなると思います。

あれはまだデザインデータを手で作っていた時代の話じゃ🖐️

有名デザインシステム、暗記できましたか？
ある程度頭に入ったところで、最低限必須の小道具を揃えます。腕利きの大工さんも手道具の刃物を研ぐところからですから。

ということで以下のコンポーネントを揃えてください。大概の画面は作れます。
上から重要な順番に並べており、HTMLタグに登録されているものが優先になっています。
そうすれば最終的なHTML表現とコンポーネントが1:1に近づき、現代のブラウザにおける「単位」に近いコンポーネント設計ができます。

※注意
以下の解説はモダンフロントエンドのprops設計ではなく、あくまでFigma上のプロパティ管理の解説と考えてください。
実装だとコールバック関数をpropsとして呼び込めるかなど、挙動に関しても設定が可能なので、Figmaで表現可能な要素の範囲を超えているためです。

コンポーネントライブラリ

ボタン系

■ボタン

言わずと知れたボタンです。
type・state・size・appearance（見た目）の種類あたりの掛け算で膨大に増えることが多いですよね。

type	size	state	appearance
primary	small	default	fill
secondary	middle	hover	outline
tertiary	large	disabled	ghost
destructive	-	active	-
-	-	loading	-

↑こんな感じでしょうか
この時点ですでに4×3×5×3=180通りの組み合わせがある形になりそうですよね。
個人的にコンポーネントファイルが膨らむと管理がしづらいので、sizeのvariantのように特定の数値が違うだけのバリエーションはトークンとして切り出して(※1 variantを圧縮してしまうことが多いです。
これで最大でも4×5×3=60通りくらいまでにパターンを圧縮できるのでコンパクトな管理ができます。
もっと小さく管理したい場合はtertiaryやloadingをカットして3×4×3=36通り程度に押さえることも可能です。

(※1
sizeトークン

name	value
small	32
middle	40
large	48

みたいな感じに値だけ切り出して、適宜高さに当てます。概ね幅は内側のコンテンツか外側のウィンドやモニター幅に依存するので、サイズは事実上高さに当てるトークンだと思っていてください。

インプット系

■全体に共通

インプット系は大体見た目が似ているものが多く、要求される機能・状態もほぼ共通なので、以下の要素とstateが揃ってればいいと思っています。

state
empty
filled
focused
error
disabled

要素
以下はshowのtrue・falseのプロパティをつける感じでいいと思います。

• ラベル
• エラーメッセージ
• 補助メッセージ

上記の要素を別のコンポーネントにして管理しているパターンもよく見かけますが、Figma上のデザインコンポーネントの管理としてはそこまで細分化しない方が良いです。
Figma的にはNested componentが増えるとパフォーマンスが悪くなりやすい上に、まとめて一気にプロパティを変更がしづらいため、デザイン作業上の取り回しが悪くなります。

また、実装のライブラリを意識しての構成だとは思うのですが、経験上実装との1:1対応はお勧めしません。
実装側の方がFigmaより表現力が高く、制約が少ないため、必ず実装側がやりたい構成にデザイン側が追随できなくなってくるからです。
　

■テキストインプット・テキストエリア・サーチ

テキストインプット

テキストエリア

サーチ

いわゆるテキストを打ち込むinputのコンポーネントです。autocompleteをつけるかどうかなどの細かい設定はありますが、概ね「全体に共通」の要素がクリアできていればできるイメージです。

■日付・期間

カレンダーです。日付を選ぶケースと期間を選ぶケースがあります。
複雑なUIを用意して、旅行サイトみたいな期間指定カレンダーを作っても良いし、単に開始と終了の日付を選択させるだけでもいいです。
なんにせよカレンダーは自前で全部作らずにライブラリを利用することも多いと思うので、適宜それらの道具の制約に任せる形で作ってください。

■ファイルアップローダー

ファイルを上げる時のinputです。
ファイルは

• 単独で上げる
• 複数上げられる
  • 1個ずつ上げられるのか
  • 一気に上げられる
• 上げたファイルをPOSTするまでは消せる

あたりの制約が付いてくることが多いです。
複数挙げられる場合は受け付ける拡張子の兼ね合いなどもありますので、複雑な機能になりやすいです。丁寧に考えて作ってみてください。

■チェックボックス・ラジオボタン

いわゆる選択式UIです。どちらもON・OFFどちらの状態でもdisabledがあり得るため以下のようなプロパティ構成になるでしょうか。
ちなみにこちらもラベルと分解してコンポーネントを管理しがちですが、既述の理由からラベル込みでコンポーネントにしてしまった方がFigma上では良いです。

ラジオボタン

state	isActive
default	true
focused	false
disabled	-

チェックボタン

state	checkState
default	checked
focused	unchecked
disabled	indeterminate

■セレクト・コンボボックス・ドロップダウンメニュー

ドロップダウンで出すinputコンポーネントです。
セレクトは原則一つだけ選択で、コンボボックスは出てくるメニュー次第で割となんでもありなコンポーネントです。
こちらも概ね「全体に共通」の要素がクリアできていればできるイメージです。せいぜいメニューのバリエーションがいろいろ変わる程度でしょうか。
一応メニューは

• 単数選択
  • ツリー構造単数選択
• 複数選択
  • ツリー構造複数選択

あたりのバリエーションがあります。

テーブル

■テーブルヘッダー

テーブルのラベルに当たるコンポーネントです。
UIとしてはラベル程度の扱いですが、データとしてはカラムヘッダーに当たるものでかなり重要度の高いコンポーネントです。見た目のstate以上にカラムに対して行えるアクションをどうするかが重要になります。自分が見たことあるものは

• カラムのCRUD
• カラムレコードのフィルタ・ソート
• カラムの型変更

あたりです。

■テーブルセル

テーブルの入力コンポーネントに当たります。
コンポーネントとしては単純なものですが、パターンを作る最たるコンポーネントでもあります。またいろんな型の値を入力したくなるコンポーネントなので、データの種類ごとに見た目が少し変わるものでもあります。
ここまでのinputのサーチ・ラジオボタン以外は全てセルの挙動として出現しうるものです。また、SaaSプロダクトではエクセル以上にたくさんのセルの状態が出現します。今まで見たことがある状態と型とその他の要素は以下です。

state	type	hasComment
default	text	true
filled	integer	false
focused	float	-
disabled	date	-
functionalError	select (relation)	-
referenceError	link	-
-	file	-
-	formula	-
-	rollUp	-

ちなみにselectは他のテーブルへのリレーションの形で出現します。自分はこれまで以下のようなものを見つけました。

• 単数選択 or 複数選択の切り替え
• 任意のテーブルのレコードのキー選択
• 任意のテーブルのカラムのレコードを選択
• アカウントや人の選択

ステート周り

■チップ・タグ・バッジ

チップ（タグ）

バッジ

呼び名がライブラリごとに違っていたりする奴らですが、一般的には現在のstateを色・アイコン・文字で示すことをメインの責務としたコンポーネントです。
アイコンは結構おまけ扱いされやすいですが、識字や色覚に異常がある方へのアクセシビリティを考慮すると意味があると思っています。

ナビゲーション周り

■タブ

ページ内でさらにビューを分けるために使うコンポーネントです。
テーブルと組み合わせた時はフィルタビューとして扱われたりするので、割と汎用的に利用されます。
こういう書き方をすると、どちらで使うべきかという話になりやすいですが、ビューを分けるということ以上の意味は方々で与えてやればいいので、コンポーネントに利用方法をあまり頑張って封入しようとしなくていいと思っています。

その他

■ツールチップ

アイコンにホバーした時などに出るあれですね。
これは特段書くこともないので、グラフィックだけ添付しておきます。

■アイコン

適宜必要なものを追加していく形でいいです。自分はもっぱらMaterial iconsを利用していました。

アプリの雰囲気を大切にするなら、角丸の大きさと線の太さである程度イメージを変えられます。
toBだとそこまで重視されづらい部分ではありますが、角丸の工夫は割と効果大なので、自分でアイコンをある程度作れる方なら挑戦してみてください。

Material designのiconの制作ルール

デザイントークン

■色（一番重い）

ここは企業によって全然違う分け方をしているので、各社がんばって作ってください。
個人的にはFigma公式が出しているSimple Design SystemのVariablesが参考になりました。

Primitive tokenとそれを参照するSemantic tokenに分けて管理するやつですね。
とりあえずPrimitive tokenとして最低このくらいの色を各10段階程度用意できてると便利です。あとは適宜アクセントのための色を追加していく感じで大丈夫です。

color	description
red	赤：エラー色で使う
blue	青：リンク色で使う
green	緑：成功色で使う
yellow	黄色：注意色で使う
gray(neutral)	グレー〜黒：文字色やボーダーなどほぼ全ての基本色で使う
white	白：背景色や黒地の文字色などに使う

またSemantic tokenは細かくし出すと無限に分かれていくので、Simple Design Systemの

• background
• text
• border
  で大きく分ける分け方はトークンを少ない量に収束できて好きです。

個人的にはshadowとiconとtextの色を変えたい時のことを考えて、

• background
• text
• icon
• border
• shadow
  くらいの大カテゴリで管理をしています。

■Gap用スペース

これは4と12を追加した8の倍数を適宜追加していくくらいでいいです。
toB SaaSなら40を超えるほど隙間が欲しいことは滅多にないのでこんなもんでしょうか。

name	value
space-4	4
space-8	8
space-12	12
space-16	16
space-24	24
space-32	32
space-40	40

■角丸

角丸です。全丸と適宜4の倍数刻みくらいがあれば十分かなという印象です

name	value
round-4	4
round-8	8
round-max	9999

■elevation

ここはちゃんとやると高さ・影の色や座標・ブラーの大きさなどが諸々出てきますがMaterial designのelevationの分類が参考になりました。（自分は2の方が好き）
Material design 2の方

Material design 3の方

フォントスタイル

■フォントファミリー

何も考えずにどのプラットフォームでも動きやすいものを選ぶなら「Noto sans JP」で終わりかもですね。好きなのを選んでください。

■ウェイト

文章用とヘッダー用が一つずつあれば基本は事足ります。
同じウェイトでもサイズで印象は変わるので、ここのバリエーションをたくさん持つ必要はあんまりないです。

weight
regular
bold

■サイズ

大体以下でしょうか。人によっては18とか40を抜く方もいると思いますが、toB画面は要素が小さく、画面が詰まっていることも多いので、24までは刻むくらいの方が取り回しがいいです。

size
10
12
14
16
18
20
24
32
40
48
64

■ラインハイト

基本文章用とヘッダー用があれば十分で、ヘッダー用の方が小さいことが多いです。
1/4でやる人は25%刻みで、1/3でやる人は33%刻みになるように調整してください。自分は1/4派です。

line-height
125
150

この話はもうちょっと続くんじゃ↩️

はー、疲れた。老いぼれの長話にここまで付き合ってくれてどうもありがとう。
ここまででも結構なボリュームになってきたので一旦前半戦完ということで切り上げましょう。
後半はいよいよこれらの道具をどう組み合わせて、どう管理していくかを紹介します。

会社紹介

前半終わりに一度弊社を紹介させてください。
ログラスでは、一緒に良い景気を作ってくれるプロダクトデザイナー、BXデザイナーを大募集中です。
もしこの記事を読んで興味を持たれた方は、ぜひカジュアルにお話しましょう！

プロダクトデザイナー

BXデザイナー