As their audiences grow and change, so does the demand for progress, evolution, and possibilities.

視聴者が成長し、変化するにつれ、進歩、進化、可能性への要求も変化する。

Many of them are turning to design systems as a potential solution.

その多くが、潜在的な解決策としてデザイン・システムに目を向けている。

In this lesson, we'll learn what a design system is and what's included in one, explore the problems a design system can help solve, help you identify when you need one, and highlight a few things to consider as you start your design system's journey.

このレッスンでは、デザイン・システムとは何か、デザイン・システムには何が含まれるかを学び、デザイン・システムが解決に役立つ問題を探り、デザイン・システムが必要な時期を見極め、デザイン・システムの旅を始めるにあたって考慮すべき点をいくつか紹介します。

So what exactly is a design system?

では、デザインシステムとは一体何なのか？

If your first thought is a style guide and a component or pattern library, you're not alone.

もしあなたが最初にスタイルガイドとコンポーネントやパターンライブラリを思い浮かべたとしても、それはあなただけではない。

Yes, you'll see aspects of these in a design system, but you'll also see a focus on the bigger picture, the entire product ecosystem.

デザイン・システムにはこれらの側面が見られるが、より大局的な視点、つまり製品のエコシステム全体にも焦点が当てられている。

After all, products aren't just a collection of UI elements splattered on a screen.

結局のところ、製品は画面上に散らばったUI要素の集合体ではない。

They're organized in strategic ways to communicate messages, encourage certain behaviors, and guide you through processes.

メッセージを伝え、特定の行動を促し、プロセスを導くために、戦略的な方法で組織されている。

They are a reflection of the vision, concepts, and values of an organization.

組織のビジョン、コンセプト、価値観を反映したものである。

It's important that a design system communicates not just the what, but the how and the why.

デザイン・システムは「何を」だけでなく、「どのように」「なぜ」を伝えることが重要だ。

Let's explore some of the resources a design system might include.

デザイン・システムに含まれる可能性のあるリソースをいくつか探ってみよう。

Style guides are a set of standards that define the appearance of elements and the overall voice and tone.

スタイルガイドは、要素の外観と全体的なボイスとトーンを定義する一連の基準である。

They focus on the visual language of the product, how things should look and feel.

彼らは製品の視覚的言語、物事がどのように見え、感じるべきかを重視する。

You'll see aspects of these in most design systems.

ほとんどのデザインシステムで、これらの側面を見ることができる。

Examples include color and typography.

例えば、色やタイポグラフィなどだ。

Component libraries contain the building blocks of a product.

コンポーネント・ライブラリには、製品の構成要素が含まれています。

This might include individual components, layouts and templates, and interaction patterns.

これには、個々のコンポーネント、レイアウト、テンプレート、インタラクション・パターンが含まれる。

They focus on how assets should behave in the product.

彼らは、アセットが製品の中でどのように振る舞うべきかを重視する。

They also often include on-canvas red lines or annotations, or are embedded alongside code components with detailed documentation.

また、キャンバス上に赤線や注釈を入れたり、詳細なドキュメントのあるコードコンポーネントと一緒に埋め込んだりすることも多い。

As you go through your design system's journey, keep in mind that there is no one design system that fits all.

デザイン・システムの旅に出るとき、すべてに適合するデザイン・システムは存在しないことを心に留めておいてほしい。

Different companies have different needs, which require different solutions.

企業によってニーズは異なり、必要なソリューションも異なる。

Now that we have an idea of what a design system is, do we actually need one?

さて、デザイン・システムとは何かということはわかったが、実際にデザイン・システムは必要なのだろうか？

You might be wondering how this could play out in real life.

これが実際の生活でどのように展開するのか、不思議に思うかもしれない。

Let's look at this scenario.

このシナリオを見てみよう。

Kai is a product designer in Habits, a habit-forming app available on multiple device types, and is supported by smart reminders and integrations.

カイはHabitsのプロダクトデザイナーで、複数のデバイスタイプで利用可能な習慣形成アプリであり、スマートリマインダーや統合機能によってサポートされている。

This app has been in development for a while, and the design team just received additional headcount.

このアプリはしばらくの間開発中で、デザインチームは増員されたばかりだ。

Recently, they were working on new screens and couldn't remember what a few elements look like.

最近、彼らは新しいスクリーンに取り組んでいたが、いくつかの要素がどのように見えるか思い出せなかった。

They referenced older screens, but noticed that some details look different across different device themes.

彼らは古いスクリーンを参照したが、いくつかのディテールが異なるデバイスのテーマで異なって見えることに気づいた。

Which of these are reliable?

どれが信頼できるか？

What if it's none of them?

そのどれでもなかったら？

In weekly critiques, Kai also noticed components looking different between different designers.

毎週の批評の中で、カイもデザイナーによってコンポーネントが違って見えることに気づいていた。

They're beginning to wonder if it's time to consider a design system.

彼らは、そろそろデザインシステムを検討する時期なのではないかと考え始めている。

There is no straightforward answer on when to implement a design system.

デザインシステムを導入するタイミングについて、明確な答えはない。

However, we can make informed decisions by understanding the benefits a design system can bring, the challenges that can come along with it, and what problems we need to solve within our organization.

しかし、デザイン・システムがもたらすメリット、それに伴う課題、組織内で解決すべき問題を理解することで、十分な情報に基づいた意思決定を行うことができる。

First, let's cover how a design system can help.

まず、デザイン・システムがどのように役立つかを説明しよう。

Even when starting small, design systems allow teams to do more with less.

小規模からスタートする場合でも、デザイン・システムによって、チームはより少ない人数でより多くのことができるようになる。

Not just when it comes to designing and prototyping features, but also when building real-world experiences.

機能の設計やプロトタイピングだけでなく、実世界での体験を構築する際にも。

Designers spend less time remaking components and sweating the small stuff.

デザイナーは部品を作り直したり、細かいことに悩んだりする時間を減らすことができる。

This increases their design output and allows them to focus more time on solving design problems.

これにより、設計のアウトプットが増え、設計上の問題解決により多くの時間を割くことができる。

When we're ready to scale teams, a design system becomes an onboarding resource that allows new teammates to contribute sooner.

チームの規模を拡大する準備ができたとき、デザイン・システムは、新しいチームメイトがより早く貢献できるようにするオンボーディング・リソースとなる。

And design systems aren't just for designers.

そして、デザイン・システムはデザイナーだけのものではない。

When we align design components with code, tokens, and animation presets, developers can translate designs into functional, accessible code in a fraction of the time.

デザイン・コンポーネントをコード、トークン、アニメーション・プリセットに合わせることで、開発者はデザインを機能的でアクセスしやすいコードにわずかな時間で変換することができます。

As a design system matures, it becomes the single source of truth within an organization.

デザイン・システムが成熟するにつれて、それは組織内の唯一の真実の情報源となる。

It provides teams with a shared vision and language that leads to better understanding and more consistent products.

チームに共通のビジョンと言語を提供することで、理解を深め、より一貫性のある製品を生み出すことができる。

These benefits don't just impact the internal processes of building a product.

これらの利点は、製品作りの内部プロセスに影響を与えるだけではない。

They also contribute to your customers' experience of the product.

また、顧客の製品体験にも貢献する。

Consistency, usability, and accessibility build trust in your product and can lead to a more engaged and loyal customer base in the long run.

一貫性、使いやすさ、アクセシビリティは、製品への信頼を築き、長期的には、より熱心で忠実な顧客ベースにつながります。

Conversations about design systems are ever-present, and with so many impressive examples to take inspiration from, the fear of missing out feels very real.

デザイン・システムに関する話題は常につきまとい、インスピレーションを得るための印象的な事例がたくさんあるため、取りこぼすことへの恐怖が非常に現実的に感じられる。

It's tempting to jump right into the deep end.

すぐに深いところに飛び込みたくなる。

So when might a design system actually be the right decision?

では、どのような場合にデザイン・システムを導入するのが正しい選択なのだろうか？

The first thing to look out for is consistency.

まず気をつけるべきは一貫性だ。

Do you spot inconsistencies between styles, components, and behaviors in the product?

製品のスタイル、コンポーネント、ビヘイビアの間に矛盾がないか？

Are you building for multiple brands or products and need unification across their experiences?

複数のブランドや製品のために構築し、それらのエクスペリエンスを統一する必要がありますか？

Does your product use more than one theme, such as dark and light modes?

あなたの製品は、ダークモードとライトモードなど、複数のテーマを使用していますか？

What about different devices?

異なる機器についてはどうですか？

Or you might need to remove redundancy.

あるいは、冗長性を排除する必要があるかもしれない。

Are people building the same things over and over?

人々は同じものを何度も作っているのだろうか？

Are teammates debating over the same issues again and again?

チームメイトは何度も同じ問題を議論しているのか？

Does the team use a shared language to talk about the product and solve problems?

チームは、製品について話し、問題を解決するために共有言語を使用していますか？

How efficient is it to find answers to product questions?

製品に関する質問に対する回答を見つけるのに、どの程度効率的ですか？

If your team is growing, how long does it take to onboard new teammates with the product information they need?

チームが成長している場合、新しいチームメイトに必要な製品情報を提供するまでにどれくらいの時間がかかりますか？

Lastly, where in the product lifecycle can you benefit from improved speed and efficiency?

最後に、製品ライフサイクルのどの段階で、スピードと効率の向上による恩恵を受けることができるのか。

How much time is spent creating, iterating, or prototyping?

創作、反復、プロトタイピングにどれだけの時間を費やしているか？

How about finding out whether a design is up-to-date?

デザインが最新かどうかを調べるのはどうだろう？

Take time to observe or reflect on how your product teams work together, the product's overall experience, and the problem areas we just outlined.

製品チームがどのように協力し合っているか、製品の全体的なエクスペリエンス、今説明した問題点を観察したり、振り返ったりする時間を取る。

If you work on a team, consider discussing as a group.

チームで仕事をしている場合は、グループで話し合うことを検討する。

Remember, not everyone needs a design system.

すべての人にデザイン・システムが必要なわけではないことを忘れないでほしい。

You may already have effective solutions for these different issues.

こうしたさまざまな問題に対する効果的な解決策をすでに持っているかもしれない。

Or, not right now may be your answer, and you revisit this later down the line.

あるいは、今すぐではない、という答えが返ってくるかもしれない。

Roam wasn't built in a day, and neither is a design system.

ロームは一日にして成らず、デザイン・システムも一日にして成らず。

Like products, a design system requires consistent time and effort, not only to implement, but also to maintain.

製品同様、デザイン・システムも、導入だけでなく維持にも一貫した時間と労力を必要とする。

And while they require investment, it might be a while before you get to see the results of your efforts.

また、投資を必要とする一方で、努力の結果が出るまでにはしばらく時間がかかるかもしれない。

This can make it challenging to get buy-in from leadership, especially if it takes away from the day-to-day work or requires hiring more people.

このため、特に日常業務から離れたり、より多くの人材を雇用する必要があったりする場合は、首脳陣の賛同を得るのが難しくなる。

Socializing a design system with the rest of the organization can also feel like an uphill battle.

デザイン・システムを組織の他の部分と社会化することも、困難な戦いのように感じられるかもしれない。

You'll need a group of design system champions to accomplish this successfully.

これを成功させるには、デザイン・システム・チャンピオンのグループが必要だ。

After discovering some design inconsistencies, a need for knowledge share with a growing team, and a need for device theming, Kai believes it's a good time to consider a design system.

デザインの矛盾、成長するチームとの知識共有の必要性、デバイスのテーマ設定の必要性を発見したカイ氏は、デザインシステムを検討する良い機会だと考えている。

They're not fully convinced that they need one quite yet, and will need to gather more information before they can convince leadership that this is worth the investment.

彼らは、まだその必要性を完全に確信しているわけではなく、投資に見合うだけの価値があることをリーダーシップに納得させるには、もっと情報を集める必要がある。

What should they do next?

次に何をすべきか？

If you're still uncertain whether a design system is for you, performing an audit could provide additional insight.

デザイン・システムが自社に適しているかどうか、まだ確信が持てない場合は、監査を実施することで、さらなる洞察が得られるかもしれない。

Audits give you the opportunity to take stock of the entire product, everything it consists of, and areas of improvement.

監査は、製品全体、その構成要素すべて、そして改善点を把握する機会を与えてくれる。

Findings from an audit can help open up conversations about various problems and even contribute to buy-in from leadership.

監査の結果は、様々な問題についての会話を広げ、さらにはリーダーシップからの賛同を得るのに役立つ。

It can be initiated by any team, but will eventually bring on other disciplines, making this a company-wide effort.

どのチームでも始められるが、最終的には他の分野も巻き込み、全社的な取り組みとなる。

Whether or not you decide to implement a design system, audits are a crucial step in understanding the current state of the product.

設計システムを導入するか否かにかかわらず、監査は製品の現状を理解するための重要なステップである。

Before you begin auditing, think about who can help you with this task.

監査を始める前に、誰がこの作業を手伝ってくれるかを考えましょう。

What cross-functional partners can provide a fuller picture of what the product consists of and what it needs?

どのようなクロスファンクショナル・パートナーが、その製品がどのようなもので構成され、何が必要なのかをより詳細に把握することができるのか？

For example, developers can help identify gaps between design and code, and the support team might know about sneaky modals and error messages that you wouldn't regularly catch.

例えば、開発者はデザインとコードのギャップを特定するのに役立ちますし、サポートチームは、あなたが普段はキャッチしないような卑劣なモーダルやエラーメッセージについて知っているかもしれません。

To perform an audit, first gather everything that exists.

監査を行うには、まず存在するものすべてを集める。

Identify user flows in all elements used in product like colors and text, illustrations and icons, buttons and dropdowns, patterns and interactions, and so on.

色やテキスト、イラストやアイコン、ボタンやドロップダウン、パターンやインタラクションなど、製品に使用されているすべての要素におけるユーザーフローを特定する。

Collect them all in one place to refer to them later.

後で参照できるように、一か所に集めておく。

Remember to interact with the product so we don't miss elements like loading states, hover states, or warning modals.

ローディング状態、ホバー状態、警告モダルのような要素を見逃さないように、製品とのインタラクションを忘れずに。

If the product spans different devices or operating systems, we'll want to audit those as well.

製品がさまざまなデバイスやOSにまたがっている場合は、それらも監査したい。

Next, sort and categorize everything.

次に、すべてのものを分類・分類する。

If there are large numbers of elements in a group, we can categorize them even further.

グループ内に多数の要素がある場合、それらをさらに分類することができる。

For example, we've collected a group of text elements being used in our product.

例えば、私たちの製品で使われているテキスト要素のグループを集めました。

We notice that we can further categorize these by paragraph, quote, heading 1, and so on.

段落、引用、見出し1など、さらに分類できることに気づく。

Each of these subcategories have more than one instance per style, which will help us in our evaluation later.

これらのサブカテゴリーはそれぞれ、スタイルごとに複数のインスタンスを持っている。

Lastly, analyze what's been gathered to identify patterns and areas of opportunity.

最後に、収集したものを分析して、パターンと機会のある分野を特定する。

Where do we see redundancy in user flows that can be Which areas have poor accessibility?

ユーザー・フローのどこに冗長性があるか？ アクセスの悪いエリアはどこか？

Think beyond contrast and readability.

コントラストと読みやすさを超えて考える。

How is alt text handled for images and icons?

画像やアイコンのaltテキストはどのように扱われますか？

Are input forms built for the device they're being viewed on?

入力フォームは、閲覧されるデバイスに合わせて作られているか？

Are assets and styles consistent with the developer's library?

アセットとスタイルは開発者のライブラリと一貫しているか？

What inconsistencies are among styles, patterns, and objects?

スタイル、パターン、オブジェクトの間にはどのような矛盾があるのか？

Kai explained to their manager the issues and opportunities they've been observing.

カイはマネジャーに、彼らが観察してきた問題や機会を説明した。

The manager gave approval to recruit the entire design team to conduct an They brainstorm various solutions to prevent the issues from happening in the future.

マネージャーは、デザイン・チーム全員を招集し、今後問題が起こらないようにするためのさまざまな解決策をブレインストーミングすることを承認した。

A design system is on this list of potential solutions, and it's looking more and more like a winner.

デザイン・システムはこの解決策候補のリストに入っており、ますます勝者になりそうだ。

So you've done some discovery work.

忖度したわけだ。

Maybe you've concluded that a design system is the path for you.

もしかしたら、デザイン・システムが自分のための道だという結論に達しているかもしれない。

What's next?

次はどうする？

Let's see what the future might hold.

どんな未来が待っているのか見てみよう。

Approval As the company grows and matures, so does its design system.

承認 会社が成長し成熟するにつれて、その設計システムも成長する。

Design systems are ever-evolving, just like the products they support.

設計システムは、それがサポートする製品と同じように、常に進化している。

To anchor us on this journey, it's important to understand that design systems have a non-linear path.

私たちをこの旅に導くには、デザイン・システムには非直線的な道筋があることを理解することが重要だ。

This process may vary from one company to the next.

このプロセスは会社によって異なるかもしれない。

Let's take a look at what phases we may encounter throughout our process.

では、その過程でどのような局面に遭遇する可能性があるのかを見てみよう。

Approval This is where we work to get leadership on board with design systems, so we have access to bandwidth and resources needed for the project.

承認 ここで私たちは、指導者たちがデザイン・システムに賛同し、プロジェクトに必要な帯域幅やリソースにアクセスできるようにする。

Discovery Where we conduct research and audits, identify audiences and problems, and brainstorm solutions.

ディスカバリー 調査や監査を行い、オーディエンスや問題を特定し、解決策をブレーンストーミングする。

Definition Where we make decisions on solutions, contributors, and approaches.

定義 解決策、貢献者、アプローチについて決定を下す場所。

Building Where we assemble the actual design system.

構築 実際の設計システムを組み立てるところ。

Documentation Where we detail how to use the design system in an approachable way.

ドキュメンテーション 設計システムの使用方法をわかりやすく説明します。

Maintenance Where we make sure the system is up-to-date with supporting the product, and that design and code are aligned.

メンテナンス 製品をサポートするシステムが最新であること、設計とコードが一致していることを確認します。

Advocacy Where we socialize the design system into the organization, often with the help of champions.

アドボカシー 多くの場合、チャンピオンの助けを借りて、デザインシステムを組織に社会的に浸透させます。

Throughout our design systems journey, we'll likely find ourselves revisiting phases on a regular basis.

デザイン・システムの旅を通して、私たちは定期的にフェーズを再訪することになるだろう。

Some phases may even overlap with each other.

段階によっては、互いに重なることもある。

Remember, this is not a linear process with a single endpoint.

覚えておいてほしいのは、これはひとつの終着点を持つ直線的なプロセスではないということだ。

Treat a design system like you would building software, an ever-evolving product that is regularly iterated on.

デザインシステムは、ソフトウェアを作るのと同じように扱い、定期的に反復される、常に進化し続ける製品なのだ。

Thoughtfully planning and doing discovery work for your design system will make an impact on its quality, as well as support a more efficient journey.

デザイン・システムのために思慮深く計画し、発見作業を行うことは、その品質に影響を与えるだけでなく、より効率的な旅をサポートする。

Here's a few things you may want to consider.

ここで、いくつか考えていただきたいことがある。

Contributors Contributors are the people who help build and maintain the design system.

コントリビューター コントリビューターとは、デザイン・システムの構築と保守を支援する人々のことです。

They can be individuals from different teams across the organization, or a team whose full-time job is dedicated to this ongoing project.

彼らは、組織全体のさまざまなチームの個人であっても、この継続的なプロジェクトに専任するチームであってもよい。

Contributors can also be individuals who approve changes to a design system, or can help champion and socialize it.

貢献者はまた、デザイン・システムの変更を承認する個人であったり、デザイン・システムの支持や社会化を支援する個人であったりする。

Take some time to consider.

時間をかけて考えてみてください。

Who in your organization would be valuable contributors?

あなたの組織では誰が貴重な貢献者となるだろうか？

How many people will it take to support the success of this project?

このプロジェクトの成功を支えるには、何人の人間が必要なのだろうか？

Remember, there is more to this process than building.

このプロセスには、建物を建てる以上のものがあることを忘れてはならない。

There are other phases like getting buy-in or documentation.

賛同を得たり、文書化したりといった他の段階もある。

You may find that some tasks are better supported by different people.

また、別の人がサポートした方がよい仕事もあるかもしれない。

Discuss with your team to determine whether you need a separate, dedicated design systems team.

デザイン・システムの専門チームが別途必要かどうか、チームと話し合ってください。

Keep in mind you'll need to balance it against the organization's needs and available resources.

組織のニーズや利用可能なリソースとのバランスを取る必要があることに留意してほしい。

Your audience are the ones who will be using your design system.

オーディエンスとは、あなたのデザインシステムを使う人たちのことです。

Think beyond designers as the audience.

デザイナーが観客であることを越えて考える。

What about developers, UX writers, brand, marketing, and product education teams?

開発者、UXライター、ブランド、マーケティング、製品教育チームはどうだろうか？

Audience can inform what and how things go into a design system.

観客は、何をどのようにデザインシステムに取り入れるかを知ることができる。

They can be recruited to pressure test the system and provide meaningful feedback on how to improve it.

そのような人たちを採用して、システムの圧力テストを行い、改善方法について有意義なフィードバックを提供することができる。

Set up time with yourself or with contributors to explore these questions and understand your audience better.

自分自身や貢献者と一緒に、これらの質問を探求し、聴衆をよりよく理解する時間を設けましょう。

Who will be using the design system and how often?

誰が、どのくらいの頻度でデザインシステムを使用するのか？

Who might we not be considering?

私たちは誰を考慮していないのだろうか？

What is their experience with design systems?

デザインシステムについての経験は？

What might the process of soliciting feedback look like, now and ongoing?

現在、そして継続的にフィードバックを求めるプロセスはどのようなものだろうか？

The last aspect is to consider how we might implement a design system.

最後の側面は、デザインシステムをどのように導入するかを考えることだ。

If we build the design system from the ground up, the result will be a unique, customized solution made to solve our specific set of problems.

デザイン・システムを一から構築すれば、その結果、私たちの特定の問題を解決するために作られた、ユニークでカスタマイズされたソリューションになる。

This method requires the most time, effort, and resources, making it challenging to get buy-in.

この方法は最も時間と労力と資源を必要とするため、賛同を得るのが難しい。

If we need something more quick and budget-friendly, we could use or borrow parts of an existing one from another company, and only document things we want to do differently.

もっと手早く、予算に見合ったものが必要なら、他社の既存のものを使うか、その一部を借りるかして、自分たちが違うことをしたいときだけ文書化すればいい。

Or, we could build a wireframe library using an existing design kit.

あるいは、既存のデザインキットを使ってワイヤフレーム・ライブラリを作ることもできる。

We may borrow a token structure from another system like Shopify's Polaris, and update it within our own guidelines.

ShopifyのPolarisのような他のシステムからトークン構造を拝借し、独自のガイドラインの中で更新することもある。

We can also pull inspiration from other design systems to better support our design system goals.

また、他のデザイン・システムからインスピレーションを得て、デザイン・システムの目標をよりよくサポートすることもできる。

We might see another company's accessibility guidelines and find that we want to include our own.

他社のアクセシビリティ・ガイドラインを見て、自分たちのガイドラインを盛り込みたいと思うかもしれません。

We might love how a system communicates information to developers, and decide we need to improve this aspect of our own system.

私たちは、あるシステムが開発者に情報を伝える方法を気に入り、自分たちのシステムのこの点を改善する必要があると判断するかもしれない。

While it's possible to stick with one of these approaches, it's more likely that we'll use a combination of them.

どちらか1つのアプローチにこだわることも可能だが、それらを組み合わせて使うことの方が多いだろう。

Here are other questions to help you evaluate further.

以下は、さらに評価するのに役立つその他の質問である。

Where does this project fit within company goals?

このプロジェクトは会社の目標のどこに合致しているか？

How much time and bandwidth do contributors have?

投稿者にはどれだけの時間と帯域幅があるのか？

How many resources is leadership willing to provide?

指導者はどれだけのリソースを提供するつもりなのか？

This is a good place to refer to your audit findings as well.

監査結果もここで参照するのがよい。

Let's pay the Habits team another visit to see how their decision is coming along.

ハビッツ・チームをもう一度訪ね、彼らの決断がどのように進んでいるかを見てみよう。

They've had multiple conversations with leadership who have ambitions to expand the company and the product more rapidly.

彼らは、会社と製品をより急速に拡大する野心を持つ指導者たちと何度も話をした。

Leadership understands that even though the number of inconsistencies in the product is nothing to be alarmed of, it's a problem that may soon grow.