طراحی صفحه اصلی سایت؛ معماری پیام، مسیر و تبدیل

کاربر همیشه از صفحه اصلی وارد سایت نمی‌شود؛ ممکن است مستقیم به محصول، مقاله یا لندینگ برسد. اما وقتی نمی‌داند شما چه می‌کنید، می‌خواهد اعتبارتان را بررسی کند یا مسیر مناسب را پیدا کند، Homepage به نقطه تصمیم تبدیل می‌شود. اگر این صفحه فقط یک تصویر بزرگ، چند شعار و فهرست خدمات باشد، نقش واقعی خود را انجام نمی‌دهد.

طراحی صفحه اصلی سایت یعنی ساختن قراردادی روشن میان نیاز کاربر و ساختار کسب‌وکار: چه کسی اینجاست، چه نتیجه‌ای می‌تواند بگیرد، چه شاهدی برای ادعاها وجود دارد و از کدام مسیر باید ادامه دهد. این راهنما از Brief و معماری پیام تا Hero، ناوبری، اعتماد، موبایل و RTL، دسترس‌پذیری، سرعت، سئو و اندازه‌گیری را به یک فرایند قابل آزمون تبدیل می‌کند.

صفحه اصلی چیست و چه کاری نباید انجام دهد؟

Homepage درگاه عمومی دامنه و مرکز جهت‌یابی سطح بالاست. وظیفه‌اش پاسخ کامل به همه نیازها نیست؛ باید هویت، حوزه، مسیرهای اصلی و شواهد کافی برای انتخاب مسیر را روشن کند. این صفحه معمولاً چند Audience و چند Stage را هماهنگ می‌کند، در حالی که صفحات تخصصی‌تر یک کار محدودتر دارند.

برای تفاوت Source-specific میان Homepage و صفحه کمپین، راهنمای طراحی لندینگ پیج و A/B تست را ببینید. اگر هدف، بهبود کل تجربه از تحقیق تا سنجش است، راهنمای جامع طراحی تجربه کاربری دامنه وسیع‌تری را پوشش می‌دهد.

آیا Homepage واقعاً «اولین نقطه تماس» است؟

نه همیشه. Search، Social، پیام‌رسان، لینک فروش و تبلیغ کاربران را به URLهای عمیق می‌رسانند. بنابراین طراحی صفحه اصلی بر فرض «همه از اینجا شروع می‌کنند» باعث می‌شود اطلاعات ضروری را فقط روی Homepage بگذارید و صفحات ورودی واقعی ناقص بمانند.

نقش Homepage را از داده تعیین کنید:

• چه درصدی از Sessionها از صفحه اصلی شروع می‌شوند و Source/Medium آن‌ها چیست؟
• کاربران پس از ورود مستقیم، کدام Routeها را انتخاب می‌کنند؟
• چه کسانی از صفحات عمیق به Homepage برمی‌گردند و بعد چه می‌کنند؟
• Search داخلی، تماس و چت چه چیزهایی را نشان می‌دهند که ناوبری پیدا نمی‌کند؟
• کاربر جدید، مشتری فعلی، متقاضی همکاری و شریک تجاری چه نیازهای متفاوتی دارند؟

این داده‌ها Homepage را کم‌اهمیت نمی‌کنند؛ نقش واقعی آن را روشن می‌کنند: گاهی موتور Discovery، گاهی صفحه اعتبارسنجی برند و گاهی Router برای چند محصول یا Audience.

مدل Audience → Promise → Evidence → Route

این چهار لایه باید در کل صفحه تکرار منطقی داشته باشند. مثلاً کارت خدمت فقط نام خدمت نباشد؛ Audience، نتیجه، یک شاهد کوتاه و لینک با مقصد روشن را نشان دهد. با این حال لازم نیست هر بلوک همه اطلاعات را حمل کند؛ هر بخش یک سؤال تصمیم را حل می‌کند.

Homepage brief را پیش از Wireframe بنویسید

شروع با Template یا Hero image باعث می‌شود تصمیم‌های محتوا تابع ظاهر شوند. Brief باید شواهد، اولویت و محدودیت را پیش از چیدمان ثبت کند. USWDS در اصول طراحی مبتنی بر نیاز واقعی کاربر و GOV.UK در راهنمای شناخت نیاز کاربر بر تحقیق، مشاهده و تبدیل نظرهای داخلی به فرضیه قابل‌آزمون تأکید دارند.

نظر مدیر یا ترند، Evidence کاربر نیست

«رقیب Slider دارد» یا «صفحه باید مدرن‌تر شود» Observation طراحی است، نه نیاز. مصاحبه، مشاهده Task، جست‌وجوی داخلی، تماس فروش، تیکت، Click path و داده Outcome را ترکیب کنید. داده کمی می‌گوید کجا رخداد اتفاق می‌افتد؛ تحقیق کیفی کمک می‌کند چرا و در چه Contextی رخ می‌دهد.

نوع Homepage را بر اساس مدل سایت انتخاب کنید

برای فروشگاه، Homepage فقط بخشی از Journey است؛ Browse، Search، Product، Cart و Checkout باید مستقل کار کنند. جزئیات در راهنمای UX فروشگاه اینترنتی آمده است.

معماری اطلاعات را حول Task بچینید، نه چارت سازمانی

کاربر معمولاً نام واحد داخلی شما را نمی‌داند. Labelهای «راهکارها»، «سامانه‌ها» یا «خدمات تخصصی» بدون زمینه مبهم‌اند. ابتدا فهرست Taskها و Destinationهای واقعی را بسازید؛ سپس Card sort، Tree test، Search log و تست کاربردپذیری را برای نام‌گذاری و سلسله‌مراتب به کار ببرید.

Route registry

برای هر Route ستون‌های Audience، Trigger، Destination، Label، Priority، Evidence، Owner، Availability و Outcome را ثبت کنید. اگر Destination هنوز پاسخ مناسب ندارد، لینک برجسته از Homepage فقط مشکل را منتقل می‌کند.

Header و Navigation را به‌عنوان ابزار Task طراحی کنید

Header محل نمایش همه لینک‌های مهم نیست. لوگو/Home، Navigation اصلی، Search در صورت نیاز، Account/Login و یک Action اولویت‌دار معمولاً کافی‌اند؛ تعداد و نوع دقیق به عمق سایت وابسته است. راهنمای Header در USWDS پیشنهاد می‌کند Navigation با Keyboard کار کند، Dropdown فقط به Hover وابسته نباشد، Navهای متعدد Label داشته باشند و نوع Basic/Extended بر اساس عمق انتخاب شود.

قواعد اجرایی Navigation

• Labelها کوتاه، آشنا و متناسب با زبان کاربر باشند.
• اولویت بصری با ترتیب DOM و Tab سازگار بماند؛ CSS order نباید مسیر Focus را گیج کند.
• منوی موبایل با Button دارای Name/State، Escape، Focus management و Scroll lock درست پیاده شود.
• Search را وقتی اضافه کنید که محتوا/کالا زیاد است و Retrieval نیاز واقعی دارد؛ سپس Queryهای بدون نتیجه را تحلیل کنید.
• Login، Register، Track order و Support را با Audience فعال/جدید مرزبندی کنید.
• Footer مکمل Navigation است، نه انبار لینک‌های رهاشده.

Hero باید یک تصمیم را آسان کند

«بالای Fold» ارتفاع ثابت و جهانی ندارد؛ دستگاه، فونت، Browser chrome و ترجمه آن را تغییر می‌دهند. Hero باید بدون Scroll اجباری، Context کافی برای تشخیص موضوع و Route اصلی بدهد، اما لازم نیست همه Argument فروش را در یک Viewport جا دهد.

فرمول پیام Hero

برای [Audience/Context]، [Offer/Category] کمک می‌کند [Outcome]؛ با [Mechanism یا Evidence].

نمونه فرضی ضعیف: «آینده کسب‌وکار شما را می‌سازیم.» نمونه روشن‌تر: «سامانه مدیریت سفارش برای فروشگاه‌های چندکاناله؛ موجودی وب‌سایت و شعبه را در یک جریان همگام کنید.» ادعای دوم هنوز به Evidence و Boundary نیاز دارد؛ اما کاربر دست‌کم Category، Audience و Outcome را می‌فهمد.

آیا در Homepage فقط یک CTA لازم است؟

نه به‌عنوان قانون عمومی. یک صفحه چندمخاطبی ممکن است Routeهای معتبر متفاوت داشته باشد. مسئله، تعداد مطلق CTA نیست؛ معماری اولویت و جلوگیری از رقابت بی‌منطق است. «خرید»، «درخواست دمو»، «مشاهده مستندات» و «ورود» Stageهای متفاوت‌اند.

CTA ladder

• Primary: مهم‌ترین اقدام برای Audience/Stage غالب؛
• Secondary: مسیر ارزیابی کم‌ریسک‌تر یا Audience مهم دوم؛
• Utility: Login، Support، Tracking یا Contact؛
• Contextual: اقدام مخصوص هر بخش، با Label مقصد.

رنگ متضاد به‌تنهایی CTA خوب نمی‌سازد. Action باید Name روشن، Stateهای Hover/Focus/Disabled/Loading، مقصد درست، بازخورد پس از کلیک و Tracking بدون داده شخصی داشته باشد. در موبایل، Sticky CTA فقط وقتی ارزش دارد که محتوا را نپوشاند و نیاز واقعی را حل کند.

بخش‌های صفحه را از سؤال‌های تصمیم بسازید

هیچ ترتیب هشت‌بخشی برای همه Homepageها وجود ندارد. هر Section باید یک سؤال مهم را حل کند و به Route بعدی کمک کند.

نمایش آخرین پست‌ها، آمار شبکه اجتماعی یا خبر شرکت فقط چون Widget آماده است، دلیل طراحی نیست. هر ماژول باید Owner، منبع داده، حالت Empty/Error و تاریخ انقضا داشته باشد.

Hierarchy بصری باید معنا را نشان دهد

سلسله‌مراتب با اندازه، وزن، Contrast، Spacing، Position و Grouping ساخته می‌شود. همه چیز را بزرگ، Bold یا رنگی نکنید؛ وقتی همه عناصر فریاد می‌زنند، هیچ اولویتی دیده نمی‌شود.

سیستم به‌جای سلیقه موردی

• Type scale محدود با نقش‌های مشخص برای H1 تا Caption؛
• Spacing scale و Containerهای سازگار با خوانایی؛
• Tokenهای Color با نقش Semantic، نه اسم «آبی روشن ۲»؛
• Componentهای Button، Card، Link و Section با State کامل؛
• قواعد تصویر، Icon، Radius و Shadow بر اساس کارکرد؛
• تست متن بلند فارسی، عدد، تومان/ریال، URL، Email و واژه انگلیسی.

فضای خالی «قسمت خالی صفحه» نیست؛ رابطه و اولویت را نشان می‌دهد. اما افزایش بی‌دلیل فاصله که Taskهای اصلی را دور می‌کند، لزوماً مینیمالیسم یا UX بهتر نیست.

تصویر، ویدئو و Carousel فقط با Visual job روشن

هر Visual باید یکی از این کارها را انجام دهد: نمایش محصول، توضیح Mechanism، اثبات نتیجه، ایجاد Context یا کمک به انتخاب. Stock photo تزئینی ممکن است فضای برند بسازد، اما نباید به‌جای Evidence استفاده شود.

Carousel پیش‌فرض Hero نیست

Slider چند پیام را در یک ناحیه پنهان می‌کند و کشف محتوا را دشوار می‌سازد. اگر نیاز واقعی به Carousel دارید، کاربر باید بتواند حرکت را Pause کند، با Keyboard کنترل کند و تغییر Slide برای فناوری کمکی اعلام شود. راهنمای Carousel در W3C WAI همین کنترل‌ها را شرح می‌دهد و اختلاف کاربردپذیری این الگو را نیز یادآوری می‌کند.

ویدئوی Hero

Autoplay با صدا را کنار بگذارید. ویدئو باید Poster، کنترل، Caption/Transcript در صورت وجود گفتار، گزینه Pause و جایگزین کم‌حجم داشته باشد. در شبکه ضعیف یا حالت Save-data، محتوای اصلی و CTA نباید به دانلود Video وابسته باشند.

برای Alt از نقش تصویر تصمیم بگیرید: تصویر کاربردی مقصد/عمل را، تصویر اطلاعاتی معنای لازم را و تصویر تزئینی Alt خالی می‌خواهد. درخت تصمیم Alt در W3C مرز این حالت‌ها را توضیح می‌دهد.

اعتماد را از ادعا به Evidence تبدیل کنید

HTTPS ارتباط را رمزگذاری می‌کند؛ هویت، صداقت یا کیفیت کسب‌وکار را تضمین نمی‌کند. لوگوی مشتری، Review، جایزه، مجوز و عدد فقط وقتی مفیدند که Source، Scope، Date و امکان Verify داشته باشند.

Review جعلی، حذف گزینشی یا رابطه مالی پنهان اعتماد را تخریب می‌کند. مرجع FTC درباره Review و Endorsement بر بازتاب صادقانه بازخورد و افشای ارتباط مادی تأکید دارد؛ برای بازار ایران نیز قوانین و سیاست‌های جاری مرتبط باید توسط متخصص حقوقی بررسی شوند. برای معماری کامل، راهنمای اعتمادسازی مبتنی بر شواهد در سایت را ببینید.

طراحی Mobile-first یعنی اولویت Task، نه کوچک‌کردن Desktop

در موبایل، فضا و پهنای باند محدودتر است؛ Context استفاده نیز متفاوت است. Content parity را حفظ کنید، اما ترتیب، تراکم و Interaction را برای صفحه کوچک بازطراحی کنید. Google در راهنمای Mobile-first indexing توضیح می‌دهد که نسخه موبایل برای Index و Ranking استفاده می‌شود و Responsive design را ساده‌ترین الگوی نگهداری می‌داند.

ماتریس پاسخ‌گویی، نه سه Screenshot

RTL و محتوای فارسی را از ابتدا وارد طراحی کنید

Flip کردن Layout پایان کار RTL نیست. جهت متن، ترتیب Navigation، Chevron، Timeline، نمودار، فرم، شماره تلفن، Email، URL و ترکیب واژه‌های انگلیسی باید جداگانه آزمون شوند.

• از ویژگی‌های منطقی CSS مانند margin-inline و padding-inline استفاده کنید.
• برای رشته‌های LTR در متن فارسی، Bidi isolation مناسب به کار ببرید.
• فونت فارسی باید وزن‌ها، اعداد، نیم‌فاصله و علائم را درست نمایش دهد.
• Button و Card را با متن ۳۰ تا ۵۰ درصد بلندتر Stress test کنید.
• نمایش تومان را از مقدار IRR در Backend جدا و واحد را صریح کنید.
• تقویم جلالی برای UI و زمان استاندارد/ISO برای Integration را با قرارداد روشن نگه دارید.

دسترس‌پذیری، Acceptance criteria طراحی است

WCAG را به مرحله Audit آخر منتقل نکنید. Navigation، Hero، CTA، Media و فرم از ابتدا باید با Keyboard، Screen reader، Zoom، Contrast و Reduced motion کار کنند. WCAG 2.2 معیارهای قابل‌آزمون را تعریف می‌کند؛ از جمله Target حداقل ۲۴×۲۴ CSS pixel با استثناهای مشخص و Focus نباید توسط محتوای دیگر کاملاً پنهان شود.

Definition of Done دسترس‌پذیری Homepage

• یک H1 معنادار و Landmarkهای Header/Nav/Main/Footer وجود دارند.
• Skip link، ترتیب Focus و Focus visible/نامخفی درست‌اند.
• تمام Actionها Name، Role و State قابل‌فهم دارند.
• Contrast متن، کنترل و Focus سنجیده شده است؛ رنگ تنها حامل معنا نیست.
• Zoom و Reflow بدون ازدست‌رفتن اطلاعات یا Action کار می‌کنند.
• Animation با Reduced motion سازگار و حرکت خودکار قابل توقف است.
• فرم Label، Instruction، Error identification و Recovery دارد.
• Alt، Caption و Transcript بر اساس نقش Media پیاده شده‌اند.

راهنمای طراحی فراگیر وب و WCAG ۲.۲ این معیارها را به Workflow، تست و Governance متصل می‌کند.

Performance budget برای Homepage بسازید

Homepage معمولاً قربانی Hero سنگین، Font زیاد، Tagهای بازاریابی، Chat و Carousel می‌شود. یک امتیاز Lab منفرد کافی نیست؛ داده Field در دستگاه و شبکه واقعی را کنار Lab و RUM ببینید.

مستند Web Vitals سنجش صدک ۷۵ بازدیدها را توصیه می‌کند. تصویر LCP را lazy-load نکنید؛ راهنمای بهینه‌سازی LCP بر کشف زودهنگام منبع و Priority مناسب تأکید دارد. جزئیات Business case، RUM و آزمایش اثر در راهنمای سرعت سایت، UX و تبدیل آمده است.

SEO صفحه اصلی را با نقش Brand و Site هماهنگ کنید

Homepage معمولاً مالک Intent برند و معرفی کلی موجودیت است، نه مقصد تمام Keywordهای خدمات. صفحه تخصصی باید مالک Query تخصصی باشد. تزریق LSI keyword یا چگالی ۱ تا ۲ درصد لازم نیست؛ Message روشن، پوشش طبیعی Category و لینک‌های معنادار مهم‌ترند.

کنترل‌های On-page و فنی

• SEO title متمایز، توصیفی و هماهنگ با نام برند و نقش سایت؛
• یک H1 عمومی که Category/Promise را روشن کند؛ لوگو H1 دوم نسازد؛
• Meta description مفید بدون وعده نمایش ثابت؛
• canonical روی URL اصلی ترجیحی و یکپارچگی HTTP/HTTPS و www/non-www؛
• Navigation و لینک‌های مهم با عنصر a و href واقعی؛
• WebSite/Organization schema مطابق داده قابل مشاهده و واقعی؛
• محتوا و Metadata اصلی در Mobile و Desktop هم‌ارز؛
• بررسی Index، Rendering، Sitemap و نسخه Cache/CDN پس از انتشار.

Google در Link best practices بر Anchor توصیفی و لینک Crawlable تأکید دارد. برای Structured data، Organization markup را در Homepage یا صفحه معرفی واحد توصیه می‌کند؛ فیلدها باید واقعی باشند و نمایش نتیجه ویژه تضمین نمی‌شود. چک کامل یک URL در چک‌لیست سئو داخلی صفحه آمده است.

Personalization و محتوای پویا را با Baseline امن بسازید

نمایش پیام بر اساس شهر، صنعت، وضعیت Login یا Source ممکن است مفید باشد، اما باید یک تجربه Default کامل وجود داشته باشد. اشتباه تشخیص Location، Cache leak، محتوای متفاوت برای Crawler، Consent ناقص و ناتوانی کاربر در تغییر Segment ریسک‌های اصلی‌اند.

• هدف و داده لازم برای Personalization را حداقل کنید.
• Fallback عمومی و کنترل دستی Region/Audience فراهم کنید.
• Cache key و داده حساب‌ها را برای جلوگیری از نشت تست کنید.
• Content parity و دسترسی Crawler را بدون Cloaking حفظ کنید.
• اثر را بر Outcome و Guardrail، نه فقط Click، آزمایش کنید.

اندازه‌گیری موفقیت Homepage را بر اساس Route تعریف کنید

Bounce پایین و Time on page بالا لزوماً موفقیت نیستند. کاربر ممکن است شماره تماس را ببیند و خارج شود، یا به‌دلیل سردرگمی زمان زیادی بماند. در GA4، Bounce rate معکوس Engagement rate است و Engaged session تعریف فنی مشخص دارد؛ راهنمای رسمی Engagement و Bounce در GA4 آن را به Sessionهای بیش از ۱۰ ثانیه، دارای Key event یا دست‌کم دو Page/Screen view متصل می‌کند.

Event dictionary نمونه

رویدادهای home_view، home_route_click، site_search_submit، evidence_open، contact_start و Outcomeهای Backend را با پارامترهای کنترل‌شده تعریف کنید. Query جست‌وجوی حساس، Email، تلفن یا متن فرم را به Analytics نفرستید. Source، Component ID و Destination را با نام‌گذاری پایدار و بدون PII ثبت کنید.

تست کاربردپذیری و A/B تست دو سؤال متفاوت دارند

تست کاربردپذیری می‌پرسد کاربر چرا Route را نمی‌فهمد یا Task را کامل نمی‌کند؛ Experiment می‌پرسد کدام نسخه در شرایط کنترل‌شده Metric تعریف‌شده را تغییر می‌دهد. A/B test جای تحقیق نیست و برای ترافیک کم ممکن است به نمونه کافی نرسد.

Experiment brief حداقلی

Hypothesis، Eligibility، Unit randomization، Primary outcome، Guardrail، MDE، حجم نمونه/مدت، QA، SRM check، Stop rule و Segmentهای ازپیش‌تعریف‌شده را پیش از شروع ثبت کنید. یک تغییر بصری می‌تواند چند Mechanism را همزمان عوض کند؛ ادعای علت را محدود نگه دارید. برای طراحی Study و Severity، راهنمای تست کاربردپذیری را اجرا کنید.

فرایند بازطراحی Homepage از Audit تا Rollout

Big-bang redesign بدون Baseline، Instrumentation و Rollback تشخیص علت تغییر را دشوار می‌کند. اگر معماری بنیادین اشتباه است، بهینه‌سازی رنگ Button کافی نیست؛ اگر معماری درست است، بازطراحی کامل ممکن است ریسک غیرضروری باشد.

Governance مانع تبدیل Homepage به تابلوی اعلانات می‌شود

تیم‌های مختلف می‌خواهند Banner، خبر، کمپین یا لینک خود را در صفحه اصلی قرار دهند. بدون Governance، اولویت کاربر زیر فشار سازمانی از بین می‌رود.

Homepage registry

برای هر Module، Purpose، Audience، Source، Owner، Publish date، Expiry، Priority، Event، States و Approval را ثبت کنید. ماژول بدون Owner یا Expiry نباید دائمی شود. برای محتوای اضطراری، قالب و سطح Severity از پیش تعریف کنید تا Banner بحران به عادت تبدیل نشود.

بومی‌سازی صفحه اصلی برای مخاطب ایران

Homepage فارسی باید واقعیت بازار و عملیات را نشان دهد، نه فقط ترجمه Template انگلیسی.

• زبان معیار و روشن، نیم‌فاصله و «ی/ک» یکدست؛ واژه انگلیسی فقط وقتی برای مخاطب مفید است.
• محدوده خدمت، شهر، ساعات پاسخ، تلفن و کانال Support با وضعیت واقعی و قابل نگهداری.
• قیمت به تومان یا ریال با واحد صریح؛ مقدار Backend و نمایش Frontend با قرارداد.
• شرایط پرداخت، ارسال، مرجوعی یا SLA در مقصد تخصصی و خلاصه تصمیم‌ساز در Homepage.
• نشان و مجوز با Holder، دامنه، تاریخ و لینک Verify؛ نه تصویر ثابت بی‌زمینه.
• تست روی Mobileهای میان‌رده و چند شبکه/ISP در چارچوب مجاز، بدون ارائه روش دورزدن محدودیت.
• RTL/Bidi، تقویم جلالی، ISO/API، اعداد و فونت فارسی در ماتریس QA.
• ابزار خارجی فقط پس از بررسی Eligibility، هزینه ارزی، Export، Privacy و مسیر خروج.

مثال فرضی: شرکت نرم‌افزار لجستیک در ایران

این مثال فرضی است. صفحه فعلی شرکت با شعار «تحول هوشمند در مسیر آینده» شروع می‌شود، سه CTA هم‌وزن دارد و خدمات را بر اساس نام واحدهای داخلی چیده است. داده فروش نشان می‌دهد مدیر عملیات، مدیر فناوری و شرکت حمل کوچک سؤال‌های متفاوتی دارند.

1. Audience: Routeها بر Job واقعی «ردیابی ناوگان»، «مدیریت سفارش» و «یکپارچه‌سازی API» ساخته می‌شوند، نه دپارتمان.
2. Promise: Hero Category را روشن می‌کند و ادعای کاهش هزینه فقط با Case و Baseline نمایش می‌یابد.
3. Evidence: Demo واقعی، محدوده Coverage، روش محاسبه Case و Status سرویس اضافه می‌شود.
4. Route: «دیدن دموی مدیریت سفارش»، «بررسی API» و Login نقش‌های جدا با Hierarchy دارند.
5. Iran: قیمت/واحد، ساعت Support، منطقه سرویس، RTL و اختلال شبکه در QA ثبت می‌شوند.
6. Measure: Route click، Demo qualified، API docs use، Activation و Lead rejection reason سنجیده می‌شوند.

تیم ابتدا Prototype را با کاربران هر Segment تست می‌کند. چون ترافیک Homepage محدود است، پیش از A/B test از Tree test و مصاحبه Task استفاده می‌کند؛ سپس تغییرات با Event plan و Rollback منتشر می‌شوند.

برنامه ۳۰/۶۰/۹۰ روزه

این برنامه تاریخ تحویل تضمینی نیست؛ اندازه سایت، CMS، Design system، تحقیق و وابستگی فنی زمان را تغییر می‌دهند. خروجی هر Gate باید قابل بررسی باشد تا سرعت ظاهری، بدهی پنهان نسازد.

چک‌لیست طراحی صفحه اصلی سایت

استراتژی و محتوا

• نقش Homepage در برابر Landing/Service/Category/App روشن است.
• Audience، Job، Entry context و Routeها شواهد دارند.
• Promise شامل Category/Outcome و Boundary است.
• هر Claim منبع، Scope، تاریخ و Owner دارد.
• هر Section یک سؤال تصمیم و مسیر بعدی را حل می‌کند.

Interaction و دسترس‌پذیری

• Navigation با Keyboard، Touch و Screen reader کار می‌کند.
• یک H1، Landmark، Skip link و Focus قابل مشاهده وجود دارد.
• CTAها Name، Hierarchy، State و Feedback درست دارند.
• Media، Carousel و Motion کنترل و جایگزین دارند.
• Zoom، Reflow، Contrast، Target size و Errorها تست شده‌اند.

فنی، SEO و عملیات

• Mobile/RTL/Bidi، متن بلند و شبکه ضعیف در QA هستند.
• LCP/INP/CLS، Payload و Third party بودجه دارند.
• Title، Meta، canonical، Schema و لینک Crawlable معتبرند.
• Eventها بدون PII و Outcomeها با Backend/CRM متصل‌اند.
• هر Module Owner، Expiry، State و مسیر Rollback دارد.

پرسش‌های متداول

صفحه اصلی سایت چه بخش‌هایی باید داشته باشد؟

فهرست ثابت وجود ندارد. معمولاً Hero، Routeهای اصلی، توضیح Offer، Evidence، ریسک/شرایط و Support مفیدند؛ اما هر بخش فقط وقتی باید باشد که یک سؤال واقعی کاربر را حل کند. Brief و داده Task ترتیب و حضور بخش‌ها را تعیین می‌کنند.

مهم‌ترین عنصر Homepage چیست؟

یک عنصر منفرد برای همه سایت‌ها وجود ندارد. هماهنگی Audience، Promise، Evidence و Route مهم است. Headline روشن بدون مسیر، یا CTA برجسته بدون اعتماد و Destination مناسب، مسئله را حل نمی‌کند.

آیا در صفحه اصلی فقط یک CTA بگذاریم؟

نه لزوماً. Homepage می‌تواند چند Audience و Stage داشته باشد. یک Action اصلی، مسیر ثانویه و Utility actionها را با Hierarchy روشن تفکیک کنید. تعداد را با Task test و Outcome بسنجید، نه قانون «فقط یک دکمه».

چگالی کلمه کلیدی صفحه اصلی چند درصد باشد؟

درصد ثابت معتبری وجود ندارد. Category، خدمت و وعده را طبیعی و دقیق بیان کنید؛ صفحه تخصصی را مالک Query تخصصی نگه دارید. تکرار مصنوعی و LSI keyword تجربه خواندن را خراب می‌کند و معماری محتوا را اصلاح نمی‌کند.

چطور بفهمیم طراحی صفحه اصلی موفق است؟

موفقیت را با Task success، کیفیت Route، Search success، CWV، Outcomeهایی مانند Lead واجد شرایط یا Purchase و Guardrailهایی مانند Complaint و Error بسنجید. Bounce یا زمان ماندن به‌تنهایی کافی نیست؛ Source، Audience و هدف Session را تفکیک کنید.

جمع‌بندی

صفحه اصلی ویترین ثابت نیست؛ لایه هماهنگ‌کننده‌ای است که Audience را به Promise، Evidence و Route مناسب وصل می‌کند. طراحی خوب از Template و ترند شروع نمی‌شود؛ از شواهد Task، مرزبندی نقش صفحه، Message map و مقصدهای سالم شروع می‌شود.

پس از آن، Hierarchy بصری، Navigation، Hero، CTA، Media و Trust باید همین منطق را قابل فهم کنند. Mobile/RTL، Accessibility، Performance و SEO معیار پذیرش‌اند، نه کارهای انتهای پروژه. در نهایت نیز Homepage باید Owner، Baseline، Event، Outcome و چرخه نگهداری داشته باشد؛ وگرنه با هر درخواست داخلی دوباره به تابلوی شلوغی تبدیل می‌شود که کاربر را به‌جای هدایت، متوقف می‌کند.