یک Email Template حرفهای باید پیام را به شکل قابل فهم به مقصد برساند و استفاده دوباره از آن برای تیم آسان باشد. زیبایی بخشی از کار است، اما قالبی که عنوان نامناسب، لینک اشتباه یا اطلاعات ناقص دارد با ظاهر مرتب اصلاح نمیشود. مخاطب ممکن است ایمیل را در گوشی، برنامه دسکتاپ یا وبمیل بخواند؛ ممکن است تصاویر را نمایش ندهد یا متن را با ابزار کمکی دنبال کند. قالب باید با این تنوع کنار بیاید و هدف پیام را روشن نگه دارد.
پیش از طراحی، نوع ایمیل را مشخص کنید. رسید خرید، اطلاعرسانی وضعیت حساب و خبرنامه تبلیغاتی قرارداد یکسانی ندارند. در رسید، شماره سفارش و مبلغ اهمیت دارند؛ در پیام امنیتی، تشخیص رویداد و اقدام بعدی مهم است؛ در خبرنامه، مخاطب باید بفهمد چرا این پیام برای او آمده است. ادعای اینکه Email برای همه کسبوکارها بیشترین بازده را دارد، جای تعریف هدف را نمیگیرد. ارزش قالب با کاربرد و نتیجه واقعی همان پیام سنجیده میشود.
محتوا را پیش از تزئین مرتب کنید
برای هر نوع پیام، چند بخش ثابت تعریف کنید: فرستنده روشن، عنوان دقیق، توضیح اصلی، اطلاعات لازم و اقدام مرتبط. همه ایمیلها به hero یا تصویر بزرگ نیاز ندارند. اگر یک تأیید ساده با چند خط اطلاعات کامل میشود، افزودن چند بخش تبلیغاتی میتواند پیام اصلی را پنهان کند. پیش از انتخاب رنگ و فونت، متن را بدون قالب بخوانید. اگر در همین حالت معلوم نیست کاربر باید چه چیزی بداند یا انجام دهد، مسئله در ساختار پیام است.
Subject باید با محتوای واقعی هماهنگ باشد. عنوانی که حس فوریت بیدلیل ایجاد میکند، ممکن است کاربر را به کلیک برساند ولی اعتماد را کاهش دهد. متن پیشنمایش یا preheader هم میتواند اطلاعات تکمیلی بدهد؛ تکرار دقیق Subject لزوماً استفاده خوبی از آن فضا نیست. برای پیام فارسی، طول عنوان را با نمونههای واقعی در نظر بگیرید. تعداد نویسه ثابت برای همه برنامهها وجود ندارد، چون عرض صفحه و نمایش نام فرستنده متفاوت است.
یک مسیر اصلی برای خواندن
خواننده معمولاً ایمیل را مثل یک گزارش طولانی مطالعه نمیکند. عنوان هر بخش باید موضوع را روشن کند و پاراگرافها به اندازهای باشند که روی نمایشگر کوچک قابل دنبال کردن بمانند. اطلاعات حیاتی را در تصویر قرار ندهید؛ ممکن است تصویر دریافت یا نمایش داده نشود. متن دکمه نیز باید مقصد یا نتیجه را بیان کند. «مشاهده وضعیت سفارش» از «اینجا کلیک کنید» اطلاعات بیشتری دارد و بیرون از بافت پاراگراف هم قابل فهم است.
اگر چند اقدام لازم است، رابطه آنها را روشن کنید. لینک راهنما میتواند کنار اقدام اصلی باشد، اما نباید هر دو به یک اندازه توجه بخواهند. در خبرنامه دارای چند مطلب، عنوان هر مطلب و توضیح کوتاه میتواند مستقل باشد. لازم نیست همه لینکها به دکمههای بزرگ تبدیل شوند. در راهنمای Email واکنشگرا، بخش فنی سازگاری و بازچینی توضیح داده شده است؛ اینجا تمرکز بر قراردادی است که محتوا را در قالب نگه میدارد.
سازگاری را دقیق تعریف کنید
برنامههای Email از نظر حمایت از CSS و روش نمایش یکسان نیستند. نام یک محصول نیز برای تعیین همه رفتارها کافی نیست؛ نسخه وب و نسخه دسکتاپ میتوانند موتورهای متفاوتی داشته باشند. بنابراین «در همه Email Clientها درست نمایش داده میشود» ادعای قابل دفاعی برای یک قالب عمومی نیست. فهرست محیطهای مهم پروژه را تعیین کنید و حد قابل قبول نمایش را بنویسید. ترتیب محتوا، خوانایی و قابل استفاده بودن لینکها معمولاً مهمتر از تطابق پیکسلی کامل هستند.
عرض ششصد پیکسل یک انتخاب رایج برای بعضی قالبهاست، نه الزام فنی Email. یک پیام تکستونه میتواند محدودیت عرض دیگری داشته باشد و در صفحه کوچک به عرض موجود تطبیق یابد. Table نیز برای برخی نیازهای سازگاری استفاده میشود، اما هر جدول باید هدف روشنی داشته باشد. اگر جدول صرفاً برای چیدمان است، نباید مانند جدول داده به فناوری کمکی معرفی شود. انتخاب ابزار چیدمان را به محیطهای هدف و ساختار پیام متصل کنید، نه به یک دستور همیشگی.
CSS و fallback
Inline CSS در بعضی فرایندها به سازگاری کمک میکند، ولی این گزاره که Gmail هیچ style blockی را نمیپذیرد درست نیست. مستندات رسمی Gmail از پشتیبانی مجموعهای از CSS، selectorها و media queryها توضیح میدهد. این حمایت به معنی پذیرفتن تمام قابلیتهای مرورگر نیست. ابزار ارسال ممکن است markup را نیز تغییر دهد. قابلیتهای مهم را از مستندات محیط مقصد بخوانید و برای حذف یا نادیده گرفته شدن سبکهای غیرضروری، محتوا را قابل استفاده نگه دارید.
نسخه پایه باید بدون رفتار پیچیده هم قابل خواندن باشد. لینک، متن، فاصله مناسب و ساختار منطقی کمک میکنند پیام با محدودیت سبکها باقی بماند. قابلیتهایی مانند تغییر رنگ در Dark Mode ممکن است میان محیطها متفاوت باشند. رنگ متن و زمینه را با هم مشخص کنید، اما انتظار کنترل کامل همه تغییرات را نداشته باشید. اگر تمایز یک بخش فقط به رنگ وابسته است، عنوان یا توضیحی اضافه کنید تا معنای آن با تغییر نمایش از بین نرود.
نمونهای بدون وابستگی تصویری
فایل زیر یک نمونه آموزشی کامل برای خبرنامه دو مطلبی است. آن را با نام newsletter.html ذخیره کنید و برای مشاهده اولیه در مرورگر باز کنید. فایل به کتابخانه یا تصویر خارجی وابسته نیست. مشاهده در مرورگر معادل بررسی در برنامههای Email نیست؛ برای استفاده واقعی باید آن را در مسیر ارسال و محیطهای هدف خود بررسی کنید. لینکهای نمونه به دو مطلب موجود مجله اشاره میکنند. اطلاعات فرستنده و تنظیمات اشتراک باید توسط سامانه واقعی ارسال اضافه شوند.
<!doctype html>
<html lang="fa" dir="rtl">
<head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>دو راهنمای تازه برای طراحی وب</title></head>
<body style="margin:0;background:#eef2f6;color:#17324d;font-family:Arial,sans-serif;line-height:1.8;">
<div style="display:none;max-height:0;overflow:hidden;">انتخاب تصویر مناسب و طراحی آیکون قابل فهم برای رابط وب.</div>
<table role="presentation" style="border-collapse:collapse;width:100%;"><tr><td align="center" style="padding:24px 12px;">
<table role="presentation" style="border-collapse:collapse;width:100%;max-width:600px;background:#ffffff;"><tr><td style="padding:24px;">
<p style="margin:0 0 12px;font-size:16px;">مجله طراحستان</p>
<h1 style="margin:0 0 20px;font-size:26px;line-height:1.5;">دو راهنما برای تصمیمهای تصویری وب</h1>
<h2 style="margin:24px 0 8px;font-size:21px;">اندازه و تحویل تصاویر</h2>
<p style="margin:0 0 12px;font-size:17px;">با ابعاد، نسخههای مناسب و زمان دریافت تصویر، تجربه بارگذاری را بهتر مدیریت کنید.</p>
<p style="margin:0;"><a href="https://tarahestan.com/magazine/web-image-optimization-format-size" style="color:#084c8d;font-size:17px;text-decoration:underline;">خواندن راهنمای بهینهسازی تصویر</a></p>
<h2 style="margin:24px 0 8px;font-size:21px;">آیکونهایی با معنای روشن</h2>
<p style="margin:0 0 12px;font-size:17px;">انتخاب شکل، برچسب و اندازه را با کار واقعی کنترلهای رابط هماهنگ کنید.</p>
<p style="margin:0;"><a href="https://tarahestan.com/magazine/web-iconography-effective-icon-design" style="color:#084c8d;font-size:17px;text-decoration:underline;">خواندن راهنمای آیکونوگرافی</a></p>
<p style="margin:28px 0 0;font-size:16px;">این فایل نمونه آموزشی قالب است. پیش از ارسال واقعی، اطلاعات معتبر فرستنده و مدیریت اشتراک را در سامانه ارسال تنظیم کنید.</p>
</td></tr></table>
</td></tr></table>
</body></html>
این نمونه عمداً اطلاعات ساختگی سفارش، نام شخص و لینک لغو اشتراک جعلی ندارد. برای خبرنامه بازاریابی واقعی، سامانه ارسال باید راه معتبر مدیریت اشتراک را با سیاست همان سرویس فراهم کند. یک لینک ظاهری به نشانی ناموجود، نمونه را آماده ارسال نمیکند. همچنین نسخه plain text را از متن واقعی پیام تهیه کنید؛ حذف ساده همه tagها ممکن است ترتیب، فاصلهها و نشانی لینکها را نامناسب کند. نسخه متنی باید همان مفهوم و اقدامات اصلی را داشته باشد.
شخصیسازی به قرارداد داده نیاز دارد
اگر قالب نام مخاطب یا مبلغ را نمایش میدهد، برای نبود آن داده تصمیم بگیرید. شروع ایمیل با نام خالی یا رشتهای مانند undefined، اعتماد را کم میکند. برای نام میتوان یک خطاب عمومی مناسب داشت؛ برای مبلغ یا شماره سفارش، نبود داده ممکن است به معنای توقف ارسال باشد. فیلدهای ضروری و اختیاری را جدا تعریف کنید. متن فارسی اطراف مقدار نیز مهم است؛ یک مقدار بسیار بلند یا ترکیب عدد و حرف لاتین میتواند ترتیب بصری را تغییر دهد.
داده دریافتی باید در زمینه درست escape شود و لینکها از مسیر مورد اعتماد ساخته شوند. قراردادن متن آزاد مخاطب در markup بدون کنترل، مسئله امنیت و ساختار پیام ایجاد میکند. نمایش تاریخ، واحد مبلغ و اعداد نیز باید با کاربرد هماهنگ باشد. «امروز» برای ایمیلی که کاربر چند روز بعد میخواند مبهم است؛ تاریخ روشن میتواند بهتر باشد. قالب فقط ظرف داده نیست، بلکه تعیین میکند اطلاعات در زمان دریافت چطور فهمیده شوند.
مؤلفههای محدود و قابل نگهداری
کتابخانه قالب بهتر است چند مؤلفه مشخص داشته باشد: سربرگ، عنوان بخش، متن، اقدام اصلی، ردیف اطلاعات و پایان پیام. هر مؤلفه باید محدودیت محتوا داشته باشد. اگر عنوان یک کارت فقط برای دو کلمه طراحی شده، تیم محتوا باید بداند متن بلند چه رفتاری دارد. ساخت دهها نسخه نزدیک به هم، هزینه اصلاح را زیاد میکند. تغییر عمومی مانند فاصله یا رنگ لینک باید از یک نقطه قابل پیگیری باشد، نه در مجموعهای از فایلهای کپیشده.
نام نسخه قالب و تاریخ تغییر را در فرایند داخلی نگه دارید. ایمیلی که قبلاً ارسال شده قابل اصلاح در صندوق همه مخاطبان نیست؛ بنابراین کنترل قبل از ارسال ارزش زیادی دارد. عنوان، لینک مقصد، داده شخصی، نسخه متنی و نمایش محدودشده تصاویر را با نمونههای واقعی مرور کنید. این مرور باید متناسب با اهمیت پیام باشد. پیام امنیتی یا مالی به دقت محتوایی بیشتری نیاز دارد و نباید در مسیر ارسال با داده آزمایشی اشتباه گرفته شود.
کیفیت را از ظاهر فراتر ببرید
برای سنجش قالب، نتیجه مرتبط با هدف را انتخاب کنید. در رسید، فهم اطلاعات و کاهش ابهام مهم است؛ در راهنما، رسیدن کاربر به اقدام لازم؛ در خبرنامه، علاقه به محتوای مرتبط. هر معیار باید محدودیت خودش را داشته باشد و یک عدد منفرد علت رفتار را توضیح نمیدهد. اگر کاربر لینک را باز نمیکند، ممکن است موضوع برای او مناسب نباشد، زمان ارسال بد باشد یا مقصد قابل اعتماد نباشد. رنگ دکمه تنها فرضیه ممکن نیست.
قالب حرفهای وقتی شکل میگیرد که متن، داده و نمایش با یکدیگر قرارداد داشته باشند. از یک ساختار ساده آغاز کنید، محدودیت محیطهای هدف را بشناسید و موارد شکست را از قبل بنویسید. برای هماهنگی رنگها میتوانید راهنمای رنگ و هارمونی را بخوانید، اما اول مطمئن شوید پیام بدون تزئین هم روشن است. قالبی که تیم بتواند با اطمینان و بدون اصلاح دستی مداوم استفاده کند، ارزش بیشتری از یک طرح پیچیده و شکننده دارد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر میدهد!