クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

crowdworks.jp のデザインシステム構築活動を振り返る 2023 (実装編)

この記事はクラウドワークス Advent Calendar 2023 シリーズ 1 の 21 日目及び、デザインシステム Advent Calendar 2023 21 日目の記事です。

こんにちは、crowdworks.jp のデザインシステム構築に携わっているエンジニアの @t0yohei です。 2023 年は crowdworks.jp にとってデザインシステムの実装元年でした。そんな実装元年において、エンジニアとして実施したことを書いてみました。

デザインシステムを実装中の方、これからデザインシステムを実装していこうという方の参考になれば幸いです。

目次

デザインシステムを学ぶ

デザインシステムについて何もわからないところから始めたので、まずはデザインシステムについて学ぶことから始めました。 参考にさせて頂いた書籍をいくつか記載いたします。

他にも、実際に運用されているデザインシステムとして、以下のデザインシステムを参考にさせていただきました。

Design Token の実装反映

crowdworks.jp のデザインシステム構築は、デザインチーム主導で始まりました。

そのため自分が実装担当として携わるより前に、新しいデザインシステム norman のブランドガイドライン・デザイン原則、及び Design Token の定義はほぼ完了していました。 そこで、実装としてはまず、定義済みの Design Token をコードに落とし込むタスクを行いました。

Figma 上で定義した Color の Design Token
Color の Design Token 実装

Design Token は上記添付画像のように、CSS 変数として実装しました。 json で定義した上で style-dictionary などを使用して CSS にパースする手法なども検討しましたが、始めやすさを優先して CSS 変数としてそのまま実装する方法を選択しました。

この実装にした場合、Figma の方で定義した Design Token との連携は手動で行う必要があるため、自動化改善ポイントの 1 つになっています。

実際に実装した Design Token としては以下のようなものが存在し、それぞれ Base Token と、それをベースにした Semantics Token から成り立っています。

  • BorderRadius
  • Color
  • Line
  • Shadow
  • Spacing
  • Typography

Design Token の分類や Base Token、Semantics Token への分割については デザインシステムを学ぶ で挙げた各種デザインシステムを参考にさせて頂きました。

関連: デザインシステムを導入する為にやって良かったこと5選| YUCCA

Design Token の画面適用

実装したものは早速使用してみよう、ということで会員登録画面ログイン画面など、複数の画面にて Design Token を適用しました。記念すべきデザインシステムの本番反映 1 発目です。

Design Token 適用の実装
会員登録画面 before/after
ログイン画面 before/after

チームとしても、自分たちで作ったものを実施にユーザーが使うようになって俄然モチベーションが上がっていきました。

今度はもっと影響範囲が大きいところへ、ということで全画面に表示されている Footer に対して Design Token を適用しました。 サービス全体で使用されている機能ということもあって、技術的負債の解消も含め 2,3 ヶ月ほど時間がかかったのですが無事完了できました。

これにより、crowdworks.jp の全ページで Design Token が反映された Vue.js のコンポーネントが表示されることになります。

Footer before

Footer after

全ページに関わるレベルのアウトプットが出てきたということで、社内的にもデザインシステム構築活動の認知が進んでいきました。

Component Library の導入方針決め

Design Token の適用が一定成果となってきたところで、もっとデザインと開発の生産性を改善して行こうということで、Component Library を導入していく方針になりました。

Component Library を導入するにあたり深く検討したことは、どういった形でコンポーネントライブラリを導入するかということです。

UIT Meetup vol.19『デザインシステムのリアル』 にて 『デザインシステムを作る意味あるの?』 という発表がありました。 この発表の中で、自社デザインシステムないしコンポーネントライブラリをフルスクラッチで作ることは、開発コストがかなりかかるため慎重に検討する必要があるという紹介がありました。

デザインシステム導入における、チーム規模ごとのおすすめ

そこで Component Library の導入前に、

のどれを選ぶか、エンジニア・デザイナー・PO(PM)それぞれの観点から意見を出し合い、議論を重ねました。 その結果、

  • 10 年もののプロダクトで、この先もさらに機能改善を行っていく予定がある
    • そのため、現時点でのコンポーネントライブラリへの投資は、回収できる見込みが高い
  • OSSコンポーネントライブラリを採用した場合、将来的に物足りなくなって別の物で置き換えたくなる可能性がある
    • 好き勝手カスタマイズできた方が、ちゃんとメンテナンスすることでずっと使える

ということで、フルスクラッチコンポーネントライブラリを作る選択をしました。 この選択の正解・不正解がわかるのは、もう少し先の未来...。

Component Library の構築

Component Library をフルスクラッチで作ることが決まったので、今度は Component Library をどう作っていくかの話に入っていきます。何で作るかと、どのようなプロセスで作っていくか(決めることが多いですね...)。

何で作るかに関しては、シンプルに Vue.js のコンポーネントとして作ることにしました。経緯については ADR(Architectural Decision Record) という形で以下のように記録を残しました。

Component Library 構築方法に関する ADR

どのようなプロセスで作っていくかについては、以下の 2 プロセスを検討しました。

  • Component Library を先に一定レベルで完成させて、新規画面の実装や既存画面への置き換えで使用していく
  • 新規画面の実装や既存画面への置き換えの中で必要になったコンポーネントを Component Library として登録していく

Component Library を先に作りきる か、 作ると使うを並行して進める かという比較です。

デザインの観点からは、前者の方が全体の整合性を保ちやすいというメリットがありました。 ただ、モチベーションの観点や開発組織内でのプレゼンス確保の観点から、ユーザーに見えるアウトプットを泥臭く続けていることが重要だと判断し、後者のやり方を選択しました。

Component Library の表示に関しては、専用のドキュメントページは用意せず Storybook 上で表示するようにしました。crowdworks.jp では、最新の master ブランチの内容を反映した Storybook のページが VPN に繋ぐと見られるようになっていたので、それに乗っかった形です。

これによりドキュメントページの環境構築コストや保守コストはほぼゼロに抑えることができました(ドキュメントページの外部公開などをする際は、専用の環境を作る必要が出てきそうですがそれはまた未来の話)。

ドキュメントページの内容に関しても、まずは手抜きで作成しました。若干の物足りなさは否めませんが、運用でカバーの範疇だと考え許容しました。完璧を求めるよりまず終わらせようの精神です。

Button コンポーネントの Storybook

Button コンポーネントFigma

この記事作成時点では Component Library として下記のコンポーネント実装済みで、現在も拡張を続けています。

  • Avatar
  • ButtonBackToTop
  • Button
  • Checkbox
  • CrowdWorksLogo
  • Heading
  • Icon
  • Input
  • LinkButton
  • SocialLogo
  • Tabs
  • TextLink

Component Library の実装に際しては、以下のデザインシステムや UI ライブラリを参考にさせて頂きました。

Component Library の画面適用

Component Library の構築方針として、 作ると使うを並行して進める という方針にしたので、Component Library の登録数が増えると画面適用数も増えるという構造になっています。 作った後に早速自分たちで使うので、フィードバックループがすぐに回るといった副次効果もあります。

Component Library の画面適用数は現状 4 画面と、まだまだこれからといった具合です。 デザインシステム構築チーム以外での Component Library の利用も始まってきたため、画面適用数はこれから順調に増えていきそうな兆しがあります。(それと同時に Component Library がどこに適用されているのかという管理の問題も出てきていますが、それはまた別の機会に)

Grid System の構築

Component Library の画面適用や Design Token の画面適用を進めていく中で、画面レイアウトを整えるための Grid System が必要になったので、その構築を実施しました。

Grid System の構築で得た知見について以下にまとめておりますので、よろしければこちらもご覧ください。

Vue.js で作る GridSystem - クラウドワークス エンジニアブログ

今後の予定

2024 年も引き続きデザインシステム構築活動を進めていく予定で、現状で下記の実施を検討しています。

  • Header への Design Token 適用
  • Component Library の拡充及び、新規・既存画面への Component Library 適用
  • デザインシステム活用の支援と、フィードバックループの仕組み構築

まだまだやることが尽きなくて楽しみですね。

終わりに

2023 年は crowdworks.jp にとってデザインシステムの実装元年で、やれること・やるべきことを手探りで積み上げていく年でした。 その中で、Design Token や Component Library の実装・適用など、 Design System の実装における基礎的な部分をどうにか形にできたのかなと考えています。

2024 年はこの基礎的なものをさらに拡充することで、よりデザインシステムの利用価値を高めていく予定です。

それでは、お読みいただきありがとうございました。

© 2016 CrowdWorks, Inc., All rights reserved.