デザインシステムがあらゆる場所の電子メールチームに力を与える方法：ウェビナーレコーディング+ Q＆A

リモートの電子メールチームで作業するかどうかに関係なく、電子メール設計システムが役立ちます。 プログラムのスケーリングと一貫性の確保から、電子メールの設計とコーディングの時間の節約まで、強力な設計システムがあなたの背中を支えます。 しかし、どのようにして作成と保守を開始しますか？

この円卓会議では、Stack Overflow、Zillow、およびLitmusの専門家が、電子メール設計システムを使用することの利点と課題について話しました。

ウェビナーをライブで見る機会がありませんでしたか？ 心配しないでください。 いつでも完全な録音にアクセスして、以下のQ＆Aを読むことができます。

Q＆A

ウェビナー中に質問をしてくれた皆さん、本当にありがとうございました！ これは、最も人気のある質問に対する回答の要約と、ライブウェビナーでは得られなかったいくつかの質問に対する回答です。 他に質問がありますか？ コメント欄に残してください。

チームを始めることができる電子メール設計システムの主要なモジュール/コンポーネントは何ですか？

Ted Goas：これはチームごとに異なります。 私たちは監査から始め、Googleドキュメントでブレインストーミングを行うように人々を招待しました。 すべての電子メールに必要な安全なもの（ボタン、タイポグラフィなど）はおそらくいくつかありますが、何から始めるべきかがわかったのは、監査とブレインストーミングのセッションの後でした。 この出発点はチームごとに異なります。 これについては、メールデザインシステムの記事の「レッスン3：小さく始めて、早く他の人を巻き込む」のセクションに書きました。

Jaina Mistry： Tedに同意します。私たちは、Litmusでも同じように始めました。現在の電子メールを監査して、頻繁に繰り返すモジュールとコンポーネントを確認しました。 私たちにとって、それはCTAボタン、段落、リスト（順序付きおよび順序なし）、ヒーロー画像、リンク、およびタイポグラフィであることが判明しました。

Crystal Ledesma：開始は、グループの他のメンバーが言及したように、電子メールを監査するのと同じくらい簡単です。 大量の電子メールを送信し、それらすべてを監査するのは非常に大きな作業である場合は、一般的に使用されているデザインパターンやパフォーマンスの高い電子メールを特定して監査します。 私は物事を手に取り、監査された電子メールを印刷し（申し訳ありませんが！）、ペンを持ってそれらを描き、何度も目にするデザインパターンを特定するのに役立てるのが好きです。 これらは、システムの「ビルディングブロック」またはモジュールになります。 これが、Zillowのメールデザインシステムを始めたきっかけです。 ボタンなどの小さなコンポーネントと、すべてのメールで一貫性を持たせる方法を学びたかったのですが、それでも物事を戸外に出そうとしていました。当初、私は1人のチームだったので、シンプルに保ちました。

メールデザインシステムを実際に構築することについて、部門の枠を超えたパートナーから賛同を得たら、それを軌道に乗せるための最初のステップとして何をお勧めしますか？

Jaina：目指すべき現実的な目標を自分で設定してください。 カレンダーを見て、特定の日付までに達成したいことを計画します。 メールマーケターは忙しい人なので、おそらくデザインシステムでの作業と日常の作業のバランスをとることになります。 また、設計システムの作業に専念する時間がない場合もあります。 あなたが数週間のうちにそれを完了することに着手したならば、あなたがそれに取り組むことができない毎日はかなり否定的に感じるでしょう。 代わりに、達成したいことをまとめて切り分け、少しずつ取り組んでください。

クリスタル：デザインシステムを使用する人を特定し、メールデザインシステムをプロジェクトではなく内部製品として考え始めます。特定した人はユーザーです。 ユーザーのフィードバックを早期に取得したいのですが、ボーナスとして、ユーザーを早期に関与させることで、システムへの信頼を育むことができます。 それとは別に、他の人のアドバイスをエコーし​​ます。 設計システムの美しさは、時間とともに進化し、拡張できることです。 それを小さく保つことは物事を進めるための最良の方法です。

多くの異なるブランドを持つマーケティングエージェンシーのデザインシステムはどのようになりますか？

クリスタル：さまざまなブランドと連携する上で難しいのは、さまざまなサブスクライバーの電子メール受信ボックスやサブスクライバーの動作に加えて、視覚的にさまざまなニーズが存在する可能性があることです。 Zillowにはよく知られているB2Cブランドがありますが、いくつかのB2Bブランドもあります。 これは、非常に幅広く多様なサブスクライバー、コンテンツ、ニーズ、および受信トレイのグループと連携していることを意味します。 すべてのブランドで1つのメールデザインシステムを構築するよう取り組んでいますが、ブランドごとに固有のニーズもあることはわかっています。 各ブランドの特定のニーズに固有のシステムのブランチを備えた「コア」メールデザインシステムを用意します。 代理店環境でも構造が役立つと思います。

チームに専任のデザインシステムコーディネーターがいない場合、テンプレート内のブランドとデザインの一貫性を維持する責任は、メール開発者またはデザイナーにあると思いますか？

Jaina：開発者とデザイナーだと思います。 開発者は技術的に達成できることについて話すことができますが、設計者はアクセシビリティなどの問題に対処するのに役立ちます。 どちらの役割も、それ自体でその責任を引き受けることはできません。彼らは協力する必要があります。

クリスタル：私がデザインシステムを管理し、1つのブランドだけに取り組む前は、それは間違いなくグループの努力でした。 デザイナーと開発者の両方が協力して、物事がブランドにとどまり、一貫性を保つようにしました。 私が経営している今でも、Zillowは大企業なので、今後もグループで取り組んでいきます。 設計システムやドキュメントへのユーザーのオンボーディングなどは、一貫性を保ち、ブランドを維持する方法をユーザーに教育するのに役立ちます。これにより、ユーザーは自分でそれを実行できるようになります。 私のチームは、パートナーチームが不確かな場合に、頼りになるエキスパートとして機能します。 あなたの会社に私たちのようなチームがない場合でも、TedがStackOverflowで説明したのと同様の関心のあるボランティアでこれを行うことができます。

新しいコンポーネントがシステムに追加される頻度はどれくらいですか。システムの一部にする前にA / Bテストを行いますか？

Crystal：これまでのところ、必要に応じて新しいコンポーネントとモジュールを追加しています。 通常、これは、現在のシステムに存在するものに完全に適合しないコンテンツまたはコンテンツの目標がある場合に発生します。 それは数回以上発生し、そのための強力なビジネスケースがある場合、我々はそれがシステムの正式な一部となるべきであると判断し、我々はそれを作成した場合。 モジュールとコンポーネントは以前の設計に基づいているため、システムの一部にする前にそれぞれをA / Bしませんでした。 ただし、デザインをシステム形式に変換することで、メールの一部を簡単にA / Bテストできるようになり、チームは、パフォーマンスが低いモジュールを棚上げして、オーディエンスとのパフォーマンスが向上するモジュールを強調することができました。 近い将来、システムを進化させ、新しい設計を模索し続けるにつれて、A / Bテストは、コンポーネントがシステムの一部になる前に必要なステップになるでしょう。

メールの専門家ではない人が作成したメールの品質をどのように維持しますか？

テッド：それは毎日の闘争です！ 電子メール設計システムは、低品質の電子メールが送信されないことを保証するものではありません。 伝道と教えは助けになりますが、一度にどこにでもいることは不可能であり、あなたはブロッカーになりたくありません。 私は、大量の送信、定期的な電子メール、および顧客体験の要点で送信される電子メールに焦点を当てることによって、影響を最大化しようとしています。

クリスタル：テッドが言ったこと！ 特にデザインシステムが真新しい場合は時間がかかります。 それを作成し、確立し、全員に参加させるなどの時間です。 時間と継続的なサポートにより、品質は向上します。 使用しているツールによっては、それらのツールを活用して微調整されたコントロールを追加し、品質を維持できる場合があります。

電子メールの双方向性のようなものは、どのように設計システムに影響を及ぼしますか？

テッド： 12月にインタラクティブなメールを試しました。 探索は機能しましたが、目前のUXの問題は解決されなかったため、棚上げになりました。 ただし、それを進めていれば、インタラクティブコンポーネントを他のすべてのコンポーネントと同じように扱っていたでしょう。3回以上使用したら、体系化して設計システムに文書化する必要があります。 それまでは、コンポーネントはアドホックデザインとして扱われます。

クリスタル：私たちはまだ電子メールとデザインシステムの双方向性を探求することができていませんが、私たちのアプローチはテッドのアプローチと同じであり、インタラクティブかどうかにかかわらず、コンポーネントを追加するのとすでに似ています。 最初はアドホックアイテムと見なされ、再び必要になった場合に備えてバックポケットに保存されます。 そのインタラクティブコンポーネントを数回以上使用し始め、それが影響力があることが判明した場合、使用のガイドラインとともにシステムに追加されます。

デザインシステムの導入を試みましたが、ブランディングチームに適切に使用してもらうことは困難です。 その後、毎回新しいメールデザインを作成する必要があります。 どのようにこれと戦うのですか？

Jaina：ブランディングチームは、デザインシステムの使用を妨げるどのような課題に直面していますか？ 彼らにフィードバックを求め、それに対処するためにどのように役立つかを理解してください。 ブランディングチームが彼らの意見を聞いていると感じた場合、デザインシステムで彼らから賛同を得ることはあなたに役立つかもしれません。

クリスタル：この種の問題は通常、システムの誤解や、私たちが気付いていなかったチームの必要性に根ざしています。 それらがシステムに直接当てはまるかどうかにかかわらず、チームのニーズ、目標、および摩擦領域を理解します。 これらの調査結果をシステムに関連付けると、チームがシステムを適切に使用するのを妨げているシステム自体に欠けているもの、またはチームがシステムを正常に使用するために必要なオンボーディングとサポートの領域をより適切に診断できる可能性があります。 。

メールデザイナーとして寄せられたフィードバックは、デザインシステムがメールを退屈に見せてくれるというものです。 どうすればメールをエキサイティングに保ちながら、デザインシステムとの一貫性を保つことができますか？

テッド：私たちは逆にこの問題を抱えていました：人々は私たちのルーチンのスターターテンプレートに従って失敗しました。 年に一度の主要な発表の最初のドラフトがいくつか見られましたが、そのほとんどは白い背景に黒いテキストでした。 それに応えて、私たちはデザインシステムにセクションを作成し、ユニークなものをデザインしても大丈夫であることと、過去にそれをどのように行ったかを人々に示しました。

Jaina：デザインシステムが整っているので、クリエイティブになることがもっとたくさんあります！ 構造が整っていると、設計者はコンテンツをどのように構造化する必要があるかを考える必要はありませんが、電子メールで使用される画像やイラスト、およびそれらのアセットが電子メールのコピーをどのように補完および強化するかについてより多くの時間を費やすことができます。 ここで、多くの典型的な「箱型」の電子メールが大きく勝ちます。この構造は、素晴らしいコピーとデザインによってサポートされています。

Crystal：設計者がシステムに制約されていると感じないようにするために、他社からのインスピレーションを共有し、それらの設計をコンポーネントに分解する方法を説明することが役立ちました。 デザイナーが彼らにインスピレーションを与えるメールを共有して、あなたが彼らを通り抜けることができるなら、さらに良いです！ 時間が許せば、デザインシステムを考慮せずに、デザイナーにメールを好きなようにデザインしてもらうこともお勧めします。 彼らにあなたと再会してもらい、最終的にその設計をシステムに適合させるためにどのような調整を行うことができるかを強調することができます。 また、これを機会として使用して、設計システムがより単純な電子メールをより速く実行するのに役立つことを強調することもできます。 節約された時間により、設計者は、将来的にシステムの一部となる可能性のあるテスト用の新しいデザインを提案する機会が得られ、システムが現在提供している以上のものを必要とするキャンペーン用に独自の電子メールデザインを提案および作成するための可用性が高まります。

設計システムを改訂する必要がある場合はどうなりますか？また、更新の要求があった場合はどうしますか？

Jaina：リトマスではまだこれを持っていませんが、「なぜ？」と尋ねます。 必要な努力がそれだけの価値があるかどうかを理解すること。

Crystal：現在、システムの改訂を進めており、すべてのブランドをサポートできるように拡張できます。 これは、改訂の重要なビジネスケースの極端な例ですが、改訂を行うかどうかを検討する際に留意するのは良い基準です。 システムが小さく、1つのブランドしかサポートしていなかった場合、改訂の理由には、ブランドの変更とアクセシビリティを向上させるためのコードの更新が含まれ、どちらも明らかに強力なビジネスケースでした。 更新のリクエストがより大きなビジネス目標またはニーズに貢献する場合、それは彼らと一緒に前進するための明確な兆候です。 はっきりしない場合は、質問してください。 改訂のユースケースは何ですか？ リビジョンはシステム内の他のすべてにどのように影響しますか？ このリビジョンはリクエスターのユースケースに非常に固有であり、そのユースケースのリビジョンは他のユーザーに破壊的な波及効果を引き起こしますか？ システムの更新に取り組んでいるチームまたは人は、修正を行う時間がありますか？ すぐに必要ですか、それとも待つことができますか？ 言い換えれば、ジャイナが言ったように、必要な努力はそれだけの価値があるのでしょうか？

テッド：なぜ、ときに私は尋ねたい、ジャイナが言ったことに構築します。 コンポーネントがどのように使用され、いつ使用されるかを理解したいと思います。 設計システムコンポーネントの最適な候補は、頻繁に再利用されるものであるため、何かが使用される頻度を理解することが重要です。