طراحی تجربهٔ کاربری وب یا UX، فرایند شناخت نیاز کاربران، طراحی مسیر انجام کار و بررسی کیفیت استفاده از سایت است. هدف این است که فرد بتواند کار مورد نظرش را با اطلاعات کافی و بدون سردرگمی کامل کند. ساختار محتوا، رابط، سرعت پاسخ و نتیجهٔ خدمات همگی در تجربهٔ او نقش دارند.
فرض کنید صاحب یک کارگاه تولیدی در ساری می‌خواهد از سایت یک شرکت، برای ساخت سامانهٔ سفارش‌گیری استعلام بگیرد. او باید بفهمد شرکت چنین کاری انجام می‌دهد، نمونهٔ مرتبط را پیدا کند، بداند چه اطلاعاتی لازم است و پس از ارسال درخواست از ثبت آن مطمئن شود. بررسی همین مسیر، نقطهٔ شروع بهبود UX است.
تجربهٔ کاربری چه تفاوتی با ظاهر سایت دارد؟
رابط کاربری یا UI شامل اجزا و رفتارهای صفحه، مانند منو، فرم و پیام‌هاست. UX گسترده‌تر است و برداشت فرد از کل تعامل با محصول یا خدمت را در بر می‌گیرد. ظاهر رابط بخشی از این تجربه را شکل می‌دهد؛ کافی‌بودن اطلاعات و عملی‌شدن وعدهٔ خدمت هم بر آن اثر دارند.
در مثال استعلام، اگر فرم خوانا باشد اما کاربر نداند درخواست به چه کسی می‌رسد، هنوز ابهام وجود دارد. اگر درخواست درست ثبت شود اما نتیجه‌ای برای پیگیری دیده نشود، تجربه کامل نیست. برای بررسی اجزای صفحه، مقالهٔ طراحی رابط کاربری و تفاوت UI و UX را ببینید.
کاربردپذیری یا Usability به امکان انجام کار و آسانی استفاده مربوط است و یکی از موضوعات مهم در بررسی UX به شمار می‌آید. مفیدبودن خدمت، اعتماد و انتظاری که پس از استفاده برآورده می‌شود نیز باید در نظر گرفته شوند. یک گزارش صرفاً بصری، همهٔ این موارد را پوشش نمی‌دهد.
بهبود UX سایت را از کجا شروع کنیم؟
به‌جای تصمیم کلی مثل «سایت باید مدرن‌تر شود»، یک کار مهم را انتخاب کنید. در سایت شرکتی ممکن است این کار ارسال درخواست همکاری باشد؛ در فروشگاه، پیدا‌کردن محصول مناسب و تکمیل خرید. هدف کسب‌وکار را در کنار هدف کاربر بنویسید تا طراحی فقط به گرفتن شماره یا کلیک ختم نشود.
برای شروع، این اطلاعات را جمع کنید:
- مخاطب: چه کسی قرار است از این مسیر استفاده کند و چه آشنایی قبلی دارد؟
- هدف: او با انجام چه کاری به نتیجهٔ مطلوب می‌رسد؟
- شرایط: با چه دستگاه، ارتباط اینترنت و محدودیت زمانی وارد می‌شود؟
- شواهد: کدام پرسش پشتیبانی، خطای ثبت‌شده یا مشاهدهٔ مستقیم، وجود مشکل را نشان می‌دهد؟
نظر اعضای تیم برای ساخت فرضیه مفید است، اما آن را با رفتار مخاطب یکی نگیرید. کسی که هر روز با سایت کار می‌کند، نام منوها و راه‌های میان‌بر را از قبل می‌شناسد. کاربر تازه‌وارد ممکن است برداشت دیگری داشته باشد.
اصول طراحی تجربهٔ کاربری در مسیر واقعی
اطلاعات را با زبان مخاطب دسته‌بندی کنید
معماری اطلاعات یعنی سازمان‌دهی و نام‌گذاری محتوا به شکلی که پیدا‌کردن آن ممکن باشد. برای خدمات شرکت، نام داخلی واحدها الزاماً عنوان مناسبی برای منو نیست. کاربری که دنبال سامانهٔ سفارش است، باید بتواند خدمت مرتبط را از عنوان و توضیح آن تشخیص دهد.
پرسش‌های پیش از تصمیم را در جای مناسب پاسخ دهید. در سایت یک شرکت محلی، محدودهٔ خدمت، راه ارتباط و نمونهٔ کار مرتبط می‌تواند به تصمیم کمک کند. تکرار نام شهر در همهٔ پاراگراف‌ها جای اطلاعات مفید را نمی‌گیرد.
وضعیت کار و نتیجهٔ اقدام را روشن نشان دهید
وقتی کاربر فرم را ارسال می‌کند، باید معلوم باشد عملیات در حال انجام است، موفق شده یا به اصلاح نیاز دارد. بی‌واکنش‌ماندن دکمه او را دربارهٔ ثبت درخواست مردد می‌کند. تأیید نهایی را با نتیجهٔ واقعی ثبت در سامانه هماهنگ کنید.
متن نتیجه، قدم بعدی را هم توضیح دهد؛ مثلاً راه پیگیری درخواست کجاست. زمان تماس یا پاسخ را فقط زمانی وعده بدهید که فرایند اجرایی شرکت از آن پشتیبانی می‌کند.
از خطا جلوگیری کنید و راه اصلاح بدهید
در فرم استعلام، اطلاعاتی را بخواهید که برای بررسی اولیه لازم است. اگر بودجه هنوز مشخص نیست، امکان بیان این وضعیت را در طراحی نیازسنجی بررسی کنید. اجبار به انتخاب یک عدد تصادفی، کیفیت اطلاعات را بهتر نمی‌کند.
کنار ورودیِ مشکل‌دار، توضیح قابل فهم قرار دهید و اطلاعات صحیح را حفظ کنید. کاربر باید بتواند انتخاب اشتباه یا مرحلهٔ قبلی را اصلاح کند. کوتاه‌ترین مسیر همیشه بهترین نیست؛ گاهی یک مرحلهٔ بازبینی از ارسال اشتباه جلوگیری می‌کند.
دسترس‌پذیری را در خود مسیر بررسی کنید
کاربران ممکن است با صفحه‌کلید، صفحه‌خوان یا بزرگ‌نمایی از سایت استفاده کنند. پیدا‌کردن فرم، فهم برچسب‌ها، تشخیص محل تمرکز و دریافت پیام نتیجه باید در این شرایط هم امکان‌پذیر باشد. مشاهدهٔ چند کاربر بدون معلولیت، جای بررسی دسترس‌پذیری را نمی‌گیرد.
W3C بر ارتباط و تفاوت دسترس‌پذیری، کاربردپذیری و فراگیری تأکید می‌کند. بررسی فنی را با شناخت نیاز افرادی که با مانع روبه‌رو می‌شوند همراه کنید. این کار را به پایان پروژه موکول نکنید.
رفتار سایت را در موبایل و اینترنت ناپایدار ببینید
روی گوشی، همان کار اصلی را از ابتدا تا پایان انجام دهید. آیا منو، فرم، بارگذاری فایل و پیام نتیجه قابل استفاده‌اند؟ اگر صفحه‌کلید باز شود یا کاربر میان دو برنامه جابه‌جا شود، اطلاعاتش حفظ می‌شود؟ فقط تصویر صفحهٔ اول را معیار قرار ندهید.
سرعت نمایش، پاسخ به تعامل و جابه‌جایی ناخواستهٔ اجزا هم مهم‌اند. Core Web Vitals این جنبه‌های فنی را با LCP، INP و CLS بررسی می‌کند. نتیجهٔ خوب این شاخص‌ها به‌تنهایی ثابت نمی‌کند کاربر خدمت مناسب را پیدا می‌کند یا فرم را می‌فهمد.
چطور یک آزمون کاربردپذیری انجام دهیم؟
در آزمون کاربردپذیری، فردی از مخاطبان هدف تلاش می‌کند کار مشخصی را با سایت یا نمونهٔ تعاملی انجام دهد و پژوهشگر رفتار و بازخورد او را مشاهده می‌کند. هدف، پیدا‌کردن مشکلات محصول است؛ توانایی فرد ارزیابی نمی‌شود.
- پرسش آزمون را تعیین کنید. مثلاً آیا متقاضی می‌تواند خدمت سفارش نرم‌افزار را پیدا و اطلاعات اولیهٔ درخواست را ارسال کند؟
- افراد مرتبط را انتخاب کنید. آشنایی با موضوع، تجربهٔ دیجیتال و دستگاه مورد استفاده باید با گروه هدف تناسب داشته باشد.
- یک موقعیت واقعی تعریف کنید. بگویید «برای مدیریت سفارش‌های کارگاهتان راهکار می‌خواهید؛ از این سایت درخواست بررسی بفرستید.» نام منو یا دکمهٔ درست را در دستور نگویید.
- مشاهده کنید و راه‌حل را زود نگویید. محل مکث، بازگشت، برداشت اشتباه و کمک لازم را ثبت کنید. از فرد بخواهید آنچه را فکر می‌کند توضیح دهد.
- مشکل‌ها را به اقدام مشخص تبدیل کنید. برای هر مورد، شاهد، پیشنهاد اصلاح و روش آزمون دوباره بنویسید.
برای آزمون، از دادهٔ ساختگی مناسب استفاده کنید تا ثبت سفارش، ارسال پیام یا افشای اطلاعات واقعی ناخواسته رخ ندهد. هدف جلسه و شیوهٔ ثبت یادداشت یا ضبط را از قبل توضیح دهید. نوع و تعداد شرکت‌کنندگان به پرسش و تنوع مخاطبان وابسته است؛ یک عدد ثابت برای همهٔ پروژه‌ها مناسب نیست.
نمونهٔ قابل کلیک برای بررسی فهم مسیر مفید است، اما آزمون آن، عملکرد سرور یا تحویل واقعی خدمت را تأیید نمی‌کند. پس از پیاده‌سازی هم مسیر کامل را در نسخهٔ واقعی بررسی کنید.
از چه معیارهایی برای سنجش بهبود استفاده کنیم؟
پیش از تغییر، تعریف موفقیت را روشن کنید. در فرم استعلام، کلیک روی «ارسال» کافی نیست؛ درخواست باید ثبت شود و کاربر نتیجه را تشخیص دهد. برای مقایسه، کار، شرایط و گروه مخاطب را تا حد امکان همسان نگه دارید.
| معیار | چه چیزی ثبت شود؟ | محدودیت تفسیر |
|---|---|---|
| تکمیل کار | تعداد تکمیل موفق نسبت به تلاش‌های بررسی‌شده | کمک پژوهشگر را از تکمیل مستقل جدا کنید. |
| خطا و نیاز به کمک | نوع خطا، محل توقف و کمک لازم | حدس پژوهشگر را به‌جای مشاهده ثبت نکنید. |
| زمان انجام کار | زمان از شروع تا نتیجهٔ تعریف‌شده | کاهش زمان همیشه به معنی تصمیم بهتر نیست. |
| برداشت کاربر | توضیح او دربارهٔ نتیجه و دشواری مسیر | نظر مثبت به‌تنهایی موفقیت کار را ثابت نمی‌کند. |
گزارش بازدید و رویدادهای سایت نشان می‌دهد کاربران در کدام مرحله‌ها کمتر ادامه می‌دهند، اما دلیل را قطعی مشخص نمی‌کند. دادهٔ تحلیلی را با مشاهده و پرسش تکمیل کنید. نقشهٔ حرارتی یا ضبط جلسه نیز به‌تنهایی نیت کاربر را نشان نمی‌دهد و باید متناسب با حریم خصوصی به کار گرفته شود.
از یک آزمون کوچک، درصد موفقیت همهٔ مشتریان را نتیجه نگیرید. برای ادعای افزایش فروش، باید داده و شرایط مقایسهٔ مناسبی داشته باشید؛ تغییر ترافیک، قیمت و پیشنهاد فروش هم می‌تواند بر نتیجه اثر بگذارد.
کدام مشکل‌های سایت را زودتر اصلاح کنیم؟
ابتدا مانع‌هایی را بررسی کنید که کار اصلی را متوقف می‌کنند یا نتیجهٔ نادرست می‌سازند؛ مانند ثبت‌نشدن درخواست، مشخص‌نبودن هزینه یا پنهان‌شدن اقدام اصلی در موبایل. سپس مشکلات تکرارشوندهٔ فهم، ناوبری و فرم را بر اساس شواهد و اثرشان اولویت دهید.
برای هر اصلاح، مسئول و معیار بررسی تعیین کنید. «فرم بهتر شود» مبهم است؛ «خطای ورودی کنار همان فیلد نمایش داده شود و داده‌های صحیح باقی بمانند» اقدام قابل بررسی است. بعد از اصلاح دوباره همان سناریو را امتحان کنید.
اگر مسئله در مسیر خرید است، مقالهٔ دلایل رهاکردن سبد خرید به بررسی همان مسیر کمک می‌کند. برای روشن‌کردن اطلاعات و اعتماد پیش از خرید نیز راهنمای اعتماد مشتری به فروشگاه اینترنتی را ببینید.
در پروژهٔ UX چه خروجی‌هایی لازم است؟
خروجی باید نشان دهد چه مشکلی با چه شاهدی بررسی شده و تغییر پیشنهادی چگونه سنجیده می‌شود. بسته به محدودهٔ پروژه، این موارد را مشخص کنید:
- گروه‌های مخاطب، نیازها و پرسش‌های تحقیق.
- مسیرهای اصلی و اطلاعات لازم در هر مرحله.
- مشاهدات، مشکل‌ها و اولویت اصلاح آن‌ها.
- طرح یا نمونهٔ تعاملی برای تغییرات پیشنهادی.
- سناریوی آزمون، نتیجه و محدودیت‌های بررسی.
- مسئول پیگیری و روش ارزیابی نسخهٔ پیاده‌شده.
اگر قصد بازطراحی دارید، چند نمونهٔ مشخص از تماس‌های پشتیبانی و کارهای ناتمام کاربران آماده کنید. برای شروع همکاری، چک‌لیست اطلاعات پیش از سفارش سایت و خدمات طراحی سایت و اپلیکیشن داپا را ببینید.
پرسش‌های متداول
آیا UX فقط برای سایت‌های بزرگ لازم است؟
در سایت کوچک هم کاربر باید بتواند هدف اصلی را انجام دهد. تحقیق و آزمون را متناسب با اهمیت مسیر، ریسک تصمیم و تنوع مخاطبان برنامه‌ریزی کنید.
آیا ابزار تحلیل بازدید جای آزمون با کاربر را می‌گیرد؟
خیر. آمار، محل احتمالی مشکل را نشان می‌دهد؛ مشاهدهٔ انجام کار و گفت‌وگو به فهم علت کمک می‌کند. این دو روش اطلاعات متفاوتی می‌دهند.
آیا هرچه تعداد کلیک کمتر باشد UX بهتر است؟
خیر. واضح‌بودن انتخاب و نتیجهٔ هر مرحله مهم است. یک گام بازبینیِ مفید می‌تواند از خطا جلوگیری کند؛ حذف آن فقط تعداد کلیک را کم می‌کند.
آیا بهبود تجربهٔ کاربری رتبهٔ گوگل را تضمین می‌کند؟
خیر. تجربهٔ مناسب، محتوای مفید و سلامت فنی باید در کنار هم بررسی شوند. نتیجهٔ آزمون UX را نباید به‌عنوان تضمین رتبه یا افزایش قطعی فروش ارائه کرد.
