منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۳ دقیقه

خطای انسانی (Human Error) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

منبع سه نوع خطا را از هم جدا می‌کند — و بعد یک فهرست نُه‌گانهٔ راه‌حل می‌دهد که برای هر سه یکسان است.

اما دلیل اصلیِ اینکه نورمن این‌ها را از هم جدا کرد این بود که درمانشان متضاد است: درمانی که لغزش را حل می‌کند اشتباه را بدتر می‌کند، و برعکس.

تعریف

خطای انسانی هر کنشی از سوی کاربر است که به نتیجهٔ ناخواسته یا شکست در رسیدن به هدف می‌رسد — و می‌تواند از راه لغزش، اشتباه یا فراموشی رخ دهد.

و منبع نکتهٔ درستی می‌گوید: این خطاها «غالباً نتیجهٔ تصمیم‌های بد طراحی‌اند که محدودیت‌ها و رفتار کاربران واقعی را در نظر نگرفته‌اند». و جملهٔ خوبش این است: «نمی‌توانید «کاربر» را از تجربهٔ کاربری بیرون بکشید.»

سه نوع خطا

منبع به رده‌بندی دان نورمن ارجاع می‌دهد:

• - لغزش (Slip). وقتی قصد نداشتید آن کار را بکنید — مثلاً از سرعت زیاد در کشیدن یا انتخاب چند مورد برای حذف. هدف درست بود، اجرا لغزید.
• - اشتباه (Mistake). خطای عمدی — نه از سر خرابکاری، بلکه چون کاربر مدل ذهنی غلطی از رابط ساخته و هدفی شکل داده که با موقعیت نمی‌خواند. کنش دقیقاً همان بود که می‌خواست، ولی برای مسئلهٔ درست نبود. مثال کلاسیکش «درِ نورمن» است: دری با دستگیرهٔ کشیدنی که فقط با فشار باز می‌شود.
• - فراموشی (Lapse). وقتی توجه کاربر روی کار نیست — حواس‌پرتی، خستگی یا «خودکار» بودن. شبیه لغزش است، ولی پایبند‌نماندن به نقشه‌ای است که خودش داشت. و منبع می‌گوید پیش‌بینی‌اش از دو نوع دیگر سخت‌تر است، چون کاربر معمولاً از بی‌تمرکز‌بودنش خبر ندارد.

طراحی بد چطور خطا می‌سازد

منبع چهار الگو می‌آورد: نبود نشانه‌های جهت‌دار روشن (کاربر نمی‌داند چه چیزی قابل‌کلیک است) · پیام‌های خطای مبهم که نمی‌گویند مشکل چیست یا چطور حل می‌شود · رابط‌های پیچیده یا کوبنده با عناصر و گزینه‌های زیاد · و نبود بازخورد و تأیید که کاربر را دربارهٔ نتیجهٔ کنشش بی‌خبر می‌گذارد.

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

نُه توصیهٔ منبع

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

لغزش و اشتباه دو درمان متضاد دارند

این بخش افزودهٔ مترجم است، و به‌نظرم مهم‌ترین چیزی که در آن فهرست نُه‌گانه گم شده.

تفکیک لغزش از اشتباه یک رده‌بندی آکادمیک نیست؛ یک دستور تشخیصی است، چون:

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

و اگر جابه‌جا اعمالشان کنید، دو نتیجهٔ مشخص می‌گیرید:

• - درمان لغزش روی اشتباه = کاربری که کنش غلط را دو بار تأیید می‌کند و همان نتیجهٔ غلط را می‌گیرد، این بار با اطمینان بیشتر.
• - درمان اشتباه روی لغزش = یک متن توضیحی که هیچ‌کس نمی‌خواند، و همان حادثه که باز هم رخ می‌دهد.

و همین یک قید مهم به توصیهٔ هشتم منبع می‌زند: دیالوگ تأیید، درمان لغزش نیست — خودش تبدیل به بخشی از لغزش می‌شود. دیالوگی که سر هر کنش بالا می‌آید به یک حرکت خودکار تبدیل می‌شود و کاربر بی‌آنکه بخواندش می‌بندد. برای کنش خطرناک، واگرد از تأیید مؤثرتر است — و اگر واگرد ممکن نیست، تأییدیه باید نادر باشد تا خودکار نشود.

اسم این چیز، تعیین می‌کند چه کسی مالکش است

این بخش هم افزودهٔ مترجم است. منبع خودش می‌گوید این خطاها «غالباً نتیجهٔ تصمیم‌های بد طراحی‌اند» — و بعد اسم خطای انسانی را نگه می‌دارد.

و این فقط بحث لفظی نیست، چون اسم تعیین می‌کند پرونده روی میز کدام تیم می‌رود:

• - تا وقتی رویداد با عنوان «کاربر اشتباه کرد» ثبت می‌شود، هیچ تیکت طراحی‌ای باز نمی‌شود. توضیح کامل شده و پرونده بسته است.
• - و اگر همان رویداد به‌شکل «طراحی اجازه داد کاربر X را انجام دهد» بازنویسی شود، ناگهان یک صاحب و یک راه‌حل دارد.

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

گزینهٔ خاکستری بدون دلیل، لغزش را به اشتباه تبدیل می‌کند

این بخش هم افزودهٔ مترجم است و به توصیهٔ سوم منبع («ممنوع‌کردن کنش‌های نامناسب») برمی‌گردد.

خاکستری‌کردن یک کنترل، لغزش را می‌گیرد — و اگر دلیلش را نگوید، چیز بدتری می‌سازد: کاربر مجبور می‌شود خودش نظریه‌ای بسازد که چرا کار نمی‌کند. و آن نظریه معمولاً غلط است: «خراب است»، «حساب من اجازه ندارد»، «اینترنتم قطع است». یعنی شما یک لغزش را به یک اشتباه تبدیل کرده‌اید — و اشتباه با خاکستری‌کردن درمان نمی‌شود.

قاعدهٔ ساده: هر کنترل غیرفعال باید شرط فعال‌شدنش را بگوید. نه «چرا غیرفعال است»، بلکه «چه کاری باید بکنی تا فعال شود» — چون دومی کنش بعدی کاربر را می‌سازد.

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

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

فراموشی یک بند گرفت و درمانش هم درست نبود

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

اما فراموشیِ پرتکرارتر و پرهزینه‌تر، فراموشی در میانهٔ کار است: کاربر شروع کرد، چیزی قطعش کرد، و وقتی برگشت نمی‌داند کجا بود. و درمان آن اطلاع‌رسانی نیست — بازگشت‌پذیری وضعیت است:

• - وضعیت نیمه‌کاره را ذخیره کنید، بی‌آنکه کاربر کاری کرده باشد.
• - بگویید کجا بود و چه چیزی مانده — نه با نوار پیشرفت، بلکه با نام گام.
• - و هیچ‌وقت فرم را با بارگذاری مجدد صفحه خالی نکنید.

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

در بافت فارسی: وقتی واگرد در دامنه وجود ندارد

این بخش هم افزودهٔ مترجم است و سه نکته دارد.

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

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

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

سه: اعتبارسنجی‌ای که می‌توانست یکسان‌سازی کند، نباید رد کند. کاربر فارسی‌زبان با چند جفت نویسهٔ عملاً یکسان کار می‌کند — ی/ي، ک/ك، ارقام فارسی و لاتین، نیم‌فاصله و فاصله. و بعد فرم می‌گوید «شمارهٔ نامعتبر» یا جست‌وجو صفر نتیجه می‌دهد.

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

جمع‌بندی

• - خطای انسانی هر کنشی است که به نتیجهٔ ناخواسته می‌رسد، و سه نوع دارد: لغزش (هدف درست، اجرا لغزید)، اشتباه (مدل ذهنی غلط، هدف نامناسب)، و فراموشی (توجه جای دیگری بود).
• - اما این رده‌بندی یک دستور تشخیصی است، نه یک فهرست: لغزش با واگرد و بازگشت‌پذیری درمان می‌شود و با توضیح نه؛ اشتباه با نمایش وضعیت و برچسب درمان می‌شود و با واگرد نه.
• - و دیالوگ تأیید درمان لغزش نیست — خودش بخشی از لغزش می‌شود. برای کنش خطرناک واگرد بهتر است، و اگر ممکن نیست تأییدیه باید نادر باشد.
• - اسم «خطای انسانی» تعیین می‌کند پرونده مالِ کدام تیم است: «خطای کاربر» را به‌عنوان دلیل بستن تیکت ممنوع کنید و جملهٔ «طراحی اجازه داد که...» بخواهید.
• - کنترل خاکستریِ بی‌دلیل، لغزش را به اشتباه تبدیل می‌کند؛ هر کنترل غیرفعال باید شرط فعال‌شدنش را بگوید.
• - و برای پیچیدگی تقلیل‌ناپذیر، درس صنعت هوایی مینیمالیسم نیست: چک‌لیست، اعلام حالت و چیدمان استاندارد است.
• - فراموشی پیشگیری‌شدنی نیست، فقط بی‌هزینه‌شدنی است: وضعیت را ذخیره کنید، بگویید کجا بود، و فرم را با بارگذاری مجدد خالی نکنید.
• - و در بافت ما: جایی که واگرد در سطح دامنه وجود ندارد تمام بار روی پیشگیری است · رمز یک‌بارمصرف ماشین تولید فراموشی است و حلش تصمیم طراحی است · و اعتبارسنجی‌ای که می‌تواند یکسان‌سازی کند نباید رد کند.