デザインガイドラインは、Web アプリのデザインをより一貫したものにするために役立ちます。一方、すでに運用しているサービスがあり、後発でデザインガイドラインを定めた場合、既存のコンポーネントを修正する必要があります。本稿では、デザインガイドラインを使って既存のコンポーネントをアップデートする方法について、Zenn を例に具体的な手順を解説したいと思います。
TL;DR
修正する対象を絞り、そのテーマについてソースコードを検索し、ヒットしたすべての項目について修正内容をレビュー・検討して反映します。
背景・経緯
ご存知の方がほとんどだと思いますが、Zenn はもともと catnose さんが個人開発でリリースしたサービスで、その後クラスメソッド株式会社が買収する形でジョインしました。私もそのタイミングで Zenn の開発へ携わることになりました。
時は流れ…catnose さんは Zenn の第一線からは退いたものの、しずかなインターネットをはじめいろいろなプロダクトを精力的に生み出しています。Zenn については、アドバイザーという立場で引き続きコントリビュートしていただいています。ちなみに「アドバイザー」と聞くと形だけの肩書みたいな印象を受けるかもしれませんが、catnose さんの場合は放っておくと後々大変そうなリスクを早い段階で指摘してくださる、ときには手まで動かしていただけるため大変ありがたいです。
とはいえ、彼に頼りっぱなしというのも今後の開発でスケールが難しくなるため、この機にコア機能のメンテナンスや新規開発の大部分は、Zenn チームで行う方針としました。そこで大きな課題のひとつだったのが、Zenn のデザインをどいう維持するかという点です。デザインは、体験、空気感、雰囲気、ブランドなどインサイトに直結する要素です。ですが、頭では大事だとわかっていても、いざ私が手を動かしてみるとどうしても既存の画面の焼き直しのような見た目になってしまいます。
デザインガイドラインの策定
たくさんのステークホルダーに動いていただき、デザイナーの@fujisawaさんがジョインしていただけることに。Zennの課題を共有すると、早速 catnose さんと会話、デザインガイドラインの作成に取り掛かってくださいました。現時点で 2 つ、ガイドラインをプロダクションに適用しています。
ガイドライン作成はfujisawaさんメインで行っていただき、チームメンバーもFigma上でディスカッションに参加することで、納得感のあるものに仕上がっています。感謝。
デザインガイドライン成果物の一部@Figma
適用の流れ
プロダクトが先にあり、デザインガイドラインが後発だったため、既存のコンポーネントを見直す必要がありました。以下の流れは、Zenn チームで行った、ひとつのサンプルとして受け止めてください。
- ガイドラインを適用するためのCSSを特定する
- 特定したすべてのCSSすべての該当箇所について、レビュー用のコメントを付与する
- レビューする
登録済みクレジットカードの box-shadow についてコメントした例
修正ターゲットを絞る（今回はCSS）
デザインガイドラインはあくまでガイド、そこから実装に落とし込むことになります。場合によってはコンポーネントを組み替えたり、APIの設計から見直さなければならなかったり、そもそも機能そのものの要否から議論しなければ…ということもあるかもしれません。しかし今回、デザインガイドラインを作成した大きな目的はZennのデザインの維持と言語化です。開発メンバーの恩恵を考えた時、費用対効果が高い箇所はCSSだと考えました。ガイドライン適用のとっかかりとして、まずは修正ターゲットをCSSにしぼりました。
レビュー: 例外や考慮外の発見
デザインガイドラインを一発で迷わず適用できるとそれがいちばんいいのですが、すんなりとはいきません。ガイドラインだけでは判断できないもの、想定していなかったコンポーネントの存在があります。なかにはデザインガイドラインに立ち戻って修正が必要なケースもあるため、すべてのターゲットをひとつずつレビューする必要がありそうだ、と考えました。
ドロップシャドウのガイドラインを適用する
ドロップシャドウはいわゆる浮き上がり・elevationを制御するスタイルです。詳細はfujisawaさんの記事に任せますが、「何を浮き上がらせて、何を浮き上がらせないか」をガイドラインで整理しました。これを適用します。
CSSを特定する
CSSでいうとbox-shadowです。わかりやすいですね。今回は新しく浮き上がらせるものがなかったため、既存の box-shadow を見直せばOKでした。
box-shadow をどうするかレビュー用プルリクを作成
修正する/しない/迷っているなど意見を付け、レビュー用のプルリクエストを作成しました。差分がでるように開発者の意見はソースコードコメントとして記載します。
変更ファイル数は154ででした
開発者の修正と意見はソースコードコメントで残し、レビュー時のやりとりや決定事項はGitHubのプルリクエストへコメントを残します。最終的な修正はこのプルリクエストでは行わず、別プルリクエストで行い、レビューで利用したプルリクエストはそのままの状態でクローズします。こうすることで、将来「あれ？なんでこうなってるんだっけ？」というbox-shadowがあった場合、プルリクエストを見返せば経緯がわかります。
レビュー・リリース
fujisawaさんとプルリクエストを上からひたすらレビューしました。3時間くらいかかったと思います。
主なレビュートピック:
- 物理的なモノを模したものの認識の違いがあった
- スティッキー（スクロールについてくる）要素に
box-shadowをつけるかディスカッションが発生した -
box-shadowをなくすと背景と見分けがつきにくくなるコンポーネントの対処を決めた - 本体だけでなく、Markdown変換後のHTMLに当たる zenn-content-css も修正する必要があると指摘してもらった
プルリクエストに経緯を残し、方針を確定させました。レビュー後は、マージ用のプルリクエストを作り、リリースしました。
レビューの経緯はプルリクエストに残しておくことで後から経緯を追える
角丸のガイドラインを適用する
流れはシャドウと同じです。角丸は border-radius を探してガイドラインを適用します。
変更（レビュー対象）ファイル数は201
レビューには合計で4時間程度かかりました。お付き合いいただき感謝。
主なレビュートピック:
- 小さい角丸（
border-radius: 4px）でも、矩形が小さいとやや丸みを帯びて見えるため2pxの角丸を定義する -
border-top-left-radiusなどの部分的な角丸がもれないように注意して（スイマセン） - Publicationのランディングページ だけはガイドラインに加えて個々の要素についてひとつずつ議論して決めたいとのことだったのでそうした
ガイドラインを適用したことによる変化
私の感想ですが、かけたコストに対する見返りは十分にあったと感じています。
機能開発の進みが1営業日分早くなった
これまで、画面の変更を含む修正は、既存のCSSからひっぱってきて模倣していました。すんなり進むこともありますが、レビューでUI面でのディスカッションが発生した場合、ベースの考え方・拠り所が少ないため個人の好みが発散してしまい、まとまるのに明日へ持ち越し…ということがありました。結果、マージされるのが1営業日分ほど後ろになっていたな、という感触です。
手を動かすメンバーの迷いが少なくなった点はもちろん、レビュー時の観点としても活躍しており、プルリクがマージされるまでの時間が早くなりました。
既存のコンポーネントに詳しくなった
Zennのフロントエンドには多くのコンポーネントがファイルへ切り出されており、適切に使うことで開発工数をカットできます。しかし、存在を知らなければ使うこともできず、「使い回せるコンポーネントはないかな」と探していました。今回のデザインガイドラインの適用で、ある程度網羅的に既存コンポーネントを眺めることができ、探す時間が減らせそうです。完全に役得ですね。
Zennのインサイトについて説明できる箇所が増えた
デザインガイドラインはすでにあるプロダクトをベースにfujisawaさんが書き起こしたため、ある種のリバースエンジニアリングといえます。結果、私がこれまで「Zennってなんとなくやわらかい雰囲気だけど玄人志向だよな」と感覚的にとらえていたインサイトをある程度説明できるようになりました。
- やわらかい雰囲気は、青を基調とした色を使うことで落ち着きを表現し、各コンポーネントのエリアの四隅は直角ではなく丸みを帯びていることでトゲトゲしい印象を抑えている。
- 一方で、本のカバー画像はシャドウとグラデーションを駆使して物理本を想起させる見た目にしたり、記事ページで「いいねボタン・シェアボタン・目次」をスクロールに追従させることで読者の望むアクションが常に画面内へ表示されるように考慮（=UXと直結）したりと、こだわりポイントを用意して玄人志向を演出している。
これらは私のなかでの言語化であり、チームの総意ではありません。言いたいのは、このように言葉に起こすことで、インサイトに対する分析やディスカッションができるようになるという点です。
これを個人開発で実装したのか…
最近、こういったUI面での理解を少しずつ深めていくにつれ、ひとりでZennのインサイトを狙って作り上げたcatnoseさんのすごさを改めて実感しています。
おわりに
ガイドラインの作成と適用にはそれなりの時間がかかりましたが、今後すべての開発に影響することを考えると、早いうちにやっておいてよかったと振り返ります。デザインガイドラインはまだ完成していません。チームで協力してつくりあげ、Zennの世界観をさらに深く大きく広げていきたいと思います。
Discussion