تجربه از انجام یک کار شروع می‌شود
کاربر می‌خواهد نوبت بگیرد، یک فایل پیدا کند یا وضعیت درخواستش را بداند. ممکن است ظاهر صفحه زیبا باشد و او همچنان نداند قدم بعدی چیست. UX دربارهٔ رابطهٔ نیاز، رفتار محصول و نتیجهٔ استفاده است. طراحی باید کمک کند کار لازم در زمینهٔ واقعی انجام شود. آسان بودن، مفید بودن و قابل دسترس بودن، بخش‌های مرتبط این رابطه‌اند؛ هیچ‌کدام را نمی‌توان از روی یک screenshot کامل تأیید کرد. تجربهٔ کاربر از یک صفحهٔ موفق فراتر می‌رود و خطا، انتظار و بازگشت را هم شامل می‌شود.
تعبیر UX خوب همیشه نامرئی است، قاعدهٔ عمومی مناسبی نیست. یک راهنمای روشن، توضیح صادقانهٔ خطا یا امکان کنترل داده می‌تواند دیده شود و مفید باشد. همچنین UX را نباید فقط خوشایند بودن لحظه‌ای تعریف کرد؛ کاربر ممکن است تصمیمی دشوار اما لازم داشته باشد. هدف این راهنما، روشن کردن اصول و مسیر تصمیم است. تمرین‌های آن فرضی‌اند و پژوهش، تست کاربر یا آمار واقعی در این مقاله اجرا و گزارش نشده است.
نیاز را با درخواست یک ویژگی اشتباه نگیرید
جملهٔ «یک dashboard جدید می‌خواهیم» هنوز نیاز کاربر را توضیح نمی‌دهد. شاید مسئله پیدا کردن وضعیت یک سفارش باشد و یک فهرست ساده پاسخ بهتری بدهد. نیاز را به کاری که فرد می‌خواهد انجام دهد، زمینه و مانع فعلی وصل کنید. راه‌حل‌های احتمالی بعداً مقایسه می‌شوند. اگر از ابتدا شکل صفحه قطعی شود، تحقیق ممکن است فقط برای تأیید همان انتخاب استفاده شود. طراحی بهتر اجازه می‌دهد دادهٔ تازه، فرض نخست را عوض کند.
برای تمرین، سرویس فرضی رزرو را در نظر بگیرید. نیاز می‌تواند انتخاب زمان مناسب و مطمئن شدن از ثبت آن باشد. داشتن انیمیشن در تقویم یا رنگ جدید دکمه، پاسخ مستقیم این نیاز نیست. ابتدا روشن کنید کاربر چه اطلاعاتی برای تصمیم لازم دارد: خدمت، زمان، محدودیت و نتیجهٔ ثبت. سپس معلوم می‌شود کدام کنترل و صفحه لازم است. نوشتهٔ کارگاه UI/UX در Figma یک مسیر محدود برای همین نمونه‌سازی ارائه می‌کند.
Research را با پرسش مشخص طراحی کنید
پیش از انتخاب روش، بنویسید کدام عدم قطعیت باید کم شود. اگر می‌خواهید زمینهٔ کار و مشکل فعلی را بشناسید، مصاحبه یا مشاهده می‌تواند مناسب باشد. اگر می‌خواهید بدانید فرد یک control را پیدا می‌کند، بررسی کاربردپذیری ابزار دیگری است. یک survey عمومی، همهٔ این پرسش‌ها را پاسخ نمی‌دهد. راهنمای برنامه‌ریزی User Research ارتباط پرسش، روش و مرحلهٔ کار را توضیح می‌دهد.
نمونهٔ مخاطب باید با کسانی که محصول برای آن‌ها طراحی می‌شود مرتبط باشد. فقط همکاران آشنا با پروژه، جای همهٔ کاربران را نمی‌گیرند. تفاوت دستگاه، زبان، مهارت و شرایط استفاده را در برنامه ببینید. تصمیم دربارهٔ تعداد افراد هم به نوع پرسش و روش وابسته است؛ یک عدد ثابت برای همهٔ تحقیقات نداریم. نتیجهٔ گروه محدود باید با همان محدوده گزارش شود و به درصد موفقیت کل جمعیت تبدیل نشود. شفافیت دربارهٔ محدودیت، بخشی از کیفیت پژوهش است.
گفتهٔ کاربر و رفتار مشاهده‌شده متفاوت‌اند
در مصاحبه، فرد ممکن است دربارهٔ عادت خود توضیح دهد؛ در استفادهٔ واقعی ممکن است مسیر دیگری دنبال کند. این اختلاف الزاماً به معنی اشتباه یا بی‌صداقتی نیست، بلکه روش‌های مختلف اطلاعات متفاوت می‌دهند. دربارهٔ آخرین تجربهٔ مشخص بپرسید و از سؤال‌های هدایت‌کننده پرهیز کنید. راهنمای مصاحبهٔ عمیق ساخت جلسه و پرسش را شرح می‌دهد. تأیید مستقیم ایدهٔ طراح، شاهد کافی برای قابل استفاده بودن آن نیست.
یادداشت پژوهش را به مشاهده و برداشت تقسیم کنید. «فرد سه بار به مرحلهٔ قبل برگشت» مشاهده است؛ «چیدمان ضعیف بود» تفسیر نیازمند بررسی است. ممکن است متن، ترتیب یا انتظار فرد علت باشد. وقتی برداشت به عنوان واقعیت ثبت شود، تیم روی راه‌حل اشتباه توافق می‌کند. برای هر مسئله، شاهد و زمینه را نگه دارید و قبل از اصلاح، چند توضیح ممکن را بررسی کنید. این کار قرار نیست تصمیم را بی‌پایان عقب بیندازد؛ دلیل تصمیم را قابل بررسی می‌کند.
Usability و utility دو پرسش جدا دارند
Utility می‌پرسد آیا محصول قابلیت لازم را فراهم می‌کند. Usability می‌پرسد فرد می‌تواند از آن قابلیت برای کارش استفاده کند. یک رابط بسیار ساده برای کاری که نیاز کاربر را پاسخ نمی‌دهد، مفید نشده است. از طرف دیگر، قابلیت کامل با navigation مبهم می‌تواند استفاده را سخت کند. برای سرویس رزرو، دیدن زمان آزاد و فهمیدن وضعیت ثبت، هر دو لازم‌اند. طراحی باید نتیجهٔ کار را مشخص کند و کاربر را مجبور نکند از تغییر رنگ دکمه حدس بزند ثبت انجام شده است.
بازخورد مناسب، وضعیت واقعی را بیان می‌کند. هنگام ارسال، معلوم باشد درخواست در حال پردازش است؛ هنگام خطا، راه اصلاح وجود داشته باشد؛ پس از موفقیت، جزئیات نتیجه قابل بازیابی باشند. وضعیت بارگذاری و Skeleton بخشی از این تجربه را توضیح می‌دهد. حرکت یا متن آرامش‌بخش، شکست واقعی را حذف نمی‌کند. اگر سیستم هنوز منتظر پاسخ است، نباید موفقیت قطعی نشان دهد. صداقت دربارهٔ وضعیت، به اعتماد قابل استفاده کمک می‌کند.
Accessibility از ابتدا بخشی از نیاز است
افراد با روش‌های مختلف به محصول دسترسی دارند: keyboard، screen reader، بزرگ‌نمایی یا محیط دارای محدودیت نور و صدا. طراحی نباید یک مدل ثابت از کاربر را پیش‌فرض همه قرار دهد. Accessibility، usability و inclusion هم‌پوشانی دارند ولی مترادف کامل نیستند. توضیح W3C دربارهٔ این مفاهیم رابطهٔ آن‌ها را روشن می‌کند. رعایت یک checklist خودکار، به تنهایی تجربهٔ کامل همهٔ افراد را ثابت نمی‌کند.
درگیر کردن افراد دارای نیازهای متفاوت، مسئله‌های واقعی‌تری از حدس طراح نشان می‌دهد. روش پژوهش و مواد جلسه هم باید برای مشارکت آن‌ها مناسب باشد. راهنمای مشارکت کاربران برای Accessibility این مسئولیت را توضیح می‌دهد. نوشتهٔ دسترس‌پذیری از روز اول به ساختار رابط می‌پردازد. این اصول باید در brief و componentها بمانند، نه اینکه بعد از نهایی شدن صفحه به یک تیم دیگر واگذار شوند.
اطلاعات را بر اساس تصمیم کاربر گروه‌بندی کنید
Navigation باید دسته‌بندی قابل فهم برای مخاطب داشته باشد. نام داخلی واحدهای سازمان همیشه نام مناسبی برای منوی محصول نیست. اطلاعات لازم برای یک تصمیم را کنار هم قرار دهید و ترتیب را با جریان کار هماهنگ کنید. اگر جزئیات مهم فقط در tooltip پنهان باشند، بعضی کاربران ممکن است آن‌ها را نبینند. Wireframe و ساختار صفحه برای بررسی همین روابط پیش از جزئیات بصری مناسب است. ساختار خوب از پرسش کاربر شروع می‌شود.
متن control باید عمل یا نتیجه را روشن بگوید. «ادامه» گاهی کافی است و گاهی مقصد را پنهان می‌کند. نام «بررسی نوبت» می‌تواند قبل از ثبت نهایی توقع دقیق‌تری بسازد. پیام خطا باید مسئله و مسیر اصلاح را بیان کند، بدون سرزنش کاربر. مقدارهای پیش‌فرض هم باید با نیاز واقعی سازگار باشند و تصمیم حساس را پنهان نکنند. ظاهر خوشایند نباید کاربر را به انتخابی هل دهد که معنی یا اثرش را نفهمیده است.
Prototype باید پرسش را قابل مشاهده کند
Prototype می‌تواند کاغذی، کم‌جزئیات یا تعاملی باشد. سطح جزئیات را بر اساس تصمیم باز انتخاب کنید. اگر مسئله ترتیب مرحله‌هاست، رنگ نهایی و animation شاید لازم نباشد. اگر سؤال دربارهٔ رفتار یک control است، نمونهٔ تعاملی محدود می‌تواند مفیدتر باشد. Prototype نشان دادن همهٔ امکانات آینده نیست. باید معلوم باشد کدام مسیرها شبیه‌سازی شده‌اند و کدام داده‌ها فرضی‌اند تا برداشت از نتیجه درست بماند.
در آزمون کاربردپذیری، task به هدف کاربر اشاره می‌کند و راه‌حل را لو نمی‌دهد. مشاهدهٔ پیدا کردن زمان و اصلاح آن، با پرسیدن «این صفحه را دوست دارید؟» شاهد یکسانی نمی‌دهد. راهنمای moderated usability testing روش اجرای جلسه را شرح می‌دهد. نتیجه را به رفتار و مسئلهٔ مشخص وصل کنید. یک جلسهٔ مثبت، تمام مسیرهای خطا و تمام مخاطب‌ها را تأیید نمی‌کند.
Iteration باید مسئلهٔ مشخص را پاسخ دهد
اگر کاربر عنوان مرحله را اشتباه فهمید، تغییر سایهٔ کارت پاسخ مستقیم نیست. اگر دکمه پیدا نشد، hierarchy، محل و متن را بررسی کنید. اصلاح‌های هم‌زمان و بی‌ارتباط، فهم اثر تغییر را دشوار می‌کنند. برای هر اصلاح، علت و انتظار را کوتاه ثبت کنید. چرخهٔ research، طراحی و بررسی همیشه یک مسیر خطی نیست؛ ممکن است یافتهٔ تازه پرسش قبلی را عوض کند. بازگشت به فرض، شکست پروژه محسوب نمی‌شود وقتی دلیل مشخص دارد.
موفقیت را با نتیجهٔ کار تعریف کنید
شاخص باید به هدف محصول و کاربر مرتبط باشد. تعداد کلیک کمتر همیشه بهتر نیست؛ حذف مرحلهٔ توضیح مهم شاید خطا را بیشتر کند. زمان کوتاه‌تر هم بدون موفقیت و فهم کافی معیار کامل نیست. دربارهٔ نتیجهٔ ثبت، خطا، نیاز به کمک و امکان بازگشت اطلاعات مناسب جمع کنید و محدودهٔ داده را حفظ کنید. جمع‌آوری بی‌دلیل دادهٔ شخصی، صرفاً برای کامل شدن dashboard، نیاز پژوهشی روشن ایجاد نمی‌کند. روش دریافت و نگهداری داده باید مناسب و شفاف باشد.
UX در محصول منتشرشده هم به تغییر محتوا، وضعیت سیستم و نیاز تازه وابسته است. قرارداد طراحی و متن باید همراه اجرا نگهداری شوند. برای توضیح تصمیم به تیم، طراحی ارائه کمک می‌کند شاهد و محدودیت در روایت بمانند. اصول بنیادی زمانی مفیدند که در تصمیم‌های کوچک دیده شوند: اطلاعات لازم، عمل واضح، بازخورد درست و مسیر اصلاح. هیچ شعار کلی جای بررسی همین رفتارهای واقعی را نمی‌گیرد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!