生き続けるデザインシステムの実現に向けたデザイナーの取り組み
昨今、「デザインシステム」という手法を目にする機会が増えましたよね。
多くのWebアプリケーションやモバイルアプリケーションでデザインシステムが設計されるようになり、最近ではデジタル庁のデザインシステムも話題になりました。
デザインシステムは、設計よりも浸透に時間がかかる点において難しさがあると私は考えます。自社事業でももちろんその難しさはありますが、クライアントワークは特に「納品」という段階が最後に存在することで難易度が跳ね上がるように思います。クライアントワークにおいて、どのようにデザインシステムと向き合えば良いのでしょうか。
例えば、とりあえず「デザインシステム」らしきものを作っても、それは「デザインガイドラインの納品」としてしか機能しない場合が多くあるように感じます。ただ、クライアントワークだからと諦めずに本気で取り組めば「デザインシステムを改善可能な形で納品する」ことは可能なのではと私は考えます。
これまで、UIデザイナーとして業務WebアプリケーションのUI設計〜開発フェーズのプロジェクトにいくつか携わってきました。これまでの経験や多くの失敗から得た示唆や、現在のチャレンジについてをこの記事ではご紹介します。
目次
こんなことにお困りではないですか？
私は、デザインシステムはあくまであらゆる解決策のうちのひとつだと考えています。機能改善やプロダクトを増やすとき、デザイン負債や開発負債を生みづらい体制を目指した結果、デザインシステムという解決策に至るパターンがある、という思考回路です。
そのため、本記事は次のような方に参考にしていただければ幸いです。
- 負債が溜まりきったプロダクトを抱え、改修に時間がかかって困っている方
- 社会的にインパクトのあるプロダクトをチームでスピード感を持って改善していきたいPM、デザイナー、エンジニアの方
- よりクリエイティブなことに時間を割きたいデザイナー、エンジニアの方
- プロジェクト離脱後も、クライアントが自走するための基盤を作りたい方
- 特にクライアントワークに従事されている方
結論
この記事では、クライアントワークにおけるデザインシステムのゴールを、クライアントがデザインシステムを改善できる状態を実現することだと定義します。
であれば、主体的に運用できるデザインシステム実現のためのデザイナーの取り組みは、あらゆるアプローチからクライアントを巻き込んで共に課題解決して意思決定することが全てだと考えています。もしも事業会社であれば、チームを巻き込んでいく取り組みと置き換えることもできます。
ただデザインシステムを設計する時点で終わらず、中長期目線でデザインシステムを見つめて運用していくには、ものづくりやFigmaというツールから徐々に離れていきます。組織の体制の全体感や現場との連携、より上位のステークホルダーへ提案しながら組織自体のシステムに対してアプローチしていかなければならないように感じています。
当記事における「デザインシステム」
定義
戦略からブランド、プロダクト方針からデザイントークンからコンポーネント設計まで、全てが一貫してデザインシステムを構築する状態が理想的です。
この図では、俗に言うデザインガイドラインがデザインシステムの一部でしかないことを実感していただければ嬉しいです。なお、端的に書くために省略した要素もあります。
効能
またこの記事では、プロダクトのデザインや開発の判断スピードが上がることをデザインシステムの最大の効能とします。
冒頭でも述べたように、のちにプロダクトの機能を増やしたりプロダクトを増やした際に、デザインや開発の負債を生みづらい体制を目指した結果、デザインシステムという解決策に至るパターンがあるという思考回路です。
- デザインや開発の判断スピードが上がる
- ユーザーへの機能提供までの時間が短縮できる
- ベースとなる使いやすさ (ユーザビリティ) と情報伝達 (アクセシビリティ) が保証されている
あえてデザインの統一性や一貫性を省いています。これらも非常に重要ですが、それらはあくまで結果であり、負債の減少による改善スピードの向上を目的とする考え方です。
「縛り」と捉えない
Reduce the chance of making a mistake?
Reduce friction so we can increase creativity!デザインシステムはミスの可能性を減らすためのものではなく、摩擦を減らすことで創造性を高めることができるもの
2回目となるFigmaのデザインシステムカンファレンス、「Schema by Figma」が東京で2022年11月3日に開催されました。オープニング・キーノートとしてショウ クワモト / Mr. Sho Kuwamoto さんがおっしゃっていたことをこちらでは引用させていただきます。私はこちらのキーノートを聞き、デザインシステムという解決策に対しより一層の希望を感じました。
デザインシステムは今の状態を維持する守りの解決策ではなく、自由を作る制約だと捉えたいです。議論の土台が揃ったデザイナーは余計な物事に捉われなくなり、よりもっとクリエイティブを発揮することができるはずです。デザインシステムはガイドでしかなく、そこからジャンプすることも可能なものだと捉えたいと考えています。
こちらの考え方に関しては本題ではありませんが、頭の片隅に入れておいていただけると幸いです。
本当にデザインシステムが必要か考える
そもそも、プロジェクトでは必ずデザインシステムを設計すべきなのでしょうか。
先ほどデザインシステムの意義で述べたように、デザインや開発の判断スピードが上がることがプロダクトの成長に大きく寄与する場合、ではないかと私は考えています。
となると、短期間でクローズしてしまうようなLP・プロトタイプに関しては多くの場合不必要でしょう。対して、顧客の声や事業戦略に応じて機能追加やプロダクトの増加などを行う可能性がある、Webやモバイルのアプリケーションでは必要な場合が多い、といえます。中長期で考えることが重要です。
また、基本的に新規事業開発でも場合によっては不必要なのではないかと考えています。私が思うに、デザインシステムはインフラのようなもので、負に気づいた時に初めて必要性を痛感するものだからです。なので、突如クライアントにデザインシステムを提案するのはほぼほぼ響かない。それは種まき程度のものだと考えています。
なぜクライアントがデザインシステム改善を継続できる状況を目指したいのか
クライアントワークにて、UIデザイナーとして業務WebアプリケーションのUI設計〜開発フェーズのプロジェクトに多く携わるうちに、気づいたことがあります。
- デザインシステムを納品したら終わり、のような安易な考え方で成果物に入れ込むべきではないこと
- クライアントワーク特有の不確実性（クライアントの体制・継続期間）を鑑みた中で、デザインシステムが最良の手か考えるべきだということ
クライアントワークに関わるデザイナーとして陥りやすい・失敗しやすいポイント
なぜその設計になったか、という文脈をクライアントが知らない
グッドパッチの離脱時にクライアントが設計に対して疑問を持てない状態で、デザインガイドラインを最後に書いただけ終わってしまったプロジェクトが過去にありました。
ここからは抽象化した話になりますが、プロダクト方針やデザイン原則は初めから完璧なものではなく、今後更新されていくものです。どうしても設計ルールに沿わない時は、「設計側に問題がある」という前提で既存設計の課題と拡張性を再考していきたいはず。
ですが、このような前提でグッドパッチ側が作ったとしても、完成したルールを受け取ったクライアント側はただ受け止めることしかできません。グッドパッチ離脱以降は特例が出てきたら「まあいいでしょう」と特例を許してしまうかもしれないし、デザイン会社側が作ったルールに忠実になりすぎて機能検討に時間がかかってしまうかもしれません。それは、設計が完成するまでの文脈を共有できていないためです。
事業会社でもデザインシステムの設計者と運用者が違い、もし設計者が離職してしまった場合そういった場面に出くわすこともあるのではないでしょうか？
経験から得た示唆
これらの失敗から私は、クライアントワークにおけるデザインシステムのゴールは、クライアントがデザインシステム改善を主体的に行うことができることだと考えるようになりました。その時、初めてデザインシステムの成果物としての恩恵を受けることができるのではないでしょうか。
主体的に運用してもらうためにも、デザインシステムを設計する際には設計を改変可能な状態で納品することがとても重要です。納品した後も形を変えながら、参照され続けるようなデザインシステムを目指したいものです。
そのためにクライアントとできることは、原則の意図や文脈をできるだけ共有し、同じ課題を共に解決していくことだと考えています。地道ですが、結局はこまめなコミュニケーションや議論という結論になってしまいましたね🤨
法律だって、時代の変化に応じて絶えず改正されていきます。原則に対して余白や合わなさを見つけたとき、それをどんな優先順位で判断するかがプロダクトの思想と紐づくのではないかと思います。
クライアントを巻き込んで共に課題解決して意思決定するべく、具体的に何をしているのか
先ほど結論で述べたように、あらゆるアプローチからクライアントを巻き込んで共に課題解決して意思決定することを行っています。実際、浸透させるためにどうするかを設計を終えてから考えるのでは遅く、設計方法から共に決めることによって浸透していくかどうかが決まっていくと考えています。なぜなら全てをグッドパッチ側で決めてしまうと、先方が主体性を持ちにくくなってしまい「クライアントだけで改善を続けられる」未来には辿り着けなくなってしまうためです。
1. ドキュメントで巻き込む
ドキュメントは章立ての段階から先方エンジニア複数名と擦り合わせ、ツールに関しても利用方法含めて共に決めていきました。そして、ざっくりとした内容を書き終えた時点で質問を頂戴していきました。
ドキュメントを書き終えた後も、質問を受けた際には逐一文脈に合わせた該当ドキュメントを送るようにしています。しつこいくらいがちょうどいいかもしれません。
ただやはり、ある具体的な課題がないといけません。課題解決を行うための議論を行って、共に決断していくことでプロダクトにおける優先順位を明らかにしていきたい。
2. 相談と議論で巻き込む
現在の案件では、開発やデザインスプリントの過程で生まれた疑問やイシューを通して、先方エンジニアやエンジニア兼デザイナーと一緒に議論していく機会が徐々に増えていきました。その中で、ルールの余白や今後の拡張性についても議論し、共にルール改変の意思決定を重ねていっています。
また、相手の懐に入っていく図々しさもあるタイミングでは必要かもしれません。私は先方オフィスに伺わせていただく際、できるだけいつでも話しかけ合える距離感にいます。軽いデザインの相談をしていただけるようになり、私の方からもルール作りで悩んでいるときに相談しやすい関係性を作っていくことができました。
3. 共に課題解決することで巻き込む
メンバーにはデザインランゲージに同意するだけではなく、それを取り入れ、前進させてほしいと思っています。
ーユルゲン・スパングル | Atlassian デザイン責任者
自分がベストだと感じたシステムだとしても、チームメンバーやプロダクトによる観点が加わって改善される状態が理想的です。
そのためにも、ペアデザインのような形で、クライアントと同時にUI設計を行うことも有効だと感じています。判断を互いに言語化することで互いの思考回路が明らかになり、よりシステムが前進する余白や糸口が発見されることも少なくありません。
0. どうにもならない要素
クライアントワークにおいてデザインシステムを理想的な形まで浸透させてからプロジェクトを離脱することは、相当難易度が高いと思っています。というのも、自分ではどうにもならない変数が大きく実現可能性を左右するためです。ただし、場がある程度揃っていたらガンガンいくべしです！
私が考えている最も大きい変数は、デザインシステムオーナーになり得るメンバーがクライアントサイドに存在するかどうかだと考えています。巻き込めそうで、一緒に議論して課題解決していけそうなメンバーが存在すると良いのですが、そういったメンバーが存在しない場合は、負債を生まないための解決策を別で検討すべきだと思います。
終わりに
クライアントワークにおけるデザインシステムに関する思想、ゴール、実践をここまでに述べさせていただきました。
なんだか良さそうな「デザインシステム」という解決策をなぜやるかを突き詰め、クライアントワークにおける障害物をどう乗り越えるか、などについて皆さんにひとつ思考する機会を提供させていただけていたら幸いです。
おまけ
文化との類似
作るだけではなく浸透や解釈が肝なところは、組織におけるビジョン・ミッション・バリュー策定や浸透施策と似ていると思っています。
デザインシステムはもはや文化、と評される所以だと思います。デザインシステムを設計することよりも策定に参加することや策定プロセスそのものの設計に関係者が関わることが重要である、と私が考えているのもこれらが理由です。
「デザインシステム」という呼称が適さないのでは
「デザインシステム」という言葉には、できることが多すぎてメンバーごとに期待する効果が異なるリスクが生じるため、その事業ごとに導入する意義に合わせた名称にした方が良いのではないかなどと考えています。