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