コーディングしやすいFigmaのデータ作りを考える

🎄 はじめに

Qiita株式会社 Advent Calendar 2021の9日目の担当は、Qiita株式会社プロダクト開発G デザインTMの相澤（@aizawa213）です！よろしくお願いします！

これは何

私は今年新卒でQiita株式会社に入社し、デザイナーとして働き始めました。
会社という組織の中でデザインをする中でコーディングしやすいFigmaの重要性を改めて感じ、整理してみました。

これが正解だ！というものではなく、コミュニケーションを取りながらブラッシュアップしていきたい内容ですので、「これは違いそう」 「こういうのも欲しい」 などありましたら、編集リクエストやコメントいただけますと幸いです！

前提共有

この記事は、以下のような状況を前提としています。
状況によっては当てはまらない内容もあると思いますので、ご了承ください。

• WebサービスのUIデザインをFigmaで作成する
• Figmaを見ながらデザインを作成した本人以外の人がコーディングする
• デザイナーがマークアップ/スタイリング部分を担当/レビューするチーム

起こりがちな課題を洗い出す

まずは、Figmaのデータを渡してコーディングをお願いしたで置きがちな課題を羅列してみます。

想定していたマークアップとズレている

私がWebサービスのUIをデザインする時は、基本的にマークアップを想定してデザインをしています。

コーディングする時に再度マークアップを考えるのは二度手間ですし、デザインした人の想定と違うマークアップをすると、情報構造やレスポンシブ時の挙動が意図したものと変わったりしてしまいます。

想定していたスタイルとズレている

色やフォント、余白の指定などがFigmaとズレている、というのはありがちかなと思います。

また、余白のサイズが合っていても、paddingにしたかった所がmarginになっているというのもあるあるです。

想定していた挙動をしない

HoverやDisabled、Focus、Blankなどのステート変化がある場合の挙動は「そもそもデザインする時」「デザインを伝達するとき」「実装する時」それぞれで漏れがちです。

また、コンテンツが変わる要素は、コンテンツがはみ出そうな時にどうするのかなども考慮する必要があります。

仕様に関するコメントと、仕様以外のコメントが入り乱れて分かり辛い

上記のような伝達したいことをFigmaのコメント機能で残すと、その他のレビューコメントや確認コメントに埋もれてしまいがちです。

結果として、コメントを残しておいたのに見つけられない、という結果になってしまいます

コーディングしやすいFigmaデータを考える

どんなデータ作りをすれば上記で洗い出した課題を解決できるかを考え、以下のようなリストを作成しました。

• 前提ルールが共有されている
• マークアップの意図が分かりやすい
• スタイルの指定が分かりやすい
• 共通部分と相違部分が分かりやすい
• 状況によって変化する部分が分かりやすい

それぞれ詳しく書いていきます。

前提のルールが共有されている

まず、デザイン/コーディングで頻出するもの（色やフォントの指定、ボタンなどのコンポーネント）は前提ルールとして共有されていると、各ファイルでのコミュニケーションを減らすことが出来ます。

Qiita株式会社では以下のようなものが、私が入社した入社した時点でデザインシステムとして定義されていました。

• ColorやFont sizeなどのよく使うスタイル
• ButtonやInputなどのサービス横断で使えるコンポーネント
• HeaderやFooterなどのサービスごとのコンポーネント

こうしたよく使われるものを予め定義し、参照できるようになっていることで、ファイルごとのコミュニケーションを減らすことが出来ています。
ボタンやInputなどの状態変化する要素にはVariants機能でそれぞれのStateも定義されています。

詳しくは以下のQiita Blogで紹介していますので、是非ご覧ください。

• Qiitaのデザインシステム公開のお知らせ（前編）
• Qiitaのデザインシステム公開のお知らせ（後編）

マークアップの意図が分かりやすい

私がFigmaでデザインを作成する場合、ある程度マークアップの構成を考えてデザインすることが多いです。また、考えたマークアップの構造を元にレスポンシブの挙動なども想定してデザインをしています。
そのため、Figmaのデータで意図したマークアップを伝えられれば、コーディングする時に再度マークアップを検討する二度手間や意図しない挙動を減らすことが出来ます。

以下のようなデータ作りで意図が伝えられそうです。

divやsectionなど、マークアップでタグで囲む部分はFrameにし、逆にマークアップで囲わない部分はFrameにしない
こうすることで、ある程度どこをタグで囲むかが伝えられます。

また、タグを連想できるFrame名にすることで意図したマークアップを伝えることが出来ます。

• Ex
  • <section /> → 〇〇 section
  • <ol />,<ul /> → 〇〇 list
  • <li /> → 〇〇 list item
  • <article /> → 〇〇 article card

逆に、リストじゃないのにlistをつけたり、Sectionなのにwrapperにしたりすると、紛らわしいFrame名をつけないようにするのも大切そうです。

スタイルの指定が分かりやすい

プロパティに関しては、FigmaがInspectパネルにわかりやすく表示しれくれます。

こんな感じ

また、マークアップを意図した構造にすることで、レイヤー構造からどこからどこまでが一つのオブジェクトなのかを読み取ることができるようになります。
これによって余白をPaddingで取るのかmarginで取るのか、背景色はどこまでつけるのかなども読み取れるようになります。

共通部分と相違部分が分かりやすい

UIを作っていると、繰り返しのパターンが高確率で発生します。
繰り返し出てくる要素はコンポーネント化することで、同じスタイルで良いことが分かりやすくなります。

逆に、「すごく似ているけど微妙に違う要素」もある程度発生します。また、FigmaではコンポーネントにOverrideでかなり柔軟な変更を加えることが出来ます。

こうした場合は、違う部分や変更した部分をコメントに残すなどしておくと、対応漏れが防げます。

状況によって変化する部分が分かりやすい

「共通部分と相違部分が分かりやすい」に近いですが、UIはしばしば状態によって見た目やコンテンツが変化します。
Blankの場合やLoading、HoverやDisabled、デバイス幅による変化、テキストが増減した場合など、考慮すべき状態が色々あります。

これらの状態変化がデザインデータで作成しておく必要があります。
また、せっかく作成しても見つけられないと意味がないので、置き方にルールを設けたりラベルをアートボード上に設置して、見つけやすくすることが出来そうです。

また、Hoverの挙動や画面遷移、スクロール時の挙動などはプロトタイプ機能を活用することでスムーズに伝達することが出来ます！

分からないなってなった時に、すぐ聞ける

ここまで色々考えてみましたが、最終的に大切なのは「ここよく分からないな」となった時に、気軽に聞いてもらえることかなと思っています。

人間がやる以上、完璧なものを作ることも、完璧に読み取ることも難しいです。

もちろんより良いデータづくりのための努力はしつつ、「ん？」となった時に気軽に聞きに来てもらえるデザイナーになれるよう精進します！

おわりに

ここまで読んでいただきありがとうございました！

明日の Qiita株式会社 Advent Calendar 2021 は、Qiita株式会社 共同基盤開発グループの水井(@mziyut)が担当します！