デザインシステムの一般的な 5 つの課題とその解決方法 | アドビ UX 道場 #UXDojo

チームは長い間、デザインシステムに対する複雑な感情を抱いてきました。というのは、デザインシステムは、デザイナーにとって多くの重要な課題を解決してくれる一方で、作成・維持するだけでもチームにとって問題の種になることがあったからです。

デザインシステムは、一貫したまとまりのある体験として製品をデザインし、開発し、公開することを可能にするために、チームにとって必要なすべての側面を集約した、絶対的な情報の集約場所だと考えられます。デザインシステムは、製品とともに進化する生きた存在であり、具体的なもの（ガイドライン、ツールなど）と抽象的なもの（協業の進め方、ブランド価値など）の両方から構成されます。デザインガイドなどの重要な資料は、デザインシステムの中核を成す要素です。

Rise において、デザインシステムの導入はビジネスの急成長に貢献してきました。しかし、そこにはもちろん課題も伴いました。これから紹介するのは、Rise がデザインシステムに関して直面した主な課題と、それらを解決するために行ったことです。

課題 1：デザインシステム立ち上げの負荷

デザインシステムの導入に向けて動き始めるときは、多くの労力が必要です。そして、チームや組織が出来上がったときには、柔軟性を維持することがより難しくなります。

この課題は、デザイナーがデザインシステムを提唱すること自体を躊躇する原因になります。デザインシステムのプロジェクトを開始しようとするだけで、さまざまな作業が求められるからです。

解決策: デザインチーム全員を最初から巻き込む

デザインシステム構築の初期段階では、デザインチームのメンバー全員からの協力が欠かせません。

まず、デザインと開発の観点から考慮すべきあらゆる側面を洗い出す必要があります。そこには、関係するすべてのデバイスとプラットフォームも含まれます。ひとたび検討すべき問題が定義されたら、視覚的にも構造的にも一貫したデザインによりそれらの問題を解決しなければなりません。全員が納得できる解決案を見つけるには、チームメンバー同士の協業が必要です。

初期段階では、チームメンバー一人ひとりが、それぞれ異なる回答を持ち出すでしょう。それは、まだシステムの基礎が定義されていないためです。いったん物事が進み始め、基礎が固まり、追加の要素が定義されるにつれて、パターンの一貫性が現れ始め、解決案の選択肢が狭まってきます。

デザインシステムの最終的なゴールは、デザインシステムが提供する要素やソリューションの使用による、意思決定プロセスの簡素化です。最初からチーム全体が関わることで、個々のチームメンバーが、デザインの決定や選択されたソリューションの背後にある理由を理解します。問題の発見と定義だけでなく、解決案の策定に参加することにより、ドキュメントに頼らなくても、全員の頭の中に解決案が定着します。この点からも、デザインチーム全員を最初から巻き込むことは重要です。

課題 2：デザインシステムの ROI をビジネス側に納得させる

ビジネス側の人々が、デザインシステムの構築に対する ROI を見出せないことがあります。その上、説得の根拠となるような過去のケーススタディを挙げることは、一般的に容易ではありません。そのため、ただでさえ困難な戦いがさらに難しくなってしまいます。

デザインシステムの初期投資は相当なものです。まず調査して、解決すべき問題を特定し、それからチーム内あるいは複数のチームと問題解決のためのセッションを行わなければなりません。さらに、その成果を維持するためのコストもかかります。付け加えると、投資に対するリターンはすぐには得られません。

費やされた時間は、あっという間に積み上がります。ビジネス側の人々が、全体像を見ることなく、この初期の問題に囚われるのはあまりに簡単です。

解決策: ビジネスオーナーにデザインシステムが長期的には多くの時間とコストの節約になることを理解させる

ビジネスオーナーが、長期的な投資という観点から考えるように仕向けます。システム導入により長期的に節約できる時間や予算は、システムのデザインや開発にかけるコストの数倍から数百倍にもなることがあります。また、デザインシステムは、日々の問題の解決に費やす時間を大幅に削減してくれるため、デザイナーや開発者がより高度な問題の解決に取り組めるようになります。これは、長期的に、ビジネスへの追加の価値になります。

また、デザインガイドを個々の問題に対する唯一の解決策にすることは、一貫性だけでなく効率面にも非常に重要です。たとえば、プライマリーアクションボタンには、さまざまなオプションを使用するのではなく、一つのスタイルだけを定義するべきです。これは、デザインと開発プロセスの生産性の向上に貢献します。

なお、このプロジェクトは一度の作業で終了する種類のものではないことを、ステークホルダーが理解することも重要です。デザインシステムが効果的であるためには、維持管理が必要であり、その作業には、一人の担当者ではなく、チームの全メンバーが関わる必要があります。新しい課題への新しい解決策を追加するために、ガイドラインは頻繁に見直されるべきです。

課題 3: 承認のタイミングがデザインシステムの効率に与える影響

時間やお金がかかるという理由で、デザインシステムの承認を得るだけでも大きなハードルになる場合があります。上層部やその他のステークホルダーの了解を得るのに時間がかかると、デザインシステムの効率が低下することがあります。

以下は、このような状況が発生するいくつかの原因です。

• 他の優先度の高い案件に気を取られている
• プロジェクトの目的とそのビジネスへの影響をきちんと理解していない
• システムが実現されるべき方法について独自の考え方を持っている

解決策: デザインチームだけでなくステークホルダーにも最初から参加してもらい、大幅な改訂の必要を減らす

プロセスの最初からデザインチームとステークホルダーを巻き込むことは、デザインシステムを可能な限り早く導入するための鍵です。より広範なチームがプロセスに関わるほど、当初は考慮されていなかった側面に対処するために改訂が必要になったり、十分に考慮されておらず不正確な解決方法になっていたりといった事態を減らせます。システムを上層部に説明する際は、できる限り丁寧に準備しておきましょう。必要な改訂が多くなるほど、遅延が大きくなりがちです。

デザインシステムの立ち上げに多大な労力をつぎ込んでいる初期段階では、上層部の注目を得て、物事を先に進めるのは比較的容易です。しかし、後から新たな問題が発生して新たな解決策が提案された場合、こうした一度限りの案件を承認してもらうのはより難しいものです。

このようなシナリオに出会ったら、デザイナーと開発者を集めて、同じような問題を抱えていて解決策がすでにあるかどうかを確認することから始めましょう。解決策が存在しない場合には、同様の問題を考慮に入れて新しい解決策を作成し、それを提案として掲げます。システムへの追加を目指すどんな新しいソリューションも、その目的は今後遭遇するであろう同種の問題を解決することです。そのため、更新は可能な限り頻繁に行うことが望ましく、最終的にそれは、承認を待つ無駄な時間を減らすことにつながります。

以下に一つの例を示します。

最初のデザインシステムには、タブを使用したコンテンツの必要性がありませんでした。しかし、後になってその必要性が出てきました。では、他のデザイナー達は、比較的量が少なくて 2 つから 7 つのカテゴリに分けられるコンテンツを表示する手段を探しているのでしょうか？カテゴリのタイトル（タブ内のテキスト）は短いでしょうか、長いでしょうか？将来的に必要になりそうなカテゴリのタイトルは何でしょう？タブ付きコンテンツの初期デザインでは、おそらくこういった点を考慮して、サイトでもアプリでも普遍的に適応可能なソリューションを検討することになるでしょう。

課題 4: デザインシステムの真の所有者の判断

デザインシステムの「所有」という考えは混乱の元になり、チームを分断する原因になることさえあります。唯一の存在とされる参照先にあるものが何であるかについて、通常、デザイナーと開発者は異なる見解を持っています。デザイナーは UI、ユーザー体験、ビジュアルデザインの観点から、開発者は実装用のコードの観点から考えがちです。

では、デザインシステムの所有者は誰なのでしょうか？デザイナーなのか、それとも開発者なのか？また、チーム内で入れ替わりがあったり、新しいメンバーが加わった場合の影響はどう考えればよいのでしょう？

解決策: デザインチームと開発チームで共同のオーナーシップを確立する

デザインチームと開発チームの全員がデザインシステムの所有者であることを、最初から明確にしておくことが必要です。一人ひとりが異なる視点を持ち、異なる考えを提供できることを考慮すれば、両方のチームの全員が、デザインシステムのプロジェクトに参画すべきです。

チームメンバーはコミュニケーションをとりながら一緒に作業して、一貫性のあるブランドに適合した解決策をデザインし開発する必要があります。あるメンバーやチームがビジョンを指示して、それを他のメンバーやチームが解釈するという分断されたアプローチで達成されるべきではありません。全員が参加することで、システムは単なるアイコンの集合やコードのモジュールではなく、全体的なビジョンや考え方を示すものになります。定期的にシステムを見直して洗練させるミーティングを開催すると、新人も含めたチームメンバー全員が、共通のビジョンを持って能動的に考え続けることができます。

付け加えると、デザインシステムの最新のコンポーネントを含む動的なドキュメントがあれば理想的です。多くの場合に、デザインシステムへの変更を反映するには、たくさんの異なるファイルを更新しなければなりません。時には、デバイスごと、OS ごとにファイルが存在します。一般的に、デザイナー向けにはベクターデータを格納したファイルがあり、開発者向けにはコードとして実装されたデザインライブラリが用意されます。

このような状況で、どのファイルも常に最新に保たれていることはあまり期待できません。従って、チームが定期的にミーティングを開き、最新のデザインシステムの情報を確認し、全員が同じ理解を持ち、最新の解決策を知っていることを確認するべきです。

理想的には、以下のようなプロセスの導入が望ましいと考えられます。

• すべてのチームメンバーにデザインシステムの編集/貢献をする権限を与える
• 更新をいつどのように実施するか（すべきか）についてのガイドラインを定める
• 通知プロセスを設定する（全てのシステムの更新は、チームメンバー全員が確認できるべきで、電子メール、ブログ記事、またはミーティングを通じて、一貫性のある方法で通知されるべき）

課題 5: デザインシステムを脅威とみなす一部のデザイナー

デザイナーの考え方次第で、デザインシステムは創造性に対する脅威であるかのように感じられるかもしれません。また、効率が高いために UX デザイナーの実際の役割に対する脅威と解釈されるかもしれません。あるいは、より高次の問題を解決する機会として捉えられるかもしれません。

デザインシステムの利点を理解するデザイナーは増えています。しかしその一方で、デザインシステムが創造性を制限すると考えるデザイナーも存在します。後者は、デザインシステムについて、最も効率的で一貫したルートが一歩ずつ記述されたロードマップであると解釈しています。すべての要素が用意されているため、創造の余地はあまりなく、デザイナーは制作担当のような位置づけになると想像しています。テンプレートは用意されているか、ドラッグ＆ドロップ操作だけで簡単に作成できて、デザイン作業は冗長なものになるというわけです。

解決策: デザインシステムはワークフローの合理化であると理解させる

これは、デザイナーが、物事の見方をどのように選択するかという話です。確かにデザインシステムはロードマップのような側面を持ちますが、それは、デザインをシステム内に留まらせることで、視覚的に一貫したまとまりのあるデザイン及びユーザー体験を、ユーザージャーニー全体を通して生み出すことが目的です。

デフォルトとプライマリのボタンが定義されていると、デザイナーは手かせをはめられているように感じるかもしれません。しかし、それらに当てはまらない UI が必要な場合はどうでしょうか？そうした場面では、デザイナーは、よく考え抜かれた解決策を実現するための調査とデザインに時間を費やすことができます。

デザイナーとしては、デザインシステムの構築を、全体的に物事を見通しよく整理された状態にする機会だと考えることができます。システムが熟考されたものであり、適切に維持されていて、メンバー全員に受け入れられているなら、それはデザイナーにとって望ましい状態です。

また、デザイナーだけではなく、開発者にとっても有益なものであるはずです。開発チームが、ある状況下で何かをひねり出さなければならず、後になってデザイナーからの修正提案があって、同じコードをもう一度見直すことになるのは珍しいことではありませんでした。そんな時代はもう終わりです。デザインシステムを導入すれば、各々の問題に対し、明確なプランを持って対処できます。

最後にもう一言付け加えるなら、デザインシステムは、デザイナーが、まだ解決されていない新しいより複雑な問題に費やす時間を増やします。どれだけ詳細まで考え抜かれていても、デザインシステムは決して完成品ではありません。新しい問題が常に発生し、新しい創造的な解決策が必要とされます。ですが、デザインシステムがあるおかげで、デザイナーはこうした新たな課題に適切に向き合い調査し探求する時間を持てます。これは、デザイナーがなかなか出会うことのない状況です。

この記事は Five Common Design System Pain Points and How to Solve Them （著者: Kahl Orr ）の抄訳です