دقیقه
1 آبان 1405وقتی طراحی رابط و تجربه کاربری در فیگما تأیید می‌شود، هنوز یک مرحله مهم باقی مانده است: بررسی اینکه محصول پیاده‌سازی‌شده همان تجربه و منطق مورد توافق را به کاربر ارائه می‌کند. شباهت کلی صفحه‌ها کافی نیست؛ ممکن است چیدمان درست به نظر برسد، اما در موبایل، حالت‌های خطا یا مسیرهای تعاملی تفاوت‌هایی وجود داشته باشد که کیفیت استفاده را پایین بیاورد.
برای کنترل این تطابق، لازم نیست هر پیکسل را بدون توجه به مرورگر و دستگاه با طرح مقایسه کنیم. باید نسخه تأییدشده را مبنا قرار دهیم، صفحه‌ها و حالت‌های مهم را در شرایط یکسان بسنجیم و تفاوت‌ها را با توجه به اثرشان بر کاربر ثبت کنیم. این راهنما یک روش عملی برای انجام همین بررسی ارائه می‌دهد.
پیش از مقایسه، مبنای تأییدشده را مشخص کنید
اگر طراح، کارفرما و تیم پیاده‌سازی هرکدام به نسخه متفاوتی از طرح نگاه کنند، نتیجه بررسی قابل اتکا نیست. ابتدا فایل یا نسخه‌ای از فیگما را که مبنای اجرا بوده مشخص کنید و روشن کنید کدام صفحه‌ها، اندازه‌های نمایش و حالت‌های تعاملی در محدوده تأیید قرار داشته‌اند. اگر بعد از تأیید، تغییری در طرح یا نیازمندی رخ داده است، همان تغییر باید ثبت شود تا در بررسی به‌عنوان خطای اجرا شمرده نشود.
در فیگما می‌توان با Dev Mode مشخصات طراحی، اندازه‌ها، رنگ‌ها و دارایی‌ها را برای بررسی و پیاده‌سازی دید. تاریخچه نسخه‌ها و قابلیت مقایسه تغییرات نیز کمک می‌کند نسخه مورد توافق از نسخه‌های در حال تغییر جدا بماند. اگر تغییر در فیگما ثبت نشده، پیش از اعلام مغایرت از طراح یا مسئول تصمیم‌گیری بپرسید کدام نسخه ملاک است.
شرایط مقایسه را تا جای ممکن یکسان کنید
یک قاب دسکتاپ فیگما را با صفحه‌ای در اندازه نمایش متفاوت مقایسه نکنید. عرض پنجره، میزان بزرگ‌نمایی، محتوای نمونه و وضعیت صفحه را هماهنگ کنید؛ برای مثال، اگر طرح فرم را با پیام خطا نشان می‌دهد، همان حالت را در سایت باز کنید. از فونت‌ها و تصاویر نهایی استفاده شود، چون فونت جایگزین می‌تواند طول سطر و شکست متن را تغییر دهد و تفاوتی بسازد که به چیدمان مربوط نیست.
فایل تحویل به توسعه‌دهنده موضوع دیگری است. اگر لازم است بدانید چه دارایی‌ها و مستنداتی باید تحویل شوند، راهنمای خروجی‌های تحویل طراحی UI/UX را ببینید. در این مقاله فرض می‌کنیم نسخه مبنا در دسترس است و می‌خواهیم اجرای واقعی را با آن بسنجیم.
چهار لایه را در هر صفحه بررسی کنید
۱. ساختار و اولویت دیداری
بررسی را از کل صفحه شروع کنید: آیا کاربر در نگاه اول متوجه موضوع صفحه و اقدام اصلی می‌شود؟ ترتیب بخش‌ها، جایگاه منو، عنوان‌ها و دکمه‌های مهم را با طرح تأییدشده تطبیق دهید. سپس به جزئیات مانند فاصله‌ها، هم‌ترازی، عرض محتوا، گوشه‌ها و اندازه اجزا برسید. تفاوت کوچک در فاصله ممکن است مسئله مهمی نباشد، اما جابه‌جایی دکمه اصلی یا پنهان‌شدن اطلاعات ضروری می‌تواند مسیر انجام کار را مختل کند.
۲. متن، فونت و دارایی‌های بصری
متن‌های واقعی را بررسی کنید، نه فقط متن‌های کوتاه آزمایشی. عنوان طولانی، نام محصول یا پیام خطا ممکن است در اجرا از کادر بیرون بزند یا چند خط شود. فونت، وزن، اندازه و فاصله سطر را بسنجید و مطمئن شوید لوگو، تصویر و آیکون درست استفاده شده‌اند. در رابط فارسی، جهت راست‌به‌چپ، ترتیب آیکون و متن، تراز اعداد و جایگاه نشانه‌گذاری هم بخشی از کنترل است.
۳. واکنش‌گرایی و بازچینش
نسخه موبایل را فقط کوچک‌شدهٔ دسکتاپ فرض نکنید. ترتیب محتوا، منوی ناوبری، کارت‌ها، فرم‌ها و دکمه‌ها ممکن است در عرض‌های مختلف تغییر کند. چند عرض نماینده را آزمایش کنید، به‌خصوص نزدیک نقاطی که ستون‌ها به یکدیگر می‌رسند یا منوی دسکتاپ جای خود را به منوی موبایل می‌دهد. محتوا نباید بی‌دلیل بریده شود، دکمه‌ها نباید روی هم بیفتند و کاربر نباید برای خواندن محتوای معمولی صفحه را در دو جهت حرکت دهد.
معیار WCAG 2.2 درباره Reflow نیز استفاده از محتوا را در عرض معادل ۳۲۰ پیکسل CSS، با استثناهایی برای محتوای ذاتاً دوبعدی، در نظر می‌گیرد. این معیار جای آزمون روی دستگاه‌ها و عرض‌های واقعی را نمی‌گیرد، اما نقطه شروع مفیدی برای پیدا کردن مشکلات بازچینش است.
۴. رفتار و حالت‌های تعاملی
فقط ظاهر صفحه در حالت عادی را نبینید. پیوندها، دکمه‌ها و فرم‌ها را اجرا کنید و حالت‌های تمرکز صفحه‌کلید، انتخاب، بارگذاری، موفقیت، خطا، خالی و غیرفعال را بررسی کنید. برای نمونه، دکمه‌ای که در طرح به مرحله بعد می‌رود اما در سایت واکنشی ندارد، از نظر بصری ممکن است درست باشد ولی تجربه مورد توافق را ارائه نمی‌کند. مسیرهای اصلی را از ابتدا تا انتها پیش ببرید و بازگشت یا اصلاح اطلاعات را هم امتحان کنید.
یک فرایند مرحله‌ای برای کنترل تطابق
- صفحه‌ها و سناریوهای مهم را فهرست کنید: صفحات کلیدی و کارهایی را که کاربر باید در آن‌ها انجام دهد، انتخاب کنید؛ مانند پیدا کردن خدمت، ارسال فرم یا تکمیل سفارش.
- نسخه مبنا و اندازه نمایش را تعیین کنید: لینک نسخه فیگما، قاب مورد بررسی، عرض صفحه و وضعیت تعاملی را یادداشت کنید.
- مقایسه دیداری انجام دهید: تصویر صفحه اجراشده را در کنار طرح قرار دهید یا از هم‌پوشانی دو تصویر برای پیدا کردن جابه‌جایی‌ها کمک بگیرید. ابزار مقایسه تصویری Playwright می‌تواند برای ثبت تصویر مبنا و تشخیص تغییرات دیداری در آزمون‌های تکرارشونده مفید باشد؛ نتیجه آن را به‌تنهایی معیار کیفیت یا پذیرش قرار ندهید، چون تفاوت محیط اجرا، مرورگر و فونت نیز ممکن است در تصویر اثر بگذارد.
- رفتار و عرض‌های دیگر را آزمایش کنید: مسیرهای اصلی و حالت‌های تعاملی را اجرا کنید و صفحه را در اندازه‌های موبایل و تبلت نیز ببینید.
- یافته‌ها را ثبت و دوباره‌آزمایی کنید: پس از اصلاح، همان سناریو و اندازه نمایش را دوباره بررسی کنید تا رفع یک تفاوت، بخش دیگری را خراب نکرده باشد.
برای هر یافته، نشانی صفحه، اندازه نمایش، گام‌های بازتولید، تصویر یا ویدئوی کوتاه، نتیجه مورد انتظار و نتیجه مشاهده‌شده را بنویسید. این ثبت دقیق، رفت‌وبرگشت میان طراح و توسعه‌دهنده را کمتر می‌کند و به جای عبارت مبهم «این قسمت درست نیست»، مسئله قابل بررسی می‌سازد.
تفاوت‌ها را بر اساس اثرشان اولویت‌بندی کنید
همه مغایرت‌ها اهمیت یکسان ندارند. تفاوتی که مانع ثبت سفارش می‌شود باید زودتر از اختلاف جزئی در سایه یک کارت بررسی شود. برای اولویت‌بندی، بپرسید آیا این مورد انجام کار اصلی را متوقف می‌کند؟ آیا اطلاعات مهم را پنهان یا ناخوانا می‌کند؟ آیا روی صفحه‌ای پرتکرار یا برای بخش بزرگی از کاربران دیده می‌شود؟ آیا دسترسی با صفحه‌کلید یا فناوری کمکی را دشوار می‌کند؟
سپس یافته را در یکی از چهار گروه قرار دهید: خطای پیاده‌سازی نسبت به نسخه تأییدشده، سازگارسازی آگاهانه برای اندازه نمایش دیگر، تغییر طراحی که بعداً تأیید شده، یا ابهامی که هنوز تصمیمی درباره آن گرفته نشده است. سه گروه آخر لزوماً باگ نیستند؛ اما باید مستند شوند و مسئول تصمیم‌گیری آن‌ها را تعیین کند. اگر تغییر جدیدی در طراحی لازم است، آن را از اصلاح خطای اجرا جدا نگه دارید تا محدوده و زمان کار روشن بماند.
اشتباه‌های رایج در بازبینی طرح و اجرا
- مقایسه با نسخه اشتباه: طرح قدیمی یا پیش‌نویس مبنای قابل قبولی برای گزارش مغایرت نیست.
- قضاوت فقط با یک اسکرین‌شات: تصویر ثابت تعامل، اسکرول، خطاها و وضعیت‌های پویا را نشان نمی‌دهد.
- بررسی فقط در یک اندازه: صفحه‌ای که در دسکتاپ درست است ممکن است در موبایل ترتیب یا دسترسی نامناسبی داشته باشد.
- تبدیل اختلاف پیکسلی به معیار نهایی: هر اختلاف تصویری مهم نیست و هر ایراد تجربه کاربری هم با اختلاف پیکسل دیده نمی‌شود.
- ارسال بازخورد مبهم: بدون نشانی دقیق، اندازه صفحه و نتیجه مورد انتظار، تیم اجرا ناچار می‌شود منظور بازبین را حدس بزند.
چک‌لیست کوتاه پیش از تأیید نهایی
- نسخه تأییدشده و محدوده بررسی برای همه اعضا روشن است.
- صفحه‌های کلیدی در اندازه‌های دسکتاپ و موبایل بررسی شده‌اند.
- متن فارسی، فونت، تصویر و آیکون نهایی در صفحه قرار دارند.
- مسیرهای اصلی و حالت‌های تعاملی، از جمله خطا و بارگذاری، آزمایش شده‌اند.
- یافته‌ها با شواهد، اولویت و مسئول پیگیری ثبت شده‌اند.
- اصلاحات مهم پس از اعمال دوباره آزمایش شده‌اند.
کنترل تطابق زمانی نتیجه می‌دهد که طرح تأییدشده، اجرای واقعی و رفتار مورد انتظار کاربر را کنار هم ببینیم. اگر در مرحله تعریف مسئله و آماده‌سازی پروژه هستید، مطلب اطلاعات لازم برای بریف طراحی UI/UX را بخوانید. برای برنامه‌ریزی و اجرای پژوهش، وایرفریم و طراحی محصول نیز می‌توانید با تیم طراحی UI/UX آژانس خلاقیت امین آشنا شوید.
برای طراحی رابطی آمادهٔ پیاده‌سازی، از کجا شروع کنیم؟ نیازهای پروژه‌تان را با ما مطرح کنید تا مسیر طراحی، جزئیات تعامل و خروجی‌های مورد توافق روشن شوند. خدمات طراحی UI/UX آژانس خلاقیت امین را ببینید.