Figma + Atomic Design でUIコンポーネント集を作りました – KRAY Inc. より
これまで何度かコンポーネント設計の工程を挟むプロジェクトにマークアップエンジニアとして携わってきましたが、反省点も多く、未だに正解も見えない部分もあるのが実情です。
記事のタイトルでは偉そうに書いていますが、今回はデザイナーやエンジニアを含んだチームがコンポーネント設計をどのように行えば良さそうかを考えたいと思います。
※ ビジュアルデザイン、ディレクトリ構成、コードの実例等は本記事に含まれません。
※ 主にデザイン(情報設計、UI作成、マークアップ)から見た視点での内容です。
※ 基本的にはWebサイトではなくWebアプリケーション開発を想定しています。
まずはコンポーネント設計を適切に行えると、どのような利点があるのでしょうか。
1.はデザイン職種、2.はエンジニア職種が感じることが多い利点になるかと思います。
後ほど触れますが、これは同時に職種によって気にする視点が異なるということも言えそうです。
これらの利点によって、ユーザーや開発組織にとってはどのようなメリットが生まれるのかを考えます。
より分かりやすくするため抽象的な表現になりますが、
を高めることができるというのが私の現時点での所感です。
※ 話が広がるため深堀りしませんが、この議題で私の考えにしっくりくる記事は デザインシステムの目的を考える|seya|note になります。
逆にそんなコンポーネント設計の難しさを理解するために、ありがちな失敗例について見ていきます。
「コンポーネント設計 失敗」などでググると、下記の記事などが出てきました。
どの記事もAtomic Designというメジャーな設計思想(フレームワーク)を使用した際の失敗体験になっています。
これはAtomic Designを使用すること自体が難易度が高いという点もあると思いますが、共通して書かれている設計の難しさとしては下記にまとめることができそうでした。
これらは私も過去に感じたことがあった内容ですね。
以降ではこの問題をより解決に導くために、どのように取り組むべきかを考えていきます。
コンポーネント設計は、こうして取り組んだほうが良さそうという現時点での私の意見は次の3点です。
コンポーネントの分割について最も難しさを感じるのは、人によって解釈の違いが多いことだと思います。
この齟齬を埋めるにはデザイナーとエンジニアの共同作業が必要で、どちらかが関わるだけだと難しい印象です。
ただ、アウトプットの最初の出処がワイヤーフレームやビジュアルの場合が多いため、コンポーネント設計の話題についてデザインが主導になることが多くなるのは必然だと思います。
また、なるべく初期の段階でエンジニアも含めたコンポーネント設計についてのディスカッションをできると良さそうです。後述しますが、最終的に開発側の観点を採用したほうがメリットが多いため、後戻りをできる限りしないで済むようにするためです。
情報設計やワイヤーフレームを引いた後の段階で、コンポーネントの粒度をどうするか、の話し合いが始まるケースがありますが、できる限りその前の工程の段階で、どのような分割方針で行うのかを皆でディスカッションできると、エンジニア側が設計思想の理解やディレクトリの想定等もしやすいのではないかと思います。
※ 【React/Vue.js】コンポーネント設計の(個人的)ベストプラクティス | Offers Tech Blog の「設計はデザイナーと協業で行う」項と同じ意見。
いざコンポーネント指向で作っていきます、という段階で、
大きく分けて2パターンになるかと思います。
この判断は、そのプロジェクトの内容や使用するフロントエンドのフレームワーク、メンバーの経験などによって決めることが多いでしょう。
「何かしらの設計思想やフレームワークに沿って作る」場合、Atomic Designは最も聞き馴染みのあるコンポーネントの設計思想と思いますが、先ほども紹介したとおり、上手く出来ずに断念した、ということもチラホラみかけます。
理由はそれぞれのプロジェクト内容に起因すると思いますが、Atomic Designという設計思想を使うという決定以外にも、本来は考慮したり決めたりする事が多いから、というのが多い印象です。
例えば、下記などが「本来は考慮したり決めたりする事」にあたるかと思います。
要は、Atomic Designを使っているから上手く開発が進められる保証はありません。
デザイン観点では破綻せずになんとか使えても、特に開発観点を考慮するとプロジェクト内での独自でルール決めが必要なことが多い印象です。
この「プロジェクト内での独自でルール決め」がそもそも発生しない想定で時間を取っていなかったり、チームのコミュニケーションが取りづらい状況で発生してしまうと段々と混沌として来てしまうなということを経験した記憶があります。
デザイン側は、見た目的にコンポーネントをどのくらいの粒度や分割で、という意見を持ちがちですが、開発側の苦労(工数)を気にせず言っていることも多く、基本的には開発の意見を優先するほうが良いと思います。
特に先ほど「本来は考慮したり決めたりする事」の中の
- 開発側の観点で不都合がないか
- ディレクトリ構成をどうするのか
- データ・状態の持ち方
- Propsの流れ
- テストのしやすさ
など、なかなかデザイン観点だけでは考慮できないことが多いです。
※ デザイナーとエンジニアで考えるReactコンポーネント設計 - KitchHike Tech Blog の「"デザインとしての構造性" と "コードとしての再利用性"」項と同じ意見。
また、分割の粒度を小さくしすぎないことも重要と感じます。
コンポーネントを追加する際のコーディング時の作業として、下記などが挙げられますが、
粒度が小さいとどうしてもバケツリレー的な処理が増えてきてしまうため、見通しやすさとのバランス次第で気持ち大きめを最小粒度とすることもアリかと思います。
この記事を書くにあたり、他のブログ等も読みながら過去の経験を思い返しましたが、プロジェクトごとにも正解は異なると思うので難しい話題だなと感じました。
なかなか端切れの悪い記事にはなってしまいましたが、現状での考えはまとめることができて良かったと思います。
これからは特にデザインとエンジニアの境界の人がどのように立ち振る舞うべきか等、継続して考察していき以降のプロジェクトでも活かせればと感じました。