چک لیست طراحی Error States

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

یک پیام درست و خوش‌ساخت می‌تواند یک لحظه شکست را به یک لحظه‌ی لذت بخش تبدیل کند.

حالت‌های خطا

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

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

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

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

پیش‌گیری بهتر از درمان است

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

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

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

صفحه خطا در فرم‌‌ها

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

به طور کلی چهار عنصر مهم در بررسی داده‌های ورودی یک فرم وجود دارد که شامل:

• اطلاع رسانی در زمان مناسب در مورد خطاها (یا موفقیت‌ها)
• نمایش اطلاعات خروجی در مکان مناسب
• رنگ مناسب برای پیام‌ها
• ساختار نوشتاری مناسب و آشنا برای کاربر
  

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

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

در فرآیند پٌرکردن فرم باید فوراً به کاربران در مورد درستی پاسخی که ارائه داده‌اند اطلاع دهیم و درست یا نادرست بودن اطلاعات را به بعد از زدن دکمه ارسال موکول نکنیم. اصل اولیه یک فرم خوب این است که: " با کاربران صحبت کنید! بگویید چه شده! " و بلافاصله کاربران را از درستی داده‌های ارائه ‌شده مطلع سازید.
این رویکرد به کاربران اجازه می‌دهد تا خطاها را تصحیح کنند بدون اینکه صبر کنند تا دکمه ارسال را فشار دهند.
با این حال، از دادان پیام تا قبل از تمام شدن تایپ کاربر اجتناب کنید زیرا در اغلب موارد، شما نمی‌توانید تا زمانی که تایپ کاربر تمام نشده، تایید کنید که پاسخ ارائه شده درست است یا نه. در برخی موارد به‌محض اینکه کاربر شروع به ورود داده‌ها میکند با پیام خطا مواجه میشود که این کار اشتباه است.

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

مایکل کونجویک (Mihael Konjević) در مقاله خود “Inline validation in forms — designing the experience” استراتژی‌های مختلفی را برای بررسی درستی داده‌های وارد شده در فرم‌ها امتحان کرده است که نهایتاً یک استراتژی ترکیبی پیشنهاد می‌کند : پاداش اولیه، مجازات دیرهنگام .

مکان مناسب برای نمایش پیام خطا

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

انتخاب رنگ درست در طراحی بصری

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

واضح بودن پیام

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

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

همچنین پیام نباید آنقدر ساده و نا‌مفهوم باشد که هیچ اطلاعات مفیدی به کاربر ندهد.

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

پیغام باید خوانا و مفید باشد، شامل یک نسخه کوتاه، مودبانه و آموزنده باشد که به وضوح بیان می‌کند :

• چه اتفاقی افتاده و چرا.
• گام بعدی را مشخص می‌کند که کاربر چگونه باید خطا را برطرف کند.

استفاده از تصویرسازی و طنز در حالت‌های خطا

تهدید را تبدیل به فرصت کنید.

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

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

چک لیست کامل و جامع از صفحات خطا

صفحات خطا باید شش مورد زیر را داشته باشند:

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

راه‌حلی برای اکثر خطاهای رایج

هدف اصلی صفحه خطای ۴۰۴ این است که کاربر را در سریع‌ترین زمان ممکن به صفحه‌ مور نظر هدایت کند.
در این صفحه باید چندین لینک اصلی و راهنمایی را که کاربر شما می‌تواند از بین آنها انتخاب کنند ارائه دهید. در این صفحه باید لینک یا دکمه بازگشت به صفحه اصلی را به عنوان اقدام اصلی در نظر بگیریم و همچنین می‌توانید لینکی را با عنوان " گزارش خطا " قرار دهید که با زدن آن به سرعت گزارش خرابی صفحه ارسال گردد. اما اطمینان حاصل کنید که اقدام اولیه ( لینک به صفحه Home ) وزن بصری قوی‌تری دارد.

ورود به برنامه ممکن نیست!

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

برنامه Mailchimp راه‌حل‌هایی را برای رایج‌ترین مشکلات ارائه می‌دهید. بیایید آنها را بررسی کنیم :
کاربر نام کاربری خود را فراموش کرده‌ است. اگر شما تشخیص دهید که مشکل یک نام کاربری ثبت نشده است، باید یک لینک ارائه دهید تا اجازه دهد کاربر آن را اصلاح کند. به کاربران بگویید که در کجا و چگونه می‌توانند این اصلاح را انجام دهند. به طور مثال " ( ایمیل دریافتی از ما را چک کنید ) " یا لینکی برای بازیابی نام کاربری داشته باشید.

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

عدم پذیرش اطلاعات کارت اعتباری

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

یکی از راه‌حل‌ها این است که باید صحت داده‌های ورودی را در لحظه بررسی کنید و خطای صورت گرفته را
به صورت بصری نشان دهید.

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

خطا در اتصال به شبکه

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

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

اطمینان حاصل کنید که برنامه شما به صورت آفلاین کار کند. در اینجا چند توصیه عملی از رابرت وو را می‌بینیم که تقریباً در هر برنامه‌ایی که در بازار موجود است قابل استفاده می‌باشد.

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

قابلیت‌ها و ویژگی‌ها در حالت آفلاین

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

در پایان

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

خوشحال میشم اگر شما تجربه یا تحقیقی در این مورد دارید، به اشتراک بگذارید و کامنت کنید.

اگر مطالب این مقاله براتون مفید بوده، پیشنهاد می‌کنم این مقاله رو هم مطالعه کنید :

چک لیست طراحی Empty state

منابع و مقالات مشابه :

How To Design Error States For Mobile Apps
Inline validation in forms — designing the experience