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