Findyデザインチームはもっと価値提供がしたい ~ デザインシステムへの挑戦 ~

Findy Incでデザインマネージャーをしていますムカイ( @osk_kamui )です。

弊デザインチームでは、ユーザー、顧客含め全てのステークホルダーに向けてデザインを通して価値提供を行えるよう日々邁進しています。

そして価値提供の重要な位置づけのひとつとしてプロダクトの改善があり、ユーザーの方がFindyを活用し、目的を達成するためにデザインは何ができるのかを日々考えています。

その中で、プロダクトをよりよいものにしていくために弊デザインチームでは中途転職Findyのみですが、デザインシステムの構築/運用に奔走しています。

今回は、なぜ中途転職のFindyでデザインシステムに取り組むことになったのか、そして実際取り組んでみた現状について書きたいと思います。

---

一貫性のないデザインで作られているプロダクトをどうするか？

お恥ずかしい話ではありますが、中途転職のFindyは一貫性があるとは言えない、認知負荷のある箇所が存在しています。そのため本来伝えたい価値が最大限伝えられていないという状況が現在進行系で存在しています。

なぜそのような状況になっているのか、そこにはサービスが辿ってきた歴史がありました。

中途転職のFindyは2017年5月のサービスインから数多くのデザイナーとフロントエンドエンジニア手によって作られてきました。

これは決して悪い事ではなく、多くの方に興味を持っていただけた結果、歴史が作られた事には感謝の意を述べたく思っています。

一方で、歴史があるという事は、その時々の最適解があったという事でもあります。

その時々に最適なデザインルールを作っていた

デザインするデザイナーやその時の状況によってデザインのルールが追加されていった結果、一貫性が失われていく事は避けられないと考えています。

約6年の中でトレンドも含め、色や段組み、画面幅などその時々の最適解があったかと思います。またボタンの角丸やメインで利用しないフォントサイズなど統一しにくい細かい点を挙げればキリがありません。

加えて、作ったルールを全て引き継いでいく事は、口伝やドキュメントのみでは実質不可能と言ってもよいでしょう。

その結果、継承されないルールが重なり現在に至っています。

その時々に最適な優先順位をつけていた

優先順位によってデザインが全て実装されないというのをみなさんご覧になったことあるのではないでしょうか。

優先順位というのは絶対的なルールがない場合が多く、質よりもスピードを優先する時もあったでしょうし、また技術力が足りずタイムアップとなる時もあったかと思います。

特に価値提供のコアな部分以外は相対的に価値を生みづらいため、優先順位が下がったまま浮上しないという事は「あるある」なのではないでしょうか。

全ては優先順位の問題で一概に悪いとは言えませんが、そういった事象の積み重ねが一貫性を徐々に失っていく事に繋がっていくのは避けて通れないのも事実です。

---

一貫性を持ちながら柔軟に対応できるデザインシステムの構築の必要性

その時々のデザインルールや優先順位の最適解が、現状を生んだ課題であるという事について記述しました。

そしてこれらを解決していくためにどうすれば良いかという話になるのですが、改めて考えるとデザインルールや優先順位がずっと変わらないという事は決してありません。

そこで、本当に必要なのは永遠に変わらない答えではなく、答えが変わる前提で柔軟に対応できる環境ではないか、と考えたわけです。

その環境を作れるものこそが「デザインシステム」であるという事で、冒頭にある通り、デザインシステムの構築/運用に奔走しているというわけです。

ここからは具体的にデザインシステムで何を実現しようとしているかを記載していきます。

またデザインシステムといえばFigmaということで、他ツールにデザインがあるものは全て移設をし、その上で構築を進めています。

堅牢かつ柔軟、そして拡張可能なデザインルール

まずツールが統一されているため再利用性が高いというもありますが、弊デザインチームではFigma Tokensを用いて、属人性を最大限排除した運用にトライしています。

コンポーネント化をしておけばルールは統一されるのではないか、と考えていた時期もありますが、明文化されないという課題が残ります。

先述した通り、口伝で伝えるのは不可能、またデザインをする度にドキュメントに残すという方法も現実的ではありません。

それならいっそコードと一体化してしまえという事でTokenを用いる事にしました。デザイナーにとって最初は負担となりますが、長期的な起こりうる問題を考えると、今やるべきという選択をしました。

またデザインレビューを文化として根付かせており、コンポーネントの追加やページをデザインするタイミングでルールが正しく運用されているかを確認するようにしています。

変更が入ったときにもTokenを変更すれば全てが変更される、かつTokenはGitHubで管理しているので、何を変更したかのログも明確にわかります。

Tokenの再利用を行うことで人に依存する事無くプロダクトのデザインを進めることができるので、拡張性も非常に高い事を期待しています。

優先順位に左右されにくいデザイン

デザインシステムを作る事で無用なルールが減っていきます。
同時にコンポーネントの再利用が増えてコード量が減るため、よりクリーンで素早い実装をフロントエンドは行うことができます。

デザインシステムに合わせてコンポーネントを実装するという手間が最初こそかかりますが、一度作ってしまえばデザインに変更があった際もフロントエンド側でTokenの変更を反映すれば一括でデザインが変更されます。

これにより、過去発生していた優先順位が落ちやすい細かな修正点も反映されやすくなり、一貫性を保ちやすくなります。

---

■さいごに

現在のデザインシステムの進捗ですが、まだ全てプロダクトに反映できてはいません。

ただ、すでにToken規定や一部フロントエンドとの繋ぎこみまで完了している状態で、あとはひたすらデザインを作り、フロントエンドの実装を進めるという所まで来ています。

このあたりのスピードをさらに上げていき、弊デザインチームのデザインを通して価値提供という目的に向けて、課題を解決していければ良いなと思っています。

是非お読みの方、弊デザインチームでデザインシステムを一緒に構築しませんか。

コミュニケーションデザイナーも絶賛募集しています。