برای طراحی سایت حرفه‌ای پیش از قرارداد چه چیزهایی را باید مشخص کرد؟
چک‌لیست نوشتن بریف و پیوست قرارداد طراحی سایت: هدف، صفحه‌ها و محتوا، تحویل‌دادنی‌ها، مالکیت و معیار پذیرش قابل‌آزمون؛ بدون قیمت‌سازی و وعدهٔ رتبه.
SE
8 min readSoheil Ebrahimpour
Founder & product engineer
برای طراحی سایت حرفه‌ای، پیش از امضای قرارداد بهتر است پنج چیز روی کاغذ مشخص شود: هدف و معیار موفقیت سایت، فهرست صفحه‌ها و محتوا و مسئول تأمین آن، تحویل‌دادنی‌های دقیق، مالکیت و دسترسی‌ها، و معیار پذیرش قابل‌آزمون. این مقاله یک چک‌لیست تصمیم‌گیری است، نه راهنمای قیمت‌گذاری؛ عددی برای هزینه نمی‌دهد و جای مشاورهٔ حقوقی را هم نمی‌گیرد. هرجا برای جمله‌ای منبع نیامده، آن جمله توصیه یا تجربهٔ عملیاتی عمومی است، نه یافتهٔ پژوهشی.
چرا «بریف مکتوب» از طرح گرافیکی مهم‌تر است؟
یکی از ریسک‌های شناخته‌شده در پروژه‌های سایت این است که دو طرف یک جملهٔ مبهم را متفاوت بفهمند (این یک جمع‌بندی تجربی است و آماری پشتش نیست): «سایت ریسپانسیو»، «سئو شده»، «پنل مدیریت» یا «پشتیبانی». اگر این عبارت‌ها در قرارداد به خروجی قابل‌مشاهده تبدیل نشوند، ممکن است هر طرف صادقانه فکر کند طبق توافق عمل کرده است. بریف خوب همین ابهام‌ها را قبل از اولین طرح می‌بندد.
اگر هنوز مطمئن نیستید که به پروژهٔ مستقل نیاز دارید یا نه، اول بخوانید چرا کسب‌وکارها به وب‌سایت نیاز دارند؛ و اگر موضوع شما یک محصول نرم‌افزاری بزرگ‌تر از سایت معرفی است، مقالهٔ برنامه‌ریزی پروژه پیش از نوشتن کد مکمل همین چک‌لیست است.
۱. هدف و معیار موفقیت را به یک جملهٔ قابل‌اندازه‌گیری برسانید
«سایت مدرن و زیبا» هدف نیست؛ سلیقه است. هدف یعنی کاری که سایت باید برای کسب‌وکار انجام دهد: دریافت درخواست مشاوره، معرفی خدمات به مشتری سازمانی، کاهش تماس‌های تکراری پشتیبانی یا فروش مستقیم. برای هر هدف یک رویداد قابل‌ثبت تعریف کنید (مثلاً ارسال فرم تماس) و تصمیم بگیرید قبل از انتشار، وضعیت فعلی چطور سنجیده می‌شود تا بعداً مقایسه ممکن باشد.
یک نکتهٔ صادقانه: رتبه یا ترافیک را نمی‌شود در قرارداد تحویل تضمین کرد. مستندات Google Search Central می‌گوید هیچ تضمینی برای افزوده‌شدن یک سایت به نمایهٔ آن وجود ندارد، تغییرات سئو ممکن است از چند ساعت تا چند ماه اثر کنند و معمولاً باید چند هفته صبر کرد تا اثر کار بررسی شود. پس بهتر است در قرارداد «خروجی فنی قابل‌بررسی» بنویسید، نه «رتبهٔ اول».
۲. صفحه‌ها، محتوا و مسئول تأمین محتوا
فهرست صفحه‌ها را با نام و هدف هر صفحه بنویسید: خانه، خدمات، نمونه‌کار، وبلاگ، تماس و هر صفحهٔ دیگر. بعد برای هر مورد روشن کنید متن و تصویر را چه کسی تأمین می‌کند، با چه فرمتی، تا چه تاریخی، و اگر تأخیر شد چه اتفاقی برای زمان‌بندی می‌افتد. تأخیر در تحویل محتوا می‌تواند زمان‌بندی را عقب بیندازد؛ بهتر است این موضوع در قرارداد صراحتاً دیده شود.
به چند پرسش ساده هم جواب بدهید: سایت یک‌زبانه است یا چندزبانه؟ سایت قدیمی دارید و آدرس‌هایش باید ریدایرکت شوند؟ چه کسی بعد از تحویل متن‌ها را ویرایش می‌کند؟ پاسخ به این‌ها معمولاً روی انتخاب فناوری و هزینه اثر می‌گذارد؛ برای مقایسهٔ WordPress و توسعهٔ اختصاصی می‌توانید از راهنمای مقایسهٔ WordPress و توسعهٔ اختصاصی کمک بگیرید.
۳. تحویل‌دادنی‌ها را اسم‌به‌اسم بنویسید
جدول زیر نمونه‌ای از چیزهایی است که بهتر است در پیوست قرارداد، یکی‌یکی بیاید. این یک الگوی پیشنهادی است و باید با پروژهٔ شما تطبیق داده شود.
| بخش | چه چیزی باید نوشته شود | نمونهٔ عبارت قابل‌آزمون |
|---|---|---|
| طراحی | صفحه‌ها، حالت‌های موبایل و دسکتاپ، تعداد دور بازبینی | طرح نهایی ۶ صفحه برای موبایل و دسکتاپ، حداکثر دو دور بازبینی |
| پیاده‌سازی | فناوری، قابلیت‌های فرم و مدیریت محتوا | فرم تماس با اعتبارسنجی و ثبت پیام در سامانه |
| محتوا | چه کسی می‌نویسد، چه کسی وارد سایت می‌کند | متن را کارفرما تا تاریخ توافق‌شده می‌دهد |
| انتقال و ریدایرکت | فهرست آدرس‌های قدیمی و مقصد جدید | جدول ریدایرکت پیش از انتشار تأیید شود |
| تحویل فنی | کد، دسترسی‌ها، مستند راه‌اندازی | مخزن کد و مستند اجرا به نام کارفرما تحویل شود |
| پس از انتشار | دورهٔ رفع اشکال و حدود پشتیبانی | رفع اشکال‌های ناشی از پیاده‌سازی تا مدت توافق‌شده |
۴. مالکیت و دسترسی‌ها: چه چیزی باید به نام شما باشد؟
دامنه، حساب میزبانی، مخزن کد، حساب‌های تحلیلی (مثل Search Console)، فایل‌های طراحی و متن و تصویرهای تهیه‌شده را فهرست کنید و کنار هرکدام بنویسید به نام چه کسی ثبت می‌شود و چه زمانی تحویل می‌شود. پیشنهاد عملی (توصیهٔ تجربی، نه الزام منبع‌دار): حساب‌های حیاتی از ابتدا با ایمیل و هویت کارفرما ساخته شوند و تیم اجرایی فقط دسترسی بگیرد، نه اینکه بعداً «انتقال» بدهد.
دربارهٔ مالکیت فکری کد، لایسنس قالب‌ها و افزونه‌های ثالث و محدودیت‌های استفاده از آن‌ها، بند دقیق حقوقی را با وکیل یا مشاور حقوقی بنویسید؛ این مقاله فقط یادآوری می‌کند که این موضوع باید صریحاً در قرارداد باشد.
۵. معیار پذیرش: «تمام شد» یعنی چه؟
معیار پذیرش باید طوری نوشته شود که یک نفر بیرون از تیم هم بتواند آن را آزمود. سه حوزهٔ زیر معمولاً ارزش مکتوب‌شدن دارند.
دسترس‌پذیری
اگر نمی‌خواهید فقط بنویسید «دسترس‌پذیر»، یک نسخه و سطح مشخص از WCAG انتخاب کنید. W3C می‌گوید انتخاب سطح هدف (A، AA یا AAA) در اصل یک تصمیم سیاستی است، و تطابق برای صفحهٔ کامل تعریف می‌شود، نه بخشی از صفحه. در فرایندهایی مثل خرید، همهٔ صفحه‌های مسیر باید با هم مطابق باشند. آزمون معیارها هم ترکیبی از ابزار خودکار و ارزیابی انسانی است؛ پس در قرارداد بنویسید کدام صفحه‌ها و با چه روش آزمونی بررسی می‌شوند. یک هشدار مهم: روش ارزیابی W3C (WCAG-EM 2.0) صریحاً می‌گوید ادعای انطباق WCAG 2 برای کل یک وب‌سایت را نمی‌توان فقط بر پایهٔ ارزیابی چند صفحه و قابلیت منتخب گذاشت؛ پس اگر ادعای انطباق کل سایت می‌خواهید، دامنهٔ بررسی و روش آن را (نه فقط یک نمونهٔ کوچک) در قرارداد بنویسید. برای راهنمای برنامه‌ریزی و درگیرکردن کاربران واقعی، صفحهٔ «Planning and Managing Web Accessibility» از W3C نقطهٔ شروع خوبی است.
سرعت و تجربهٔ کاربر
اگر سرعت برایتان مهم است، به‌جای «سایت سریع» از معیار مشخص استفاده کنید. Google در web.dev برای Core Web Vitals آستانه‌های زیر را معرفی کرده است: LCP تا ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱، و توصیه می‌کند صفحه وقتی «قبول» حساب شود که این سه شاخص در صدک ۷۵ بارگذاری‌ها به هدف برسد. نکتهٔ مهم: این اعداد دادهٔ میدانی (کاربران واقعی) را توصیف می‌کنند؛ پس در قرارداد بنویسید اندازه‌گیری روی چه صفحه‌هایی و با چه ابزاری و پس از چه مدتی از انتشار انجام می‌شود. (استنباط: سایت تازه‌منتشرشده یا کم‌بازدید ممکن است هنوز دادهٔ میدانی کافی نداشته باشد.)
سئوی فنی پایه
سئو را به فهرست کارهای فنیِ قابل‌بررسی تبدیل کنید: عنوان و توضیح یکتا برای هر صفحه، آدرس‌های توصیفی، ریدایرکت از آدرس‌های قدیمی (در صورت وجود سایت قبلی)، جلوگیری از چند آدرس برای یک محتوا و قابل‌دیدن‌بودن صفحه‌ها برای خزندهٔ Google. راهنمای شروع سئوی Google همین موارد را توضیح می‌دهد و می‌گوید ثبت sitemap اجباری نیست، متای keywords را Google استفاده نمی‌کند و تکرار بیش‌ازحد کلمات (keyword stuffing) خلاف سیاست‌های اسپم Google است. بنابراین بند «تکرار کلمهٔ کلیدی در هر پاراگراف» نباید به‌عنوان تعهد در قرارداد بیاید.
۶. روند بازبینی و تغییرات
مشخص کنید چه کسی از طرف شما تصمیم‌گیرنده است، بازخورد چگونه جمع می‌شود (یک فهرست واحد، نه پیام‌های پراکنده)، هر دور بازبینی چند روز زمان دارد و درخواست خارج از محدوده چگونه ثبت و قیمت‌گذاری می‌شود. اگر محدودهٔ پروژه روشن باشد، تغییر بد نیست؛ فقط باید دیده و تصمیم‌گیری شود. اگر نیاز دارید پروژهٔ در حال اجرا را ارزیابی کنید، خدمت ممیزی مهندسی یک مسیر ممکن است؛ این خدمت طبق توضیح صفحه‌اش معماری، کد، امنیت و زیرساخت محصول را بررسی می‌کند.
نشانه‌های هشدار در پیشنهادهای مبهم
- عبارت‌هایی مثل «طراحی مدرن» یا «سئو شده» بدون خروجی قابل‌آزمون.
- نبود فهرست صفحه‌ها و تعداد دور بازبینی.
- مبهم‌بودن اینکه دامنه، هاست و کد به نام چه کسی است.
- وعدهٔ رتبه یا ترافیک مشخص در تاریخ مشخص.
- نبود تعریف مرحلهٔ تحویل و دورهٔ رفع اشکال.
چک‌لیست نهایی پیش از امضا
- هدف سایت و یک رویداد قابل‌سنجش برای هر هدف نوشته شده است.
- فهرست صفحه‌ها، مسئول و موعد تأمین محتوا مشخص است.
- تحویل‌دادنی‌ها اسم‌به‌اسم و قابل‌آزمون آمده‌اند.
- مالکیت دامنه، میزبانی، مخزن و حساب‌های تحلیلی روشن است.
- معیار پذیرش برای دسترس‌پذیری، سرعت و سئوی فنی تعریف شده است.
- روند بازبینی، تغییرات و پشتیبانی پس از تحویل مکتوب است.
- بندهای حقوقی توسط مشاور حقوقی بازبینی شده‌اند.
اگر می‌خواهید این چک‌لیست را روی پروژهٔ خودتان پیاده کنید، می‌توانید با تخمین هزینهٔ پروژه یک برآورد اولیه ببینید یا در صفحهٔ شروع پروژه مسئله و محدودیت‌هایتان را بنویسید تا بررسی شود؛ ارسال آن فرم، طبق توضیح خود صفحه، تعهد به شروع پروژه نیست.
منابع و مراجع
- Planning and Managing Accessibility (Planning and Policies Overview) — W3C Web Accessibility Initiative.
- Understanding Conformance (WCAG 2.2) — W3C WAI.
- Search Engine Optimization (SEO) Starter Guide — Google Search Central.
- Web Vitals — web.dev (Google)، آخرین به‌روزرسانی ۳۱ اکتبر ۲۰۲۴.
- WCAG Evaluation Methodology (WCAG-EM) 2.0 — W3C Group Note، ۲۳ ژوئیهٔ ۲۰۲۶.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
