はじめに
こんにちは！株式会社ispecでフロントエンドエンジニアをやってるs.katoです🙇♂️
弊社ではWebアプリケーション開発の効率化や品質の担保のために、社内デザインシステムを作成しています。
私はエンジニアとしてその実装周りを担当しましたので、本記事ではエンジニアの視点からどのようなことを意識してデザインシステムの作成に参加したのか、を紹介していけたらと思っています！
具体的な実装方法や使用した技術などについて、というより実装の進め方や考え方、設計など抽象度高めな内容になっています。
完成品をつくらない
これは「特定のアプリケーションに限らず再利用され続けるもの」を実装する上で私が大切にしたいと思っている観念です。
具体的な考え方としては大きく分けて2つあります。
コンポーネントはある程度カスタマイズをして利用させることを前提とする
ちょっとプロパティを渡すだけでよしなにレンダリングされるようなリッチなコンポーネントも良いのですが、柔軟性を意識するなら一貫性を担保するための最低限のスタイリングだけして運用するときにさらに肉付けしていく、みたいなことを前提とした薄めの実装を心がけることも大事なんじゃないかなと思っています。コンポーネント利用側がカスタマイズできる余白をたくさん作ってあげるって感じ。
その点、Headless UIやshadcn/uiが参考になりますね。
複数の要素で構成されるコンポーネントを作るときは、可能な限り固有の実装を避けて既存のコンポーネントを以て構成する
DatePickerやPagerなどのような大きなコンポーネント(以降"上位コンポーネント"と表記)をデザインシステム側で実装する場合、可能な限り既にデザインシステムのコンポーネントとして作っているButtonやCardなどのような小さなコンポーネント(以降"原始的なコンポーネント")を組み合わて構成するように実装します。そうすると自然と上位コンポーネント固有の実装は薄くなり、原始的なコンポーネントはよりモジュール性が高くなるような実装が必要とされるようになります。
こうして実装された上位コンポーネントは分解が容易になり、「原始的なコンポーネントを組み合わせるとこんなものもできますよ」というような「使用例」としての側面も出てくるので、アプリケーションの要件に応じて構成要素を組み替えた新たな上位コンポーネントも作りやすくなります。
逆に固有の実装が厚い上位コンポーネントを作ってしまうと柔軟性を担保しづらい「完成品」になってしまうというワケですね。
ルールのコンポーネント化
デザインシステムには、余白の取り方や特定のレイアウトについてのルールなども含まれています。こういったルールは文章ベースのドキュメントを以て開発者側に従ってもらうのがベターかと思いますが、今回の実装においてはその辺も可能な限りコンポーネント化していく方針で進めています。(文章ベースのドキュメントも作成する/しないは別として)
以下、その方針に基づいて実装されたコンポーネントの例です。
FlexLayoutを使ったレイアウトを行うコンポーネント
gapの値のパターンをコンポーネント側で持つことで、アイテム同士の間隔のパターンを規定
このように頻出するレイアウト、スタイルをコンポーネント化することで最終的に開発者は、<div>タグや<p>タグのようなHTML要素を置いてclassを付与してスタイルを当てて...という作業をほとんどせず、ただコンポーネントを組み合わせていくだけで適切なレイアウトで画面が実装できるような状態を実現しています。
デザイナーとの密な連携
冒頭に私が「エンジニアとして」デザインシステムの作成に関わった、と書いたようにこの社内デザインシステムはデザイナーと役割分担をしつつ協働で作成しており、円滑にデザインの作成->実装への落とし込みを進めていくにあたって、以下のような取り組みを行っています。
- コンポーネントの設計方針やUX面を考慮したUIの構成について週次、また必要に応じて突発的に同期で相談する時間をとる
- 非同期で相談できる内容は文章ベースでコミュニケーションをとるが、細かなニュアンスなどものせて相談できるようにするため極力同期で相談しやすい空気感を作る
-
Storybook/Chromaticを用いて、実装したコンポーネントをデザイナーに実際に触ってもらってビジュアル、挙動のレビューをもらう
- デザイナーにも実際にブラウザ上で動かして検証してもらうことで考慮しきれていなかったUIの差分を見つけやすくする
- UIのデザインに関する意思決定に、エンジニアも積極的に参加する
- 「こんな感じでデザイン作成しようと思っているけど、実装する上で不都合とかある？」などのコミュニケーションを都度とることで、手戻りを減らしたり、アクセシビリティなどフロントエンド実装時に考慮すべき点も併せてUIの検討/設計を進めることができる
おわりに
「完成品をつくらない」項ではコンポーネントの設計について述べましたが、今回作成した社内デザインシステム本体も「完成品」としては作られておらず、今後の運用を通じて得られるであろうフィードバックを元にどんどん改善していくことを前提としています。
やはり最初から上手く設計して作り切ることよりも、後の運用プロセスが重要だと考えているので今後も積極的なアップデートをしていけたら良いなと思っています🥳
このデザインシステムの作成に携わったデザイナーの方からも記事が出ていますので、よければ併せてどうぞ🙌
Discussion