デザインシステムとは「共通言語」である。グッドパッチの実例から学ぶデザインシステムの“本領”

デザインシステムは、従来のスタイルガイドやモジュール化とどう違うのか。そもそもデザインシステムとは何か。株式会社グッドパッチの大角将輝さんと金谷薫さんは、すべての関係者に通底する「共通言語」のようだと言います。そのココロについて、実際にお二人が担当されたデザインシステム構築事例を振り返りながら教えてもらいました。

教えてくれたのは…

デザインシステムの使いどころ

デザインシステムは、現在のデザイン制作における大きな関心ごとの一つであり、実際の活用事例も増えてきました。Goodpatchでは、Webやアプリ等のソフトウェア開発を行うクライアントワークが多く、これらのプロダクトとの親和性が高いことから、デザインシステムの構築を初動から要件に含めるケースも多くなってきました。

デザインシステムは、デザインの一貫性を保ち、開発効率やUI品質を向上させるためにつくられるものです。しかし、デザインシステムは必ずしも万能ではなく、すべてのプロジェクトに適するわけではありません。その前提として、そもそもデザインシステムとは何か、という点に触れておきましょう。

デザインシステムは、定義自体が抽象的であり、画一的な規格が決まっているわけではありません。デザインシステムに含まれ得る具体的な要素としては、さまざまなものがあります。

わかりやすいものとしては、ブランドガイドラインや、プロダクトのユーザーインターフェイス（UI）のガイドライン、そしてその中のツールセットとしてのコンポーネントや、それを運用するルール等が例に挙げられるでしょう。そして、これらの要素をどのように構成するかは、プロジェクトやプロダクトの課題・目的に応じて、個別に議論し、関係者間で合意を形成しながら決定する必要があります。つまり、デザインシステムの構築自体、労力や時間等のコストが非常にかかるわけです。

そのため、単発的なランディングページや小規模なWebサイトのように、短期間で仕様がクローズし、機能追加や刷新を想定しない場合は、デザインシステムを構築する費用と効果が見合わないケースが多々あると思われます。

デザインシステムは、プロダクトやコンテンツが拡大・拡張していく場面において、その力を発揮するものです。特に、多くの人が関わり「組織で」開発・運用していく場面では不可欠なものと言え、発展性を持ったプロジェクト・プロダクトを中心に、今後ますます利活用が広まっていくでしょう。

デザインのルール化が失敗する要因

Webデザインの世界では、従来から、スタイルガイドの作成やいわゆる「モジュール化」等、デザインの統一ルールをつくる試みは行われてきました。しかし、それらが上手く定着・機能せずに失敗に終わった経験も、多くの制作者が持つところでしょう。そこで、従来のルールづくりとデザインシステムの違いや、デザインシステムが注目を集める理由について、考えてみましょう。

デザインのルールづくりが失敗する要因は大きく2つあると考えられます。まず一つは、職域で閉じて局所最適化してしまうことです。例えば、デザイナーはデザイナー間でデザイン規則を定め、エンジニアはそれとは無関係に、エンジニアの理論でコンポーネントの実装規則をつくる、といったケースがこれにあたります。

もう一つは、設計思想が属人化してしまうことです。例えば、ルール作成者が、ルールの意図や背景を残さずプロジェクトから抜けてしまい、後続メンバーが、ルールの意図・背景がわからず、変更も無視できないまま、「形だけ」従うようになるケースです。

スタイルガイドやUIコンポーネント等が最終的な形にまとまるまでには、さまざまな意図、背景、そして議論といった「文脈」が存在します。しかしこの「文脈」が共有されないままプロジェクトが拡大すると、個人や職域間で分断が起き、ルールがうまく根づかないまま形骸化・自然消滅してしまうわけです。

この点、デザインシステムは、「組織で」使うことを前提に構築するものです。言い換えるなら、いかに組織全体で「文脈」を共有するかが、デザインシステムの成功の鍵と言えます。

そのためには、職域横断的に、場合によっては企業の枠を取り払って、構築から運用まで、関わるステークホルダー全体で議論し、合意した上で活用していく意識が、デザインシステムの根底には必要です。すなわち、デザインシステムを「つくる」人、そして「使う」人、全員の「巻き込み・巻き込まれる」力が重要になってきます。

実例から考えるデザインシステム構築

ここで、Goodpatchが行ったデザインシステム構築の実例を紹介します。

このプロジェクト以前には、社内でも、統一的なルールの下での運用に課題を抱えた時期がありました。例えば、同一のコンポーネントがデザイナーによって異なる意味で使われていて、その擦り合わせに確認や手戻りが発生したり、あるいはクライアントワークで、UIコンポーネントの完成形のみを「文脈」抜きに納品してしまい、納品先でうまく活用されなかった事案もありました。そうした問題意識から、デザインシステムに注目していたのです。

プロジェクトの概要は、法人向けWebサービス用のUIコンポーネントの設計・作成でした。Webサービス（プロダクト）の開発自体は、クライアント自身が行うことが決まっていたことから、クリアすべき課題は2つありました。

まず一つは、クライアント側での開発を含め、スケジュールがタイトであったことから、全体的に開発効率を上げることが至上命題としてありました。

もう一つは、Goodpatchはプロダクトに直接は関わらないことから、納品したUIコンポーネントを、クライアント自身にしっかり「使ってもらえる」状態にすることが必要でした。

そこで、UIコンポーネントをただつくるだけでなく、その土台にある「文脈」を関係者間で共有するため、デザインシステムを構築することになりました。

流れは大きく3つのフェーズに分けられます。❶GoodpatchのUIデザイナー主導での、コンポーネントの素案・デザインの作成。❷Goodpatchエンジニア主導でのUIコンポーネントの実装（コーディング）。そして、❸クライアント側でのプロダクト開発です。

これらのフェーズは、完全に分断はせず、双方向のレビューを取り入れながら進めました。詳細は後述しますが、❶では、コンポーネントの整理にエンジニアも入り、❷では、毎朝、エンジニアからデザイナーへの質問・提案を行う「朝会」の時間を設けました。

また、❸では、クライアントの開発・運用担当者とGoodpatchのUIデザイナーでのペアデザイン等を実施しています。その他、クライアントが適宜、積極的かつ細やかにレビューをくださり、そうした密な関係性で進行できたことが、プロジェクト成功の要因だったと感じます。

デザイナーとエンジニアの協働から得られた相乗効果

このプロジェクトを通して、デザインシステムについて多くの学びがありましたが、まずは、Goodpatch内部での取組みと得られた知見を振り返ってみます。

プロジェクトではまず、UIデザイナーがプロダクトの使用場面に応じて、UIコンポーネントの素案をつくっていきました。ここで良かった点は、ある程度全体像が見えた早期の段階、すなわち設計が固まり切る前に、エンジニアがレビューに入ったことです。というのも、想定コンポーネントの総量が非常に多く、予定工数内での実装には取捨選択が必要となったためです。

その進め方としては、素案にあるコンポーネントを一覧化し、まず、機能・意味の似通ったものの統廃合を進めました。次に、「必須」のものと「あれば便利」なものに分類し、後者については使用確度の観点から精査していきました。

もう一つ良かった点として、UIデザインの設計思想に、エンジニアの設計思想が組み込まれたことがありました。例えば、コンポーネントの命名規則や分割方法については、UIデザイナーも正解がわかっていないこともよくあります。その点、エンジニアは普段からさまざまな既成のUIコンポーネントライブラリに親しんでおり、それらを参考に、使いやすい規則・分割方法をデザイナーに提案するといったことも、議論の中でよく見られました。

このデザイナーとエンジニアの協働によって得られた価値は、一義的には、実装工数の削減・開発効率の向上と言えます。しかし、より本質的な価値は、職域を超えて「同じ舟に乗って」議論ができたことだと感じています。

デザイナーとエンジニアは専門性や視座が異なり、一方通行の説明では論点が噛み合わないことも多々あります。その点、このプロジェクトでは、議論する中で相互理解が進み、同じ前提に立って議論をする「土台」が整ったことに意義を感じました。その結果、設計思想も洗練され、職域を超えて理解されるUIコンポーネントが生まれたのです。

ペアデザインで見えた課題と改善方法

このプロジェクトはクライアントワークだったため、Goodpatch内で作成したものを納品先でもしっかり「使って」もらう部分まで視野に入れる必要がありました。つまり、デザインシステムの「運用」を意識して、クライアントをどう「巻き込む」かも課題でした。

大きな試みとして、クライアント側のプロダクト開発担当者とGoodpatchのUIデザイナーによる「ペアデザイン」があります。これは、Goodpatch内でUIコンポーネントが一旦完成した段階で、実際にそれを使って先方担当者にデザインしてもらい、その様子をGoodpatchのUIデザイナーが隣で見ながら、コンポーネントの使用方法を確認・レビューするものです。

実際にやってみて実感したのは、「文脈」の共有は想像以上に難しいということでした。UIコンポーネントの設計・実装の過程でも、その設計思想や「文脈」の共有には重きをおいて、ドキュメント等にまとめていたつもりでした。しかし、ペアデザインをしてみると、先方担当者がGoodpatch側の意図しないコンポーネントの使い方をする場面も多くありました。

そこで注意したのは、Goodpatch側の意図を押しつけることではなく、先方の意図を確認・訊くことでした。クライアントには、プロダクトオーナー（事業会社）としての視点や、私たちとは異なる背景があります。異なる「文脈」から見ることで、Goodpatchの作成したガイドラインには、不足や誤読を招く部分も多かったことに気づかされました。また、Goodpatch側の意図を優先してほしい場合も、その理由を説明し、納得・合意してもらうことを大切にしました。

そして、これらのクライアントとの議論・協議から得られた新たな「文脈」は、適宜デザインシステムにも組み込んでいきました。クライアントの「文脈」が入ることで、納品後もGoodpatch抜きで自立し、運用に耐え得る強度のデザインシステムになったと感じます。

ここでの成功要因としては、クライアントの能動的な姿勢があり、強制的な教え／教わる関係ではなく、対等に議論できる関係性を築けたことがあります。デザインシステムは、運用する側に自身が「使う」気持ちがなければ強固なものにはなりません。構築には運用関係者の「巻き込まれ」力も重要です。

デザインシステムは議論の土台を整える「共通言語」

プロジェクトを通して見えてきたのは、「共通言語」としてのデザインシステムのあり方です。

デザインは、ブランドやイメージという抽象的なものを、具体的な表現に落とし込んでいく仕事です。その過程では当然に、曖昧・抽象的なワードが飛び交い、特に「組織で」デザインする上では、さまざまな背景を持つ人々との協働のために、前提や視座を揃えることが必要です。デザインシステムは、この議論の土台、すなわち関係者間で通じる「共通言語」となり、抽象と具体をつなぐ紐帯として機能します。

この点、デザインシステムに対する誤解として、表現の幅が狭まることを懸念する声もときおり聞かれます。しかし、極論するなら、最善の表現にデザインシステムからの逸脱が必要ならば、その逸脱は構わないのです。

一方で、根拠のない思いつきを許すと、そこから統一性が崩れてしまいます。そのため、最低限遵守すべき基本としての集約が、デザインシステムとして存在するのです。言い換えれば、絶対的な「型」というより、より良い表現を模索するための土台としての基本の「型」と捉えるほうが、デザインシステムの本領に近いでしょう。

また、デザインシステムの正しい運用には、ただ無思考に形をなぞるのではなく、むしろ、デザイナーやエンジニア、関わる一人ひとりが、デザインシステムの「文脈」に立脚した上で、自己の思想を表現に乗せることが大切です。表現に個々の意図や思想が通うことで、形を統一するだけではない、デザインの有機性が生まれるのです。

加えて、デザインシステムは、つくって終わりというものではありません。個々のデザインに昇華する中で、一般原則として組み込むべき「文脈」が発見されれば、それはデザインシステムに還元されるべきです。すなわち、デザインシステム自体も、それを使う人たちによって成長していくものと言えます。

関係者全員で、「共通言語」を編み、使い、育てる。その営み自体がデザインシステムだと、捉えることもできるでしょう。

Text：原明日香（アルテバレーノ）
※本記事は、「Web Designing 2024年4月号」の記事を一部抜粋・再編集して掲載しています。