デザインシステムが貴社にもたらす価値とは？
なぜ「育てる」必要があるのか
「デザインシステムは導入したものの、更新されず使われなくなってしまった」
「Figma上にコンポーネントはあるが、実際の使い方がチーム内で共有されていない」
そういった状態に、心当たりのある方も多いのではないでしょうか。
私たちも、いくつかのプロジェクトでデザインシステムの設計と運用に取り組んできましたが、感じるのは、デザインシステムの価値は「作った瞬間」よりも「どう運用するか」にあるということです。
この記事では、デザインシステムを継続的に活用し、チーム内で育てていくための考え方と運用の工夫についてまとめています。
運用に課題を感じている方や、これから仕組みを整えようとしている方のヒントになれば幸いです。
参照記事：デザインシステムとは？基礎から学ぶ重要性と導入のポイント
現場で見えてきた「定着しないデザインシステム」のパターン
私たちは、短納期でローンチするWebサイトから、クライアントのビジネス成長に寄与する中〜大規模なWebサイトまで、幅広いプロジェクトを手がけています。
その中で特に意識しているのは、単なる受託制作にとどまらず、クライアントのビジネス課題に長期的に伴走し、Webサイトを事業成長の装置として機能させることです。
その中で、デザインシステムの導入を試みたケースも多くありますが、うまく定着しない事例にも数多く直面してきました。
以下は、そうした現場で見えてきた典型的なパターンです。
更新の責任が曖昧で、時間とともに使われなくなる
初期設計時に担当者がまとめたルールがあっても、運用フェーズで誰がその内容を更新・維持すべきかが明確でなく、放置されてしまう。
デザインの基準やパーツの正しさが判別できない
実装側が参考にする情報が明文化されていないため、どのUI表現が現在の基準に基づいたものなのかが分からず、再利用されない。
仕様変更の履歴や意図が共有されていない
コンポーネントがいつ・なぜ変わったのかが分からない。結果的に、使いづらいものとして扱われ、新たに似たようなUIが作り直される。
ユニークなコンポーネントが作られ続けてしまう
一度きりしか使われないような専用コンポーネントが、毎回新たに作られる。
デザインシステムという枠組みがあるにもかかわらず、資産としての蓄積ではなく、分散が進んでしまうことに大きな課題を感じています。
これは、プロジェクトオーナー、ディレクター、デザイナー、エンジニアといった関係者全員の認識が統一されていないことが原因のひとつであり、文化的な整備も重要です。
「とりあえずまとめる」ことが目的化する
納品物の一環としてガイドラインを作成するが、プロジェクト完了と同時に運用が止まる。次のプロジェクトには引き継がれず、活用されない。
こうした事例に共通しているのは、デザインシステムが“生きた状態”で保たれていないことです。「導入して終わり」ではなく、更新され、使われ続けるための仕組みや文化がない限り、資産としての価値は発揮されません。
この気づきが、私たちがデザインシステムを「育てるもの」として捉え直すきっかけになりました。
デザインシステムを「育てる」とはどういうことか
「育てる」というと少し大げさに聞こえるかもしれませんが、デザインシステムが継続的に機能するには、更新されることを前提に設計されているかどうかが重要になります。
私たちも運用の中で改めて整理したのは、「何が大事なのか」は特別なノウハウではなく、当たり前のようでいて、日々の運用の中で見落とされがちな要素をいかに丁寧に整備するかという点でした。以下は、実務の中で特に意識しているポイントです。
状態が「常に最新」であること
「今チームが使っているUI表現」がそこにある状態が不可欠です。意図しない古い情報が残っていると、使われなくなる原因になります。更新される前提で設計されていること
ルールやコンポーネントは一度決めたら終わりではありません。変更の必要が出たときに混乱せずに対応できる構造やプロセスが必要です。利用者の声が反映されること
実際に手を動かすメンバーの「こうしたほうが良い」「使いづらい」といった声を吸い上げられる状態であり、それが反映されていくサイクルがあると、自然と信頼され、使われるようになります。チームの文化に馴染んでいること
「どこにあるかわからない」「誰に聞けばいいか分からない」状態では使われません。チャット内で自然にリンクが貼られる、会話の中で仕様が引き合いに出される──そんな状態が文化として定着している目安になります。
デザインシステムをグロースしながら運用する仕組み
「BRAND DECK」と私たちの工夫
これまでお話ししてきたように、デザインシステムを本当の意味で“資産”として機能させるには、使いやすく、更新され続け、チーム全体で共通認識が持てる状態が不可欠です。
私たちはこれまでの制作・運用の現場で得た課題意識をもとに、その運用と管理を支えるためのツールとして、デザインシステム管理SaaS「BRAND DECK（ブランド デック）」を開発しました。
BRAND DECKは、博報堂アイ・スタジオがこれまで培ってきたWebサイト構築や運用、ブランディングを熟知したデザイン開発などのノウハウを活かした、デザインシステムをグロースするSaaS型プラットフォームです。
「BRAND DECK」資料ダウンロードはこちら
BRAND DECK は、ただガイドラインをまとめるだけではなく、デザインシステムを「使われる状態」で維持するための仕組みをふんだんに組み込んだツールです。
この章では、BRAND DECK の機能と活用の工夫を紹介しながら、私たちがどのようにデザインシステムをチームの中で“育てている”のかをご紹介します。
情報の“見える化”で迷いを減らす
デザインシステムを「資産」として機能させるためには、誰もがアクセスしやすく、迷わず使える状態を保つことが最も重要です。
BRAND DECK は、そのための“情報の見える化”に強みを持っています。
BRAND DECK では、以下のような情報を一箇所にまとめて管理し、チーム全体で活用しています。
ブランドガイドライン
ロゴやブランドカラー、企業理念、トーン＆マナーなど、ブランドの土台となる情報。デザインガイドライン
色やフォント、アイコン、UI構造など、デザインのルールを体系的にまとめたもの。UIコンポーネント
Figmaやコードと連携したUIパーツと、その使い方に関する仕様や背景情報。関連ドキュメントや画像
運用ルール、設計意図、参考資料など。視覚的な補足やアニメーションも含めて管理。
これらをWebベースで誰でも閲覧できる状態にしておくことで、チーム内の迷いや誤解が減り、運用の効率も高まります。また、「探しやすく、説明しやすい」状態は、認識の揃ったデザインシステム運用に欠かせない要素だと考えています。
安心して更新できる仕組みをつくる
デザインシステムは、一度作って終わりではなく、プロダクトの進化に合わせて更新されることが前提です。
ただし、変更の意図や影響範囲がチーム内で共有されていないと、ルールの見直しに対して「混乱が起きるのではないか」という不安が生まれがちです。
そこで私たちは、変更の履歴と背景が可視化される仕組みを整え、更新の不安を減らすことを意識しています。
BRAND DECK では、以下のような情報を記録・表示できる仕組みがあります。
誰が、いつ、どこを更新したか
その変更が、どのプロジェクトに影響するか
この情報によって、たとえば以下のような判断がしやすくなります。
「この変更は他プロジェクトに影響するか？」
「このルールの更新に関係するチームはどこか？」
「複数のWebサイトで共通化されているUIか？」
こうした文脈を明示することで、変更に伴う判断やコミュニケーションの質が上がり、結果として、「安心して更新できる」状態をつくることができると感じています。
共通認識をつくるための工夫
いくら優れたツールがあっても、それをどう使うかがチーム内で共有されていなければ、デザインシステムは機能しません。BRAND DECK も例外ではなく、使い方や位置づけに対する共通認識があってこそ、初めて意味を持ちます。
私たちは、以下のような工夫を通じて、チーム内での共通認識の形成を支援しています
UIの意図や背景を明記し、ルールの根拠を記録する
コンポーネントの再利用可否や例外条件を明確にする
プロジェクト開始時に判断基準をチーム全体で確認する
ツールはあくまで仕組みの一部に過ぎません。大切なのは、「なぜそうするのか」をチームで共有し続ける文化であり、それがあって初めて、デザインシステムは育ち続けるものになると考えています。
非制作職でも使える「画面シミュレーター」
BRAND DECK には、登録されたUIコンポーネントを選んで画面イメージを構築できる「シミュレーター」機能があります。
この機能は、デザイナーやエンジニアでなくても利用できるよう設計されています。
たとえば
企画会議で思いついた画面構成をすぐに試作する
プロダクトオーナーがユーザー導線を検討しながら構成を検証する
UIパーツが不足していることに気づいたとき、デザイナーと議論を始める
といった場面で活用されています。
現在は、UIコンポーネントをクリックで選択・追加して構成する仕様となっており、複雑な操作なしに、誰でも直感的に画面構成を検討できるようになっています。
BRAND DECK というツールも“育てている”
私たちは、デザインシステムの運用や改善において「育てる」という視点を大切にしていますが、この BRAND DECK というツール自体も、私たち自身の実務から生まれ、“育てながら使っている”プロダクトです。
複数のプロジェクトで生まれた課題
「情報が散らばって探しづらい」「ルールが属人化していて共有されない」
そんな実感から開発をスタートし、現在は外部のお客さまにも提供可能なSaaSとして進化しています。
これからの展望─“資産として育てる”ために
デザインシステムは、導入した時点で完成するものではありません。
むしろ、運用が始まってからこそ、さまざまな課題や改善の余地が見えてくるものだと思っています。
私たちも、これまでに複数のプロジェクトに関わる中で、「育てていく」という視点の重要性を強く感じてきました。ツールとして何を実装するかよりも大切なのは、「これは資産である」という視点でデザインシステムに向き合う姿勢だと考えています。
BRAND DECK は、そうした変化を支える一助として、今後も以下のような機能の拡充を進めていきます
よりスムーズなFigmaとの連携
コンポーネントの活用状況を横断的に可視化する仕組み
公開リンクを通じた外部との共有機能
AI活用を前提としたコンポーネント設計の支援
この記事が、デザインシステムの導入や運用に取り組む皆さんにとって、今後の方針や設計のヒントになれば嬉しく思います。
もし私たちが開発している BRAND DECK にご興味を持っていただけたなら、ぜひお気軽にご連絡ください。
実際の画面や使い方をご紹介しながら、一緒に資産としてのデザインシステムを考えていければと思っています。
