10年続くWEARにおける、デザインシステム事始め

WEARとFigmaのアイコンが並んでいる。その下にFirst Step of Design Systemと書かれている

こんにちは、WEAR Webフロントエンドチームの吉田と大脇です。

現在WEARではNext.jsでのリプレイスが進行中です。今回はリプレイスのデザイン面における課題と解決に向けて行った取り組みを紹介します。

リプレイスの経緯や技術選定については、弊社の藤井の記事をご覧ください。

techblog.zozo.com

10年の歴史のあるアプリケーションと向き合う

トップページ

WEARは今年で10年目となります。Webサービスとしては長期間に渡って運用されているのではないでしょうか。WEARは幾度かのデザインリニューアルや担当者の交代などの経緯があり今のデザインに至っています。デザインルールの���備やマスタデータの管理フローなども時代によって変化しており、現時点のルールは明文化されていません。そのため、現在の実装内容が正しいデザインとして扱われていました。

リプレイスにおける課題

今回のリプレイスでは、大きなデザインリニューアルは行わず、既存のデザインを踏襲していく形で進行しています。そのため、実装内容からデザインを読み解き、それを基に開発しており、品質を担保しながらスピード感をもって開発を進めることに課題を感じていました。

具体的には以下のような課題があります。

    • 旧環境でも色定義をしていたが、定義外の色も多く使用されており、色を都度デザイナーに確認しながら実装していく必要がある
  • 余白
    • 入れ子の要素それぞれが余白を持っており、正確な余白を直感的に判断できない
    • line-heightを余白の調整に利用しており、正確な余白の算出が困難である
  • コンポーネント
    • 「角丸が1px小さい」など似ているが微妙に違うUIが複数存在する
    • UIの共通化を都度デザイナーに相談する形をとっているが、1つ1つは小さくても積み重なるとお互いにコストとなる

これらの課題を解決できればよりスピード感を持って開発ができそうです。また、今後も継続してサービスを改善し成長させていくためにも、足場を固める必要があると考えました。そこでWebフロントエンドチーム内では「エンジニアとデザイナー間での共通言語としてデザインシステムを採用し、認識を合わせていくのはどうか」という話が上がりました。

こうしてWEARのデザイン開発効率を上げるための環境作りを目指した活動が始まりました。

他部署との連携

Googleジャムボードを使った課題整理の例

まずは、前章で挙げたような漠然としていた課題を整理しました。ホワイトボードツールを用い、改善したい項目を重要度難易度の2軸でグラフ化しました。その中でも「重要度が高く、難易度が低い」ものを優先してデザイントークン化していくことにしました。

デザイナーとエンジニアの歩み寄り

デザインシステムを作っていく上で当然デザインに関わることを決めるので、エンジニアのみで進めることは難しく、デザイナーと協力して進める必要がありました。また、WEARはWeb/iOS/Androidでサービスを展開しているため、モバイルエンジニアとも話し合う必要がありました。デザインシステムのチームがあるわけではないので、各チームから代表者を募り、ミーティングをしました。

ミーティングで話し合ったこと

  • エンジニア側でデザインシステムがないことで困っていること
  • デザインルールが明文化されていないことで起こる、エンジニアとデザイナー間での無駄なコストを下げるために必要なこと
  • 各チームがデザインシステムに対して期待していること
  • 過去にデザインシステムを作ったことがあるメンバーの経験に基づく「作成していく上で大変なこと」

ミーティングを行って得た気づき

  • WebとiOS/Androidで困っているポイントが違う
  • コンポーネント単位でデザインレビュー1を行えれば、再度同じ部分のデザインレビューが不要になる
  • デザインシステムを仮に作り上げたとしても、それを既存のサイトやアプリに反映するだけでも大きな工数がかかる
  • 初めから完成されたデザインシステムを目指さずとも、既存デザインのルールをまとめるだけでも価値がある

特に、既存デザインのルールをまとめるだけでも価値があるという意見に共感しました。WEARは既に10年運用されているサービスで、言語化していなかったとしても潜在的にデザインルールが存在していると思うので、そのルールを明文化するだけでも以下のメリットがあると考えました。

  • 新しく入社したメンバーのオンボーディングに役立つ
  • デザイナーとエンジニアの共通言語となる
  • デザインシステムを作成するときに流用可能

よって、まずはデザイナーに現状をヒアリングして、既存デザインのルールをまとめることにしました。

デザインツールの変遷

既存デザインのルールをまとめていくにあたって、どのツールを使って形にしていくかという問題があります。候補は以下の3つがありました。

  • Adobe XD + Zeplin
  • Figma
  • Confluence

WEARではデザインツールとしてAdobe XD、デザイン共有ツールとしてZeplinを利用していました。しかし、Webフロントエンドチームとしては以下のような理由からFigmaを利用したいと考えていました。

  • 行間の指定(line-height)などWebとの親和性が高い
  • デザインデータのプレビューがConfluenceなどのドキュメントツールで埋め込み可能
  • プラグインが豊富
  • コンポーネント化できる(これはXDでも可能)

しかし、デザインツールを乗り換えるコストからFigmaの利用は断念し、Adobe XDまたはConfluenceを利用する方針になりました。そんな矢先、今年の1月ごろAdobeから「今後XDの積極的なアップデートは行わない」との発表が出ました。

結果、候補はFigmaとConfluenceに絞られました。FigmaとConfluenceを比較し、以下の意見が出ました。

  • 視覚的なわかりやすさ

    • Confluenceを使うと文字メインでデザインを説明することになる。それでは視覚的にわかりづらく、運用していくのも大変そう
    • Figma上でデザインルールを起こせば視覚的にわかりやすい
  • デザインシステムへの流用のしやすさ

    • Confluenceでデザインルールを残しても、流用しづらい中途半端なデータとなってしまう
    • Figmaならデザインデータをそのままデザインシステムにも流用できる

よって、Figmaを利用して既存デザインのルールをまとめることになりました。

未来のこと、これからやっていきたいこと

デザインルールをまとめる作業は分量が多く、すぐに終わることはないので、時間を見つけて引き続きやっていくことにしました。この章では、デザインルールのまとめ作業と並行して、これからやっていきたいことを紹介します。

デザイントークンの定義

他部署との連携の章で書いたような「エンジニアとデザイナー間での無駄なコストを下げる」を実現するために、デザイントークンの定義をしたいです。例えば、文字サイズ、余白、角丸、シャドウなどのルールを明文化し、iOS/Androidでも共通のルールで運用することで、各プラットフォームごとのズレを減らすことができると考えています。

デザイン周りの負荷軽減

他部署との連携の章で書いたようなデザイン周りのコスト削減のために、以下のような運用をしたいです。

  • 似たようなデザインで再度デザイン作業が発生しないように抑止
  • Figma上でコンポーネント化し、コンポーネント単位での管理・デザインレビュー
    • デザイナーが「このコンポーネントは既にレビューしたから今回はレビューしない」という判断ができるようになること
  • デザイン作成・デザイン共有がFigmaで完結すること
  • 仕様書の作成コスト削減
    • Confluenceで仕様書を作成する際に、デザインデータをプレビューで埋め込み可能

技術面でやりたいこと

デザイン面だけでなく、実装面への反映と運用方法を検討しています。

Tailwind CSS

WEARのWebサイトではTailwind CSSを利用しています。Tailwind CSSは tailwind.config.js にtheme2を記述し、決められたクラス名のみを利用して実装していきます。デザイントークンを決めるということは制限を持たせることでもあり、これはTailwind CSSとの親和性が高いと考えています。デザイントークンがまとまったらTailwind CSSのthemeを設定し、徐々にサイトへ反映していきたいです。

Storybook

WEARのWebサイトの開発ではStorybookを利用しています。Storybookを用いることで、コンポーネント単位での表示の確認が可能です。今後デザインシステムのドキュメントを作成する場合、実際に動作するコンポーネントをドキュメントに載せることができ、新しく入社した社員のオンボーディングにも役立つと考えられます。

上記のようなTailwind CSSとStorybookの運用方法を改善をすることで、リプレイスにおける課題の節で書いたような「スピード感を持った開発」が実現できると考えています。

終わりに

WEARは長い歴史を持つアプリケーションであり、デザイン関連の整備には時間がかかると想定されます。そこで、デザインシステムを導入する際には、開発の停滞を避けるため、取り組みやすいところから徐々に進めていこうと考えています。私たちは、デザインシステムを作成すること自体が目的ではなく、エンジニアとデザイナーが共通のルールに基づいて協力し、開発をスムーズに進めることを目指しています。なので、デザインシステムに関しては、“共通認識のルールを作っていたら、いつの間にか副産物的にデザインシステムができた”という心持ちでやっていきたいです。

ZOZOではデザインシステムに興味のある方を募集しています。ぜひ、下記のリンクからご応募ください。

hrmos.co
hrmos.co


  1. WEARにおいてデザインレビューとはステージング環境で実際に動いているものをデザイナーの観点でレビューしてもらう確認作業のこと。
  2. スタイルを変数として定義できる機能。
カテゴリー