بیشتر پروژه‌های طراحی سایتی که به دردسر می‌افتند، از جلسه اول مشکل داشته‌اند؛ فقط مشکل دیر دیده شده است. سفارش‌دهنده تصور روشنی از نتیجه داشته، طراح تصور روشن دیگری، و هیچ‌کدام آن را روی کاغذ نیاورده‌اند. چند ماه بعد، هر دو طرف حس می‌کنند حقشان خورده شده.
خبر خوب این است که بخش بزرگی از این سوءتفاهم‌ها با چند سؤال ساده قبل از شروع کار برطرف می‌شود. سؤال‌هایی که تیم طراحی خوب به‌هرحال از شما می‌پرسد، اما اگر خودتان از قبل جوابشان را بدانید، هم انتخاب تیم راحت‌تر می‌شود و هم پروژه با تصمیم‌های بهتری شروع می‌شود.
برای هر سؤال یک توضیح کوتاه، یک مثال و یک کار عملی آورده‌ایم. مثال‌ها فرضی‌اند، اما از موقعیت‌هایی گرفته شده‌اند که در پروژه‌های وب رایج‌اند.
«سایت می‌خواهیم» هدف نیست؛ وسیله است. هدف چیزی است که بعد از راه‌اندازی سایت باید عوض شود: تعداد درخواست مشاوره، فروش آنلاین، کم شدن تماس‌های تکراری با پشتیبانی، یا اعتبار در چشم مشتریان سازمانی.
مثال: یک آموزشگاه زبان می‌گوید سایت می‌خواهد. با کمی سؤال معلوم می‌شود مشکل اصلی‌اش این است که منشی روزانه ده‌ها بار به سؤال «کلاس بعدی کِی شروع می‌شود و هزینه‌اش چقدر است؟» جواب می‌دهد. این یعنی صفحه تقویم کلاس‌ها و ثبت‌نام آنلاین از گالری عکس مهم‌تر است.
کار عملی: هدف سایت را در یک جمله بنویسید که یک عدد یا رفتار قابل مشاهده در آن باشد. اگر نشد، هنوز برای سفارش آماده نیستید.
سایتی که برای «همه» طراحی شود، معمولاً با هیچ‌کس درست حرف نمی‌زند. مخاطب اصلی را مشخص کنید و ببینید او قبل از تماس گرفتن یا خرید، به چه سؤال‌هایی باید جواب بگیرد.
مثال: یک تولیدکننده قطعات صنعتی دو مخاطب دارد: مدیر خرید که دنبال مشخصات فنی، گواهی‌ها و زمان تحویل است، و مدیرعامل که می‌خواهد بداند شرکت چقدر قابل اتکاست. سایت باید برای هر دو مسیر جدا داشته باشد.
کار عملی: پنج سؤالی را که مشتری‌ها معمولاً پشت تلفن می‌پرسند فهرست کنید. سایت باید به همین‌ها جواب بدهد.
فهرست امکانات معمولاً با نگاه به سایت رقبا بلند می‌شود: چت آنلاین، وبلاگ، باشگاه مشتریان، دو زبانه بودن. هر کدام هزینه ساخت و هزینه نگهداری دارد. امکاناتی که کسی از آن استفاده نکند، فقط سایت را سنگین‌تر می‌کند.
مثال: بخش وبلاگ برای کسب‌وکاری که هیچ‌کس را برای نوشتن ندارد، بعد از سه پست رها می‌شود و آخرین تاریخ انتشارش، بیشتر از نبودِ وبلاگ به اعتبار سایت ضربه می‌زند.
کار عملی: امکانات را در سه ستون بنویسید: «بدون این راه‌اندازی نمی‌کنیم»، «مفید است»، «بعداً». نسخه اول فقط ستون اول را لازم دارد.
یکی از رایج‌ترین دلایل تأخیر در پروژه‌های وب، نه برنامه‌نویسی است و نه طراحی؛ محتواست. متن صفحه‌ها، عکس محصولات، مشخصات فنی، نمونه‌کارها. وقتی مشخص نباشد چه کسی مسئول آماده کردن این‌هاست، پروژه هفته‌ها منتظر می‌ماند.
مثال: طراحی یک فروشگاه آنلاین تمام شده، اما عکس‌های ۲۰۰ محصول هنوز گرفته نشده‌اند. سایت یا با عکس‌های بی‌کیفیت باز می‌شود، یا اصلاً باز نمی‌شود.
کار عملی: قبل از قرارداد روشن کنید تولید متن و عکس با شماست یا با تیم طراحی، و برای تحویل محتوا هم مثل بقیه کار، تاریخ بگذارید.
بودجه بدون دامنه کار مشخص، عدد بی‌معنایی است و دامنه کار بدون بودجه، فهرست آرزوهاست. این دو باید کنار هم تعریف شوند. اگر بودجه محدود است، بهتر است دامنه را کوچک کنید تا کیفیت را.
مثال: دو پیشنهاد قیمت با اختلاف زیاد معمولاً دو کار متفاوت را قیمت داده‌اند: یکی قالب آماده با کمی شخصی‌سازی، دیگری طراحی اختصاصی با تحلیل نیاز. مقایسه عددی آن‌ها بدون مقایسه شرح کار گمراه‌کننده است.
کار عملی: از هر پیشنهاددهنده بخواهید شرح کارش را به تفکیک بنویسد و بپرسید درخواست تغییرات خارج از قرارداد چطور قیمت‌گذاری می‌شود.
سایت تنها نیست. درگاه پرداخت، پنل پیامک، نرم‌افزار حسابداری، انبار، CRM یا حتی یک جدول ساده که تیم فروش با آن کار می‌کند. هر اتصال باید از اول دیده شود، چون اضافه کردنش بعد از راه‌اندازی معمولاً گران‌تر است.
مثال: فروشگاهی که موجودی‌اش را در نرم‌افزار حسابداری نگه می‌دارد و این دو به هم وصل نیستند، دیر یا زود کالایی را می‌فروشد که در انبار ندارد.
کار عملی: فهرست ابزارهایی را که امروز استفاده می‌کنید بنویسید و برای هر کدام مشخص کنید چه اطلاعاتی باید بین آن و سایت رد و بدل شود.
سایت را برای امروز می‌سازید، اما باید بتواند فردا هم تغییر کند: محصول جدید، شهر جدید، زبان دوم، پنل نمایندگان. لازم نیست امروز همه این‌ها را بسازید؛ کافی است ساختار جلوی آن‌ها را نبندد. پیچیده کردن پروژه برای آینده‌ای که شاید هیچ‌وقت نیاید، به همان اندازه اشتباه است.
مثال: اگر احتمال می‌دهید سال بعد فروش عمده هم داشته باشید، کافی است از حالا مدل کاربران طوری طراحی شود که بعداً بشود نوع «مشتری عمده» با قیمت متفاوت به آن اضافه کرد.
کار عملی: سه تغییر محتمل در دو سال آینده را با تیم طراحی در میان بگذارید و بپرسید هرکدام بعداً چقدر هزینه دارد.
این سؤال کمتر از بقیه پرسیده می‌شود و وقتی اهمیتش معلوم می‌شود که رابطه کاری تمام شده است. اگر دامنه به نام مجری ثبت شده باشد، رمز هاست فقط دست او باشد یا کد سایت به شما تحویل نشود، عملاً بدون او نمی‌توانید سایت خودتان را جابه‌جا یا توسعه دهید.
مثال: کسب‌وکاری که می‌خواهد تیم توسعه‌اش را عوض کند، متوجه می‌شود دامنه .ir با شناسه ایرنیک مجری قبلی ثبت شده و برای انتقالش باید با او هماهنگ کند.
کار عملی: در قرارداد بنویسید دامنه به نام چه کسی ثبت می‌شود، کد منبع و دسترسی‌های مدیریتی کِی و چطور تحویل می‌شوند، و داده‌های مشتریان متعلق به کیست. این بند برای هر دو طرف شفافیت می‌آورد.
سایت بعد از راه‌اندازی تمام نمی‌شود. به‌روزرسانی‌های امنیتی، پشتیبان‌گیری، رفع خطا و تغییرات کوچک همیشگی‌اند. اگر مشخص نباشد چه کسی و با چه هزینه‌ای مسئول این‌هاست، سایت آرام‌آرام فرسوده می‌شود.
مثال: افزونه‌ای که دو سال به‌روز نشده، راه نفوذ به سایت را باز می‌کند و تازه آن موقع معلوم می‌شود هیچ نسخه پشتیبان سالمی وجود ندارد.
کار عملی: بپرسید پشتیبان‌ها کجا و هر چند وقت یک بار گرفته می‌شوند، آخرین بار کِی بازیابی آن‌ها آزمایش شده، و زمان پاسخ به یک خطای جدی چقدر است.
این دو یکی نیستند. معیار تحویل یعنی چه چیزهایی باید ساخته و کار کند تا قرارداد تمام شده حساب شود. معیار موفقیت یعنی بعد از چند ماه، چه چیزی در کسب‌وکار باید بهتر شده باشد. اولی را باید در قرارداد نوشت؛ دومی را باید با هم دنبال کرد.
مثال: «سایت روی موبایل و دسکتاپ بدون خطا کار کند و فرم‌ها به پنل فروش برسند» معیار تحویل است. «درخواست‌های آنلاین در سه ماه اول از تماس تلفنی بیشتر شود» معیار موفقیت است.
کار عملی: یک فهرست کوتاه از معیارهای پذیرش بنویسید که بشود تک‌تک آن‌ها را آزمایش کرد، و جدا از آن، یکی دو عدد را انتخاب کنید که می‌خواهید بعد از راه‌اندازی دنبالشان کنید.
اگر وقت ندارید همه متن را دوباره بخوانید، قبل از امضای قرارداد این فهرست را مرور کنید:
هدف سایت در یک جمله، همراه با یک عدد یا رفتار قابل اندازه‌گیری، نوشته شده است.
مخاطب اصلی و پنج سؤال پرتکرارش مشخص است.
امکانات به «ضروری»، «مفید» و «بعداً» تقسیم شده‌اند.
مسئول و تاریخ تحویل محتوا روشن است.
شرح کار تفکیکی است و نحوه قیمت‌گذاری تغییرات مشخص شده.
سیستم‌هایی که باید به سایت وصل شوند فهرست شده‌اند.
تغییرات محتمل دو سال آینده با تیم طراحی مطرح شده است.
مالکیت دامنه، کد، دسترسی‌ها و داده‌ها در قرارداد آمده است.
برنامه پشتیبان‌گیری، به‌روزرسانی و پشتیبانی بعد از تحویل معلوم است.
معیارهای پذیرش و شاخص‌های موفقیت جداگانه تعریف شده‌اند.
هیچ‌کدام از این سؤال‌ها فنی نیست و برای جواب دادن به آن‌ها لازم نیست برنامه‌نویسی بلد باشید. اما همین‌ها هستند که تعیین می‌کنند سایت شما بعد از راه‌اندازی به کار کسب‌وکار می‌آید یا فقط یک هزینه انجام‌شده است. و اگر تیمی که با آن صحبت می‌کنید خودش این سؤال‌ها را نپرسید، همین هم نشانه خوبی برای تصمیم‌گیری است.
