デザインシステムを使ってプロダクトのデザイン負債を解消する その1

クックパッドでデザイナーをしているkenjowです。

今回は2022年11月25日に行われた「Cookpad TechConf 2022」で発表した「デザインシステムを使ってプロダクトのデザイン負債を解消する」の内容を紹介します。

村山と見上による「デザインシステムを使ってプロダクトのデザイン負債を解消する」では、過去の歴史を振り返りつつデザイン負債の話と、デザインシステムを導入したことについてお話がありました。デザインシステムを導入したことでサービスの品質が向上したとのことです！　#CokpadTechConf pic.twitter.com/lDJh7dqsIk

— Cookpad Tech Life (@cookpad_tech) November 25, 2022

PART1のこの記事では、デザイン負債のお話と、デザインシステムの紹介をします。

また、PART2の記事では、デザインシステムのシステム化と、プロダクトへ適用した結果について紹介をしますので、合わせてご覧いただけると嬉しいです。

内容の説明

今回は、デザイン推進部として行ってきたデザインシステムに関する以下のような取り組みについて、代表として村山と見上が発表します。

• デザイン負債との対峙

• デザインシステムについて

• プロダクトに適用した結果

みなさんの中で、「プロダクトのデザイン負債を解消したいけどどうしたらいいんだろう」というお困りや、「デザインシステムって作った後どうするの？」という疑問をお持ちの方がいたら参考になるかもしれません。

デザイン負債との対峙

クックパッドは1998年に前身となるサービスが誕生し、それから長くみなさんに使っていただいているサービスです。

2000年頃のクックパッドのWebサイト

2014年頃に、現在の形に近い状態にリニューアルされました。しかしPC版のサイトについては、その後7年間ほど大きなアップデートが無いままとなっていました。

デザイン負債が積もったままの状況

そして2022年、デザインシステムを適用することで、リニューアルを行いました。

各コンポーネントの色やフォントを整理

リニューアル前は、デザインが正しく管理されないことで以下のような問題がありました。

• フォントサイズがバラバラで視認性が悪い

• 色数が多く、ルールが統一されていない

• 使われない機能のCSSが残る

こういった問題を引っくるめてデザイン負債と呼んでいます。これらが、ユーザビリティやブランド力の低下、開発効率の低下の一因となっていました。

実際にユーザーから「安っぽくて萎びたサイト」というご意見を頂いてしまったことも

このような状況に至った原因として、いくつかの課題がありました。
ひとつはCSSフレームワークのレガシー化です。

デザインをルール化・開発を効率化するために長年利用されたCSSフレームワーク

元々はCSSフレームワークがガイドラインの役割を果たしていました。しかし、7年の間にデザイントレンドの変化や担当者の入れ替わりがあった結果、CSSフレームワークのアップデートが追いつかない状況になりました。

そのため、新規開発される画面やモバイルアプリにはだんだんと独自のデザインが適用されるようになり、結果としてプラットフォーム間や画面間でデザインがバラバラになっていきました。

もうひとつの課題は、デザインの改善活動に対し、事業としての優先順位を高く設定することが難しいことです。

開発チームのみんなで改善活動を行うこともありましたが、どうしても大きなコストを捻出することは難しかったです。そのため、プラットフォームを横断的に修正することや、大きな機能の修正はハードルが高いという状況でした。

こういった状況の中で時が流れていきましたが、2020年にiOSアプリの大型リニューアルがあり、これが転機となりました。

アプリの機能とともに画面デザインを大きく変更

このような事業上必要な開発を行う開発チームとは別に、クックパッドには社内のデザインを横断的に見る組織（現・デザイン推進部）があります。

この組織は社内のデザインに対して責任を持つため、リニューアルプロジェクトに一部メンバーが参加し、開発チームとともにデザインシステムの制作を行うことにしました。

開発チームとは責任範囲が違うことで、事業的な優先度を気にせず、純粋なデザインの治安維持に踏み込むことができたということです。

デザインシステムについて

ここからは、以下の順番でデザインシステムについて紹介をします。

• ガイドラインの定義

• ガイドラインをみんなで使うためのシステム

最初にガイドラインの定義から紹介します。まずは既存のアプリで使用されているカラー、フォント、UIコンポーネントなどの整理を行いました。

整理する前はグレーの種類がたくさん

デザインシステムが適用される前は、例えばそれぞれの利用ケースごとに新しいグレーの色ができてしまう状況でした。それを整理し、例えば濃いグレーであればBoldの見出しに利用しましょう、薄いグレーであればborderに使用しましょうといった定義が行われました。

とはいえこのようなガイドラインは、必ず守らなければならないものではなく、あくまで推奨しているといった立場で、発想の幅を狭めないようにと考えています。

他の色やタイポグラフィ、グリッドのルールなども整理されています。

また、このようなデザインファンデーションだけではなく、コンテンツについてもガイドラインが用意されています。

ユーザーへの適切なトーンでのコミュニケーションや、文体についてもトンマナを設けています。

デザインコンセプトやデザインキーワードの言語化もされました。

もともとクックパッドは「毎日の料理を楽しみにする」というミッションを掲げており、全社員がこのミッションに向かって制作をしています。

とはいえ、各々の解釈によって制作をしている部分もあったため、デザインのコンセプトやキーワードを明確に言語化することで、みんなの思想を統一しやすい状態になりました。

また、グラフィックや写真のルールもあります。

例えば写真については、家での料理を想起させる、自然光のような光を意識することが推奨されています。

クックパッドのデザインキーワードは「楽しい、ケの日のデザイン」であるため、商品写真の様なキラキラしたライティングは合わないというわけです。

また、イラストに関してもオリジナルのイラストレーションシステムが用意されています。

例えば、なにかの説明の際に人のイラストを使うことがよくありますが、表情や体をパターン化しており、これを用途に応じて組み合わせることで、誰でもすぐにクックパッドらしいイラストを利用することができるという仕組みになっています。

アイコンに関してもクックパッドのトンマナに合わせたものが用意されています。

元々はWebサイトで利用するためのWebフォントが昔から提供されていましたが、今回のリニューアルのタイミングでデザインもモダンにアップデートし、さらにSVGファイルで配布することで、全プラットフォームで統一して使用できるようになっています。

一部ではありますが、以上がデザインシステム「Apron」のご紹介でした。

※ また、Apronの内容の一部はFigmaCommunityにも公開しています。気になる方はぜひ見てみてください。

Apron | Figma Community

PART1の内容は以上です。
PART2の記事では、Apronをみんなで使うためのシステムと、Apronをプロダクトに適用した結果についてご紹介します。

会場から出た質問

会場に来ていただいた方からの質問と回答をご紹介します。

フレームワークがレガシーになっていくのメンテナンスが大変という印象

そうですね。デザインシステムはサポート期限が無いので、自主的にメンテしていくしかないと思います。

クックパッドのCSSフレームワークは、リッチデザインのまま時を止め、フラットデザインやマテリアルデザインのトレンドから置いていかれてしまいました。

現在のデザインシステムApronも、いずれデザインの式年遷宮をする時がくると考えています。その時に変更しやすい構造にしておくことは意識しています。

例えば、Apron-cssでは具体度の高いコンポーネントのみを提供することで、後から取り除きやすいようにしています。

デザインシステム自体のメンテナンスについては、みんなでできる状態を作っていきたいと考えていますが、現状は横断組織であるデザイン推進部デザイン基盤グループのメンバーで行っています。

また、事業部の開発チームからも意見や要望がGHEのIssueで届くので、都度ガイドラインやコードを更新しています。

デザイン推進部の他のnote記事もご紹介します。

デザインの式年遷宮の話

具体度の高いコンポーネントの話

継続して更新し続けることが一番難しいと思うけど、どういう運用でやっているんだろう

その通りで、例に挙げたCSSフレームワークについても、一時期はメンテナーがいない状況になってしまいました。

現在のデザインシステムApronは、明確にデザイン推進部をオーナーとしてメンテナンスを行っています。

いずれはデザイナー組織全体で更新作業を行う環境になるように、まずはデザイン推進部のデザイン基盤グループが浸透活動を頑張っていく計画です。

コミュニケーションのガイドラインもデザインシステムの一部なの？

UXライティングのルールに近いと思います。

最近の事例として、Push通知の開封率を向上するために作成した文章が、ユーザーさんがびっくりする文言になってしまったという問題が発生し、デザインシステムのガイドラインをベースに議論をしたということがありました。

デザイン基盤グループ、どの職種の人が何人いるのか気になる

デザイン推進部の構成は以下のようになっております。

• 部長1人(デザイナー)

• コーポレートデザイングループ(今回のTechConfのデザインなど作ってます)

  • デザイナー2人

• デザイン基盤グループ

  • エンジニア1人(村山)

  • デザイナー1人(見上)(+業務委託2名)

  • オペレータ1人

事業の優先順位との折り合いって難しいよね

開発チームでも「当たり前品質の改善プロジェクト」として週1時間の改善活動への投資義務を設けた時期がありましたが、デザイン負債に立ち向かうには時間が足りませんでした。

また、プラットフォーム自体の事業優先順位としても、iOS > Android or SP Web > PC Webとなっており、PC Webにおいては7年間大きなアップデートができない状況が続きました。

明確に事業リソースと切り分けて時間を確保できないと、コード量が膨大なクックパッドの場合は改善が難しかったです。

---

PART2の記事もぜひご覧ください。

また、今回の内容について少しでも興味を持ってもらえた方はカジュアル面談などでお話できればと思います。

ぜひこちらのサイトも覗いて見てください。

採用情報 | クックパッド株式会社