TL;DR まとめ

• 多くの (ほとんどの?) デジタル製品チームには、設計中心のリーダーシップや、製品の大幅な再設計 (または新しい設計システムの包括的適用) に必要なリソースがありません。
• しかし、これらの組織に共通する設計者の落とし穴は、システムの大きな変化を表す「理想的」で野心的なパターンを設計することです。既存の製品。
• 私が好むアプローチは、「革命」ではなく「進化」です。既存の製品のルーツからシステムを成長させることにより (革新的な変更を強制するのではなく)、一貫性があり、予測可能で、ユーザー フレンドリーなユーザー エクスペリエンスをはるかに迅速に実現できます。 .

企業は、設計変更を容易にするためのリソースが限られています

AirbnbやAppleなどの組織は、製品に対するデザイン ファーストのアプローチが美しい体験につながり、時には商業的な成功にさえつながることを示しています。また、 MailChimpや Google ( Material Designの立ち上げ) などの企業は、コースを修正して包括的なポジティブなデザイン変更を行うという立派な仕事をしています。

多くの場合、デザイン チームがデザインシステムについて話すとき、それらは彼らが念頭に置いている会社です。非常にエキサイティングなことですが、限られた需要の高いエンジニアリング リソースを持ち、すでに多くのバックログを抱えているチームにとって、それは難しい注文です。彼らはうまく設計された製品を手に入れたいと思っていますが、最初に [X, Y ,および Z プロジェクト]… これらはすべて、おそらく設計変更よりも明確な「ROI」ストーリーを持っています。

おなじみですか？特に、私が働きたい初期段階から中期段階の組織ではそうです。

つまり、あなたはエンジニアリングの「予算」が限られている設計者です。製品の素晴らしいアイデアに加えて、実装したい新しいパターン、動作、および美学があります。しかし、一歩下がって今日の製品全体を見てみると、次のように感じます。

これで、大規模でコアなユーザー エクスペリエンスが得られました。これは、兄弟ページ、フロー、およびその他の製品ブランチと時間の経過とともに隣接してきました。これらは、さまざまなデザインの方向性を持つさまざまな製品関係者によって、数か月または数年にわたって構築されました。これらの機能の一部は、おそらく MVP ソリューションとして構築されたものです。後で「デザイン」を追加します」—それ以来、触れられていません. これらはすべて、ユーザーとビジネスにとって最善の意図で構築されましたが、設計システムとして、ネズミの巣の経験を扱っている可能性があります。

では、プロダクト デザイナーであるあなたは、どのようにこれを形にするのでしょうか?

革命: 一気に設計の極致に到達

革命万歳！Apple Thunderbolt ディスプレイの前で Sketch に座っていると、これは簡単に感情的な罠に陥ります。」。しかし、これを実際にどのように実装する予定ですか? おそらく次のようなものです：

よくできました: 完璧な設計システムが完成しました! デザインシステムを適用するためのこのアプローチを分解してみましょう。

長所

• あなたの製品は、私たちの夢のデザインになりました! それは魔法です！
• 部屋に同じデザイナーがいて、すべてを一度にデザインしたので、すべてが非常にまとまりがあり、思慮深いものになっています。気持ちいい！

• これは… この方法で実際にうまくいくことはほとんどありません。
• 長期間にわたって大量のリソースを投入する必要がありました。
• これは（十分に研究されているかどうかにかかわらず）孤立して設計されているため、実際のユーザーが使用を開始すると必然的に発見されるいくつかの実際の課題は考慮されていません.
• 最後に (おそらくほとんどの場合)、ユーザー/顧客は、製品の古い安っぽいバージョンを数か月または数年間使用しなければならず、この新しいものをリリースするたびに、製品設計の突然の大規模な変更に直面するだけです。

「北極星」モデル: プロダクト デザインの涅槃を達成する

あなたのチームは理想的な製品体験をデザインしていますが、一方的なデザイン革命に必要なリソースがないことがわかりました。ファンシー！しかし、これらの優れたパターン、動作、およびルールを設計したので、とにかく製品ページと機能に取り組むときに、それらを日和見的に適用し始めましょう. ここには何もありません：

よし、ここでいくつかの動きがあり、このプロセスの終わりまでに、製品で本当に素晴らしい経験を得ることができます (まだ荷物を持っているとしても)。

長所

• たとえそれがほんの一部であっても、あなたのデザインの夢があなたの製品で実現するのを見てください.
• 完全なデザイン レボリューションよりもはるかに現実的です。
• 遠い将来 (そして、この数年間同じデザインの好みを維持できた場合)、製品の残りの部分が完成するのを見るかもしれません. 多分。

• より劇的な変更では、変更ごとにより多くのリソースが必要になるため (エッジ ケースや技術的な制限などを開くため)、変更の速度は、古いパターンや保守的に変更されたパターンを使用した場合よりも遅くなります。
• 最終的に素晴らしいデザインがいくつかできましたが、このプロジェクトの移行フェーズを見てください。ユーザーや顧客がこれらの非常にまだら模様の製品を使用している期間は数か月または数年であり、画面ごとにエクスペリエンスとスタイルが劇的に変化する可能性があります。あなたの作品が数年後に最終的に実を結ぶように本当に設計していますか？そうは思いませんでした。
• 製品の大部分がこの新しいシステムに移行するまでに、あなた (およびその他のデザイン コミュニティ) は、優れた、一般的な、またはトレンディな UI デザインと見なされるものに関して、おそらくシフトしているでしょう。これらすべてが機能し、まだ数年前の設計 (そうです、「新しい設計」) に固執しています。

スタイルと動作の点で、これらは非常に異なるため、UX の一部を少しずつ移行すると、製品全体で表示されるフォームと入力が劇的に異なることになります。これは、断片的な方法で劇的な設計変更を行う際の大きな問題を表す小さな例です。

でも、希望はあります！持っているものの上に構築するシステムを設計することで、困難でずさんな設計変更を避けることができます。製品を現在の状態から「進化」させるべきだと言う人さえいるかもしれません…

それは進化だ、ベイビー：あなたが持っているものを評価することによって、より良い製品をより速く手に入れる

エンジニアリング予算が限られている設計チームの場合、製品がすでに行っていることを最大限に活用し、その上に構築することで、設計システムを構築 (または強化) することをお勧めします。あなたが小規模なスタートアップ チームの最初のデザイナーであっても、誰か(デザイナー、プロダクト リーダー、開発者のいずれであっても)は、本当の理由でこれらの UI の決定を行うことを選択しました。手順は製品の現在の状態によって異なりますが、プロセスは次のように始まります。

1. 現在の設計システムについて学びます (もしあれば) : コンポーネントはどこから来たのですか? 組織のどこかにコア スタイル シートまたはライブラリはありますか? これらはどのように編成されていますか？誰が建てたの？誰が最もよく使用し、どの部分を使用していますか? それなしでオフロードに行かなければならないのはいつですか？
2. 製品に見られるパターンと動作​​の一覧を作成します。さまざまな種類の情報をユーザーにどのように提示しますか? ユーザーは見たいものをどのように選択しますか? 彼らはどのように情報を入力しますか？インターフェイス要素: タブ、カード、リスト、またはフォームが表示されますか? それぞれの要素はどのような状況で登場しますか?
3. あなたの製品が従うと思われるルールを書き留めてください。次に、自分自身でルールを強化します。すべての設計負債の背後には、製品がどのように組み立てられたかについての論理があります。あなたの製品が従うように見えるデザインルールを理解してから、それらを倍増させてください. 「私たちは多くのことにテーブルを使用しているようです。たとえば、ユーザーが何を操作するかを選択する必要がある場合などです。」おそらくルールに変わります。
4. チームからコンセンサスを得る:評価と計画を伝えます。コンセンサスの構築は言うは易く行うは難しですが、既存の製品からこのシステムを構築した方が、まったく新しいパターンやルールを作成する場合よりも、この会話と移行が容易になります。確かに、これらの利害関係者の多くは、今日の製品の外観に貢献していたので、このパスは彼らの役割をより尊重し、すべての組織の知識が既存の設計に組み込まれています.
5. このシステムで構築を始めましょう: 従うべきルールと使用するパターンがわかったので、それらのパターンを特定して、ルールに従い始めましょう! 次回、エンジニアがテーブル、カード、フォームなどを配置するときは、それが仕様化された要素であり、正しい方法で使用されていることを確認してください。やがて、この新しいデザイン システムを使用するインターフェイスが増えることになりますが、インターフェイスの古い部分と比較的うまく調和するはずです。

長所

• とても緑。新しいシステムを既存のパターンから大まかにベースにすることで、より早く「良い」状態に到達できます。
• 「良い経験」は「古い経験」と比較的うまく混ざり合い、よりシームレスな経験を生み出します。そうです、厳しい過渡期の月や年の間でも。
• 劇的な変化が少ないということは、新しいコンポーネントとパターンをより速く適用できることを意味します。次に、それらがすべてシステムに接続されたら、システム レベルでそれらを変更および更新できます。これにより、ジョーンズの隣のドア (つまり、競合他社) が後で必然的に取得した後についていくことができる可能性が高くなります。独自の新しい UI。
• あまり劇的な変化はユーザーの観点からも良い場合があります: ユーザーはやや有名な変化を嫌います (これまでのすべての Facebook の再設計、またはお気に入りの B2B ツールの大規模な再設計を参照してください)。ユーザー/顧客。
• これはリソース集約型ではなく、有機的な組織にとってより自然です。「革命」や大規模な幹部のイニシアチブとは対照的に、これはチームの善意をよりよく維持することができます。本当に難しい仕事がたくさんあるように感じるだけでなく、良いデザインをすることが正しいと感じさせてくれます。

• なし！
• 冗談だ。おわかりのように、このモデルでは設計の「理想的な」段階には到達していません。より保守的な「進化」モデルは、優れた設計をより迅速かつ簡単に行うことができましたが、そうでなければ可能だった「大きなアイデア」の機会を受け入れなかったのかもしれません。
• 小規模に作業し、「壮大なビジョン」を計画しないと、設計システムの進化の後の依存関係や機会を逃す可能性があります。これを軽減する方法はいくつかあります。たとえば、「一歩一歩を踏み出す」以外のビジョンを持つことです。これについては、後で詳しく説明します。
• 場合によっては、製品の「古い」製品設計が本当に悪いものであり、良い出発点でさえない場合があります. (これはたどりたくなる精神的な道ですが、そうしないことをお勧めします。ほとんどの場合、ある程度成功した製品に取り組んでいる場合でも、好むと好まざるとにかかわらず、古い設計の何かがうまく機能しています。 ）。

あなたの仕事は、顧客やユーザーが製品を使って体験することを改善することです。すべての小さな設計で月を狙い撃ちし、それらの変更を実現するために大量のエンジニアリング リソースを燃やした場合、それらのリソースを不十分に「消費」し、ユーザーのために他のものを改善するために実行できる作業の量を制限する可能性があります。 . 3 つのユーザー フローを適切に作成するよりも、1 つの ユーザー フローを完全にする方がよいでしょうか? あなたのためかもしれませんが、ユーザーのためではないかもしれません。

設計システムをより現実的にする (既存の基盤から構築し、移行しやすい状態に保つ) ことで、新しいシステムをより迅速に採用し、あなた (およびあなたのユーザー) が利益を享受し始めることができます。

さあ、進化しよう！

アップデート（約1年後）

Hired で取り組んでいたこのデザイン システムについては、別の記事を書きました。これは、1 年前にこの「進化」の記事に影響を与えたのと同じプロジェクトです。

デザイン システムの構築から得られる成功、損失、および教訓

そのプロジェクトから得たいくつかの教訓を踏まえて、「北極星のような」アプローチに対する私の立場を少し和らげましたが、この記事の核となるテナントは依然として変わりません。ほとんどの場合、進化は依然としてユーザーや製品に対する責任あるアプローチです。 、およびあなたの組織。