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

اصطکاک شناختی (Cognitive Friction) چیست؟

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

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

آن مکث اسم دارد.

تعریف

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

این اصطلاح را Alan Cooper — که او را پدر ویژوال بیسیک می‌دانند — در کتاب The Inmates Are Running the Asylum مطرح کرد.

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

چه چیزی آن را می‌سازد

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

و منبع دو عدد می‌آورد که بافت این بحث را می‌سازند: بیش از ۶۲ درصد ترافیک وب جهان از دستگاه‌های همراه می‌آید (Statista)، و نزدیک به نیمی از اپلیکیشن‌ها ظرف ۳۰ روز از نصب حذف می‌شوند (AppsFlyer).

چطور کمش کنیم

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

منبع همچنین مفهوم اصطکاک شمول را معرفی می‌کند: اصطکاکی که از طراحی غیرفراگیر می‌آید — مثل فرمی که گزینه‌های محدودی برای جنسیت می‌گذارد و کاربری را در جایی متوقف می‌کند که هیچ گزینهٔ درستی برایش نیست.

با بار شناختی یکی نیست

این بخش افزودهٔ مترجم است. منبع این تفکیک را انجام نمی‌دهد و به‌نظر من نبودش باعث می‌شود این دو مدام جای هم به‌کار بروند، در حالی که دو مشکل متفاوت‌اند و دو راه‌حل متفاوت می‌خواهند.

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

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

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

چطور اصطکاک خودتان را پیدا کنید

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

• - دنبال مکث و بازگشت بگردید، نه دنبال خطا. اصطکاک خطا تولید نمی‌کند؛ تردید تولید می‌کند. در هر ضبط جلسه یا مشاهدهٔ حضوری، لحظه‌ای که کاربر دست نگه می‌دارد یا یک گام برمی‌گردد، دقیقاً همان‌جاست.
• - تیکت‌های پشتیبانی را با یک عبارت جست‌وجو کنید: «فکر کردم». هر پیامی که با «فکر کردم این دکمه…» شروع می‌شود، یک گزارش اصطکاک است که کاربر مجانی برایتان نوشته. این‌ها معمولاً در دسته‌بندی‌ها گم می‌شوند چون خطا محسوب نمی‌شوند.
• - نرخ بازگشت و لغو را در هر گام بسنجید. گامی که کاربران زیادی بلافاصله از آن برمی‌گردند، وعده‌ای داده که نگه نداشته — و این را می‌شود بدون هیچ مصاحبه‌ای از داده دید.

اما همهٔ اصطکاک بد نیست

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

• - تأییدیهٔ پیش از حذف دائمی.
• - اینکه برای حذف یک مخزن کد، باید نامش را تایپ کنید.
• - مکث پیش از یک انتقال وجه بزرگ.
• - گام «بازبینی سفارش» پیش از پرداخت نهایی.

همهٔ این‌ها کار کاربر را بیشتر می‌کنند و همه‌شان درست‌اند. پس مرز کجاست؟

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

از این یک آزمون سه‌بخشی درمی‌آید که می‌شود روی هر اصطکاکی در محصول اجرا کرد:

• - عمدی است؟ کسی تصمیم گرفته این گام باشد، یا صرفاً باقی مانده؟
• - در همان لحظه دلیلش معلوم است؟ نه در مستندات، نه در پیامی که بعداً می‌آید — همان‌جا.
• - متناسب است؟ یک تأییدیه برای حذف حساب منطقی است؛ همان تأییدیه برای حذف یک آیتم از سبد خرید، آزاردهنده است.

هر اصطکاکی که هر سه را نداشته باشد، اصطکاک تصادفی است — یعنی همان چیزی که کوپر دربارهٔ آن نوشت.

در رابط فارسی، قرارداد را چه کسی تعیین می‌کند؟

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

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

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

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

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

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

جمع‌بندی

• - اصطکاک شناختی وقتی رخ می‌دهد که رابط شهودی به‌نظر برسد اما نتیجهٔ غیرمنتظره بدهد؛ اصطلاح از Alan Cooper در The Inmates Are Running the Asylum است.
• - شرط لازمش این است که چیزی شهودی به‌نظر برسد — رابطی که آشکارا پیچیده است سخت است، نه پراصطکاک.
• - عامل اصلی‌اش نقض قرارداد جاافتاده است، و موبایل به‌دلیل تنوع شیوه‌های تعامل و نبود استاندارد واحد، دشوارتر است.
• - کاهشش پیش از توسعه با مصاحبه و جریان کاری و معماری اطلاعات، و در حین توسعه با ارزیابی اکتشافی و شناختی و آزمون کاربردپذیری.
• - با بار شناختی یکی نیست: بار یعنی کار زیاد است و راه‌حلش کم‌کردن؛ اصطکاک یعنی کار هدر رفت و راه‌حلش هم‌راستاکردن. بار بالا گاهی قابل‌قبول است، اصطکاک هرگز.
• - تشخیصش ساده است: کاربر خسته شد یا غافلگیر شد؟
• - برای پیداکردنش دنبال مکث و بازگشت بگردید نه خطا، تیکت‌های حاوی «فکر کردم» را بخوانید، و نرخ بازگشت هر گام را بسنجید.
• - و همهٔ اصطکاک بد نیست: اصطکاک عمدی خوانا است و باید عمدی و بی‌درنگ توضیح‌داده‌شده و متناسب باشد.
• - در رابط فارسی، قرارداد را نه راهنمای رسمی، که چند محصول پرکاربرد تعیین می‌کنند — پس «از قرارداد پیروی کن» یعنی «ببین کاربرت از قبل با چه چیزی کار می‌کند».