翻訳記事：デザインシステムのジレンマ：見た目は似ているが、機能が違う
読むときについでに訳してしまおう活動。今回は、UX Collectiveに投稿されたこの記事。デザインシステムを作るときのジレンマです。
コンポーネントは、見た目が似ていても機能が違う場合があり、デザイナーや開発者はあえて使い分けて作っている場合があります。しかし、デザインシステムの健全性を機能させるには、しっかりとそれらを明文化する努力（投資とも言う）が必要で、プロダクトがスケールすればするほど管理がおざなりになり、亜種なのかそうではなく意図があるのか曖昧になりシステムが破断する危険性があります。アセットを作るだけなく、文書化と布教（教育）活動を怠らないようにしましょう。
ということで以下翻訳（著者許諾済み）
Deanさんは今日本語勉強中だそうです😁
デザインシステムのジレンマ：見た目は似ているが、機能が違う
なぜ異なる要素がユーザー体験にとって重要なのか
By Dean Harrison
October 2, 20024. Published in UX Collective
デザインを確認しているときに、誰かが「間違ったコンポーネントを使ってるよ」と口を挟んでくるこがありませんか？「バッチを使うべきなのにピルを使ってる」と指摘され、実際にその二つのコンポーネントを見比べると、ほとんど一緒に見えることがあります。
私は職場でまさに「その人」です。
楽しい仕事ではありませんが、必要な仕事です。デザインシステムに取り組み、エンジニアと密接に連携してそれを実装してきた経験から、よく聞く不満の一つは、コンポーネントが正しく利用されていないということです。デザイナーやエンジニアが、コンポーネントで可能なことの制約を押し広げたり、既に別のコンポーネントでできることをしようとして新しいバリエーションを追加したりすることがよくあります。これが、健全なシステムを維持することを難しくします。
これを解決する方法の一つは、開発前にデザインとエンジニアがレビューするプロセスを設けることです。また、デザインファイルに明確な注釈を付け、使用されているコンポーネントにリンクすることで曖昧さを排除することも重要です。しかし、それでもなお、デザインシステムに関する適切なドキュメンテーション（文書化）と教育の重要性を見過ごすことはできません。
Nathan Curtisは数年前にこの重要性について書いており、その指摘は今でも私の心に響いています。彼が言うように、「適切な文書化は無料ではない。それは計画、努力、プロセスを要し、凡例やガイドラインを作成し、それが違いを生む。」
ということは、文書化が答えなのか？
文書化の問題の一つは、私たちは問題がある時だけそれを見ることが多く、その時でさえ（探している）答えよりも質問が増えることがあることです。
前に出たバッジとピルの例を続けよう。文書化にはこんなことが書いてあるかもしれない：
バッジは、PDFやWord、docxなどのファイルタイプのように、ユーザーが興味を持つかもしれないメタデータの一部を強調表示する。
ピルは、ユーザーが変更や削除を希望するかもしれない選択を示すために使われる。例えば、何かを共有したい相手のメールアドレスを追加する時など。
なるほど、素晴らしい。しかしそれぞれの使い方はよりよく理解できたが、ここで「見た目が同じなのに、なぜそのように違う働きをするコンポーネントを分けるのか？」という疑問が出てくる。もっともな質問です。
見た目がほとんど同じコンポーネントが二つあるなら、なぜそれらを一つのインスタンスにまとめずに分けるのか？これらは簡単に一つのコンポーネントにまとめれないのか？
まあ、一般的に、これはデザイナーや開発者がメンテナンスしやすくするためにしています。つまり利用可能なオプションを増やしすぎて使いにくくするのを避けたいためです。例として、以下のコンポーネントごとに必要なオプションを見てみます。
+-----------+-------------------------+--------------------------+----------------------+------------+--------------------------------------+
| Component | Interaction | Feedback | States | Theme | Modifiers |
+-----------+-------------------------+--------------------------+----------------------+------------+--------------------------------------+
| Badge | default | N/A | N/A | light/dark | Label, no Label, Icon Right, No icon |
| Pill | default, hover, focused | disabled, error, warning | selected, deselected | light/dark | Label, Close button, Radio button |
+-----------+-------------------------+--------------------------+----------------------+------------+--------------------------------------+これらは小さな違いのように思えるかもしれませんが、新しいインスタンスをFigmaに追加するたびにこれらのオプションを全部切り替えると想像してみてください。さらに、この使い方に関するすべてのケースや、やってはいけないことをカバーするために、どれだけのドキュメントが必要になるか考えてみてください。おそらく途中で投げ出してしまうでしょう。
このアプローチの一つの利点は、ピルのデザインをバッジに影響を与えずにより目立たせたい場合、これらが結合されてなければ簡単に変更することができる点です。これにより、システムのスケーリングがはるかに容易になります。
私たちがコンポーネントをこのように分けるもう一つの利点は、UIに階層を導入できることです。要素をスタイリングしてユーザーの注意を引き、製品を通じてユーザーを案内し、求めているものを見つけやすくすることができます。
それを踏まえ、意図がどのように変わるかを見てきた中で最も多く使われて交換されている3つのコンポーネントを見ていきたいと思います。
バッジとピル/チップス
まずは、これまで使ってきた例をまとめましょう。まず、<Badge/> は静的なヘルプ的に詳細や属性を示すために使用します。日付からファイルタイプまで何でもありえますが、一般的にはあまり重要でないもので、インタラクティブ性ないものです。
一方、<Pills/> はユーザーが操作できるスニペットを示します。例としては、データの表示方法を変更したり、不要なフィルターを削除することができます。これらはインタラクティブなステートが必要で、<Chips/>、<Tags/> など必要に応じて、あるいは環境に応じて意味が通じやすい他の名前で呼ばれることもあります。
ボタンとアクションボタン
<Button/> ほど頻繁に使われるコンポーネントは他にあまりないでしょう。これはユーザーにアクションを実行させたりページを遷移させたりします。ページ上で重要なインタラクションポイントに注目を集め、多様なスタイルで階層を形成します。
一方で、<ActionButton/> は目立たないインターフェース要素に最適で、ユーザーにワークフロー内でタスクを実行したり選択をさせたりします。例としては、テーブルの編集アクションなどが考えられます。
セレクトとドロップダウン
<Select/> と <Dropdown/> を使い分けるとき、最初は少し混乱するかもしれません。これら2つの主な違いは、ユーザーを別の場所に遷移するのを手伝うか、それとも選択するのかにあります。
ユーザーに単一のオプションを選んでもらう場合は <Select/> コンポーネントを使用すべきです。例としては、テーブルの並べ替え操作が挙げられます。一方で、複数のアイテムを選択できる場合には <Dropdown/> が最適です。例えば、リストから名前を選ぶ場合です。他の形式としては <Combobox/>があり、<Dropdown/> 内をすばやく検索するためにキー入力することができます。
ほんの触り程度。
ここでの話はかなりハイレベルで、いくつかのコンポーネントしか取り上げていませんが、構築中にどのコンポーネントで一番苦労したか、あるいはどうやって管理したかをぜひ聞きいてみたくなります。
私の経験では、この問題はスタートアップがスケールし始めるときに、よくつまずくポイントになることが多いです。というのも、しっかりと明文化したものがほとんどないことが多く、この作業に時間を投資する余裕がないことが多いからです。ただし、チームの規模が小さい場合は、明確な承認とハンドオフのプロセスで補うことも可能です。
それでも、どのコンポーネントを使うべきか迷ったり、わからなくなったりしたときは、The Component Galleryを使うことをお勧めします。特定のコンポーネントで何をすべきかを理解する際に非常に役立ちます。このサイトはSpectrum、Carbon、Base、Backpackなど、さまざまなデザインシステムを参照できる例や直接リンクを提供しており、コンポーネントの分け方やその使い方を確認できます。
翻訳以上。
この記事が気に入ったらサポートをしてみませんか？