Since implementing their design system, the Habits team has seen more consistency in designs and no longer debates endlessly over which standards to use.

デザイン・システムを導入して以来、Habitsチームはデザインに一貫性が生まれ、どのスタンダードを使うかで延々と議論することがなくなった。

However, the Habits app is evolving and growing.

しかし、Habitsアプリは進化し、成長している。

After discovering that their users track their habits before bed, the team wants to add a dark theme to ease tired eyes.

ユーザーが寝る前の習慣を記録していることを発見したチームは、疲れ目を和らげるためにダークテーマを追加したいと考えている。

While the spatial system has sped up the design process and solved alignment issues, the team struggles to keep track of which border radius and spacing values to use.

空間システムは設計プロセスをスピードアップし、アライメントの問題を解決したが、チームはどのボーダー半径とスペーシングの値を使うべきかを把握するのに苦労している。

This has led to an unpredictable and inconsistent user experience.

このため、予測不可能で一貫性のないユーザー体験がもたらされている。

And, they're adding new teammates and features and want a more efficient way to manage changes and improve accuracy during the handoff process.

また、新しいチームメイトや機能が追加され、変更をより効率的に管理し、ハンドオフ・プロセスの正確性を向上させる方法を求めている。

Kai has been learning about design tokens and believes that this could be the next step in supporting scalability of the Habits design system.

カイはデザイン・トークンについて学んでおり、これがHabitsデザイン・システムのスケーラビリティをサポートする次のステップになると考えている。

The benefits of design tokens are very similar to that of design systems.

デザイン・トークンの利点は、デザイン・システムのそれと非常によく似ている。

They're a source of truth that maintains consistency between design and code.

デザインとコードの一貫性を保つ、真実の源なのだ。

They improve management of a scaling design system.

スケーリング設計システムの管理を改善する。

And they remove the guesswork when building products and help you build more efficiently.

また、製品を製造する際の当て推量を排除し、より効率的な製造を支援する。

But what exactly are design tokens?

しかし、デザイン・トークンとは一体何なのか？

How might this help the Habits team?

これはハビッツ・チームにどのように役立ちそうですか？

Design tokens are a method for managing design properties and values across a design system.

デザイン・トークンは、デザイン・システム全体でデザイン・プロパティと値を管理する方法です。

Each token stores a piece of information, such as color, sizing, spacing, font, animations, and so on.

各トークンは、色、サイズ、間隔、フォント、アニメーションなどの情報の一部を格納する。

To make them easier to refer to, each token also gets a name.

参照しやすくするため、各トークンには名前も付けられている。

The tokens can be reused across your designs and become a source of truth and shared language between design and code.

トークンはデザイン全体で再利用することができ、デザインとコードの間で真実と共有言語のソースとなる。

For example, Kai recently handed a design file to a developer that contained spacing values of 25 points.

例えば、カイが最近開発者に渡したデザインファイルのスペーシング値は25ポイントだった。

However, the Habits codebase uses an 8-point spatial system.

しかし、ハビッツのコードベースは8点空間システムを使っている。

The developer assumed this was intentional and updated the codebase with the new designs.

開発者はこれを意図的なものだと思い、新しいデザインでコードベースを更新した。

Oops!

おっと！

Kai actually meant to have spacing values of 24 points, but their file was set up incorrectly.

甲斐は本当はスペーシングを24ポイントにするつもりだったが、ファイルの設定が間違っていた。

If the team used tokens, the design file would have included information on which spacing token to use.

トークンを使用するチームであれば、デザインファイルにはどのスペーシング・トークンを使用するかという情報が含まれていたはずだ。

The spacing token would point to a value that's already confirmed to be correct, preventing errors and ambiguity.

スペーシング・トークンは、すでに正しいことが確認されている値を指すので、エラーや曖昧さを防ぐことができる。

In addition to having a reliable source of truth, using tokens means that updating our designs and design system becomes faster and more efficient.

信頼できる真実のソースを持つことに加え、トークンを使用することは、デザインやデザイン・システムの更新がより迅速かつ効率的になることを意味する。

For example, say the Habits team has this color token being used in different areas of the product.

例えば、Habitsチームが製品のさまざまな分野でこの色のトークンを使用しているとします。

If they changed the value of this color token, then every asset using the token will change too.

もし彼らがこのカラー・トークンの値を変更すれば、トークンを使用しているすべてのアセットも変更されることになる。

This can be useful like when changing a color system for a product rebrand.

これは、製品のリブランディングのためにカラーシステムを変更する場合などに便利です。

However, what if they only wanted the values of some assets to change?

しかし、一部の資産の価値だけを変えたいとしたらどうだろう。

Currently, they'd have to remap these values one by one to a different token.

現状では、これらの値をひとつひとつ別のトークンにマッピングし直さなければならない。

This isn't a problem if only a few assets need updating, but if many assets had to be updated, the Habits team would need a lot more time and resources.

更新が必要なアセットが少数であれば問題ないが、多くのアセットを更新しなければならない場合、Habitsチームはより多くの時間とリソースを必要とすることになる。

This is where aliasing comes in.

ここでエイリアシングが発生する。

Aliasing allows any token to reference or take on the value of another token.

エイリアシングは、トークンが他のトークンの値を参照したり、その値を引き継いだりすることを可能にする。

If a token changes, then any token referencing it will update as well.

トークンが変更されると、それを参照しているすべてのトークンも更新されます。

But how does this solve the Habits team problem?

しかし、これでハビッツ・チームの問題はどう解決するのだろうか？

Well, aliasing lets you neatly organize tokens into categories, subcategories, and so on.

エイリアシングを使えば、トークンをカテゴリーやサブカテゴリーなどにきちんと整理することができる。

The categories communicate how a token is used.

カテゴリーとは、トークンがどのように使われるかを伝えるものである。

If Habits had their tokens set up correctly, they'd be able to quickly update any category and all associated tokens downstream would get updated without unintentionally affecting others.

もしハビッツがトークンを正しく設定していれば、どのカテゴリーも素早く更新でき、下流にある関連するすべてのトークンが、意図せず他のカテゴリーに影響を与えることなく更新されるはずだ。

There's no limit to how far a series of token references can go.

一連のトークン・リファレンスに限界はない。

And no limit to how many times a single token can be referenced, allowing us to create complex design token structures.

また、1つのトークンの参照回数に制限がないため、複雑なデザインのトークン構造を作成することができる。

Keep in mind aliasing isn't always necessary, especially for assets like fonts and animations.

特にフォントやアニメーションのようなアセットでは、エイリアシングは必ずしも必要ではないことを覚えておいてください。

After realizing the benefits, the Habits team decided to implement design tokens in their system.

その利点を理解した後、Habitsチームはシステムにデザイントークンを導入することを決めた。

Before they jump in, they want to understand how tokens are organized.

彼らは飛び込む前に、トークンがどのように組織化されているかを理解したいのだ。

The most common structure of design tokens starts with the foundation of values called primitive tokens.

デザイン・トークンの最も一般的な構造は、プリミティブ・トークンと呼ばれる値の基礎から始まる。

From there, you can build on top of your foundation with semantic tokens and component-specific tokens.

そこから、セマンティックトークンやコンポーネント固有のトークンを使って、基礎の上に構築することができる。

Each type communicates a what, how, and where about the token.

それぞれのタイプは、トークンについて「何を」「どのように」「どこで」を伝える。

Let's take a closer look at each one, starting with our foundation.

では、それぞれの基礎から詳しく見ていこう。

Primitive tokens tell us what properties and values exist within our designs.

プリミティブ・トークンは、デザインの中にどのような特性や値が存在するかを教えてくれます。

Also known as global tokens, they define every value in a property system.

グローバルトークンとも呼ばれ、プロパティシステムのすべての値を定義する。

For example, primitive color tokens would include every color used in the app and its brand, while primitive spacing tokens would include all padding, margin, and spacing between values.

例えば、プリミティブ・カラー・トークンには、アプリで使用されるすべての色とそのブランドが含まれ、プリミティブ・スペーシング・トークンには、すべてのパディング、マージン、値間の間隔が含まれる。

Note that primitive tokens are reference only.

原始トークンは参照のみであることに注意。

They are the foundation for other tokens to build from but are never applied directly in designs.

他のトークンの土台となるものだが、デザインに直接応用されることはない。

Semantic tokens, however, can be applied to designs.

しかし、セマンティック・トークンはデザインに適用できる。

Semantic tokens gives us context on the how the token should be used.

セマンティックトークンは、トークンがどのように使われるべきかについての文脈を与えてくれる。

As no ted in lesson 2, assets with semantic names convey meaning, purpose, and how and where the asset should be used.

レッスン2で説明したように、セマンティックな名前を持つアセットには、意味、目的、アセットがどこでどのように使用されるべきかを伝える意味があります。

For example, the token surfaced brand contrast references a primitive token called pink 400.

例えば、surfaceed brand contrastというトークンは、pink 400というプリミティブなトークンを参照している。

It takes on whatever value pink 400 is set to.

ピンク400がどのような値に設定されていても、それを引き継ぐ。

Surface tells us that it should be used for an object's background color.

Surfaceは、オブジェクトの背景色に使用することを指示している。

Brand tells us that the color is central to the app's identity.

ブランドは、この色がアプリのアイデンティティの中心であると語る。

And contrast tells us that this color is saturated and should be used to grab a user's attention.

そしてコントラストは、この色が飽和色であり、ユーザーの注意を引くために使われるべきであることを教えてくれる。

Lastly, we have component-specific tokens, which provide us even more specificity on usage by telling us where a token is used.

最後に、コンポーネント固有のトークンがある。これは、トークンがどこで使用されるかを示すことで、使用方法をさらに具体化するものである。

And yep, they're used directly in designs too.

そう、デザインにも直接使われているんだ。

Say we have a set of buttons, primary and secondary, each with a state, default, hover, and inactive.

プライマリとセカンダリのボタンがあり、それぞれにデフォルト、ホバー、非アクティブのステートがあるとします。

We could create a token for each one.

それぞれにトークンを作ればいい。

Button primary, for example, could reference surface brand contrast, since primary buttons should grab a user's attention.

例えば、プライマリーボタンは、表面のブランドコントラストを参照することができる。

The token for this could look something like button, primary, background, default.

このトークンは、button、primary、background、defaultのようになる。

The rest of the button's tokens would follow the same format, asset, type, property, state.

ボタンの残りのトークンは、アセット、タイプ、プロパティ、ステートという同じフォーマットに従う。

This level of tokens is detailed and more might not be necessary for everyone.

このレベルのトークンは詳細であり、誰にとっても必要なものではないかもしれない。

Design token structures should always begin with the foundation of primitive tokens.

デザイン・トークンの構造は、常にプリミティブ・トークンの基礎から始めるべきである。

Beyond that is entirely up to the unique needs of your system and organization.

それ以上は、システムや組織独自のニーズ次第だ。

You might only need semantic tokens or component-specific tokens added on.

セマンティックトークンやコンポーネント固有のトークンだけを追加する必要があるかもしれない。

You might need both in any order that you need.

必要な順番で両方必要かもしれない。

They could be on the same level.

同じレベルかもしれない。

You might even want to have multiple levels of each type.

それぞれのタイプで複数のレベルを用意することもできるだろう。

Whatever the format, take the time to thoughtfully plan what your token structure will look like.

どのような形式であれ、トークンの構成がどのようなものになるか、時間をかけて熟考してください。

This will save hassle in the long run, as any future restructures could require significant time and effort.

将来的なリストラには多大な時間と労力が必要となる可能性があるため、長期的には手間を省くことができる。

Now that we've gotten a better grasp on design tokens, let's check back in with the Habits team.

デザイン・トークンについて理解を深めたところで、Habitsチームに話を戻そう。

They decided to set up both semantic and component-specific tokens on the same level.

彼らは、セマンティック・トークンとコンポーネント固有トークンの両方を同じレベルに設定することにした。

Since their design system already lives in Figma, they can use two key Figma features to implement their tokens, styles and variables.

彼らのデザイン・システムはすでにFigmaの中に存在しているので、トークン、スタイル、変数を実装するために、Figmaの2つの主要な機能を使用することができます。

Before we continue, check out our resources on styles and variables to get an understanding of how they work.

次に進む前に、スタイルと変数に関するリソースをチェックして、それらがどのように機能するかを理解しよう。

You might be wondering, why should the Habits team use both styles and variables?

なぜ習慣チームはスタイルと変数の両方を使わなければならないのか？

Variables can support complex token structures because they can be used to define other variables and styles.

変数は、他の変数やスタイルを定義するために使うことができるので、複雑なトークン構造をサポートすることができる。

They can also support multiple modes for theming, scoping for specifically where a variable can be used, and code syntax for a better handoff experience.

また、テーマ設定のための複数のモード、変数が使用できる場所を特定するためのスコープ、より良いハンドオフ体験のためのコード構文もサポートできる。

Meanwhile, styles can support color gradients and composite values, like multiple fills or multiple shadow effects.

一方、スタイルは、複数の塗りつぶしや複数のシャドウ効果のように、カラーグラデーションや合成値をサポートすることができる。

For many, implementing design tokens means a combination of styles and variables.

多くの人にとって、デザイン・トークンの実装は、スタイルと変数の組み合わせを意味する。

To get more insight on the difference between styles and variables, check out the article linked below.

スタイルと変数の違いについてより詳しく知りたい方は、以下のリンク先の記事をご覧ください。

Kai is interested in diving into migrating colors first.

カイはまず、移動する色に飛び込むことに興味がある。

If you followed along in lesson 3, you'll know that the Habits app color system is connected to color styles, each organized by their purpose or usage.

レッスン3をお読みになった方なら、Habitsアプリのカラーシステムが、それぞれの目的や用途によって整理されたカラースタイルにつながっていることをご存知でしょう。

The Habits team decided to migrate all of their color styles to variables except for one gradient, which they'll keep as a style since variables can't capture gradients.

Habitsチームは、1つのグラデーションを除いて、すべてのカラースタイルを変数に移行することを決定した。

They create a new variables collection called Primitives for their primitive tokens and copy each color value over.

プリミティブトークンのためにPrimitivesという新しい変数コレクションを作成し、それぞれの色の値をコピーする。

Each color variable is organized by their base color.

各カラー変数は、ベースカラーごとに整理されている。

Within each base color, a ramp is created based on their tint and shade using a numbering system.

それぞれのベースカラーの中で、色合いと陰影に基づいて、番号システムを使ってランプが作られる。

The more white a base color contains, the lower its number.

ベースカラーに含まれる白の量が多いほど、その数値は低くなる。

The more black it contains, the higher the number.

黒が多いほど数字が高くなる。

Tip!

ヒント

To prevent primitive tokens from being used directly in designs, you can scope and hide them from getting published to team libraries.

プリミティブ トークンがデザインで直接使用されないようにするには、スコープを設定し、チーム ライブラリに公開されないようにします。

From the Primitives collection, select all the variables, right-click, and choose Edit Variables.

プリミティブ・コレクションから、すべての変数を選択して右クリックし、Edit Variables を選択します。

From the Edit modal, uncheck the Show in all supported properties box and check the Hide from publishing box.

Editモーダルから、Show in all supported propertiesボックスのチェックを外し、Hide from publishingボックスのチェックを入れる。

Next, they want to direct how and where the colors can be used, so they create a second variables collection called Tokens for their semantic and component-specific tokens.

次に、色をどこでどのように使うかを指示したいので、セマンティック・トークンとコンポーネント固有トークンのためにTokensという2つ目の変数コレクションを作成する。

The team conducted an audit to document every color used in the product and identified a few areas that use color.

チームは、製品に使用されているすべての色を文書化するための監査を実施し、色を使用している部分をいくつか特定した。

Surface, Button, Text, Border, and Icon.

サーフェス、ボタン、テキスト、ボーダー、アイコン。

Within each area, they further identified color categories like Brand, Toast, User Colors, and more.

各エリアでは、さらにブランド、トースト、ユーザーカラーなどのカラーカテゴリーを特定した。

From there, they established tokens within each category and gave them names that communicate how or where the color can be used.

そこから、それぞれのカテゴリーにトークンを設け、その色がどこでどのように使われるかを伝える名前をつけた。

For example, a semantic token might include the word Primary to communicate its use on the most common elements or actions on a page.

例えば、セマンティックトークンにはPrimaryという単語が含まれ、ページ上の最も一般的な要素やアクションでの使用を伝えることができる。

Secondary, on the other hand, are for less common elements.

一方、セカンダリーは、あまり一般的でない要素のためのものである。

After creating these tokens, they organize them into variable groups based on their categories and apply them to their designs.

これらのトークンを作成した後、カテゴリーに基づいて可変グループに整理し、デザインに適用する。

Now that our color primitives and semantic tokens are set up, how might they approach Dark Mode?

カラー・プリミティブとセマンティック・トークンがセットアップされたところで、ダークモードにどのようにアプローチするのだろうか？

Remember that every semantic and component-specific token is assigned a job and communicates a function.

すべてのセマンティックおよびコンポーネント固有のトークンにはジョブが割り当てられ、機能を伝達することを覚えておいてほしい。

To add a Dark Mode or any other theme, you need to create a separate set of tokens.

ダークモードやその他のテーマを追加するには、別のトークンを作成する必要があります。

Within this set, they can change any aliases or references as needed by connecting them to different tokens.

このセットの中で、異なるトークンに接続することで、必要に応じてエイリアスやリファレンスを変更することができる。

In Figma Design, the Habits team is able to account for a Dark Mode theme through variable modes.

Figmaデザインでは、Habitsチームは可変モードを通じて、ダークモードのテーマを考慮することができます。

They create a new mode in the tokens collection and update references to variables in the primitives collection as needed.

トークン・コレクションに新しいモードを作成し、必要に応じてプリミティブ・コレクションの変数への参照を更新する。

And that's it!

それで終わりだ！

No need to change the names of tokens since they already communicate information on how and where they're used.

トークンはすでに、どこでどのように使われているかという情報を伝えているので、トークンの名前を変える必要はない。

Changing a design to Dark Mode can be quickly done from the right-side bar.

ダークモードへの変更は、右サイドバーから素早く行えます。

The Habits team is all done setting up their color tokens, so they tackle their spatial system using number variables next.

ハビッツ・チームはカラートークンのセットアップを終えたので、次は数変数を使った空間システムに取り組む。

We cover creating number variables for spatial systems more in our Intro to Variables tutorial, so be sure to check it out.

空間システムのための数変数の作成については、変数入門のチュートリアルで詳しく説明していますので、ぜひご覧ください。

Tips for Naming Tokens If you're ready to set up tokens for your design system, here's a few tips to help you with naming.

トークンの命名に関するヒント デザイン・システムにトークンを設定する準備が整いましたら、命名に関するいくつかのヒントをご覧ください。

Make sure tokens are easy to understand.

トークンをわかりやすくする。

Creating language-neutral names makes them approachable across different teams.

言語にとらわれない名前をつけることで、異なるチーム間でも親しみやすくなる。

You may want to factor in people from different countries as well.

異なる国の人々も考慮に入れたほうがいいかもしれない。

Use full words instead of abbreviations.

略語の代わりに完全な単語を使う。

Abbreviations can be unclear and open to interpretation.

略語は不明瞭で解釈の余地がある。

Be consistent with prefixes.

接頭辞に一貫性を持たせる。

For example, token names for background colors should start with background instead of appearing in a different part of the name.

例えば、背景色のトークン名は、名前の別の部分に現れるのではなく、backgroundで始まるべきである。

Use single or plural names based on the context for which they're being used.

使用する文脈に応じて、単数形か複数形を使い分ける。

If you have multiple products or brands, avoid using the brand's name in a token.

複数の製品やブランドを持っている場合、トークンにブランド名を使うのは避けましょう。

Instead, choose a more generic name so that tokens can be used in broader contexts.

その代わりに、トークンがより広い文脈で使用できるように、より一般的な名前を選択します。

Future-proof tokens by anticipating potential growth of your design system.

デザイン・システムの潜在的な成長を予測することで、トークンを将来に備える。

Token names should be able to accommodate new additions and modifications without causing confusion.

トークン名は、混乱を招くことなく、新たな追加や変更に対応できるものでなければならない。

Now that the tokens are set up to go, Kai and the Habits team are looking forward to building Dark Mode for their users and experiencing the efficiency that this shared language provides.

トークンの準備が整った今、カイとHabitsチームはユーザーのためにダークモードを構築し、この共有言語がもたらす効率性を体験することを楽しみにしている。

Are you ready to dive even deeper into design tokens and variables?

デザイン・トークンと変数をさらに深く掘り下げる準備はできていますか？

Check out our resources below or let us know what you want to learn about next.

以下のリソースをご覧いただくか、次に何を学びたいかお知らせください。

And be sure to like and subscribe to keep up to date with the latest product and community news.

また、「いいね！」や「購読」をして、最新の製品やコミュニティに関するニュースをチェックしてください。

We'll see you in the next one.

また次回でお会いしましょう。