marketing-vs-product-system

マーケティングとプロダクトは、1つのブランドを構成する2つの表面です

公開サイトは売り、プロダクトは使われます。訪問者はマーケティングページを1つ、90秒間読み、離れていきます。運用担当者は毎朝、同じブランドを開き、何時間も使います。両方を同じ仕様で設計すると、作業するには疲れるパンフレットか、何も売れないプロダクト画面のどちらかになってしまいます。

そのため、2つの表面は異なるべきです。問うべきなのは、異なるべきかどうかではなく、どのレイヤーで異なることを許容するかです。

マーケティングとプロダクトの組み合わせがこの問いを突きつけるのは、誰も同じ仕事だと装えない2つだからです。しかし、その根底にあるルールは2つに限った話ではありません。ほとんどのブランドには、サイト、プロダクト、ドキュメント、取引関連メール、ステータスページ、場合によっては営業資料など、4つか5つの表面があります。それぞれ、異なる読者が異なるタイミングで使う、別々の役割を担います。**ブランドがレイヤーを所有し、各表面はそこから選びます。**6つ目の表面を加えてもルールが変わらないこと、それがルールが正しいかどうかを判断する基準です。

新しい表面がどこに属するかは、どのチームが作ったかではなく、レイヤーのルールが問うのと同じ問いで決まります。ドキュメントは作業中の人が一度に数分間読むため、密度はプロダクトに近く、読み幅はサイトに近くなります。取引関連メールにはテーマの制御もホバーもないため、共有の値を使い、それ以外はほとんど使いません。どちらも特別扱いではなく、一般的なルールを適用したものです。

レイヤーのルール

ブランドの値は共有します。アプリケーションの値は表面ごとに選びます。

共有する値（両方で1つの値）	表面ごとに選ぶ値
色相：ブランドアクセント、暖色アクセント、ステータスカラー	画面でどの色を主役にするか
フォントファミリー	使用する文字のスケール
角丸のスケール（使用可能な段階のセット）	表面ごとにどの段階を使うか
アイコンライブラリ	アイコンのサイズと太さ
テキストのコントラストの最低基準（本文は4.5:1、大きな文字は3:1）	密度、間隔のリズム
コンポーネントの契約（ボタンとは何か）	ボタンのデフォルトサイズ

値が自分たちは何者かに答えるなら、共有します。この画面は何のためのものかに答えるなら、その表面独自の判断に委ねます。プロダクト画面でより小さな角丸を選ぶのは、デザインです。プロダクト画面で別の青を選ぶのは、逸脱です。

正当に異なってよい点

こうした違いは健全なものであり、偶然に生じるままにせず、明確に述べる価値があります。

• 文字サイズの段階。 マーケティングではディスプレイ用のサイズを使い、実際に大きなヒーローサイズも用意します。プロダクトではそこから二、三段階下を使い、インターフェースの大半はスケールの小さい側が担います。スケールは同じ段階で構成されますが、二つの画面は異なる段に立っています。
• ウェイト。 マーケティングでは、見出しが注目を集める必要があるため、太字を多用します。プロダクトでは、画面にあるものはすでにすべて必要とされているため、ミディアムやセミボールドを多用します。
• 角丸。 マーケティングでは要素が少なく、余白もたっぷりあるため、より大きく柔らかなカードを使えます。プロダクトではより小さめにします。高密度の画面で大きな角丸を使うと、隣接する要素の角が削られ、ぼやけた印象になるためです。二つの画面で五段階、あるいは六段階を使うこともあるでしょう。それぞれの段階が同じ段階表から取られている限り、スケールが崩れているわけではありません。崩れるのは、どの段階表にも存在しない値を使ったときです。
• 密度と幅。 マーケティングでは、目が文章の一行を追える範囲が上限となるため、読み物のカラム幅を基準にします。プロダクトでは、データが上限を決め、画面が広くなってもデータの幅は狭くならないため、作業領域の幅を基準にします。だからこそ、幅はページではなくシェルに属します。ページごとにカラム幅が異なるプロダクトでは、ページを移動するたびにコンテンツが横に飛びます。
• モーション。 マーケティングでは、訪問者にまだ何も求めていないため、画面の表示時にアニメーションを使うことがあります。プロダクトでは、ユーザーの操作に応じてアニメーションさせます。ただし、二つの例外があります。一つはオンボーディングです。動きによって、初めて使うユーザーに要素の出どころを示すためです。もう一つは空の状態です。画面が壊れているのではなく、待機中であることを伝えるためです。どちらもユーザーの状況に応じたものであるため、このルールに反するものではありません。
• テーマ。 マーケティングサイトでは不要でも、プロダクトではライトモードが必要になることがあります。ツールを六時間使う人には選択する権利がありますが、通りすがりの訪問者に切り替え機能は必要ありません。

両方で表示されるコンポーネント

ヘッダー、主要な CTA、料金ウィジェット、フッターなど、両方の画面に表示されるコンポーネントはいくつかあります。画面ごとのルールをめぐって議論になるのは、そうしたコンポーネントです。これらはどちらの画面にも属しません。

ルール：共有コンポーネントは、画面ごとのバリアントを持たず、コンテキストから画面の設定を読み取ります。 marketing プロパティと app プロパティを持つコンポーネントは、その時点ですでに分岐しています。どちらも引き続きレンダリングされるため、次の変更で二つの分岐が別々に進んでも、誰も気づきません。

実際には、次のようになります。

• コンポーネントは、配置された画面のトークンを使います。プロダクトにテーマがあり、サイトにはない場合でも、コンポーネントはどこでもテーマに対応させます。そのうえで、サイト側では値を変更しないようにします。
• 画面ごとのサイズは、コンポーネントがすでに持っているプロパティです。ランディングページでは大きく、ツールバーでは中くらいのサイズで表示する CTA は、二つのコンポーネントではなく、一つのコンポーネントの二つのサイズです。
• 二つの画面でサイズだけでなく動作も本当に異なる必要があるなら、それは別々の名前を持つ二つのコンポーネントです。ブール値の背後に分岐を隠さず、そうであることを明言しましょう。
• 共有コンポーネントの所有者は、最後に手を加えたチームではなく、トークンの供給元の所有者です。

違いではなく、ずれにあたるもの

• 一方の画面にしかない、二つ目のグレーやブランドブルー
• サイトとプロダクトで意味が異なるコンポーネント。たとえば、片方ではリンク、もう片方ではラベルとして使われるピル
• マーケティングページでは最低基準を満たすコントラストが、文字の小ささによってさらに厳しくなる高密度のプロダクト画面では、気づかないうちに基準を下回ること
• 一方の画面にしかない操作の手がかり。たとえば、フォーカス可視状態、キーボード操作の経路、ARIA ロールが、プロダクトにはあるのにサイトにはない場合、またはその逆

トークンレイヤーは一元化する必要があります

1つのコードベースで両方のサーフェスに対応すると、よくここで失敗します。そして、その失敗は気づかれないまま起こります。

失敗の形は、同じ値を3つの仕組みが同時に持つことです。1か所で定義されたCSSカスタムプロパティ、マークアップに貼り付けられた16進数の値、テーマごとにクラス名を返すランタイムヘルパーです。どれも個別には妥当な理由から導入されます。しかし、組み合わさると、色を1か所で変更できなくなり、不一致を知らせるものもありません。

ルール：値の信頼できる唯一の情報源は1つにし、利用者はいくつあっても構いません。 テーマを使うサーフェスが実行時にトークンを解決するのは問題ありません。ただし、独自のコピーを持つのではなく、共有トークンを解決する場合に限ります。確認方法は簡単です。ブランドのアクセントカラーを1か所で変更し、両方のサーフェスに反映されるか確かめてください。片方に反映されないなら、同じロゴを掲げた2つのデザインシステムが存在しています。

マークアップ内のリテラル値は、次の2つの理由から、特に探すべきものです。トークンの監査では見つけられず、テーマからも変更できないためです。リテラル値だらけのサーフェスは、テーマ設定を使わないと決めたのではありません。気づかないうちに、テーマ設定を不可能にしているのです。

境界が実際にある場所

余分な16進数よりも多く見られるのは、リポジトリやシステムの境界で2つ目の青が生まれるケースです。境界の位置によって、単一の情報源に必要な作業が決まります。

• 1つのリポジトリで両方のサーフェスに対応する場合。 最も簡単なケースですが、それでも最も失敗しやすいケースです。値はどちらのサーフェスのフォルダーにも属さない場所に置く必要があります。そうしないと、先に構築されたサーフェスが、いつの間にか定義元になります。
• リポジトリが別々の場合。 情報源は公開済みのバージョン管理された成果物でなければならず、両方がそれを利用し、更新はコピーではなくリリースとして行う必要があります。「サイトはどうやって新しいアクセントカラーを取得するのか」という問いに「誰かが貼り付けます」と正直に答えるなら、単一の情報源は存在せず、ただの慣習にすぎません。
• 製品の隣にCMSやマーケティングプラットフォームがある場合。 値は、管理画面に手入力するのではなく、ビルド工程としてプラットフォーム独自のテーマ設定にエクスポートする必要があります。設定欄に入力した値は、履歴のない分岐です。
• デザインツールを起点とする場合。 一方向が正とされているなら問題ありません。デザインツールとコード間の双方向同期は単一の情報源ではなく、遅れて発生するマージコンフリクトを抱えた2つの情報源です。

実際に人々が最適化するのは、境界を越えるコストです。共有の情報源を利用するより値をハードコードするほうが速ければ、値はハードコードされます。それを防げるルールはありません。

情報源の担当者を決める

全員が所有する情報源は、誰も所有していないのと同じです。そしてこれは、ここで挙げた他のどの点よりも長く影響が残る失敗です。トークンは古くなり、確認を依頼するより自分たちで直すほうが速いため、各サーフェスが個別に修正します。誰かが提案する前に、分断は完成しています。

トークンの情報源を管理する担当者を1人、または1つのチームに定め、トークンの保管場所に明記してください。 担当者は各サーフェスの見た目を決めるわけではありません。共有レイヤーに含める内容を決め、変更をレビューし、サーフェスのチームが値を追加する前に相談する相手となります。

名目上ではなく、実質的な所有権にするためのルールがさらに2つあります。

• 共有レイヤーへの追加は担当者が決めます。そこから何を選ぶかは担当者が決めることではありません。 ページで使うすべての角丸半径について担当者に確認するよう求めると、担当者はボトルネックになり、1か月もしないうちに迂回されます。
• 境界を越えるコストを低く保つ責任は担当者にあります。 チームが値をハードコードし続けるなら、それはチームの規律を責めるのではなく、担当者が解決すべき問題です。

フォーク後の進め方

多くの読者はすでにフォークした状態でここにたどり着きます。また、正しい最終状態を定めるだけでは計画になりません。順序が重要です。ありがちな順序で進めるとうまくいかないためです。

1. 統一する前に棚卸しします。 ドキュメントではなく、実際に動作している各サーフェスを確認し、それぞれが実際に使っている値をすべて列挙します。両者の食い違いこそが、本当に取り組むべき課題です。
2. 衝突と重複を切り分けます。 2つのサーフェスが同じ値をそれぞれの場所に保持しているのは重複で、修正は簡単です。1つの役割に対して2つのサーフェスが異なる値を保持しているのは衝突で、人による判断が必要です。頻度を基準にツールに勝者を選ばせてはいけません。
3. まず衝突を整理し、方針を書面にまとめます。 アクセントカラーは1つ、役割ごとのグレーは1つ、角丸の段階も1つにします。これはリファクタリングではなくデザイン上の判断であり、自動化できない唯一の手順です。
4. その後でソースを作成し、片方のサーフェスをそこに接続します。 片方だけです。単一の利用側で検証されたものがソースです。2つの利用側に同時に対応するよう作られたソースは、どちらについても推測にすぎません。
5. 2つ目のサーフェスを移行し、同じ変更で古い値を削除します。 古い仕組みを残す移行は、仕組みを取り除くのではなく追加しています。そうして、そもそも仕組みが3つに増えたのです。
6. ビルドを失敗させるチェックを追加します。 マークアップ内のリテラル値によって CI が失敗するようになるまでは、数は増える一方で、フォークはチームのリリース速度に応じて自ら再構築されます。

チームが飛ばすのは3番目の手順です。自分が所有していないサーフェスに異議を唱える人が必要だからです。まさにそのためにオーナーがいます。

実践的なチェック

• 両方のサーフェスから値を抽出し、パレットを比較します。一方にあって他方にない色相は、受け入れるべき事実ではなく、答えを出すべき問いです。
• 両方のサーフェスで使われている角丸の値を列挙します。数ではなく、すべての値が定義済みスケールの段階に含まれているかが重要です。スケールから外れた値が1つあるほうが、スケールに沿った値が6つあることより重要です。
• マーケティング用の本文ではなく、プロダクトで最も情報量の多い画面の最小テキストでコントラストを確認します。本文テキストは 4.5:1、太字で 18.66px 以上、または標準の太さで 24px 以上は 3:1 です。マーケティングページはサイズだけで基準を満たすため、問題が起きる画面については何もわかりません。
• マークアップ内の色のリテラル値を grep します。その数がドリフトによる負債であり、放っておけば増える一方です。

関連項目：プロダクトの密度を選ぶには ui-density、1つのサーフェスにテーマを追加するには color-mode-and-theme、コンポーネントがどこでも同じ意味を持つようにするには component-family-consistency を参照してください。