HTMLメールは小さなウェブページではありません。メールクライアントはスタイルを削除し、リンクを書き換え、画像をプロキシ経由で表示することがあります。さらに端末によってフォントや使用可能な幅も変わります。信頼できる確認対象は、エディターのプレビューではなく、実際に送信したメールです。
1. まずテスト基準を固定する
テンプレートを修正する前に、テンプレートのバージョン、送信環境、宛先、送信時刻、想定する変数を記録します。毎回変更する要素は1グループだけにしましょう。たとえばコンテナ幅だけを調整する、またはボタン構造だけを置き換えるといった具合です。そうしなければ結果が改善しても、どの変更が効いたのか判断できません。
少なくともデスクトップ用クライアント1つと、幅390px前後のモバイル端末1台を用意しましょう。複数の市場向けにサービスを提供しているチームは、最も長い言語のサンプル、長いメールアドレス、長い注文番号、変数が空のサンプルも加えてください。これらをトランザクションメールのワークベンチに保存しておけば、毎回その場で組み立てる必要がありません。
テンプレートのバージョン、トリガー時刻、受信時刻、クライアント、画面幅、件名、From、スクリーンショット、元のヘッダー。これらがなければ、互換性の問題を再現するのは困難です。
2. まずヘッダー、次に見た目を確認する
受信者が最初に目にするのは、差出人名、件名、プレビュー文です。件名は「新しい端末からのログインを確認」のように、行動を具体的に示しましょう。「重要なお知らせ」だけでは不十分です。From名はユーザーが直前に行った操作と一致させ、Reply-Toは担当者が対応するアドレスにするか、返信できないことを明記します。
プレビュー文は件名を補足するもので、件名の繰り返しにしないでください。長い件名がモバイルで途中までしか表示されなくても、重要な行動が伝わるか確認します。確認コード、金額、注文ステータスはプレビュー文だけに依存しないでください。クライアントによっては安定して表示されないためです。
3. レイアウトとレスポンシブ表示を確認する
デスクトップではメール本文を読みやすい幅に保ち、モバイルでは1列に自然に縮小できるようにします。メールクライアントとの互換性が高いテーブル構造と重要なインラインスタイルを優先し、ウェブサイトで使うGrid、複雑な位置指定、外部スタイルシートには依存しないでください。
- 幅390pxで横スクロールが発生せず、長いリンクや注文番号が折り返されることを確認する。
- 見出し、段落、リスト、ボタンの間隔に一定のリズムがあり、システムフォントに置き換わっても詰まらないことを確認する。
- 背景画像を削除してもう一度読み、重要な情報が画像や背景色だけに依存していないことを確認する。
- 200%に拡大して本文と操作内容が理解できるか確認し、ボタン同士が重ならないことを確認する。
4. 画像、ボタン、動的コンテンツを個別に検証する
画像を無効にしても、ブランド装飾は消えて構いませんが、確認コード、金額、日付、操作説明は残る必要があります。情報を伝える画像には意味のある代替テキストを付け、装飾画像には空の代替テキストを使ってスクリーンリーダーによる重複読み上げを防ぎます。
ボタンは3つの観点で確認します。文言が操作内容を示しているか、見た目のボタンに十分なタップ領域があるか、リンク先とパラメーターが正しいかです。デザインツールのプレビュー上でクリックするだけでは不十分です。受信した完成メールからリンクを開き、リダイレクト、ログイン状態、無効なリンクへの遷移を確認してください。
動的変数には特に境界値のサンプルが必要です。長すぎる名前、空の注文リスト、タイムゾーンをまたぐ日付、通貨の桁数の変化は、整ったレイアウトを崩すことがあります。トランザクションメールの種類ごとに、通常値、長い値、空の値を保存しておくほうが、公開後に一通ずつ対応するより効率的です。
5. アクセシビリティとプレーンテキストへのフォールバックは必須
本文は前景色と背景色に十分なコントラストを確保し、リンクを色だけで判別できる状態にしないでください。読み上げ順序は視覚的な順序と一致させます。見出しの階層は文字サイズの都合で自由に飛ばすのではなく、スクリーンリーダー利用者が内容を理解できるように設定します。アニメーションが重要な操作を伝える場合は、最初のフレームにも情報を完全に含めてください。
プレーンテキスト版には、件名に対応する文脈、確認コード、有効期限、完全なリンクを残します。HTMLタグをすべて取り除いた残りかすではありません。送信前に HTMLメールテストチェックリストを項目ごとに確認し、HTML版とプレーンテキスト版が同じ操作を伝えているか比較しましょう。
6. 実際に送信して公開前の受け入れ確認を行う
最後はテンプレートエディターの「テスト送信」ではなく、実際の業務システムからメールを起動します。実際の配信経路でなければ、変数の注入、キュー、署名、リンクの書き換え、実際のFromを確認できません。専用のテストアドレスを1つ用意してトリガー時刻を記録し、メールが届いたらヘッダーと本文を同時に確認します。
メールが想定どおり届かなくても、すぐに連続再送しないでください。まず送信サービスの状態とアドレスの綴りを確認し、次に確認コードメールの遅延を調べる手順を参考に、待つのか、アドレスを変えるのか、再度トリガーするのか判断します。修正後は新しい完全なサンプルを送信し、古いスクリーンショットで再確認を済ませないでください。