سه رابط کاربری (رابط کاربری) به یک کافه می روند! اولین رابط کاربری یک نوشیدنی سفارش می دهد و پس از آن چندین نوشیدنی دیگر. چند ساعت بعد درخواست صورت حساب می دهد و کافه را ترک می کند. دومین رابط کاربری یک نوشیدنی سفارش می دهد و پولش را پرداخت می کند نوشیدنی دیگری سفارش می دهد و مجددا برای آن پرداخت انجام می دهد و به همین ترتیب ادامه می دهد. چند ساعت بعد او کافه را ترک می کند. سومین رابط کاربری بلافاصله بعد از ورود به کافه درحالیکه قبلا نوشیدنی خورده است و دیگر نیازی به صرف چیزی ندارد کافه را بلافاصله بعد از وارد شدن ترک می کند – او می داند که چگونه کافه ها کار می کنند و نمی خواهد که زمان خود را در آنجا تلف کند. آیا شما در مورد این سومین رابط کاربری چیزی شنیده اید؟ آن را  "رابط کاربری خوش بینانه" می نامند.

طراحی رابط کاربری خوش بینانه در مورد نگاه کردن به وب سایت از طریق عینک های قرمز رزی نیست - حداقل تنها در مورد آن نمی باشد.

در حالیه قبلاَ در مورد بهینه سازی عملکرد روانشناسی در تعدادی از کنفرانس های اختصاص داده شده هم به توسعه فرانت اند و هم طراحی UX صحبت شده است، من شگفت زده شده بودم چقدر کم موضوع طراحی رابط کاربری خوش بینانه در جامعه مورد توجه قرار گرفته است. صادقانه بگویم، این اصطلاح حتی به خوبی تعریف نشده است. در این مقاله، ما متوجه خواهیم شد که مفاهیم آن بر چه مبنایی است، و ما به برخی از نمونه های آن نگاهی خواهیم انداخت و همچنین پیشینه روانشناسی آن را مرور خواهیم نمود. پس از آن، ما ملاحظات و نکات اصلی در مورد نحوه اجرا و  کنترل این روش UX را بررسی خواهیم کرد.

اما قبل از اینکه بحث را شروع کنیم، درواقع می توان گفت هیچ چیز واحدی را نمی توان به عنوان "رابط کاربری خوش بینانه" نام گذاری نمود. بلکه رابط کاربری خوش بینانه، مدل ذهنی در آن سوی بکارگیری یک رابط است. طراحی رابط کاربری خوش بینانه دارای تاریخچه و منطق خاص خود می باشد.

روزی روزگاری

مدتها پیش - زمانی که کلمه "tweet" بیشتر به پرندگان نسبت داده می شد ( توئیت در انگلیسی به معنای جیک جیک پرنده است) ، اپل در آستانه ورشکستگی قرار داشت و مردم همچنان شماره فکس خود را روی کارت های کاری خود قرار می دادند – رابط های وب کاملا تارک الدنیا بودند و اکثریت قریب به اتفاق آنها هیچ اشاره ای به خوش بینی نداشتند. برای مثال، فعالیت های متقابل با یک دکمه میتواند یک سناریو شبیه به سناریوی زیر داشته باشد:

1. کاربر یک دکمه را کلیک می کند.
2. این دکمه به حالت غیر فعال تبدیل می شود.
3. یک درخواست به سرور ارسال می شود.
4. پاسخ از سرور به صفحه ارسال می شود.
5. صفحه مجددا بارگذاری می شود تا وضعیت پاسخ را منعکس نماید.

در گذشته، رابط های کاربری تقریبا به هیچ وجه خوش بینانه نبودند.

این امر ممکن است در سال 2016 کاملا ناکارآمد باشد؛ با این حال، به اندازه کافی شگفت آور اینکه همین سناریو همچنان در بسیاری از صفحات وب و برنامه های کاربردی استفاده شده است و هنوز بخشی از روند تعامل برای بسیاری از وب سایت ها است. دلیل آن این است که تقریبا قابل پیش بینی است و کمابیش بدون خطا: کاربر می داند که عمل از سرور درخواست شده است (حالت غیر فعال شده دکمه حاکی از این امر است) و هنگامی که سرور پاسخ می دهد، صفحه به روز شده به وضوح پایان این تعامل مشتری-سرور-مشتری را نشان می دهد. مشکلات این نوع تعامل کاملا واضح است:

• کاربر باید صبر کند: در حال حاضر می دانیم که حتی کوتاه ترین تاخیر در زمان پاسخ سرور، تاثیر منفی بر روی درک کاربر نه تنها از آن صفحه وب سایت دارد بلکه درک منفی از کل نام تجاری مربوط به آن ایجاد می کند.
• هر بار که کاربر پاسخ خود را به درخواست خود دریافت می کند، کار بسیار خراب تر می شود (یک صفحه جدید بارگذاری می شود به جای آن که صفحه کنونی به روز شود) بطوری که کار کاربر را مختل می کند و ممکن است رشته افکار او را نیز تحت تاثیر قرار دهد. اگرچه ما در این مورد لزوما در مورد درخواست های چند وظیفه ای صحبت نمی کنیم، هر گونه تغییر زمینه ذهنی ناخوشایند است. بنابراین، اگر یک عمل ذاتا به معنای تغییر و سوئیچ زمینه و بافت سایت نیست (پرداخت آنلاین یک مثال خوب از زمانی است که یک سوئیچ طبیعی است)، سوئیچ و تغیر، یک تناقض غیر دوستانه از گفتگوی بین کاربر و سیستم را ایجاد می کند.

روزهای خوب و نه خیلی دور

سپس، به اصطلاح Web 2.0 وارد عرصه شد و حالت های جدید تعامل با صفحات وب را فراهم نمود. در هسته آنها XMLHttpRequest و AJAX قرار داشت. این حالت های جدید تعامل با " چرخنده ها (spinners)" انجام می شد: ساده ترین شکل شاخص پیشرفت که تنها هدف آن برقراری ارتباط با کاربر بود که بگوید سیستم مشغول اجرای برخی عملیات ها است. حال، پس از دریافت پاسخ از سرور، نیازی به بارگذاری مجدد صفحه نیست. می توانیم به جای آن بخشی از صفحه ارائه شده را به روز رسانی کنیم. این امر باعث شد که وب سایت پویا تر باشد، در حالی که اجازه می دهد تجربه های راحت تر و جذابتری برای کاربران ایجاد شود. تعامل معمولی با یک دکمه می تواند اینگونه باشد:

1. کاربر یک دکمه را کلیک می کند.
2. این دکمه به حالت غیرفعال در می آید و یک علامت چرخنده خاصی روی دکمه نشان داده می شود که نشان می دهد سیستم کار می کند.
3. یک درخواست به سرور ارسال می شود.
4. پاسخ سرور به صفحه ارسال می شود.
5. وضعیت بصری دکمه و صفحه با توجه به وضعیت پاسخ به روز می شود.

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

XMLHttpRequest و علامت های چرخنده یکی از مسائل روش های قدیمی تعامل را حل می کنند: یک تغییر و سوئیچ مخرب در بافت سایت پس از دریافت پاسخ سرور.

این نوع الگوی تعامل متقابل در همه جا در رسانه های دیجیتالی به طور گسترده مورد استفاده قرار گرفته است. اما یک مسئله باقی می ماند: کاربران هنوز هم باید منتظر پاسخ سرور باشند. بله، ما می توانیم سرویس هایمان را مجبور کنیم سریعتر پاسخ دهند، اما مهم نیست که چقدر سعی می کنیم زیرساخت را سرعت دهیم، کاربران هنوز هم باید صبر کنند. باز هم، کاربران دوست ندارند صبر کنند. به عنوان مثال، تحقیقات نشان می دهد که 78 درصد از استفاده کنندگان احساسات منفی را در نتیجه وب سایت های آهسته یا غیر قابل اعتماد پیدا می کنند. علاوه بر این، بر اساس نظرسنجی که توسط Harris Interactive برای Tealeaf انجام شد، 23 درصد کاربران اعتراف به بدوبیراه گفتن به موبایل ، 11 درصد اعتراف به فریاد زدن و 4 درصد نیز موبایل خود را در واقع انداختند وقتی که یک مشکل با یک انتقال آنلاین داشته اند. تاخیر باعث آن مشکلات است.

حدود 78٪ از استفاده کنندگان احساسات منفی را در نتیجه وب سایت های کند و یا غیر قابل اعتماد پیدا می کنند.

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

رابط کاربری خوش بینانه

همانطور که قبلا اشاره شد، رابط کاربری خوش بینانه چیزی جز یک راه رسیدگی به تعامل بین کامپیوتر و کاربر نیست. برای درک ایده های اصلی در ورای آن، ما سناریوی " کاربر بر روی یک دکمه کلیک می کند " را در نظر می گیریم. اما اصول آن برای تقریبا هر گونه تعامل متقابلی یکسان است که شما ممکن است مایل به ایجاد بصورت خوش بینانه باشید. با توجه به فرهنگ لغت انگلیسی آکسفورد:

خوش بینانه ( op-ti-mis-tic، adj ) : امیدوار و مطمئن در مورد آینده.

بیایید با بخش "مطمئن در مورد آینده" شروع کنیم.

شما چه فکر میکنید: چند بار سرور شما خطایی در پاسخ به عمل کاربر ارسال میکند؟ به عنوان مثال، آیا API شما اغلب هنگامی که کاربر بر روی یک دکمه کلیک کنید با نقص مواجه می شود؟ یا شاید زمانی که کاربران بر روی یک پیوند کلیک می کنند، بسیار با نقص روبرو می شود؟ صادقانه بگویم، من این طور فکر نمی کنم. البته، این امر بر اساس نوع API، بار سرور، سطح رفع خطا و سایر عواملی که شما به عنوان یک توسعه دهنده فرانت اند یا متخصص UX ممکن است مایل به مداخله در آن نباشید متفاوت باشد، اما تا زمانی که API پایدار و قابل پیش بینی باشد و فرانت اند به طور صحیح با تعاملات و اعمال مشروع در رابط کاربری ارتباط برقرار می کند آنگاه تعداد خطاها در پاسخ به اقدامات آغاز شده توسط کاربر بسیار کم خواهد بود. من می گویم که هرگز نباید بیش از 1 تا 3 درصد باشد. به این معنی که در 97 تا 99٪  از موارد که کاربر بر روی یک دکمه در وب سایت کلیک می کند، پاسخ سرور باید بدون خطا باشد. این امر شایسته است که در یک دیدگاه بهتر مورد بررسی قرار گیرد:

رابط های کاربری خوش بینانه بر اساس این فرض هستند که وقتی کاربر بر روی یک دکمه کلیک می کند، سرور باید یک پاسخ موفقیت آمیز را در 97 تا 99٪ موارد نشان دهد.

در مورد این مورد یک لحظه فکر کنید: اگر ما 97 تا 99 درصد در مورد پاسخ موفقیت آمیز اطمینان داشتیم، آنگاه می توانیم در مورد آینده این پاسخ ها مطمئن باشیم - خوب، حداقل در مورد آینده نسبت به گربه شرویدینگر مطمئن تر بودیم. در اینجا ما می توانیم یک داستان کاملا جدیدی در مورد تعامل های متقابل با دکمه بنویسیم:

1. کاربر یک دکمه را کلیک می کند.
2. وضعیت بصری دکمه بلافاصله به حالت موفقیت آمیز در می آید.

خودشه! حداقل از نقطه نظر کاربر، چیزی بیشتر برای آن وجود ندارد - هیچ انتظار، هیچ زل زدنی به یک دکمه غیرفعال، و حتی بدتر از آن زل زدن به یک چرخنده آزار دهنده ای وجود ندارد. تعامل بدون نقص است، بدون اینکه سیستم به شدت در حال سعی باشد که به کاربر مداوماَ درباره خود یادآوری نماید.

در یک تعامل رابط کاربری خوش بینانه هیچ جایی برای یک علامت چرخنده یا دکمه غیرفعال وجود ندارد.

از ديدگاه طراح، چرخه کامل به شرح زير است:

1. کاربر یک دکمه را کلیک می کند.
2. وضعیت بصری دکمه بلافاصله به حالت موفقیت آمیز در می آید.
3. درخواست به سرور ارسال می شود.
4. پاسخ سرور به صفحه ارسال می شود.
5. در 97 تا 99 درصد موارد، ما می دانیم که پاسخ موفقیت آمیز خواهد بود و بنابراین نیازی به زحمت دادن به کاربر وجودندارد.
6. فقط در صورتی که درخواست با شکست مواجه شود، سیستم صحبت خواهد کرد. در حال حاضر در مورد این مورد نگران نباشید - بعدا در این مقاله به این نکته خواهیم رسید.

بیایید به نمونه هایی از تعاملات خوش بینانه نگاه کنیم. شما احتمالا با دکمه های "پسندیدن" آشنا هستید، همانطور که در فیس بوک و توییتر یافت می شود. بیایید به دومین مورد یعنی تویتر نگاه بیندازیم.

این عمل با کلیک بر روی دکمه، آغاز می شود. اما به حالت بصری دکمه هنگامی که کاربر دیگر آن را فشار نمی دهد یا در اطراف آن شنا نیست دقت کنید. این دکمه (پسندیدن یا like)  بلافاصله به حالت موفقیت آمیز تبدیل می شود!

پس از کلیک بر روی دکمه پسندیدن، توییتر بلافاصله به طور خارق العاده ای به حالت موفقیت آمیز آن دکمه را به روز رسانی می کند.

بیایید ببینیم چه چیزی در زبانه "شبکه" در ابزار توسعه دهنده مرورگر ما اتفاق می افتد.

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

برگه "Network" نشان می دهد که درخواست به سرور ارسال شده است اما هنوز هم در حال انجام است. شمارنده "پسندیدن" افزایش یافته است، اما با تغییر رنگ، رابط کاربری به طور واضح ارتباط موفقیت آمیز کاربر را، حتی قبل از دریافت پاسخ از سرور نشان می دهد.

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

در حالی که دکمه ی پسندیدن در حالت موفقیت آمیز بصورت بصری قرار دارد، شمارنده تنها بعد از آنکه پاسخ سرور موفقیت را تأیید می کند به روز رسانی می شود.

مثال دیگری از تعامل خوش بینانه در فیس بوک در دکمه ی پسندیدن ان دیده می شود. سناریو بسیار شبیه سناریوی تویتر است، به جز اینکه فیس بوک فورا، همراه با رنگ موفقیت آمیز دکمه، بدون انتظار برای پاسخ سرور،  شمارنده را  نیز به روزرسانی می کند.

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

با این حال، به یک چیز در اینجا بایستی توجه داشته باشید. اگر ما به زمان پاسخ سرور نگاه کنیم، خواهیم دید که کمی بیش از 1 ثانیه است. با توجه به اینکه مدل RAIL توصیه می کند 100 میلی ثانیه به عنوان زمان پاسخ مطلوب برای یک تعامل ساده است، این زمان به طور نرمال خیلی بیشتر است. با این حال، کاربر به دلیل طبیعت خوش بینانه این تعامل، هیچ زمان انتظار درک شده ای در این مورد نمی بیند. خیلی عالی! این نمونه دیگری از بهینه سازی عملکرد روانشناسی است.

اما اجازه دهید به وجه دیگر قضیه برویم: هنوز هم 1 تا 3 درصد احتمال دارد که سرور پیام خطایی بازگرداند. یا شاید کاربر خیلی ساده آفلاین باشد یا به احتمال زیاد، شاید سرور یک پاسخی را باز گرداند که از لحاظ فنی موفقیت آمیز است اما پاسخ حاوی اطلاعاتی است که می گوید باید بیشتر توسط مسئول آن پردازش شود. در نتیجه، کاربر یک شاخص شکست را دریافت نخواهد کرد، اما ما نیز نمیتوانیم پاسخ را یک موفقیت در نظر بگیریم. برای درک چگونگی رفتار با چنین مواردی، ما باید در درجه اول درک کنیم که چرا و چگونه رابط های کاربری خوش بینانه از نظر روانشناختی کار می کنند.

روانشناسی آن سوی رابط کاربری خوش بینانه

تا کنون، من از هیچ کسی نشنیده ام در مورد تعاملات خوش بینانه در شبکه های اجتماعی شکایت کند. بنابراین، بگذارید بگوییم این مثالها ما را قانع می کنند که رابط کاربری های خوش بینانه کار می کنند. اما چرا آنها برای کاربران کار می کنند؟ آنها فقط به این دلیل کار می کنند که مردم از انتظار بیزار هستند. جواب این است، مردم! شما می توانید به بخش بعدی مقاله بروید.

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

مطالعه مغز به ما کمک می کند تا روانشناسی موجود در پشت این که چرا رابط های کاربری خوش بینانه کار می کنند را درک کنیم.

رابط کاربری خوش بینانه دارای دو جزء اساسی است که ارزش تحلیل روانشناختی را دارند:

• پاسخ سریع به عمل کاربر؛
• رسیدگی به شکست های احتمالی در سرور، شبکه و جاهای دیگر.

پاسخ سریع به اقدام کاربر

هنگامی که ما در مورد طراحی رابط کاربری خوش بینانه صحبت می کنیم، در واقع ما در مورد زمان پاسخ مطلوب در تعامل انسان و کامپیوتر صحبت می کنیم. توصیه هایی برای این نوع از ارتباطات تا اواسط سال 1968 صورت گرفته است. در آن زمان، رابرت بیل میلر، قطعه معاصر خود را "زمان پاسخ در تراکنش های مکالمه مرد و کامپیوتر" (PDF) منتشر کرد، که در آن او تا 17 انواع پاسخ هایی که کاربر می تواند از یک رایانه دریافت کند. میلر یکی از آن ها را "پاسخ به کنترل فعال سازی" می نامد - تاخیر بین افسردگی کلید و بازخورد بصری. حتی در سال 1968، نباید بیش از 0.1 تا 0.2 ثانیه باشد. بله، مدل RAIL اولین کسی نیست که این را توصیه کند - مشاوره حدود 50 سال است. میلر می گوید، حتی این تاخیر کوتاه در بازخورد ممکن است برای کاربران ماهر بسیار کند باشد. این بدان معنی است که در حالت ایده آل کاربر باید تصدیق عمل خود را ظرف 100 میلی ثانیه دریافت کند. این در حال رسیدن به محدوده ی یکی از سریع ترین اقدامات ناخودآگاه است که بدن انسان می تواند انجام دهد - چشم چشمک زدن است. به همین دلیل، فاصله زمانی 100 میلی ثانیه معمولا فورا درک می شود. داوینا بریستو، موسسه نورولوژي دانشگاه کالج لندن می گوید: "اکثر مردم حدود 15 بار در دقیقه چشمک می زنند و به طور متوسط ​​100 تا 150 میلی ثانیه طول می کشد، و این بدان معنی است که ما حداقل 9 روز در هر سال چشمک می زنیم. "

به دلیل پاسخ فوری فوری (حتی قبل از اینکه درخواست واقعی به پایان رسید)، یک رابط کاربری خوش بینانه یکی از نمونه های تکنیک های تکمیل اولیه است که در بهینه سازی عملکرد روانی استفاده می شود. اما واقعیت این است که مردم مانند رابطهایی هستند که در چشمک زدن پاسخ میدهند نباید به عنوان بسیاری از ما واقعا تعجب آور باشند. و برای رسیدن به آن سخت نیست. حتی در روزهای گذشته، پس از کلیک بر روی آنها دکمه های غیرفعال شده را بلافاصله غیرفعال کردیم و این معمولا برای تایید ورودی کاربر کافی بود. اما حالت غیرفعال در یک عنصر رابط به معنای خروجی غیر فعال است: کاربر نمیتواند در مورد آن کاری انجام دهد و هیچ کنترلی بر روی فرآیند ندارد. و این برای کاربر خیلی خسته کننده است. به همین دلیل است که در حالت رابط کاربری خوش بینانه حالت غیرفعال را از حالت غیرفعال حذف می کنیم - ما نتیجه مثبتی را به جای انتظار کاربر منتقل می کنیم.

نحوه برخورد با نقص احتمالی

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

انسان ها به طور طبیعی فعالیت خود را به صورت دسته ای سازمان دهی می کنند، که با تکمیل یک هدف یا زیرمجموعه هدف تعریف می شوند. گاهی اوقات ما به این دسته ها به عنوان "رشته اندیشه ها"، "جریان فکر" (PDF) یا خیلی ساده "جریان" اشاره می کنیم. در حالت جریان فکر، نهایت بهره گیری ، تمرکز پر انرژی و تفکر خلاقانه وجود دارد. در طول جریان فکر، کاربر به طور کامل به فعالیت جذب می شود. صدای جیر جیر نوشته شده تامی اورتس به خوبی این امر را نشان می دهد:

تامی اورتس: من همه چیز را در مورد قرار گرفتن دررشته افکار را دوست دارم جز آن قسمتی که فراموش می کنم برای ساعت ا پلک نزنم یعنی وضعیت چشمان من دقیقاَ در همین الان!

گاهی اوقات مشخص کردن یک شخص در یک جریان فکر بسیار ساده است.

در وب، طول مدت این دسته های فعالیت بسیار کوتاه تر است. بیایید لحظه ای دوباره به کار رابرت ب. میلر بپردازیم. واکنش هایی که وی ذکر می کند عبارتند از:

• پاسخ به یک درخواست ساده از اطلاعات فهرست شده؛
• پاسخ به یک درخواست پیچیده در قالب گرافیکی؛
• پاسخ به "سیستم، آیا من را درک می کنی؟"

او تمام اینها را به همان فاصله زمانی 2 ثانیه ای که کاربر باید پاسخ مربوطه را دریافت کنند، ارتباط می دهد. بدون عمق شکافی بیشتر، باید توجه داشته باشیم که این فاصله همچنین به حافظه کاری شخص بستگی دارد (اشاره به بازه زمانی دارد که فرد می تواند در آن، مقدار مشخصی از اطلاعات را در حافظه خود نگه دارد و مهمتر از آن، بتواند آن را دستکاری کند). برای ما، به عنوان توسعه دهندگان و متخصصان UX، این بدان معنی است که در عرض 2 ثانیه از تعامل متقابل با یک عنصر، کاربر در جریان فکر قرار گرفته است و بر پاسخی که انتظار آن را دارد متمرکز است. اگر سرور در طول این فاصله یک خطا را ارسال کند، بنابراین کاربر همچنان با رابط کاربری  صحبت می کند. این امر مشابه گفتگو بین دو نفر است، جایی که شما چیزی می گویید و شخص دیگر با ملایمت با شما مخالفت می کند. تصور کنید اگر شخص دیگری مدت زمان طولانی تری را در توافق باقی بماند (که معادل شاخص ما از وضعیت موفقیت در رابط کاربری است) اما در نهایت به شما بگوید: "نه". خیلی بی معنی است، این نیست؟ بنابراین، یک رابط کاربری خوش بینانه باید وجود نقص را به کاربر در عرض 2 ثانیه از جریان فکری اطلاع دهد.

یک رابط کاربری خوش بینانه باید به صراحت و با دقت عدم موفقیت را به کاربر اطلاع دهد. مهمتر از همه، این اینکه باید در عرض 2 ثانیه جریان فکری کاربر رخ دهد.

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

وجه بدبینانه طراحی رابط کاربری خوش بینانه

از همه مهمتر چیزی که می شنوم این است که طراحی رابط کاربری خوش بینانه یک نوع الگوی سیاه است - تقلب، اگر بخواهید. به این ترتیب، با استفاده از آن، ما به کاربران خود در مورد نتیجه تعامل خود دروغ می گوییم. از لحاظ قانونی، هر دادگاه احتمالا از این نظر حمایت می کند. هنوز من تکنیک پیش بینی یا امید را در نظر می گیرم. (تعریف "خوش بینانه" را به یاد دارید؟ اینجا جایی است که ما اجازه بخش "امیدوارکننده" آن را می دهیم.) تفاوت بین "دروغ گفتن" و "پیش بینی کردن" در نحوه برخورد شما با  آن 1 تا 3٪ از درخواست های شکست خورده قرار دارد. بیایید نگاه کنیم که چگونه دکمه خوش بینانه "پسندیدن" توییتر بصورت آفلاین عمل میکند.

اما چون کاربر آفلاین است، درخواست با شکست مواجه می شود.

بنابراین، در اسرع وقت در جریان کار کاربر، شکست باید اطلاع داده شود. دوباره، 2 ثانیه معمولا طول مدت چنین جریانی است. توییتر این را به بهترین نحو ممکن انجام می دهد، به سادگی با برگشت دادن حالت دکمه به شکل اولیه اش.

پس از درخواست شکست خورده، توییتر حالت بصری دکمه پسندیدن را بدون هیچ گونه آشفتگی بصری دوباره تغییر می دهد.

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

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

خوب، اکنون همه ما می توانیم توافق کنیم که این کار کمی پیچیده است. در حالی که این طرز رفع خطا برای مثلا یک فرم بزرگ در یک وبسایت معقول است، برای یک اقدام ساده مثل کلیک کردن بر روی دکمه پسند کردن - هم از نظر پیشرفت فنی مورد نیاز و حافظه کاری کاربران - معقول نیست.

بنابراین، بله، ما باید در مورد عدم موفقیت در رابط کاربری خوش بینانه صریح باشیم، و ما باید آن را در اسرع وقت رفع کنیم تا خوشبینی ما یک دروغ نباشد. اما باید متناسب با بافت کاری وب سایت باشد. برای یک پسند کردن ناموفق ، دکمه ای که به حالت اولیه خود تغییر داده شود ، می تواند کافی باشد.

بدبینی شدید

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

اگر یک رابط کاربری خوش بینانه به درستی بکار گرفته شود و تعاملات تنها برای آن دسته از عناصری که هرگز بیش از 2 ثانیه برای پاسخ سرور صبر نمی کنند، اعمال شود آنگاه کاربر مجبور است مرورگر را در این 2 ثانیه ببندد. این کار با یک ضربه صفحه کلید چندان سخت نیست. با این حال، همانطور که مشاهده کردیم، در 97 تا 99 درصد موارد، درخواست موفقیت آمیز خواهد بود، چه آن برگه فعال باشد یا خیر (فقط مسئله این است که پاسخ به مشتری ارسال نخواهد شد).

بنابراین، این مشکل ممکن است فقط برای 1 تا 3 درصد افرادی که خطا را دریافت می کنند، رخ دهد. بنابراین، چه تعداد از آن افراد با عجله پنجره را در عرض 2 ثانیه خواهند بست ؟ فکر نمی کنم تعداد این افراد قابل توجه باشد. اما اگر احساس می کنید این موضوع مربوط به پروژه خاص شماست و ممکن است عواقب منفی داشته باشد، آنگاه از برخی ابزارها برای تجزیه و تحلیل رفتار کاربر استفاده کنید. اگر احتمال چنین سناریویی به اندازه کافی بالا باشد، آنگاه تعاملات خوش بینانه را به عناصر غیر ضروری محدود کنید.

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

قوانین سرانگشتی

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

• یک پیش شرط برای همه چیزهایی که تا به حال صحبت کرده ایم: اطمینان حاصل کنید که API شما بر آن متکی هستید پایدار است و نتایج قابل پیش بینی را برمی گرداند. در مورد آن به اندازه کافی گفته شده است.
• قبل از اینکه یک درخواست به سرور ارسال شود، باید خطاهای و مشکالت بالقوه را از بین ببرید. با این حال بهتر است هر چیزی را که می تواند منجر به خطا از API می شود حذف کنید. هر چه یک عنصر رابط کاربری ساده تر باشد، خوش بینانه ساختن آن ساده تر است.
• از الگوهای خوش بینانه برای عناصر ساده دوگانه مانند که برای آن عناصر چیزی جز یک پاسخ موفقیت یا شکست انتظار نمی رود استفاده کنید. به عنوان مثال، اگر در کلیک یک دکمه از سرور پاسخی مانند "بله"، "نه" یا "شاید" (که ممکن است در هر درجه ای نشان دهنده موفقیت باشد) فرض شود، چنین دکمه ای بهتر خواهد بود بدون الگوی خوش بینانه باشد.
• زمان پاسخ API خود را بدانید. این امر بسیار مهم است. اگر شما می دانید که زمان پاسخ برای یک درخواست خاص هرگز کمتر از 2 ثانیه نیست، آنگاه ایجاد ابتدا کمی خوش بینی نسبت به API شما شاید بهترین کار باشد. همانطور که گفته شد، یک رابط کاربری خوش بینانه برای زمان پاسخ سرور کمتر از 2 ثانیه بهترین عمل و تاثیر را دارد. فراتر رفتن از آن می تواند منجر به نتایج غیر منتظره و ناامیدی کاربران شود. بنابراین این نکته را همواره مد نظر قرار دهید.
• رابط کاربری خوش بینانه فقط در مورد کلیک کردن بر روی دکمه نیست. این رویکرد می تواند برای تعاملات و رویدادهای مختلف در طول چرخه عمر صفحه، از جمله بارگیری صفحه، اعمال شود. به عنوان مثال، صفحه نمایش اسکلت ایده ای مشابه را دنبال می کند: شما می توانید پیش بینی کنید درحالیکه قسمت های مختلف صفحه را پر می کند سرور با موفقیت در اسرع وقت به کاربر پاسخ خواهد داد.

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