デザイナーがノーと言える方法を教える記事は数多く あります。これは主にフリーランサーと、難しいクライアントとやり取りする方法についてです。プロダクト マネージャーとのやり取りのヒントを掲載した記事もあります。しかし、デザイン システムをサポートしている場合はどうでしょうか。他のデザイナーや開発者からの相反する要求をどうするか。

まだ何をしているのかわかりません…

あなたが専門家ではなく、自社のデザイン システムをゼロから作成し始めたばかりの場合、どの方向に進むべきかわからないかもしれません。もちろん、「開始方法」に関するレシピ付きの記事をいくつか読むことができますが、個人的な経験に勝るものはない場合があります。何かに挑戦し、時には間違いを犯し、間違いから学ぶこと。新しいものに対してオープンであること。「はい、やってみよう」の人になりましょう。

このような状況では、可能な限り柔軟に対応する必要があります。ただし、成功した決定を「黒魔術」のままにし、失敗した決定を未知の偶然として残しておきたくない場合は、決定を文書化してください。

単に決定そのものを書き留めるという意味ではなく、あなた (または他の人) がどのようにそこにたどり着いたかを書き留めます。引数など はい、これは難しい場合があります。特に決定が直感的 (直感) であった場合。しかし、自分自身や他の人に質問することを学べば、最終的にはアイデアの源を理解し始めることができます.

このような文書化により、因果関係をさらに理解し、何が機能し、何が機能しないかを知ることができます。次回、新しい提案が既知のパターンに適合する (または同じ方向に進む) ことがわかった場合は、これを他の人に指摘することができます。つまり、危険な解決策に対して合理的な理由を与えることを学びます。

これどこかで見たことある…

悪い決定については、いつでもコミュニティに例を求めることができます。デザイナー (および他の多くの職業)は、すべきでないことのリストを作成するのが好きです。

「 10の最悪の設計上の決定」などのカテゴリの記事の大きな断面があります。ただし、デザイン システムに関しては、「良い/悪い」プラクティス、「パターン」、「すべきこととすべきでないこと」などの説明が最も重要です。オープンなデザイン システムのドキュメントでそれらを探すのが最善です。

多くの場合、そのようなドキュメントは、特定のソリューションに対する賛成または反対の簡潔な議論を提供し、システムで発生する状況を分析するのに大いに役立ちます。日常のデザイン作業にも。

「すべきこととすべきでないこと」は、システム設計文書の重要な要素であり、システムの「良い/悪い」プラクティスの文書化を早く開始すればするほど、より多くの質問や誤解を避けることができます。

「文書化されていなければ存在しない」

ドキュメントはコミットメントです。また、「できること/すべきこと」に関するガイダンスも提供します。結局、設計者は、設計システム内で何をすべきで何をすべきでないかを認識していないため、疑わしい決定を下すことがよくあります。それがなければ、「何でも可能だ」という言葉は合理的な考えです。

しかし、ここで強調しておくことが重要です。文書化は禁止に関するものではありません。ドキュメンテーションは、システムがどのように機能するかを説明し、実行する価値のあることとそうでないことを合理的に示すように設計されています。したがって、デザイナー (または開発者) が「私はこれが好きだ」ということだけに駆り立てられ、それがドキュメントと矛盾する場合、ドキュメントを参照して拒否する合理的かつ正当な理由があります。

ドキュメントは、他の人が自分の考えを主張するための良い例を示すのに役立ちます。そして、アイデアをソリューションに変えて、デザイン システムを次のレベルに引き上げます。

デザインライブラリ≠デザインシステム

多くの場合、ユーザー (または貢献者) がデザイン システムとは何かを理解せず、それをデザイン ライブラリと見なすと、問題が発生します。多くの設計者は、既製の設計ライブラリを扱い、ニーズに合わせて変更しなければならないことに慣れています。

「このUI-Kitは気に入っていますが、自分のユースケースを考慮せずに作成されたので、カスタマイズする必要があります。」かなり合理的に聞こえますよね？はい、あなた（または他の誰か）がほんの一部しか使用しないサードパーティのソリューションについて話している場合. しかし、社内の設計システムの場合、これは混乱につながる可能性があります。

これと似てるけどちょっと違う…。

私の意見では、最も難しいのは、ユーザーが小さな変更を要求したときです。非常に小さな変更:

• ヘッダーにアイコンを使用する機能を追加します。
• リスト内のブロックの順序を変更します。
• 2 つではなく 3 つのボタンを表示します (コンポーネントによって定義されます)。

• 他のコンポーネントとのアプローチの一貫性。
• コードおよび設計コンポーネント (Figma、Sketch など) での実装の複雑さ。

まず、パターンが他のコンポーネントと交差しているかどうかを確認する必要があります。これを行うには、すべてのコンポーネントとその動作を暗記するか、それぞれを調べて、提案が他のコンポーネントと競合するかどうかを確認する必要があります。わずかな矛盾がある場合は、提案を個別にではなく、いくつかのコンポーネントの動作のコンテキストで議論する必要があります。これには、多くの人を議論に招待することが必要になる場合があります。

実装の複雑さ

多くの場合、設計上は単純なソリューションのように見えても、開発には多大な労力が必要になることがあります。おそらく、現在のアーキテクチャには十分な柔軟性がないためです。おそらく、開発で使用される基本的な標準/アプローチに反するだけです。理論的には、ほとんど何でも可能ですが、より多くの労力が必要になるものもあります。このような状況では、これらの変更がどれほど重要かを理解する必要があるかもしれません: 「あると便利」または「重要なニーズ」です。

私たちは独裁者ではなく召使いです

デザインシステムは製品です。しかし、それは非常に具体的なものです。大多数の製品の成功は、どれだけの収益を上げるかによって測定できますが、デザイン システムの場合、主な指標は、それを使用するユーザーの数と、それによってユーザーの生活がどれだけ楽になるかです。つまり、デザインシステムは「最も正直な製品」です。そして、それには多くの責任が伴います。お客様が望むものを最大限に活用するだけでなく、疑わしい決定の結果をお客様が理解できるように支援する必要があります。

• 見込み客の柔軟性の欠如
• ソリューション開発の遅延 (ソリューションとそのメンテナンスの複雑さによる)
• 他のコンポーネントまたは契約に変更をカスケードする必要性
スチュワーディング デザイン システムへの貢献

最終的に、デザイン システムはユーザー (デザイナーと開発者) に関するものです。そのため、それらに非常に注意を払う必要があります。結局のところ、それらがなければ、私たちは何者でもありません。そして、編集が合理的で、何も壊さないのであれば、なぜそれらを作成しないのですか?

「いいえ」と言う理由はすべて、ユーザーが望む製品ではなく、ユーザーが必要とする製品を確実に作成するためです。

フォード モデル T の開発における顧客の意見について尋ねられたとき、ヘンリー フォードは有名な言葉を残しました。

読んでくれてありがとう！連絡を取り合いましょう！LinkedInで私とつながり、 DribbbleとここMediumで私をフォローして、より多くのデザイン関連のコンテンツを入手してください。