مقایسه پروپوزال طراحی سایت؛ تفاوت دو پیشنهاد قیمت را چطور بفهمیم؟
دو پیشنهاد طراحی سایت را چگونه مقایسه کنیم؟ از تعداد قالب‌ها و مسئولیت محتوا تا آزمون، تحویل و هزینه‌های ادامهٔ کار؛ با جدول عملی و یک مثال فرضی.
دو پیشنهاد برای طراحی سایت شرکتی گرفته‌اید؛ هر دو «طراحی اختصاصی، نسخهٔ موبایل و سئوی پایه» را قول می‌دهند، اما مبلغ و زمان تحویلشان فرق دارد. از روی این سه عبارت نمی‌توان فهمید کدام پیشنهاد برای شما مناسب‌تر است. ممکن است یکی فقط طراحی و اجرای چند صفحه را پوشش دهد و دیگری بازنویسی محتوا، انتقال آدرس‌های قبلی، ورود محصولات و آموزش تیم را هم در نظر گرفته باشد.
برای مقایسه پروپوزال طراحی سایت، ابتدا خروجی مورد انتظار را یکسان کنید. بعد، دامنهٔ کار، مسئول هر فعالیت، معیار تحویل، وابستگی‌های زمانی و هزینه‌های ادامهٔ کار را کنار هم بگذارید. پیشنهاد ارزان‌تر می‌تواند انتخاب خوبی باشد، اگر کارهای حذف‌شده واقعاً برای شما ضروری نباشند یا تیم خودتان بتواند انجامشان دهد.
قبل از مقایسه، یک صورت‌مسئلهٔ مشترک بنویسید
هر دو تیم باید بدانند سایت برای چه مخاطبی ساخته می‌شود و بازدیدکننده قرار است چه کاری انجام دهد: بررسی یک خدمت، دریافت کاتالوگ، انتخاب محصول یا ارسال درخواست قیمت. فهرست صفحات ضروری، زبان‌ها، محتوای آماده، اتصال‌های مورد نیاز و محدودیت زمان را در یک صفحه بنویسید. موارد نامشخص را هم با برچسب «نیازمند بررسی» مشخص کنید.
مثلاً «سایت صنعتی دوزبانه با معرفی سه خانوادهٔ محصول و فرم درخواست قیمت» از «یک سایت مدرن» قابل قیمت‌گذاری‌تر است. هنوز لازم نیست راه‌حل فنی را تجویز کنید؛ این شرح کمک می‌کند بفهمید تفاوت پیشنهادها از توصیهٔ متفاوت می‌آید یا از برداشت متفاوت دربارهٔ نیاز شما.
۱. تعداد صفحات را از تعداد قالب‌های طراحی جدا کنید
«۲۰ صفحه» ممکن است یعنی ۲۰ محتوای محصول در یک قالب مشترک؛ «۶ قالب» ممکن است شامل صفحهٔ اصلی، خدمت، محصول، پروژه، مقاله و تماس باشد. این دو عدد واحد یکسانی ندارند. از هر تیم فهرست قالب‌های متمایز، تعداد محتوایی که وارد می‌کند و بخش‌های قابل ویرایش را بخواهید.
برای طراحی نیز روشن کنید چه چیزی ارائه می‌شود: ساختار اطلاعات، وایرفریم، طرح نهایی، حالت موبایل و وضعیت‌های خطا یا خالی؟ تعداد دور بازبینی و مسئول جمع‌کردن بازخوردها را بنویسید. «اصلاحات نامحدود» بدون تعریف مرحله و مرز تغییر، ابزار خوبی برای برنامه‌ریزی نیست.
۲. مسئولیت محتوا و زبان دوم را ریز کنید
تولید متن، ویرایش، ترجمه، انتخاب تصویر و ورود محتوا پنج فعالیت جدا هستند. اگر پروپوزال فقط «بارگذاری محتوای مشتری» دارد، نباید آن را معادل نگارش صفحهٔ خدمات بدانید. برای هر فعالیت تعداد صفحات، تأمین‌کنندهٔ اطلاعات، مسئول تأیید و زمان مورد نیاز را مشخص کنید.
در سایت دوزبانه، تنها داشتن دکمهٔ تغییر زبان کافی نیست. طراحی چیدمان هر زبان، پیوند دو نسخه، ترجمهٔ فرم‌ها و پیام‌ها، متن جایگزین تصاویر و امکان ویرایش مستقل محتوا باید در دامنه روشن باشد. همچنین بپرسید محصولی که هنوز ترجمه نشده در زبان دوم چگونه نمایش داده می‌شود.
۳. امکانات را با یک سناریوی قابل آزمون تعریف کنید
عبارت «اتصال به CRM» را به یک مسیر مشخص تبدیل کنید: کاربر فرم را ارسال می‌کند؛ درخواست به کدام سیستم می‌رود؛ چه فیلدهایی منتقل می‌شوند؛ چه کسی مسئول پاسخ است؛ و اگر سیستم مقصد قطع بود چه اتفاقی می‌افتد؟ ارسال ایمیل، ثبت در پنل و ساخت فرصت فروش در CRM سه خروجی متفاوت‌اند.
همین روش را برای جست‌وجو، فیلتر محصولات، بارگذاری فایل و دسترسی کاربران به کار ببرید. نام سرویس بیرونی، نیاز به اشتراک و محدودیت‌های شناخته‌شده را ثبت کنید. برای انتخاب بستر هم، بحث را از نام فناوری به نیاز ویرایش و اتصال‌ها ببرید؛ راهنمای وردپرس یا سایت اختصاصی به همین تصمیم می‌پردازد.
۴. «سئوی پایه» و «تست کامل» را به اقلام تحویل تبدیل کنید
در بازطراحی، از تیم بپرسید فهرست آدرس‌های فعلی را چه کسی تهیه می‌کند، کدام آدرس‌ها حفظ می‌شوند و برای صفحات جابه‌جاشده چه نگاشتی آماده می‌شود. راهنمای انتقال سایت گوگل بر آماده‌سازی نگاشت آدرس‌ها و پایش پس از انتقال تأکید دارد. این کارها را از وعدهٔ رتبه یا فروش جدا کنید؛ انجامشان تضمین نتیجهٔ تجاری نیست.
برای کیفیت تحویل نیز نمونهٔ آزمون بخواهید: ارسال موفق و ناموفق فرم، دریافت درخواست توسط مسئول، کارکرد منو با صفحه‌کلید، نمایش صفحات مهم در موبایل و درست‌بودن لینک‌ها. راهنمای W3C دربارهٔ برنامه‌ریزی دسترس‌پذیری ارزیابی را در طول کار توصیه می‌کند. دربارهٔ سرعت، ابزار، صفحات نمونه و شرایط آزمون مشخص باشد؛ یک امتیاز آزمایشگاهی به‌تنهایی تجربهٔ همهٔ کاربران را نشان نمی‌دهد. مستندات Web Vitals تفاوت سنجش آزمایشگاهی و دادهٔ کاربران واقعی را توضیح می‌دهد.
۵. زمان‌بندی، تحویل و ادامهٔ همکاری را کنار هزینه ببینید
برای هر مرحله خروجی، مسئول تأیید و پیش‌نیاز را مشخص کنید. «چهار هفته تا تحویل» وقتی محتوا هنوز آماده نیست، با چهار هفته پس از تأیید محتوا یک تعهد اجرایی یکسان نیست. برنامه باید اثر تأخیر در اطلاعات، دسترسی یا تصمیم‌های مشتری را روشن کند.
در تحویل، وضعیت حساب دامنه و میزبانی، سطح دسترسی مدیر، فایل‌های طراحی، مخزن کد در صورت توافق، نسخهٔ پشتیبان و آموزش را ثبت کنید. استفاده از نرم‌افزار متن‌باز یا سرویس اشتراکی لزوماً اشکال نیست؛ مهم این است که بدانید چه چیزی را دریافت می‌کنید و جابه‌جایی یا ادامهٔ کار به چه وابسته است.
هزینهٔ ساخت را از هزینهٔ میزبانی، دامنه، مجوزها، سرویس‌های بیرونی و نگهداری جدا کنید. پشتیبانی هم باید بگوید رفع اشکال چه مدتی پوشش دارد، پاسخ اولیه چه زمانی داده می‌شود و درخواست قابلیت تازه چگونه برآورد می‌شود. «زمان پاسخ» با «زمان حل همهٔ مشکلات» یکی نیست.
جدول مقایسه‌ای که می‌توانید برای دو تیم بفرستید
برای هر ردیف، از هر تیم یکی از وضعیت‌های «شامل»، «خارج از دامنه» یا «نیازمند برآورد» را همراه توضیح بخواهید. خانهٔ خالی را به معنی شامل‌بودن حساب نکنید.
| موضوع | پاسخی که باید در هر پیشنهاد روشن باشد |
|---|---|
| ساختار و طراحی | قالب‌های متمایز، حالت موبایل، فایل‌ها و دورهای بازبینی |
| محتوا و زبان‌ها | تعداد محتوا، نگارش، ترجمه، ورود و تأیید |
| فرم و اتصال‌ها | سناریو، مقصد داده و رفتار هنگام خطا |
| مهاجرت و سئو | آدرس‌ها، انتقال محتوا، ریدایرکت و کنترل بعد از انتشار |
| آزمون و پذیرش | صفحات و شرایط آزمون، گزارش و معیار رفع ایراد |
| تحویل و کنترل | حساب‌ها، دسترسی‌ها، فایل‌ها، پشتیبان و آموزش |
| زمان و هزینه | پیش‌نیازها، اقلام اختیاری، تمدیدها و روش برآورد تغییر |
یک مثال فرضی: چه وقت پیشنهاد کوچک‌تر منطقی است؟
فرض کنید شرکتی متن و تصاویر تأییدشده دارد، فقط یک زبان می‌خواهد و سایت قبلی هم ندارد. پیشنهاد «الف» طراحی و اجرا و ورود محتوای آماده را پوشش می‌دهد. پیشنهاد «ب» علاوه بر این‌ها، نگارش، زبان دوم و مهاجرت را در بر می‌گیرد. اگر نیاز واقعی همین نسخهٔ محدود باشد، دامنهٔ اضافهٔ «ب» ممکن است لازم نباشد.
حالا همین شرکت را با صدها صفحهٔ قدیمی، دو زبان و تیم محتوای پرمشغله در نظر بگیرید. در این وضعیت، حذف مهاجرت و ورود محتوا از پیشنهاد «الف» بار کار را به مشتری منتقل می‌کند. این مثال شرح پروژهٔ واقعی روند نیست؛ نشان می‌دهد چرا باید کار و منابع مورد نیاز را مقایسه کرد، سپس قیمت را سنجید.
پیش از انتخاب، پاسخ این پنج سؤال را مکتوب بگیرید
- از فهرست نیازهای ما دقیقاً چه چیزهایی شامل نیست؟
- ما باید چه محتوا، دسترسی و تصمیم‌هایی را تا چه زمانی آماده کنیم؟
- چه شواهدی نشان می‌دهد سایت آمادهٔ تحویل است؟
- پس از انتشار، چه هزینه‌ها و مسئولیت‌هایی ادامه دارند؟
- اگر دامنه تغییر کند، زمان و هزینهٔ تازه چگونه تأیید می‌شود؟
وقتی پاسخ این سؤال‌ها روشن شد، می‌توانید دربارهٔ کوچک‌کردن نسخهٔ اول، مرحله‌بندی یا تغییر بودجه تصمیم بگیرید. لازم نیست پرحجم‌ترین پیشنهاد را انتخاب کنید؛ پیشنهاد مناسب باید نیاز شما را با خروجی و مسئولیت روشن پوشش دهد.
برای پروژهٔ خودتان از کجا شروع کنید؟
در روند، طراحی تجربه و مهندسی محصول بخش‌های یک مسیر مشترک‌اند. برای دیدن نمونه‌ای از خروجی سایت شرکتی، پروژهٔ وب‌سایت چندزبانهٔ ترموپکس را ببینید؛ این نمونه‌کار، مدرک افزایش فروش یا نتیجهٔ تضمین‌شده نیست.
اگر برای طراحی یا بازطراحی سایت پیشنهاد می‌خواهید، نشانی سایت فعلی، مخاطب اصلی و سه نیاز ضروری را در فرم شروع گفت‌وگو بفرستید. همین اطلاعات نقطهٔ شروع مناسبی برای روشن‌کردن دامنه و تهیهٔ پیشنهادی قابل مقایسه است.