قبل از سفارش طراحی سایت چه اطلاعاتی آماده کنیم؟

برای شروع طراحی سایت لازم نیست همهٔ جواب‌ها را داشته باشید. اما باید معلوم باشد چه چیزی را می‌دانیم و دربارهٔ چه چیزی هنوز تصمیم نگرفته‌ایم. بریف خوب همین مرز را روشن می‌کند و اجازه نمی‌دهد اختلاف انتظار تا روز تحویل پنهان بماند. ## سایت قرار است چه کاری را ممکن کند؟ یک اقدام اصلی انتخاب کنید: معرفی خدمات، ثبت درخواست، رزرو یا فروش. بعد توضیح دهید مخاطب پیش از آن تصمیم به چه اطلاعاتی نیاز دارد. اگر چند مخاطب متفاوت دارید، آن‌ها را جدا بنویسید. ممکن است مشتری تازه دنبال شناخت خدمت باشد و مشتری فعلی دنبال پشتیبانی؛ یک تیتر نمی‌تواند بدون تصمیم روشن هر دو مسیر را هدایت کند. برای نمونهٔ فرضی، سایت یک استودیوی معماری باید کمک کند بازدیدکننده نوع پروژه‌ها، روش همکاری و راه تماس را بفهمد. این صورت مسئله از «سایتی شیک و مدرن» قابل استفاده‌تر است، چون می‌توان دربارهٔ ترتیب اطلاعاتش بحث کرد.

## فهرست صفحه‌ها را با محتوای واقعی بسازید خدمات، پروژه‌ها، معرفی، تماس و هر صفحهٔ دیگری که لازم دارید بنویسید؛ اما فقط به نام صفحه اکتفا نکنید. یک نمونهٔ واقعی از متن، تصویر و اطلاعات هر نوع صفحه آماده کنید. اگر محتوایی هنوز وجود ندارد، مسئول تولید و زمان آماده‌شدنش را مشخص کنید. برای سایت چندزبانه، از ابتدا روشن کنید کدام صفحه‌ها ترجمه می‌شوند، چه کسی ترجمه را تأیید می‌کند و نسخهٔ ناقص چه رفتاری دارد. نمایش متن انگلیسی در صفحهٔ فارسی جای ترجمهٔ کامل را نمی‌گیرد. جهت نوشتار و طول متفاوت متن‌ها هم باید در طراحی بررسی شود. ## مسیرهای مهم و حالت‌های خطا را ثبت کنید توضیح دهید یک کاربر چطور از ورود به سایت به اقدام اصلی می‌رسد. اگر فرم دارید، فیلدهای ضروری، پیام خطا، پیام موفقیت و مقصد درخواست را مشخص کنید. فرم زیبا بدون مسیر دریافت و پیگیری، راه ارتباط قابل اتکایی نیست. از تیم بخواهید حالت‌های بارگذاری، خالی، نبود نتیجه و قطع ارتباط را هم در دامنه حساب کند. [راهنمای فرم‌های W3C](https://www.w3.org/WAI/tutorials/forms/) برای بررسی برچسب‌ها، دستورالعمل‌ها و بازخورد فرم مرجع مناسبی است.

## دسترس‌پذیری را از بریف حذف نکنیم [ارزیابی WebAIM در فوریهٔ ۲۰۲۶](https://webaim.org/projects/million/) یک میلیون صفحهٔ اصلی پربازدید را با ابزار WAVE بررسی کرده است. نمودار، سه خطای قابل شناسایی را نشان می‌دهد. این شاهدی برای اهمیت بررسی واقعی است، نه دلیلی برای پیچیده‌ترکردن بی‌هدف سایت. A: کنتراست کم؛ B: نبود متن جایگزین؛ C: نبود برچسب فرم. این دسته‌ها هم‌پوشانی دارند. بررسی خودکار همهٔ موانع را نمی‌یابد و تأیید انطباق کامل با WCAG نیست؛ این داده، ارزیابی سایت شما نیست.

## طراحی، توسعه و محتوا را جدا توافق کنید پیشنهاد همکاری باید بگوید خروجی طراحی چیست و چه کسی آن را پیاده می‌کند. نوشتن متن، ترجمه، خرید مجوز تصویر، اتصال پرداخت و مهاجرت اطلاعات را خودکار جزو طراحی فرض نکنید. اگر اجرای فنی هم در پروژه است، محدودهٔ آن و مسئول نگهداری بعدی روشن باشد. دسترسی‌های لازم را فهرست کنید، اما رمزها را داخل بریف نگذارید. برای تحویل دسترسی از مسیر امن و حساب‌های مناسب استفاده کنید. تیم طراحی برای فهم مسئله همیشه به دسترسی مدیریتی کامل نیاز ندارد. ## مهلت واقعی و تصمیم‌گیر را بنویسید تاریخ رونمایی را از تاریخ تحویل طراحی جدا کنید. بعد از طراحی، زمان اجرا، ورود محتوا و بررسی نهایی هم لازم است. تأخیر در دریافت محتوا یا تأییدها می‌تواند روی زمان‌بندی اثر بگذارد؛ این وابستگی‌ها را از ابتدا مشخص کنید. یک نفر مسئول جمع‌بندی بازخوردها باشد. نظرهای متناقض چند نفر، اگر بدون تصمیم واحد به طراح برسند، زمان را صرف رفت‌وبرگشت می‌کنند. معیار تأیید را به هدف سایت و نیاز مخاطب وصل کنید. ## بریف یک‌صفحه‌ای شما در یک سند کوتاه این موارد را ثبت کنید: هدف اصلی، مخاطب، صفحه‌های لازم، یک نمونهٔ واقعی محتوا، مسیر تماس یا خرید، زبان‌ها، محدودیت فنی، محدودهٔ همکاری، زمان و مسئول تأیید. هر مورد نامعلوم را با برچسب «نیاز به تصمیم» نگه دارید. با همین اطلاعات می‌شود دربارهٔ [طراحی سایت](/services/website-design) برآورد دقیق‌تری داشت. اگر فقط یک پیشنهاد تبلیغاتی و یک اقدام دارید، شاید [لندینگ‌پیج](/services/landing-page-design) نقطهٔ شروع مناسب‌تری باشد. انتخاب باید از نیاز بیاید، نه از تعداد صفحه‌هایی که می‌توان ساخت.

• بریف طراحی سایت
• سفارش طراحی سایت
• محتوای سایت