設計システムの視覚的な変化

コードAPIを尊重します。しかし、色、タイプ、スペースはどうですか?

シリーズのデザインシステムをリリースする6のうち4番目:
出力|ケイデンス|バージョン|壊す|依存関係|プロセス

設計システムは、基本的な依存関係である基本的な視覚スタイルを確立します。これらの選択肢(色、タイポグラフィ、スペースなど)は堅牢に指定されており、リリースごとに安定して、予想どおりに変更されると予想されます。採用者がアップグレードする場合、設計システムが予期せずに破損することはありません。

だから、自問してください…

採用者は、システムの視覚的な変更によってUIが破損しないことを確信して、マイナーリリースにアップグレードできますか?

セマンティックバージョニング(SemVer)は、メジャー、マイナー、パッチの指定を使用して、リリース間で変更を伝達する明確な基準を提供します。私が遭遇するすべての設計システムは、SemVerを使用し、パッケージのアプリケーションプログラミングインターフェイス(API)の変更を監視します。これは、JavaScriptプロップとHTMLマークアップをコーディングする開発者にとって馴染みのある領域です。 APIを壊すと、次のバージョンでは、1.4.0から2.0.0など、次のメジャーリリースにバージョンをインクリメントする必要があります。

構図の視覚的スタイルへのインターフェイスを指定することは私たちを避けます。スタイルの変更を監視するための明確でシンプルなルールを定義するのは非常に難しいと感じています。システムメーカーは、「このスタイルを変更すると、採用者のUIが壊れる」と「そのスタイルを変更すると、」という理由を明確にするのに苦労しています。そのような基準を文書化するシステムチームはほとんどありません。 「どのような種類の視覚的変化がメジャーバージョンをトリガーしますか?」と尋ねます。

この記事では、少なくとも色、タイポグラフィ、およびスペースが重大な変化を構成する基準を保証することを提案します。考慮すべき他のプロパティもあります。設計システムは、これらの基準を定義、文書化、伝達できるため、採用者は自信を持ってリリースごとにアップグレードできます。

速報色

ほとんどのシステムチームは、プライマリボタンの背景色を調整しても安全だと感じています。たぶん彼らの動機は、通常白いテキストラベルに対するコントラストを改善することです。 「ティールを少し暗くしましょう」と彼らは言います。 「AAからAAAへのボタンのアクセス可能な色のコントラストを改善します。」

主ボタンの背景色を調整する

確かに、採用チームは標準のプライマリボタンの色セットをオーバーライドしないでください。システムの選択をオーバーライドすると、システムとの接続が切断されます。その時点で、採用者は自分自身です。したがって、プライマリボタンの背景色の濃淡を調整することは安全であり、重大な変更ではありません。

ただし、他の場所で色を変更すると、採用者が危険にさらされる可能性があります。以下のシナリオを検討してください。

例:カスタム背景のシステムテキスト

システムチームがインタラクティブな青を微調整して色のコントラストを改善することを想像してください。 v1.4.0のインタラクティブブルーは、白い背景ではアクセスできましたが、木炭の背景では失敗しました。

contrast-grid.eightshapes.comを使用したカラーコントラストチェック

そのため、v1.5.0では、チームはインタラクティブブルーを、白と木炭の両方で機能する、より明るく飽和したトーンに調整しました。

予測できない背景上のゴーストボタンラベルのテキストの色を調整する

ただし、採用者は、明るい灰色の背景でその色に依存するゴーストボタンを使用していました。システムの変更後、ラベルのテキストの色のコントラストにアクセスできなくなります。システムが製品を破壊しました。

例:カスタムオーバーレイテキストを使用したシステムの背景

同様に、システムがカードコンポーネントの背景色を暗くするとします。カードのコンテンツ領域には、「安全な」コンテンツコンテナゾーンが含まれており、採用者は必要なコンテンツやマークアップを挿入できます。

含まれるカスタムコンテンツを許可するカードの背景色を調整する

そのおそらく安全なゾーンでは、採用者がセカンダリテキストを追加しましたが、これは微妙な中程度のグレーでありながら、カラーコントラストテストに合格しました。システムの変更後、色のコントラストにアクセスできなくなります。システムが製品を破壊しました。

システムのマイナーリリースにこれらの調整が含まれていたとします。下位互換性がありますか?アップグレードのリスクはありません、彼らは信頼していますか?いや!システムが製品を破壊しました!

したがって、変更された色のプロパティを評価して、次のようなシステムが変更されたかどうかを判断します。

  • 採用者の背景色、画像、またはその他のテクスチャの上に表示されるテキストの色。
  • 採用者のテキストの色がオーバーレイされる背景色。
  • 背景色、境界線の色、テキストの色、ボックスの影、または要素間のコントラストを弱めるために別のコンポーネントのエッジまたはコンテンツの横、上、または下に構成されるその他のプロパティ。

これらの例は、アクセシビリティによって促進されました。美的なリスクもあります。意図的なシステム変更は、製品設計者が達成するカラフルな調和を混乱させる可能性があるためです。色の相互作用は、システム設計者が制御したり、可視性を持たないUI全体にたくさんあります。

テイクアウト:色の基準で変更の会話を中断し始めます。リスクを伝えやすく、客観的に測定可能であり、情熱を掻き立てるアクセシビリティに結びついています。いくつかの基準を用意して、他の懸念事項に進むことができます。

タイピングを破る(ラッピングによる)

タイポグラフィは、あらゆる視覚スタイルの中核的な側面です。チームはそれを適切に取得したいと考えています。また、調整するダイヤルは非常に多くあります。フォントファミリ、フォントウェイト、フォントサイズ、テキスト変換、行の高さ、文字間隔などです。

システムがタイポグラフィを調整する場合、すべてが破損するリスクはありません。コンテンツが豊富なエクスペリエンスの場合、各要素のコンテンツは予測不可能で、長さが異なり、ビューポートの幅の変化をラップして対応するように設計されています。

密度の高いインターフェイスの場合、タイポグラフィは正確でなければなりません。デザイナーは、タイポグラフィの微調整を何時間も行い、コンパクトな領域に収まるようにラベルを配置します。システムタイポグラフィを調整すると、それらの要素が予期しない方法でラップまたはトリミングされる場合があります。

例:折り返しタブがひどい

システムがタブlabelfont-weightを通常から太字に調整することを想像してください。

マイナーバージョンのアップグレード後、応答しないタブがラップします。良くない。

アダプターのアップグレード。既存の応答しないタブは、割り当てられたスペースを超えているため、折り返します。恐ろしい!システムが製品を破壊しました。

例:文字間隔の混乱

ブランドガイドラインが進化し、新しい見出し階層とスタイルが生まれました。したがって、システムは各見出しの文字間隔を増やすことで適応します。

採用者は、それぞれがフォーム要素と見出しでいっぱいになっている無数のコントロールパネルで構成される14言語に翻訳された高密度の単一ページラジオロジーアプリをアップグレードします。それらはアップグレードされ、UIは予想外に切り取られた見出しであふれています。彼らは危機会議を呼び出します。彼らは、バックエンドのデータエンジニアを招きます。システムが製品を破壊しました!

システムのタイポグラフィを調整することは危険です。あなたにとって、それは図書館全体に楽々と展開される活版印刷の進化です。彼らにとって、テキストは誤動作し始めます。彼らはあなたを責めます。たぶん、彼らは#system-design Slackチャンネルであなたを炎上させます。誰もそれを必要としません。

まとめ:1.0.0より前は、顧客の多様性に適した活字スタイルを実験、改良、および仕上げるために熱心に取り組んでください。 1.0.0が経過したら、安定したベースを維持し、慎重に変更を検討します。次のメジャーリリースのために危険なシフトを予約することを検討してください。それまでは、記事のコピーだけをスタイリングするためのロングフォームテキストコンポーネントなど、含まれる機能を段階的に追加します。

分割スペースとサイズ

少なくとも、色と活版印刷を見ることができます。スペースとサイズ?それらを具体的に再利用可能であると定義することは難しく、破壊的な変化を監視することは言うまでもありません。

HTMLでは、コンポーネントのボックスモデルプロパティ(パディング、マージン、幅、高さ、表示、ボックスサイズ、位置、左、右、上、下)を変更すると、そのコンポーネントを他のページ要素に配置するレイアウト構成に影響を与える可能性があります。

例1:垂直間隔の削除

システムチームは、マージン間隔の形でフォームコントロールを適用した垂直間隔を削除することにしました。これは、