Skip to content
بازگشت به وبلاگ طراحی و تجربه کاربری

طراحی تجربه کاربری چیست؟ از تحقیق تا تست یک تجربهٔ واقعی.

طراحی تجربه کاربری چیست؟ از تحقیق تا تست یک تجربهٔ واقعی

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

با یک توضیح کوتاه در لحظهٔ درست و تغییر ترتیب دریافت اطلاعات، مسئله تا حد زیادی حل شد. این همان جایی است که طراحی تجربه کاربری از طراحی یک صفحه فراتر می‌رود.

طراحی تجربه کاربری یا UX فرایند فهمیدن نیاز و زمینهٔ کاربر و ساختن مسیری است که او بتواند با وضوح، کنترل و اطمینان به هدفش برسد. خروجی این فرایند ممکن است یک صفحه، تغییر متن، حذف یک مرحله یا حتی تصمیم به نساختن یک قابلیت باشد.

تجربهٔ کاربر فقط داخل صفحه اتفاق نمی‌افتد

کاربر قبل از باز کردن محصول انتظار و نگرانی دارد. ممکن است از تبلیغ، توصیهٔ دوست یا نتیجهٔ گوگل وارد شود. بعد از انجام کار هم سؤال‌هایی برایش می‌ماند: آیا سفارش ثبت شد؟ اگر اشتباه کردم چه؟ پشتیبانی کجاست؟

برای همین UX را نمی‌شود به وایرفریم محدود کرد. تجربه شامل سرعت، محتوا، اعتماد، خطاها، پشتیبانی، دسترس‌پذیری و هماهنگی میان کانال‌هاست. حتی ایمیل تأیید یا پیامک نامفهوم می‌تواند تجربهٔ یک جریان خوب را خراب کند.

من معمولاً مسیر را از لحظه‌ای می‌بینم که نیاز در ذهن کاربر شکل می‌گیرد تا زمانی که مطمئن می‌شود کارش تمام شده است. این نگاه کمک می‌کند نقطه‌های شکست بیرون از صفحهٔ اصلی هم دیده شوند.

مرحلهٔ اول: مسئله را قبل از راه‌حل تعریف کنیم

جمله‌هایی مثل «یک داشبورد جدید می‌خواهیم» یا «باید onboarding بسازیم» مسئله نیستند؛ راه‌حل پیشنهادی‌اند. سؤال این است که چه کسی، در چه موقعیتی و برای رسیدن به چه هدفی مشکل دارد.

تعریف خوب مسئله باید به‌اندازه‌ای دقیق باشد که تیم بداند چه چیزی را بررسی می‌کند و به‌اندازه‌ای باز باشد که فقط یک پاسخ از قبل تعیین‌شده نداشته باشد. مثلاً: «کاربر تازه‌وارد قبل از دیدن ارزش اصلی محصول، با درخواست اطلاعات زیاد روبه‌رو می‌شود و ثبت‌نام را رها می‌کند.»

این تعریف ما را به سؤال‌های بهتر می‌رساند: کدام اطلاعات ضروری است؟ ارزش اصلی چه زمانی دیده می‌شود؟ چه چیزی باعث بی‌اعتمادی است؟ چه داده‌ای دربارهٔ ریزش داریم؟

مرحلهٔ دوم: تحقیق کاربر، نه تأیید حدس خودمان

تحقیق قرار نیست ثابت کند ایدهٔ ما درست است. قرار است فاصلهٔ میان تصور تیم و واقعیت زندگی کاربر را کمتر کند. بسته به مسئله می‌توان از مصاحبه، مشاهده، تحلیل داده، بررسی درخواست‌های پشتیبانی، تست فعلی محصول و مطالعهٔ رقبا استفاده کرد.

در مصاحبه تلاش می‌کنم به جای سؤال «آیا این قابلیت را دوست دارید؟» دربارهٔ رفتار واقعی بپرسم: آخرین بار چه زمانی این کار را انجام دادید؟ کجا متوقف شدید؟ چه راه جایگزینی داشتید؟ چه چیزی باعث شد تصمیم بگیرید؟

آدم‌ها در پیش‌بینی رفتار آینده دقیق نیستند، اما روایت تجربهٔ گذشته نشانه‌های خوبی می‌دهد. چند مصاحبه به‌تنهایی حقیقت قطعی نمی‌سازد؛ یافته‌ها باید با داده‌های دیگر و موارد مخالف سنجیده شوند.

مرحلهٔ سوم: الگوها را به فرصت تبدیل کنیم

بعد از تحقیق، وسوسه می‌شویم همهٔ جمله‌ها را در چند sticky note مرتب کنیم و سریع وارد طراحی شویم. بخش مهم‌تر این است که بفهمیم کدام الگو واقعاً تکرار شده، شدت مشکل چقدر است و حل آن چه اثری روی کاربر و محصول دارد.

من یافته‌ها را به سه دسته تقسیم می‌کنم:

  • چیزی که شواهد کافی برایش داریم؛
  • فرضیه‌ای که ارزش آزمودن دارد؛
  • نکته‌ای جالب که فعلاً نباید بر اساسش تصمیم بگیریم.

این تفکیک جلوی اعتماد بیش از حد به یک نقل‌قول جذاب را می‌گیرد. بعد فرصت‌ها را اولویت‌بندی می‌کنیم: کدام مشکل پرتکرارتر، پرریسک‌تر و با هدف محصول مرتبط‌تر است؟

مرحلهٔ چهارم: جریان و معماری اطلاعات

پیش از جزئیات بصری، باید مشخص شود کاربر چه مسیری را طی می‌کند و چه اطلاعاتی در هر لحظه لازم دارد. User flow کمک می‌کند نقطه‌های تصمیم، مسیرهای جایگزین و بازگشت از خطا را ببینیم. معماری اطلاعات هم تعیین می‌کند محتوا چطور گروه‌بندی و نام‌گذاری شود.

یک جریان خوب فقط مسیر موفق را نشان نمی‌دهد. اگر کاربر مدرک لازم را نداشت چه؟ اگر پرداخت شکست خورد چه؟ اگر وسط کار خارج شد، از کجا ادامه می‌دهد؟ اگر دسترسی لازم را نداشت، پیام بعدی چیست؟

همین حالت‌ها تجربهٔ واقعی را می‌سازند. اسکرین‌شات مرتب مسیر ایده‌آل برای ارائه خوب است، اما محصول باید برای زندگی نامرتب کاربران آماده باشد.

مرحلهٔ پنجم: وایرفریم و نمونهٔ اولیه

وایرفریم راهی ارزان برای فکر کردن به ساختار است. در این مرحله لازم نیست همه‌چیز زیبا باشد. می‌خواهیم بفهمیم ترتیب اطلاعات و اقدام‌ها منطقی است یا نه. چند طرح ساده به تیم اجازه می‌دهد دربارهٔ گزینه‌ها حرف بزند، بدون اینکه به جزئیات پرهزینه وابسته شود.

بعد نمونهٔ اولیه کمک می‌کند جریان قابل تجربه شود. میزان جزئیات نمونه به سؤال ما بستگی دارد. برای سنجش ترتیب مراحل، یک پروتوتایپ ساده کافی است. برای بررسی اعتماد به صفحهٔ پرداخت، محتوا و ظاهر واقعی‌تر لازم است.

نمونه هدف نیست؛ ابزار یادگیری است. اگر برای نمایش مهارت بصری آن را بیش از حد کامل کنیم، ممکن است از سؤال اصلی دور شویم.

مرحلهٔ ششم: تست کاربردپذیری

در تست، به کاربر یک هدف واقعی می‌دهیم و مشاهده می‌کنیم چطور به آن نزدیک می‌شود. قرار نیست طرح را برایش توضیح دهیم. هر جا مجبور شویم بگوییم «اینجا باید این دکمه را بزنی»، اطلاعات ارزشمندی دربارهٔ ضعف رابط گرفته‌ایم.

در تست فقط موفق یا ناموفق بودن مهم نیست. مکث‌ها، برگشت‌ها، حدس‌ها، جمله‌هایی که کاربر با خودش می‌گوید و اطمینان او بعد از انجام کار هم معنا دارند. گاهی کاربر کار را تمام می‌کند، اما مطمئن نیست نتیجه ثبت شده؛ این تجربه هنوز کامل نیست.

بعد از تست، همهٔ بازخوردها را برابر نمی‌بینم. مشکل باید بر اساس شدت، تکرار و اثرش روی هدف اولویت بگیرد. هر پیشنهادی هم الزاماً راه‌حل درست نیست؛ کاربر در توصیف مشکل متخصص است، اما طراحی راه‌حل مسئولیت تیم محصول است.

مرحلهٔ هفتم: انتشار پایان کار نیست

رفتار واقعی بعد از انتشار با جلسهٔ تست فرق دارد. داده‌های محصول، پیام‌های پشتیبانی و بازخورد مستقیم نشان می‌دهند کدام فرض‌ها درست بوده‌اند. باید از قبل معیار داشته باشیم: کاهش خطا، تکمیل سریع‌تر، افزایش فعال‌سازی یا بالا رفتن اطمینان کاربر؟

عدد بدون زمینه هم کافی نیست. ممکن است نرخ تکمیل بیشتر شود اما درخواست پشتیبانی بالا برود. ممکن است مسیر کوتاه‌تر شود ولی کاربران تصمیم اشتباه بیشتری بگیرند. ترکیب دادهٔ کمی و کیفی تصویر کامل‌تری می‌دهد.

UX چرخه‌ای از ساختن و یاد گرفتن است، نه پروژه‌ای که با تحویل فایل بسته شود.

چند اشتباه رایج در UX

اول اینکه تحقیق را با پرسیدن نظر دربارهٔ راه‌حل اشتباه بگیریم. دوم اینکه personaهای زیبا بسازیم ولی هیچ تصمیمی را تغییر ندهند. سوم اینکه فقط مسیر happy path را طراحی کنیم. چهارم اینکه موفقیت را با رضایت جلسهٔ ارائه بسنجیم، نه رفتار بعد از انتشار.

اشتباه مهم دیگر تلاش برای حذف تمام اصطکاک است. اصطکاک بد کاربر را بی‌دلیل کند می‌کند؛ اصطکاک مفید جلوی اشتباه، حذف ناخواسته یا تصمیم پرریسک را می‌گیرد. طراحی خوب تفاوت این دو را می‌فهمد.

پرسش‌های متداول

خروجی طراح تجربه کاربری چیست؟

بسته به مسئله می‌تواند گزارش تحقیق، نقشهٔ سفر، تعریف مسئله، جریان کاربر، معماری اطلاعات، وایرفریم، پروتوتایپ، نتیجهٔ تست و پیشنهاد بهبود باشد. ارزش اصلی در تصمیمی است که این خروجی‌ها بهتر می‌کنند.

آیا UX فقط برای اپلیکیشن و سایت است؟

نه. هر محصول یا خدمتی که انسان با آن تجربه دارد می‌تواند موضوع طراحی تجربه باشد؛ از دستگاه خودپرداز تا فرایند مراجعه به درمانگاه. در این سایت تمرکز من بیشتر روی محصولات دیجیتال است.

تفاوت UX و UI چیست؟

UX کل مسیر و کیفیت تجربه را بررسی می‌کند؛ UI لایهٔ دیداری و تعاملی آن مسیر است. در مقالهٔ «UI و UX چیست» این تفاوت را با مثال بلیت قطار توضیح داده‌ام.

جمع‌بندی من

من، محمد عبدی، طراحی تجربه کاربری را هنر حدس زدن خواستهٔ مردم نمی‌دانم. UX یعنی مسئله را روشن کنیم، با شواهد جلو برویم، راه‌حل را زود و ارزان بیازماییم و بعد از انتشار مسئول نتیجه بمانیم.

گاهی بهترین خروجی یک صفحهٔ تازه است و گاهی حذف یک مرحله، تغییر یک جمله یا نشان دادن اطلاعاتی که اعتماد می‌سازد. معیار، تعداد وایرفریم‌ها نیست؛ این است که آیا کاربر راحت‌تر، مطمئن‌تر و با خطای کمتر به هدفش رسیده یا نه.

نوشتهٔ محمد عبدی، طراح محصول و تجربهٔ کاربری.

منابع و مطالعهٔ بیشتر