طراحی عمدی اصطکاک
بدون اصطکاک مرده است. بهترین محصولات ۲۰۲۶ اصطکاک را عمداً، در جاهای مشخص و به دلایل مشخص برگرداندند. نقشه‌ی جاهایی که اصطکاک ارزش خودش را ثابت میکند، شکل‌هایی که اصطکاک میتواند داشته باشد و چارچوب ممیزی برای محک زدن هر جریان.
«بدون اصطکاک» مرده است. دوی ده‌ساله برای حذف هر تپ، هر تأیید و هر مکثی، محصولات را به ماشین‌های اسلات «تپ کن و دعا کن» تبدیل کرد، و بهترین تیم‌ها در ۲۰۲۶ بی‌سروصدا اصطکاک را برمی‌گردانند. نه از سر اتفاق. عمداً. در جاهای مشخص، به دلایل مشخص.
اصطکاک دشمن UX نیست. اصطکاک راهی است که UX احترامش را نشان میدهد. محصولی که اجازه میدهد کاربر حسابش را با یک تپ حذف کند به او احترام نمی‌گذارد. محصولی که اول از او می‌خواهد نام حساب را تایپ کند، احترام میگذارد. مکث همان پیام است.
اصطکاک تصادفی چیز دیگری است
بیشتر استدلال‌های «اصطکاک بد است» درباره‌ی اصطکاک تصادفی‌اند. لگ. رابط گیج‌کننده. دارک پترن‌ها. فرم‌هایی که در ۲۰۲۶ شماره‌ی فکس می‌خواهند. فرایندهای انبوردینگ که قبل از اینکه محصول کار مفیدی بکند، تأیید ایمیل، کد پیامکی و ویزارد راه‌اندازی می‌خواهند. این نوع اصطکاک بد است. هیچ‌کس از آن دفاع نمی‌کند.
اصطکاک طراحیشده چیز دیگری است. مکثی عمدی در لحظه‌ای پرریسک است تا کاربر به‌جای تصمیم اتفاقی، تصمیمی واقعی بگیرد. تپ دوم در Apple Pay. تایپ نام ریپو برای حذف در GitHub. دیفی که Cursor قبل از دست زدن به کدتان نشان میدهد.
اصطکاک تصادفی باگ است. اصطکاک طراحیشده ویژگی است. قاطی کردن این دو باعث شد صنعت به دکمه‌های حذف حساب با یک تپ برسد، آن هم کنار مودال‌های «مطمئنید می‌خواهید این صفحه را ترک کنید» روی فرم‌های تماس.
شش جایی که اصطکاک ارزشش را ثابت میکند
اصطکاک در زمینه‌های مشخصی ارزش خودش را ثابت میکند. شش مورد، مرتب‌شده بر اساس اینکه نبودشان چقدر کاربر را تنبیه میکند.
اقدامهای برگشتناپذیر
هر کاری که کاربر نتواند واگردانی کند اصطکاک می‌خواهد. حذف حساب. حذف دیتابیس. Force-push. خالی کردن سطل زباله. پاک کردن دستگاه. هزینهی یک تپ اشتباهی جبران‌ناپذیر است، پس محصول مدیون کاربر است که لحظه‌ای برای تأیید نیت بدهد.
حذف ریپو در GitHub نسخه‌ی کتاب درسی است. کاربر باید نام کامل ریپو را دقیقاً تایپ کند تا دکمه‌ی حذف فعال شود. این اصطکاک نمایشی نیست، یک تابع اجبارکننده است که حافظه‌ی عضلانی را به انتخاب آگاهانه تبدیل میکند. Stripe آن را روی ابطال کلید API به کار می‌برد. AWS روی حذف منابع. الگوی «DELETE را تایپ کن» وجود دارد چون حافظه‌ی عضلانی از نیت جلو می‌زند و اقدامهای برگشتناپذیر نمی‌توانند در برابر حافظه‌ی عضلانی ببازند.
جریانهای پول
هر محصولی که پول جابه‌جا میکند مدیون کاربر است که مرحله‌ی تأیید بگذارد. Stripe Checkout عمداً جریانی دو مرحله‌ای است. جزئیات کارت در یک صفحه، خلاصه و تأیید در صفحه‌ی بعد. مرحله‌ی «اضافه» کل ماجراست. کاربر می‌بیند چه چیزی می‌پردازد، به چه کسی و در ازایش چه می‌گیرد، پیش از اینکه کسر شود.
دوبار فشردن دکمه در Apple Pay همین ایده است که در سخت‌افزار فشرده شده. کاربر دو بار متعهد می‌شود، با یک ثانیه فاصله، پیش از اینکه پول جابه‌جا شود. آن فشار دوم تفاوت پرداخت و تصادف است.
پرداخت‌های بدون اصطکاک وجود دارند. اسمشان اشتراک است و بی‌دلیل پرشکایت‌ترین دسته در اپ‌استورها نیستند. حذف مرحله‌ی تأیید کاربر را خوشحال‌تر نمی‌کند، این حس را به او میدهد که محصول دارد از او سوءاستفاده میکند.
فراخوانی ابزار توسط AI
هر بار که AI می‌خواهد کار واقعی انجام دهد، روی فایل‌سیستم بنویسد، دستوری اجرا کند، ایمیل بفرستد یا API صدا بزند، کاربر سزاوار یک لحظهی تأیید است.
دیف قبول یا رد در Cursor استاندارد طلایی است. مدل تغییری پیشنهاد میدهد، دیف ظاهر می‌شود و کاربر پیش از اعمال تغییر قبول، رد یا ویرایش میکند. تأیید آرتیفکت در Claude هم همین شکل را دارد. ایجنت کد ویرایش فایلی پیشنهاد میدهد، کاربر مرور میکند، بعد کامیت می‌شود. اصطکاک همان لایه‌ی اعتماد است. بدون آن، ایجنت فقط راه سریع‌تری برای خراب کردن یک کدبیس است.
محصولات AI که در ۲۰۲۴ و ۲۰۲۵ این مرحله را رد کردند اعتماد زیادی سوزاندند. آن‌هایی که لحظهی تأیید را ساختند، همان‌هایی‌اند که کاربران واقعاً رهایشان می‌کنند تا اجرا شوند.
حذف حساب و تنظیمات مخرب
تأییدیه‌های اقدام مخرب در Linear مثال دست‌کم‌گرفته‌شده‌اند. آرشیو یک پروژه، سیستم یک بار می‌پرسد. حذف پروژه، دو بار می‌پرسد و نشان میدهد چه چیزی ناپدید می‌شود. حذف ورک‌اسپیس، سیستم می‌خواهد نام ورک‌اسپیس را تایپ کنید. اصطکاک با اندازه‌ی ضرر بزرگ می‌شود.
Notion همین شیب را اجرا میکند. آرشیو با یک تپ چون برگشت‌پذیر است. حذف پشت تأیید تایپی چون برگشت‌پذیر نیست. کاربر هرگز لازم نیست بپرسد کدام کدام است، چون خود اصطکاک ریسک را نشان میدهد.
محصولی که آرشیو و حذف را یک حرکت تک‌تپی میکند، فرق را به رسمیت نمی‌شناسد. کاربر به سختی می‌فهمد، معمولاً ساعت ۱۱ شب یک سه‌شنبه، که دکمه‌ای که زده همان دکمه‌ای نبود که فکر می‌کرد.
لحظههای اشتراک‌گذاری و انتشار
دکمه‌ی انتشار یک مکث لازم دارد. فرستادن توییت، پیام اسلک به یک کانال، انتشار پیش‌نویس بلاگ، اشتراک یک فایل Figma با مشتری. این کار در تئوری برگشت‌پذیر است و در عمل شرم‌آور. یک مکث پیش از ارسال جلوی دایرکت ساعت ۲ بامدادی را می‌گیرد که برای یک نفر بود و به کل یک بخش رفت.
هشدار «مطمئنید می‌خواهید این را بفرستید» در توییتر روی ریپلای‌های تحریک‌آمیز مثالی کارآمد است. هشدار «دارید به ۴٬۲۰۰ نفر پیام می‌دهید» در Slack مثال دیگر. اصطکاک یعنی محصول به یاد می‌آورد کاربر بعداً چه می‌خواست از او پرسیده شود.
همین منطق برای انتشار هم صدق میکند. WordPress، Ghost، Webflow و هر CMS درخوری، پیش از انتشار خلاصه‌ی تأیید نشان میدهد. اصطکاک فرق «منتشر کن» و «منتشر کن و فوراً مجبور شو لغوش کنی» است.
دادهی حساس و دسترسی به حساب
ورود به حساب جای اصطکاک نیست. تأیید دستگاه جدید هست. درخواست 2FA در اولین اقدام حساس هست. مکث «ورودی از یک مکان جدید دیدیم» هست.
اصطکاک را در سطح تهدید بگذارید، نه در ورودی. پیام‌های Are You Sure اپل روی ورود جدید شکل درستی دارند. احراز هویت مجدد گوگل پیش از تغییر ایمیل بازیابی شکل درستی دارد. بانک‌هایی که برای انتقال وجه بالای یک سقف فاکتور دوم می‌خواهند شکل درستی دارند. بانک‌هایی که هر بار کاربر موجودی را چک میکند فاکتور دوم می‌خواهند شکل غلطی دارند و کاربر را عادت می‌دهند هشدارهای مهم را نادیده بگیرد.
جایی که اصطکاک محصول را می‌کشد
اصطکاک در جای اشتباه فقط محصول بد است. سه الگو که باید از آن‌ها پرهیز کرد، هرکدام یک شکست واقعی در محصولات منتشرشده.
اصطکاک در ورودی. مراحل اضافه برای ورود. کپچا در هر نشست. فرایندهای تأیید ایمیل که سه روز طول می‌کشند. کاربر هنوز متعهد نشده، پس هر مرحله‌ی اصطکاک فرصتی برای رفتن است. اصطکاک را برای بعد از تصمیم کاربر به ماندن نگه دارید.
لغو اشتراک دارکپترنی. اصطکاکی که برای جلوگیری از رفتن کاربر طراحی شده. دکمه‌های لغو که چهار صفحه عمیق دفن شده‌اند. مودال‌های عذاب وجدان «مطمئنید می‌خواهید همه‌ی مزایایتان را از دست بدهید». الگوی «برای لغو رمز عبور را وارد کن» روی حساب‌هایی که برای ثبت‌نام رمز نمی‌خواستند. اصطکاک خصمانه حفظ کوتاه‌مدت را به آسیب بلندمدت به اعتبار تبدیل میکند. برندهایی که این کار را می‌کنند تاوانش را می‌دهند.
دروازه‌های انبوردینگ. ویزاردهای راه‌اندازی که پیش از هر کاری همه‌ی ترجیحات را می‌خواهند. دیوارهای «پروفایلت را کامل کن تا ادامه دهی» روی محصولی که کاربر تازه برای امتحانش ثبت‌نام کرده. اصطکاک در فاز اعتمادسازی اصطکاکی است که کاربر هنوز برایش پول نداده. الگوی درست افشای تدریجی است، جایی که کاربر هرچه محصول بیشتر کسب میکند، بیشتر به آن میدهد.
قاعده‌ی سرانگشتی: اصطکاک در لحظهی اقدام، نه در ورودی. اصطکاک متناسب با هزینهی اشتباه. اصطکاکی که کاربر آن را مراقبت بخواند، نه مانع.
اصطکاک یک ماده‌ی طراحی است
اشتباه اغلب تیم‌ها این است که اصطکاک را دوگانه می‌بینند. تأیید یا بدون تأیید. تیم‌هایی که بهترین محصولات ۲۰۲۶ را تحویل می‌دهند اصطکاک را ماده‌ای با شکل قابل تنظیم می‌دانند. شش شکل رایج، هرکدام با وزنی متفاوت.
مکث. یک وقفه‌ی ۲۰۰ میلی‌ثانیه‌ای بین تپ و اجرا. سبک‌ترین اصطکاک ممکن. برای الگوهای hover-to-confirm و دکمه‌های کند.
تأیید. یک مودال که یک بار می‌پرسد. اصطکاک پیش‌فرض برای اقدامهای با ریسک متوسط مثل آرشیو یک پروژه یا ارسال فاکتور.
تأیید دوباره. دو پرسش پشت سر هم، دومی متفاوت با اولی. زمانی که پرسش اول چیزی است که کاربران از سر عادت می‌بندند.
تایپ برای تأیید. کاربر نام منبع، کلمه‌ی DELETE یا ایمیل حساب را تایپ میکند. توجه آگاهانه را اجبار میکند. برای برگشت‌ناپذیرترین اقدام‌ها.
خنک‌سازی. یک بازه‌ی تأخیر پیش از اینکه اقدام قابل تکرار یا واگرد شود. برای عملیات انبوه و اقدامهای مدیریت محتوا که احتمال هول‌شدن دارند.
پنجره‌ی واگرد. اقدام انجام می‌شود اما کاربر بازه‌ای ثابت برای واگرد دارد. واگرد ارسال در Gmail. پنجره‌ی ویرایش در Slack. شکل درست وقتی که اقدام با زحمت برگشت‌پذیر است اما فاجعه‌بار نیست.
شکل درست به ریسک، برگشت‌پذیری و تناوب اجرای اقدام بستگی دارد. طراحانی که یک شکل واحد برای همه‌ی جریان‌ها انتخاب می‌کنند مثل کسی طراحی می‌کنند که برای همه‌ی چیدمان‌ها یک وزن فونت انتخاب میکند. محدودیت باگ است، نه ویژگی.
برای اینکه ببینید سرعت و اصطکاک چطور بر هم اثر می‌گذارند، سرعت همان برند است و اصول طراحی لندینگ پیج را ببینید.
چارچوب ممیزی اصطکاک
هر جریان را پیش از انتشار از این چهار پرسش بگذرانید. اگر پاسخ‌ها غلط باشند، اصطکاک غلط است.
- آیا اقدام برگشت‌پذیر است؟ اگر بله، اصطکاک میتواند سبک یا غایب باشد. اگر نه، اصطکاک اجباری است و باید با هزینهی اشتباه بزرگ شود.
- اگر کاربر تصادفی تپ کند چه از دست میدهد؟ زمان، پول، داده، اعتبار، هر چهار. شکل اصطکاک باید با اندازه‌ی ضرر بخواند.
- اصطکاک در کجای جریان نشسته؟ اصطکاک ورودی بد است. اصطکاک لحظهی اقدام خوب است. اصطکاک بین کاربر و ارزش در جای اشتباه است.
- آیا اصطکاک مثل مراقبت خوانده می‌شود یا مانع؟ کاربری که به اصطکاک می‌خورد باید احساس احترام کند، نه مسدود شدن. اگر این‌طور خوانده شود که محصول کندش میکند، اصطکاک خصمانه است.
چهار پرسش، به ترتیب، روی هر جریانی که ریسک دارد. بیشتر تیم‌ها این را رد می‌کنند چون هزینهی مهندسی اضافه کردن یک مودال تأیید ناچیز است و گفت‌وگوی طراحی درباره‌ی اینکه باید باشد یا نه ناچیز نیست.
برای مطالعه‌ی عمیق‌تر درباره‌ی تصمیم‌های سطح جریان، اصول طراحی وب، مرگ موک‌آپ و طراحی انبوردینگ محصول AI را ببینید.
سوالات متداول
کی باید به یک جریان UX اصطکاک اضافه کرد؟
در لحظههای پرریسک اصطکاک اضافه کنید. اقدامهای برگشتناپذیر، جریانهای پول، فراخوانی ابزار توسط AI، حذف حساب، انتشار و تغییر دادهی حساس. اصطکاک باید با هزینهی یک تپ تصادفی بزرگ شود و در لحظهی اقدام بنشیند، نه در ورودی.
آیا طراحی بدون اصطکاک مرده است؟
«بدون اصطکاک» بهعنوان هدف همگانی مرده است. بدون اصطکاک در لحظههای درست هنوز درست است. بیزحمت و بدون اصطکاک یکی نیستند و اصطکاک طراحیشده در لحظههای پرریسک نشان میدهد محصول به کاربر احترام میگذارد.
فرق اصطکاک خوب و دارک پترن چیست؟
اصطکاک خوب کاربر را از اشتباهی که پشیمانش میکند محافظت میکند. اصطکاک دارکپترنی شرکت را از تصمیمی که کاربر از قبل گرفته محافظت میکند. اصطکاک خوب در لحظهی اقدام زندگی میکند. اصطکاک دارکپترنی بین کاربر و خروجی. شکلشان میتواند شبیه باشد. نیت دقیقاً برعکس است.
لایه‌ای بسازید که اعتماد کسب میکند
اصطکاک نقطه‌ی مقابل UX خوب نیست. بخشی از UX است که نشان میدهد محصول می‌داند برای چه ساخته شده. تیم‌هایی که در ۲۰۲۶ محصولاتی تحویل می‌دهند که مردم به آن‌ها اعتماد دارند، جریان‌هایشان را نقشه کردند، لحظههای پرریسک را نام‌گذاری کردند، شکل درست اصطکاک را برای هرکدام انتخاب کردند و وقتی مدیریت پرسید چرا این جریان مودال تأیید دارد، از انتخابشان دفاع کردند.
اگر محصول شما اعتماد نشت میدهد چون همه‌ی اقدام‌ها یک‌شکل حس می‌شوند، Brainy را استخدام کنید. ما ممیزی UX، بازطراحی جریان و لایه‌ی اصطکاکی تحویل می‌دهیم که محصول «تپ کن و دعا کن» را به محصولی تبدیل میکند که مردم با آن می‌مانند. اصطکاک یک ماده است. عمداً، در جاهای درست و با شکل درست از آن استفاده کنید، و محصول هر بار که کاربر لمسش میکند مثل مراقبت خوانده می‌شود.
If your product is leaking trust because every action feels the same, Brainy ships UX audits, flow redesigns, and the friction layer that turns a slot machine into a product people respect.
Get Started
