تفاوت UI و UX؛ مشکل محصول شما کدام است؟

اگر کاربر نمی‌تواند خریدش را تمام کند، هنوز نمی‌دانیم مشکل از ظاهر دکمه است یا از مسیر خرید. ممکن است دکمه دیده نشود، هزینهٔ ارسال دیر مشخص شود یا خطای پرداخت هیچ راه برگشتی ندهد. این تفاوت، نقطهٔ خوبی برای فهم UI و UX است. ## UI چیزی است که کاربر با آن تعامل می‌کند طراحی رابط کاربری به شکل و رفتار اجزای رابط می‌پردازد: تایپ، رنگ، فاصله‌ها، دکمه‌ها، فرم‌ها و وضعیت‌های آن‌ها. یک فرم فقط حالت خالی ندارد؛ در حال تکمیل، خطا، بارگذاری و موفقیت هم باید قابل فهم باشد. تصمیم‌های بصری از این رفتارها جدا نیستند. برای مثال، اگر پیام خطا خوانا نباشد یا فیلد نامعتبر مشخص نشود، کاربر نمی‌فهمد چه چیزی را اصلاح کند. تغییر درست رابط می‌تواند همین ابهام را کم کند. اما اگر از او اطلاعات غیرضروری بخواهیم، خواناترکردن فرم به‌تنهایی تصمیم محصول را اصلاح نمی‌کند.

## UX به کل تجربه نگاه می‌کند [تعریف Nielsen Norman Group از تجربهٔ کاربری](https://www.nngroup.com/articles/definition-user-experience/) فراتر از خود رابط است. برای یک محصول دیجیتال، مسئله می‌تواند از پیدا‌کردن خدمت شروع شود و تا انجام کار، دریافت نتیجه و پیگیری خطا ادامه پیدا کند. در این نگاه، ترتیب اطلاعات و قواعد سرویس هم بخشی از تجربه‌اند. در یک مسیر ثبت‌نام فرضی، انتخاب روش ورود، دریافت کد، بازیابی دسترسی و توضیح خطا به هم وابسته‌اند. طراحی تجربه کمک می‌کند این مسیر قابل بررسی شود. سپس رابط، تصمیم‌ها را به چیزی تبدیل می‌کند که کاربر بتواند ببیند و با آن کار کند. این مثال گزارش آزمون یک محصول واقعی نیست. ## برای تشخیص مسئله از کجا شروع کنیم؟ یک کار مهم را انتخاب کنید؛ مثلاً رزرو، پرداخت یا ثبت درخواست. مسیرش را روی موبایل و دسکتاپ طی کنید و هرجا مکث یا ابهام دیدید، همان اتفاق را ثبت کنید. به‌جای «صفحه قدیمی است» بنویسید «کاربر قبل از پرداخت نمی‌داند هزینهٔ نهایی چقدر است». اگر دادهٔ رفتار یا بازخورد مشتری دارید، آن را کنار مشاهده بگذارید. افت یک مرحله به‌تنهایی علت را ثابت نمی‌کند؛ ممکن است خطای فنی، ورودی نامرتبط یا محدودیت سرویس هم مؤثر باشد. برای نتیجه‌گیری، باید فرضیه را با شواهد مناسب بررسی کرد.

## چرا ظاهر به‌تنهایی پاسخ نیست؟ در [گزارش Baymard](https://baymard.com/lists/cart-abandonment-rate)، دلایل تجاری و رابطی کنار هم دیده می‌شوند. نتیجهٔ عملی: پیش از تغییر ظاهر، هزینه، تحویل و مسیر پرداخت را هم بررسی کنید. نمودار زیر چند پاسخ گزارش‌شده را نشان می‌دهد، نه علت قطعی رفتار تمام کاربران. A: هزینهٔ اضافه؛ B: تحویل کند؛ C: بی‌اعتمادی به پرداخت؛ D: اجبار ساخت حساب؛ E: طولانی‌بودن فرایند. پاسخ خریداران آنلاین آمریکا، پس از کنارگذاشتن گروه «صرفاً مرور می‌کردم». درصدها سهم کل همهٔ سبدها نیستند و جمعشان قرار نیست ۱۰۰ شود. حجم نمونه در متن عمومی صفحه مشخص نشده است؛ این داده نرخ سایت شما نیست.

## از طراح چه خروجی‌هایی بخواهیم؟ برای مسئلهٔ مسیر، نقشهٔ جریان، اولویت اطلاعات، وایرفریم و نمونهٔ قابل آزمون می‌توانند خروجی مناسبی باشند. برای رابط، صفحه‌ها و حالت‌های لازم، اجزای مشترک و توضیح رفتار آن‌ها اهمیت دارند. فهرست صفحه‌ها باید حالت‌های خطا، خالی و بارگذاری را هم پوشش دهد؛ تعداد اسکرین به‌تنهایی دامنه را روشن نمی‌کند. در تحویل به توسعه، واکنش‌گرایی، محتوا، ترتیب فوکوس و وضعیت‌های تعاملی را مشخص کنید. [راهنمای فرم‌های W3C](https://www.w3.org/WAI/tutorials/forms/) نشان می‌دهد برچسب، دستورالعمل و بازخورد فرم از اجزای یک تجربهٔ قابل استفاده‌اند. بررسی دسترس‌پذیری هم باید در کار واقعی انجام شود، نه فقط در چک‌لیست تحویل. ## آیا هر پروژه به هر دو نیاز دارد؟ معمولاً رابط و تجربه روی هم اثر می‌گذارند، اما دامنهٔ کارشان یکسان نیست. اگر مسیر درست است و تیم فقط به یک زبان بصری منظم و پوشش حالت‌ها نیاز دارد، پروژه می‌تواند متمرکزتر باشد. اگر خود مسیر مبهم است، شروع مستقیم با صفحه‌های نهایی احتمالاً مسئله را عقب می‌اندازد. برای تعریف همکاری، شرح یک کار واقعی کاربر از عبارت کلی «UI/UX می‌خواهم» مفیدتر است. در [طراحی محصول دیجیتال](/services/ui-ux-design) دامنه را بر اساس همین مسئله تعیین می‌کنیم؛ نتیجهٔ طراحی هم باید با اجرا و استفادهٔ واقعی بررسی شود.

• UI و UX
• تجربه کاربری
• رابط کاربری