デザインと実装の違いをどう学べばいいかを探る

Gaji-Labo UI デザイナーの伊藤です。
デザイナーのみなさんに質問です。デザイン作業を行なっていて、「このデザイン、本当に実装しやすいのかな？」と思ったことはありませんか？私はたびたび思います。

「 Figma のコンポーネントと実装のコンポーネントは違う」「デザイナー視点だけで作ると、エンジニアが苦労する」という話はよく耳にするのではないでしょうか。
私は具体的なケースについて、ある程度把握し、対応していますが、エンジニアはどういう時に困るのか、その根本を理解できているかは怪しいところです。

その不安を解消するために、この記事では、「デザイナーに不足しがちな視点」と「どう学んでいけばいいか」を考えていきます。

情報収集してみる

なんとなくわかっていない……を脱却するためにひとまず情報を集めてみることにしました。

弊社エンジニアに聞いてみる

デザインを確認し、実装をしていく過程で困った経験を聞いてみたところ、次のような意見が集まりました。

1. スペーシングの問題: コンポーネント自体に外側の余白（ margin ）を含めると取り扱いに困ってしまう
2. State やパターンの抜け漏れ: 必要な State が揃っていない場合がある。例 :focus-visible
3. コンポーネントの肥大化: 後から State が増えることで、コンポーネントが肥大化してしまうことがある

また、ざっくりでも違いを把握するために、 Figma と実装のコンポーネントの違いは何か、AIに聞いてみました。

あくまで参考なので全文書き起こしはしませんが、大まかにこういう違いがあることがわかります。

• Figma : 静的な「見た目の設計図」
• 実装: 動的な「機能するプログラムの部品」

なぜエンジニアは困るのか？

エンジニアの声と AI の回答を突き合わせると、エンジニアが困ってしまうデザインでは、「動的に考える」視点が不足していると推測できます。
今回エンジニアに回答いただいた問題それぞれについてどのような視点が必要かみていきます。

1.スペーシングの問題

なぜコンポーネントの外側に余白がついていると問題なのか？
コンポーネントは、どんな場所にでも自在に当てはめることが必要だからです。
余白が外側についていると、当てはめる場所によっては、都度余白の調整が必要になる可能性がでてきます。取り回しのよいコンポーネントにするためには、レイアウトとパーツを切り分けて考える必要があります。

デザイン上で「ヘッダーの下には必ず64 px の余白がつくから余白も含めてコンポーネント化した」という例は過去何度か見たことがあります。
ページデザインを作る過程で、余白の一貫性を保ちやすくすることに重きを置いた結果かなと思います。そのように管理したい場合、エンジニア宛に実装時にはコンポーネントに余白を含めなくていいことがわかるよう書き添えをする必要がありそうです。

もっとも、 Figma では Variables で数値の管理ができるので、 AutoLayout と組み合わせて余白を設定するようにしたいですね。

必要な視点: コンポーネントは特定の場所に当てはめるだけではなく、あらゆる場所で利用することができるような設計が必要。

2. Stateやパターンの抜け漏れ

必要なパターンがデザインから抜け落ちていると、エンジニアはどのような状態にするのかデザイナーに確認しなければなりません。手を止めさせてしまうことは避けたいところです。
ボタンひとつとっても、 :hover のようなわかりやすい変化だけでなく :focus-visible など普段あまり意識しないような状態も実装では必要になります。
どういった状態変化があるのか、自分が知らない状態変化はないか確認してみると良さそうです。
また、コンテンツによっては EmptyState のような入るデータの状態に合わせたパターン展開が必要な場合があります。極力抜け漏れが起きないように考慮しておきたいです。

必要な視点: ユーザーの操作やデータの状況によってどう変化するか、など多様な状態に関する知識が必要。

3. コンポーネントの肥大化

上記の2点とは違い、表層からは理解しづらい問題です。
私もきちんと把握ができていないのですが、具体例を考えてみました。
最初は「通常」と「無効」の2パターンを定義したボタンにあったとして、後から「アイコン有り」「サイズ違い」といった Variant が追加されていく状況を想定します。
Figma 上では Variant が増えるだけに見えます。
しかし実装側では、「どのStateの組み合わせで、その結果CSSをどう切り替えるか」を管理するコストが雪だるま式に増えていくのではないでしょうか。

プロダクトの年数が経つにつれ、 State や Variant が追加が必要な場面が増えてくると思います。
デザインをする上でもパターンを追加していくだけではなく、コンポーネントを分割したり、不要な　State や Variant はないかを検証することも必要かもしれません。

必要な視点: コンポーネントに後から要素（ State や Variant ）を追加することで、見た目以上に実装側の管理コストが増大していくケースがある。

それぞれのケースにどういった理解が必要なのかは整理できました。
ですが現時点の理解では、自身が知り得ないケースについて対応できない可能性があります。
デザインをする段階から「動的に考える」ための勉強が必要そうです。
どんな学習が必要かを考えてみます。

学習方法を考える

UIデザインの観察

日頃から行なっていると思うのですが改めて、見た目だけではなく動的な部分に着目して観察をしていきます。

• どういった状態変化があるのか
• Tab キーで操作を行う場合はどのような順番でフォーカスされるか
• Banner message はどのような案内がどういうタイミングで表示されるか
  などなど

既存のUIライブラリの「ドキュメント」を読む

観察を行ったうえで、気になった UI について Material-UI (MUI) など、エンジニアが使うUIライブラリのドキュメントを読んでみるとより理解を深めやすそうです。
1つのボタンにどのような Props や State が定義されているかを見ることで、動的な考え方の解像度を上げられます。

Figmaの機能で「動的」な状態をシミュレーションする

Figma には、実装の考え方に近い機能が揃っています。これらを使って動きのシミュレーションをすると実装状態を想像しやすくなるでしょう。普段使っていない機能があれば触って理解を深めてみるとよさそうです。

• Variants を使って、 :hover や :focus などのStateを定義する。
• Variables を使って、スペーシングやカラーモードを管理する。
• Conditional Prototyping を使って、動的な変化を Figma 上で再現してみる。

実際にReactに触れてみる

最終的には実際に触れて作ってみるのが一番です。
実装時にどのような考慮をするかを理解するには体験することに勝るものはないでしょう。
とはいえ踏み出すハードルがやや高いので、Reactに触れるための第一歩として、LLM を使ってコンポーネントの作成と、解説をしてもらうというのも良いのではないかと意見を弊社エンジニアからいただきました。

おわりに

長々と書いてきましたが、動的な視点を身につけるためには知識をアップデートし続ける必要があるなと痛感しました。フレームワークが隆盛したあたりから自分でコーディングを行うことから離れてしまっているので、知らないことが盛りだくさんありそうです。
幸い、 Figma 自体も Variables や Dev Mode をはじめとして、どんどん実装に寄り添うように進化しており、理解しやすい環境が昔よりも整っていると感じます。できるところから一歩づつ地道に理解を深めていきたいと思います。