بریف طراحی سایت، شرح نیاز شما پیش از گرفتن قیمت است: سایت برای چه مخاطبی ساخته می‌شود، چه کاری باید انجام دهد، چه خروجی‌هایی لازم دارد و با چه محدودیت‌هایی روبه‌روست. برای نوشتنش لازم نیست برنامه‌نویسی بدانید. هدف این است که مجری به‌جای حدس‌زدن خواسته‌های شما، درباره یک پروژه روشن پیشنهاد بدهد.
نکات کلیدی
نکات کلیدی: هدف تجاری را از معیار تحویل جدا کنید؛ امکانات ضروری را همراه با موارد خارج از محدوده بنویسید؛ مسئول محتوا، حساب‌ها و هزینه‌های تمدید را مشخص کنید؛ و همان بریف را برای مقایسه پیشنهاد مجریان بفرستید.
بریف خوب، نیاز را روشن می‌کند
«یک سایت مدرن و حرفه‌ای می‌خواهیم» نقطه شروع گفت‌وگوست، اما برای برآورد کافی نیست. «مشتری خدمات ما را بشناسد، نمونه پروژه مرتبط را ببیند و درخواست بازدید ثبت کند» به طراح می‌گوید سایت باید چه مسیری را کامل کند.
بریف اولیه می‌تواند کوتاه باشد و در جلسه مشاوره تکمیل شود. الگوی Digital Culture Network، به‌روزشده در آوریل ۲۰۲۶ هم بر شرح روشن و مختصر هدف، محدوده، زمان، امکانات و معیار انتخاب مجری تأکید دارد. لازم نیست از ابتدا تمام راه‌حل‌های فنی را تعیین کنید؛ موارد نامشخص را با «نیازمند پیشنهاد مجری» علامت بزنید.
مسیر تبدیل یک ایده به پیشنهاد قابل‌مقایسه
مسئله و مخاطب
مشخص کنید سایت قرار است مشکل چه کسی را حل کند.
اقدام موردانتظار
خرید، درخواست مشاوره یا ارسال مشخصات پروژه را تعیین کنید.
محدوده و مسئولیت
صفحات، امکانات، محتوا و موارد خارج از نسخه اول را فهرست کنید.
ملاک تحویل
برای هر خواسته، روش بررسی و تأیید خروجی را بنویسید.
سند
نقش آن
سند
بریف کارفرما
نقش آن
بیان مسئله، اولویت‌ها و محدودیت‌های پروژه
سند
پیشنهاد مجری
نقش آن
شرح راهکار، خروجی‌ها، فرض‌های برآورد، هزینه و زمان
سند
قرارداد و پیوست اجرایی
نقش آن
ثبت محدوده و تعهدات توافق‌شده
بریف به‌تنهایی جای قرارداد را نمی‌گیرد. نتیجه جلسه‌ها و تغییرات مهم باید در نسخه به‌روز شرح پروژه و توافق نهایی هم منعکس شوند.
هدف سایت و مسیر تبدیل کاربر به مشتری
هدف را به یک اقدام مشخص وصل کنید: خرید، رزرو، درخواست مشاوره یا ارسال اطلاعات پروژه. سپس توضیح دهید چه کسی این اقدام را انجام می‌دهد و پیش از آن به چه اطلاعاتی نیاز دارد.
برای شرکت خدمات شبکه، مدیر فناوری اطلاعات ممکن است جزئیات فنی و سابقه اجرا بخواهد، درحالی‌که مدیرعامل درباره زمان، هزینه و مسئولیت پشتیبانی تصمیم می‌گیرد. پرسش‌های تماس‌های فروش و گفت‌وگو با مشتریان به شناخت این نیازها کمک می‌کنند.
نتیجه تجاری و تحویل فنی را جدا بنویسید
«دریافت درخواست‌های مرتبط‌تر» هدف تجاری است؛ «ثبت درست درخواست و رسیدن اعلان به مسئول فروش» معیار تحویل فنی. هر دو مهم‌اند، اما یکسان نیستند. نتیجه فروش به ورودی سایت، پیشنهاد شما، قیمت و پیگیری تیم فروش هم ارتباط دارد.
از ابتدا مشخص کنید چه چیزی را می‌سنجید. ثبت موفق فرم، کلیک روی شماره تماس و تماس برقرارشده سه اتفاق متفاوت‌اند. در راهنمای تعیین شاخص‌های عملکرد GOV.UK، انتخاب شاخص از هدف خدمت آغاز می‌شود؛ برای سایت تجاری هم شاخص باید معنای روشنی داشته باشد.
مسیر درخواست را بعد از ارسال فرم ادامه دهید
فرم تماس وقتی کاربردی است که درخواست گم نشود. مشخص کنید کجا ذخیره می‌شود، چه کسی مطلع می‌شود، مسئول پیگیری کیست و در صورت نرسیدن اعلان چه راهی برای دیدن درخواست وجود دارد.
برای تعریف «درخواست مرتبط»، از نیاز واقعی فروش استفاده کنید؛ مثلاً نوع خدمت یا محدوده جغرافیایی. اطلاعات اضافه را صرفاً برای کامل‌ترشدن فرم نگیرید. اصل کاربردی در راهنمای ساختار فرم GOV.UK این است که برای هر داده، دلیل دریافت و شیوه استفاده از آن روشن باشد.
صفحات، امکانات و محتوا را قابل‌برآورد کنید
فهرست صفحات را بنویسید، اما تعداد صفحات را از تعداد طرح‌های مستقل جدا کنید. ده صفحه خدمت با ساختار مشترک، با ده صفحه دارای طراحی متفاوت یک محدوده کار نیست. تعداد صفحات یا محصولات اولیه‌ای که مجری باید وارد کند نیز موضوع جداگانه‌ای است.
تعداد صفحه با تعداد طراحی فرق دارد
برای امکانات، رفتار موردانتظار را توضیح دهید:
عبارت مبهم
شرح قابل‌بررسی
عبارت مبهم
فرم پیشرفته
شرح قابل‌بررسی
دریافت نوع خدمت، اطلاعات تماس و در صورت نیاز فایل پیوست؛ ذخیره درخواست و ارسال اعلان
عبارت مبهم
مدیریت آسان
شرح قابل‌بررسی
کارشناس شرکت بتواند صفحه خدمت و نمونه پروژه را بدون برنامه‌نویسی اضافه کند
عبارت مبهم
اتصال به CRM
شرح قابل‌بررسی
ثبت درخواست در نرم‌افزار مشخص، با تعیین اطلاعات ارسالی و رفتار هنگام خطا
عبارت مبهم
محتوای کامل
شرح قابل‌بررسی
تعیین مسئول نگارش، تأیید اطلاعات، آماده‌سازی تصاویر و ورود تعداد مشخصی صفحه
امکانات را در سه گروه «ضروری برای شروع»، «مرحله بعد» و «نیازمند بررسی» قرار دهید. برای یک سایت خدماتی، معرفی خدمات و ثبت درخواست می‌تواند ضروری باشد؛ پنل مشتریان را می‌توان جداگانه بررسی کرد.
اولویت امکانات را قبل از برآورد مشخص کنید
ضروری برای شروع
چیزی که بدون آن مسیر اصلی کاربر یا کسب‌وکار ناقص می‌ماند.
مرحله بعد
قابلیتی که می‌توان پس از راه‌اندازی و دریافت بازخورد ساخت.
نیازمند بررسی
اتصال یا قابلیتی که هزینه و امکان اجرا هنوز روشن نیست.
مسئولیت محتوا و نمونه‌های بصری
تهیه اطلاعات، نگارش متن، آماده‌سازی عکس و ورود محتوا چهار کار متفاوت‌اند. برای هر کدام مسئول، مقدار و موعد تحویل تعیین کنید. مثلاً کارفرما اطلاعات فنی را تأیید کند، نویسنده متن را آماده کند و مجری تعداد توافق‌شده‌ای صفحه را وارد سایت کند.
لینک سایت‌های موردعلاقه را همراه با دلیل انتخاب بفرستید: «مسیر خدمات واضح است» یا «عکس پروژه‌ها خوب دیده می‌شود». بخش‌هایی را که نمی‌پسندید هم مشخص کنید تا معرفی یک نمونه، تأیید تمام ظاهر و امکانات آن تلقی نشود.
اتصال به نرم‌افزار را پیش از قیمت قطعی بررسی کنید
نام نرم‌افزار حسابداری، انبار یا CRM و اطلاعات موجود درباره امکان اتصال را ارائه کنید. سپس بخواهید مشخص شود چه داده‌ای، در چه جهتی و با چه تناوبی منتقل خواهد شد.
در اتصال‌های مهم، حالت خطا را هم توضیح دهید؛ مثلاً اگر CRM در دسترس نبود، درخواست در سایت باقی بماند و قابل پیگیری باشد. هزینه اشتراک، دسترسی فنی یا همکاری شرکت ارائه‌دهنده نرم‌افزار نیز ممکن است جزو وابستگی‌های پروژه باشد.
کیفیت سایت را با معیار قابل‌آزمایش تعریف کنید
عبارت‌هایی مانند «سریع»، «امن» یا «سئوشده» باید به خروجی مشخص تبدیل شوند. سطح جزئیات را متناسب با پروژه نگه دارید؛ بریف یک سایت شرکتی نباید بی‌دلیل به سند پیچیده مهندسی تبدیل شود.
سه آزمون واقعی، بهتر از سه صفت تبلیغاتی
سرعت
صفحات واقعی را با شرایط آزمون مشخص بسنجید؛ فقط یک امتیاز نخواهید.
فرم و پیگیری
درخواست آزمایشی را ارسال و ثبت، اعلان و امکان پیگیری آن را بررسی کنید.
کار با موبایل
مسیر اصلی، خطاهای فرم و استفاده با صفحه‌کلید را آزمایش کنید.
سرعت؛ صفحه واقعی و شرایط آزمون مشخص
از مجری بخواهید صفحات منتخب را با متن، تصاویر و سرویس‌های واقعی آزمایش کند و شرایط آزمون را ثبت کند. امتیاز یک صفحه خالی یا یک بار اجرای تست، تصویر کاملی از تجربه مشتریان نمی‌دهد.
طبق راهنمای Web Vitals، آزمون آزمایشگاهی در زمان توسعه و داده کاربران واقعی دو کاربرد متفاوت دارند. اهداف توصیه‌شده برای داده واقعی شامل LCP حداکثر ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱، در صدک ۷۵ و با تفکیک موبایل و دسکتاپ است. نمره Lighthouse به‌تنهایی اثبات نمی‌کند این اهداف برای کاربران واقعی محقق شده‌اند.
برای سایت تازه یا کم‌بازدید ممکن است داده عمومی کافی موجود نباشد. روش بررسی پیش از انتشار و برنامه پایش پس از انتشار را جدا توافق کنید.
استفاده‌پذیری و دسترس‌پذیری
به «نمایش درست در موبایل» اکتفا نکنید. مسیر اصلی را با صفحه‌کلید، بزرگ‌کردن متن، خطای فرم و استفاده از دکمه‌ها آزمایش کنید؛ کاربر باید بداند هر فیلد چیست و خطا را چطور اصلاح کند.
اگر انطباق با استاندارد WCAG درخواست می‌کنید، نسخه، سطح و دامنه بررسی را مشخص کنید. بررسی چند مورد پایه به معنای انطباق کامل با WCAG نیست. W3C تأکید می‌کند ابزارهای خودکار همه جنبه‌های دسترس‌پذیری را بررسی نمی‌کنند و ارزیابی انسانی هم لازم است.
فرم‌ها و فایل‌های مشتریان
در بریف بنویسید چه اطلاعاتی واقعاً لازم است، چه کسانی آن را می‌بینند و مدت نگهداری و روش حذف چگونه تعیین می‌شود. برای همه پروژه‌ها یک مدت ثابت و خودکار مانند «۳۰ روز» فرض نکنید؛ نیاز عملیاتی و الزامات مربوط به همان کسب‌وکار باید بررسی شوند.
اگر پیوست لازم دارید، نوع و حداکثر حجم فایل و سطح دسترسی به آن را مشخص کنید. راهنمای امنیت بارگذاری فایل OWASP بر کنترل نوع و حجم فایل و محل نگهداری مناسب تأکید دارد. به‌عنوان مثال، فایل ارسالی مشتری نباید صرفاً به دلیل ارسال در فرم، به یک لینک عمومی قابل مشاهده برای همه تبدیل شود.
سئو و دیده‌شدن در جست‌وجوی هوش مصنوعی
محدوده سئوی اولیه را روشن کنید: امکان ویرایش عنوان و توضیحات، ساختار آدرس‌ها، نقشه سایت، لینک‌های داخلی و بررسی اجازه ایندکس صفحات عمومی. تحقیق کلمات کلیدی، نگارش محتوا و فعالیت مستمر سئو را جداگانه مشخص کنید.
اگر پیشنهادی با عنوان GEO یا بهینه‌سازی جست‌وجوی هوش مصنوعی دریافت کردید، خروجی دقیق آن را بخواهید. طبق مستند رسمی گوگل درباره AI Overviews و AI Mode، فایل یا نشانه‌گذاری ویژه‌ای برای حضور در این قابلیت‌ها لازم نیست و رعایت الزامات هم نمایش را تضمین نمی‌کند. این توضیح درباره قابلیت‌های گوگل است و نباید به همه ابزارهای هوش مصنوعی تعمیم داده شود.
بودجه، مالکیت و ادامه همکاری را شفاف کنید
بودجه اولیه می‌تواند یک بازه باشد. مشخص کنید ساخت، محتوا، مهاجرت اطلاعات و خدمات جانبی داخل آن هستند یا جداگانه برآورد می‌شوند. برای شناخت عوامل هزینه، راهنمای هزینه طراحی سایت را ببینید.
از مجری جدول سرویس‌های دورهای بخواهید: نام سرویس، مسئول پرداخت، موعد تمدید، مبنای هزینه و اثر تمدیدنکردن آن. پایان اشتراک ممکن است روی به‌روزرسانی، پشتیبانی یا خود قابلیت اثر بگذارد؛ نتیجه برای همه ابزارها یکسان نیست.
دسترسی به حساب، مالکیت دارایی و مجوز استفاده از آن یک مفهوم نیستند. مشخص کنید دامنه و حساب‌های اصلی تحت کنترل چه کسی باشند، چه فایل‌هایی تحویل شوند و شرایط استفاده از قالب، فونت، تصویر یا ابزارهای ثالث چیست. رمزها را در بریف ننویسید؛ مسیر انتقال امن دسترسی‌ها را جدا تعیین کنید.
این نگرانی در پرسش‌های واقعی خریداران هم دیده می‌شود. در یک گفت‌وگوی عمومی کسب‌وکارهای کوچک، کاربر پیش از قبول پیشنهاد ماهانه می‌پرسد اگر نتواند پرداخت را ادامه دهد، دسترسی به سایتش چه می‌شود؛ این یک تجربه موردی است، اما سؤال مهمی برای بریف و قرارداد شماست.
در صورت تغییر مجری، شیوه خروجی‌گرفتن از محتوا و داده، انتقال حساب‌ها و ادامه استفاده از سرویس‌ها باید روشن باشد. نمونه ابزار بریف Still Matter نیز حساب‌ها، فایل‌ها، مجوزها، بازیابی و هزینه‌های دورهای را جدا بررسی می‌کند.
زمان‌بندی، تغییر درخواست و بازطراحی
موعد مطلوب را از موعد غیرقابل‌تغییر جدا کنید و بنویسید به چه چیزی وابسته است. مسئول تأیید نهایی و زمان پاسخ‌دادن کارفرما به بازبینی‌ها نیز باید مشخص باشد.
تعداد دورهای اصلاح و تفاوت «رفع مغایرت با توافق» با «درخواست قابلیت جدید» را روشن کنید. درخواست جدید باید پیش از اجرا از نظر هزینه و زمان بررسی و تأیید شود.
اگر سایت فعلی دارید، صفحات مهم، داده‌ها و قابلیت‌های قابل حفظ را فهرست کنید. در صورت تغییر آدرس‌ها، تعیین مقصد مرتبط، اجرای انتقال و پایش پس از انتشار باید جزو محدوده باشد؛ راهنمای انتقال سایت گوگل نیز بر همین برنامه‌ریزی تأکید دارد.
نمونه تکمیل‌شده بریف برای شرکت خدماتی
این نمونه فرضی و آموزشی است؛ پروژه یا تعهد واقعی ایده‌نو محسوب نمی‌شود. مقدارها و شرایط آن را با نیاز کسب‌وکار خودتان جایگزین کنید.
بخش
شرح نمونه
بخش
کسب‌وکار و مخاطب
شرح نمونه
شرکت خدمات شبکه؛ مخاطب اصلی مدیران فناوری اطلاعات و مدیران تصمیم‌گیر سازمان‌ها
بخش
مسئله و هدف
شرح نمونه
خدمات و نمونه پروژه‌ها در سایت فعلی روشن نیست؛ هدف، دریافت درخواست‌های مرتبط با خدمات و حوزه پوشش شرکت است
بخش
نسخه اول
شرح نمونه
صفحه اصلی، چهار صفحه خدمت با ساختار مشترک، نمونه پروژه‌ها، درباره شرکت و تماس؛ طرح‌های مستقل پیش از برآورد نهایی فهرست شوند
بخش
فرم درخواست
شرح نمونه
نوع خدمت و اطلاعات تماس ضروری؛ پیوست اختیاری با نوع، حجم و دسترسی توافق‌شده
بخش
مسیر رسیدگی
شرح نمونه
ذخیره درخواست در پنل، ارسال اعلان به مسئول فروش و امکان پیگیری در صورت نرسیدن اعلان
بخش
محتوا
شرح نمونه
اطلاعات فنی و عکس‌های دارای مجوز با شرکت؛ نگارش، آماده‌سازی و ورود محتوا با مقدار و مسئول جداگانه برآورد شود
بخش
خارج از نسخه اول
شرح نمونه
پنل مشتریان؛ اتصال CRM تا زمان بررسی امکان‌پذیری، جزو محدوده قطعی نیست
بخش
کیفیت و سنجش
شرح نمونه
آزمایش مسیر درخواست در موبایل و با صفحه‌کلید؛ بررسی عملکرد صفحات واقعی؛ ثبت رویداد موفقیت فرم
بخش
حساب‌ها و هزینه‌ها
شرح نمونه
کنترل حساب‌های اصلی، فایل‌های تحویلی، محدودیت مجوزها و هزینه سرویس‌های دورهای مشخص شود
بخش
موارد باقی‌مانده
شرح نمونه
بازه بودجه، موعد انتشار، مسئول تأیید، دورهای بازبینی و محدوده پشتیبانی تکمیل شود
تبدیل خواسته‌ها به معیار تحویل
جدول زیر نمونه توافق اجرایی است، نه استاندارد اجباری برای تمام پروژه‌ها. شرایط و موعد بررسی آن باید با مجری نهایی شود.
خواسته
شاهد قابل‌بررسی هنگام تحویل
خواسته
درخواست‌ها گم نشوند
شاهد قابل‌بررسی هنگام تحویل
ارسال درخواست آزمایشی، مشاهده ثبت آن و دریافت اعلان؛ بررسی مسیر پیگیری در حالت خطا
خواسته
تیم شرکت محتوا را مدیریت کند
شاهد قابل‌بررسی هنگام تحویل
کارشناس شرکت پس از آموزش، یک نمونه پروژه را اضافه و ویرایش کند
خواسته
محتوای اولیه کامل باشد
شاهد قابل‌بررسی هنگام تحویل
صفحات توافق‌شده با متن و تصویر نهایی، بدون محتوای آزمایشی بررسی شوند
خواسته
اندازه‌گیری درست باشد
شاهد قابل‌بررسی هنگام تحویل
ثبت رویداد پس از موفقیت واقعی فرم، بدون ثبت همان درخواست به‌صورت چند رویداد تکراری
خواسته
نسخه موبایل قابل استفاده باشد
شاهد قابل‌بررسی هنگام تحویل
تکمیل مسیر اصلی روی دستگاه‌ها یا مرورگرهای توافق‌شده و بررسی خطاهای فرم
خواسته
ادامه کار ممکن باشد
شاهد قابل‌بررسی هنگام تحویل
دریافت دسترسی‌ها، مستندات و خروجی‌های توافق‌شده و تعیین مسئول نسخه پشتیبان و بازیابی
مقایسه پیشنهادها و آماده‌کردن بریف اولیه
بریف یکسان را برای مجری‌های منتخب بفرستید و هر پیشنهاد را در برابر همان نیازها بررسی کنید. برای هر مورد وضعیت «شامل می‌شود»، «هزینه جدا دارد»، «نیازمند بررسی» یا «پاسخ روشن ندارد» ثبت کنید.
برای هر خدمت، یک وضعیت روشن ثبت کنید
فقط مبلغ نهایی را کنار هم نگذارید؛ خروجی، فرض‌های برآورد، مسئولیت محتوا، تعداد طرح‌های مستقل، هزینه‌های دورهای، آموزش و خدمات پس از انتشار را هم مقایسه کنید. گران‌تر یا ارزان‌تر بودن به‌تنهایی نشان نمی‌دهد پیشنهاد برای نیاز شما مناسب‌تر است.
برای آماده‌کردن نسخه اولیه، از این برگه استفاده کنید:
بخش بریف
اطلاعاتی که باید وارد کنید
بخش بریف
هدف و مخاطب
اطلاعاتی که باید وارد کنید
مسئله فعلی، مخاطب اصلی و اقدام موردانتظار او
بخش بریف
محدوده
اطلاعاتی که باید وارد کنید
صفحات، امکانات ضروری، مرحله بعد و موارد خارج از کار
بخش بریف
محتوا و ظاهر
اطلاعاتی که باید وارد کنید
محتوای آماده، مسئول تهیه و ورود، نمونه‌های بصری همراه با دلیل انتخاب
بخش بریف
اتصال‌ها و محدودیت‌ها
اطلاعاتی که باید وارد کنید
نرم‌افزارهای فعلی، موارد نیازمند بررسی و شرایط غیرقابل‌تغییر
بخش بریف
بودجه و زمان
اطلاعاتی که باید وارد کنید
بازه هزینه، پوشش خدمات، موعد مطلوب و وابستگی‌ها
بخش بریف
کیفیت و تحویل
اطلاعاتی که باید وارد کنید
مسیرهای قابل‌آزمایش، حساب‌ها، فایل‌ها، آموزش و پشتیبانی
بخش بریف
تصمیم‌گیری
اطلاعاتی که باید وارد کنید
مسئول تأیید، روش بازبینی و بررسی تغییرات
برای شروع گفت‌وگو درباره طراحی سایت در ایده‌نو، لازم نیست پاسخ تمام موضوعات فنی را بدانید. نیازهای قطعی را بنویسید، موارد مبهم را مشخص کنید و از مجری راهکار بخواهید. بریف آماده، متنی است که کمک کند دو طرف درباره خروجی یک پروژه مشخص صحبت کنند و هنگام برآورد و تحویل، مرجع مشترکی داشته باشند.
