この記事は12月22日に行われた「Figma Design File 大公開！ デザイナー忘年会2022」で話した内容を記事化したものです。
デザインデータは中間成果物
これはこの記事のベースとなる考え方です。僕はデザインデータは中間成果物であり、いつか捨てられる（メンテされなくなる）ものだと考えています。
デザインデータを作る目的はエンジニアやBizDevの人たちとのコミュニケーションを円滑に進めることです。その目的を達成する以上に整っている必要はないと考えています。
また僕は実装されお客さんが実際に利用するアプリケーションの品質が全てだと考えていて、デザインデータをきれいに整えることは時間の無駄になることが多いと思っています。本当に考えるべきことはデザインデータをきれいに運用することではなく、品質の高いUIがきちんとリリースされる仕組みです。
しかしあまりにも無秩序に散らかっているとコミュニケーションを阻害することになってしまい良くないです。そこでデザイナーが最低限守るルールや則るべきフォーマットを整備することが大事です。Ubieでは次のようなルールやフォーマットを定めています。
最低限守るライン
- デザイントークン
- Auto Layoutをできる限り使うこと
- etc...
フォーマット
- ファイル分割の単位
- Ubieではスクラム開発にデザイナーも参加しているのでPBI（プロダクトバックログアイテム）ごとにファイルを作っている
- カバー画像の作り方
- JIRAでチケットからカードを作るWidgetを使用している
- https://www.figma.com/community/widget/1094001923188252679/Jira
- ファイルの中の構成
- Main：FIXしたデザインが置いてある場所。エンジニアはここを参照して実装する。
- Workspace：デザイナーが作業する場所。
- README：カバー画像やドキュメントへのリンク置き場。
- Embed：外部サービスにEmbedするアイテムを置く場所。誤って削除してリンクが行方不明になったりしないように場所を分ける。
- Archive：古いデザインのアーカイブ先。ボツ案も消さずに残す。
プラグインに業務を依存しない
僕は業務にプラグインをできるだけ組み込まないようにしています。個人でプラグインを使うぶんには何も問題ないですが、業務に組み込んでしまうとメリットよりデメリットのほうが大きいと感じます。
プラグインを使って業務設計をするとそれぞれのツールの使い方を説明しなければならずオンボーディングコストが上がります。ツールに詳しい人がその説明に時間を割かなければならず負荷が集中してしまったりツールに詳しい人間が退職してしまい使い方がわからず業務に支障が出るかもしれません。
ツールの学習コストは低ければ低いほどよいです。プラグインを業務に組み込むと指数関数的に業務プロセスのカオス度が増してしまうので導入には慎重になる必要があります。
またプラグインが急に使えなくなったときも困ります。Atlassianなどの大き会社が作っているツールならともかく個人が開発しているツールはいつメンテナンスが終了するかわかりません。そのようなツールを業務に組み込むことはとても危険です。
ツールはできるだけシンプルに保ち、ツール本体で解決できないことは無理にプラグインで解決ぜず適度に諦めたり仕組みやワークフローで解決することで、サスティナブルなデザインワークフローが構築できるはずです。プラグインという小手先のHowに頼りすぎないようにしたいです。
デザインが雑でもきちんと実装される仕組みを考える
デザインデータをきれいにしたいモチベーションの1つに「デザインデータをきれいに整えることで意図通りにきちんと実装してもらいたい」という思考があると思います。
こう考えるデザイナーの気持ちも理解できますが、デザインデータをきれいに整えることは実装品質の向上にさほど役立たないと思います。なぜならエンジニアの大半はデザインデータからデザイナーの意図を汲み取れないからです。
デザインの意図を汲み取れないエンジニアのUI実装品質を向上させるためには、デザインのルールをエンジニアが使えるフォーマットに変換してあげることが必要です。
FigmaはWeb APIから情報を取得できるのでデザインデータからルールを抽出してコード化することが可能です。UbieではデザイントークンやアイコンをFigmaから自動でコード化する仕組みを整えています。
まとめ
Figmaとは適度な距離感を保って良い関係を続けていきたいですね！みなさん良いお年を！
Discussion