デザイナーとエンジニア、両者の目線が大切なコンポーネント粒度の設計

この記事は株式会社SODA初の外部向け勉強会、SODA Flutter Talk #1で登壇した際の資料を1部抜粋したものです。

https://soda-inc.connpass.com/event/316752/

株式会社SODAではモバイルのアプリをFlutterで開発し、デザインをFigmaで作成しています。
コードサンプル等はFlutter(Dart)で書かれていますが、その概念等はどのフレームワークでも応用できるはずです。

SODAでは事業を成長させる過程でFlutterのWidget数も増えていきますし、FigmaのComponent数も増えていきます。
効率よく開発を進めていくにはエンジニアとデザイナー両者の目線でコンポーネントづくりをしていく必要があり、実際にどのような工夫をしているのかをこの記事で紹介します。

コンポーネントの粒度における課題

エンジニア目線の理想の粒度

エンジニア目線のコンポーネントの粒度で一番大切なのはFigmaのComponentの粒度と揃えることです。
もし粒度がそれぞれ異なると、Figma側の変更に対してFlutter側の変更の範囲が異なってしまうため、思わぬバグが生まれてしまう可能性もあります。

ex)形は似てるが別のComponentとして作成されている

/// FigmaのComponentと抽象度が一致していないWidget
class ComponentAB extends StatelessWidget {
  ...
}

さらに欲を言えばカラーやテキストなどは異なるが、サイズなど基本的な形が一致しているComponentは1つとして定義されているほうがコードの総量が減ってメンテナンスはしやすいはずです。
つまり抽象度をあげるということです。
(形が似ていてもコンポーネントの役割が異なる場合はもちろん統一しない方が良いです。)

FigmaのPropertyを使ってテキストを定義している。

デザイナー目線の理想の粒度

デザイナー目線ではComponentの使いどころがなるべくわかりやすい方が使いやすいと言う意見がありました。
例えば、ComponentAとComponentBは形や役割は同じだが使う画面によって分けているなどのケースです。
こういったComponentは抽象化しすぎてしまうと、どう言う使い方されるかが把握しづらくなってしまいます。
(もちろんComponent1つ1つにドキュメントを作成すれば解決されるかもしれませんが、そのコストに見合うかは微妙なところです。)

もちろん、事業によってデザイナーの求める粒度も違うと思います。
その認識を揃えるためにコミュニケーションをエンジニア側から投げかけるのが良いはずです。

FigmaのVariantとFlutter(Dart)の名前付きコンストラクタを使った設計

• エンジニア目線: Figmaとコンポーネントの粒度を揃え、なるべく抽象化したい。
• デザイナー目線: Componentをある程度具体化することでユースケースをわかりやすくしたい。

これらの認識を揃えるべくSODAでは毎週30分~1時間ほどのミーティングをデザイナーとFlutterエンジニアで行っています。
そこで話した内容を紹介します。
Figmaの整理もFlutterの実装も斬新なものを紹介しているのではなく、割と当たり前のことだったりするかもしれませんが開発を効率的に行うための参考になれば嬉しいです。

FigmaのVarinat機能を使ったComponent

FigmaのVariant機能を使って複数のComponentをまとめました。
Variantというのは類似のComponentを1つのComponentとして扱う機能で、例えばボタンのEnabledやDisabledを1つのComponentとして定義することが可能です。

この機能を使い類似するComponentを1つのComponentとしています。

Flutterの名前付きコンストラクタを使ったWidget

デザイン側で抽象化を行ってくれたので、実装もそれに合わせた粒度でWidgetを作成しています。
変数もFigmaのPropertyに合わせたインターフェイスを意識していますが、特にVariantで作成されたComponentの"パターン"をFlutterで表現するときは名前付きコンストラクタやFactoryコンストラクタを使って表現しています。

class ComponetA extends StatelessWidget {
  /// ComponentA/a
  const ComponetA.a({
    required this.child,
  }) : color: Colors.blue;

  /// ComponentA/b
  const ComponetA.b({
    required this.child,
  }) : color: Colors.green;

  final Color color;

  ...省略...
}

運用してみてどうだったか

SODAでは毎週新しい機能の実装に取り掛かったりと変化の早いプロダクトだと感じています。

そんな中で、実際この運用を始めてみて、FigmaとFlutterのコンポーネントの粒度が揃っていることで設計もしやすいですし、命名なども統一しやすいなと感じています。
すでに存在しているComponentを一気に揃えていくのはかなりの時間を費やすことになるので、直近で触る箇所からデザイナーとエンジニアで話し合って整理して行っています。

また、毎週のミーティングではマテリアルデザインやHIGをはじめとする他社のデザインシステムを参考にすることが多く、エンジニアリング以外のスキルが磨かれていく実感があってとても楽しいです。

その他デザイナー←→エンジニア間のコミュニケーションを円滑に進めていけるようなことをしていきたいなと思っているので別で紹介できたらなと思います。
もし興味があればTwitter等でフォローしてもらえると嬉しいです。

https://x.com/imasirooo