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

قانون فیتس (Fitts's Law) چیست؟

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

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

این تفاوت، تصادفی یا سلیقه‌ای نیست. یک رابطهٔ اندازه‌گیری‌شدنی پشتش هست که سال ۱۹۵۴، یعنی سال‌ها پیش از آنکه صفحه‌نمایشی در کار باشد، صورت‌بندی شد و امروز یکی از معدود قانون‌های واقعاً کمّی طراحی رابط است. اسمش قانون فیتس است.

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

قانون فیتس چیست؟

پاول فیتس، روان‌شناس آمریکایی، در سال ۱۹۵۴ آزمایشی ساده انجام داد: از آدم‌ها خواست میان دو صفحهٔ فلزی با سرعت هرچه بیشتر ضربه بزنند، و فاصلهٔ صفحه‌ها و پهنایشان را تغییر داد. چیزی که پیدا کرد این بود که زمان لازم برای رسیدن به هدف، رابطه‌ای منظم با دو چیز دارد و فقط با همان دو چیز: فاصله تا هدف و اندازهٔ هدف.

صورت متعارف فرمول این است:

MT = a + b · log₂(2D / W)

که در آن MT زمان حرکت است، D فاصله تا مرکز هدف، W پهنای هدف در راستای حرکت، و a و b دو ضریب تجربی‌اند که به دستگاه ورودی بستگی دارند — برای موس یک مقدار، برای ترک‌پد مقداری دیگر، برای انگشت روی شیشه مقداری دیگر.

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

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

آن لگاریتم در عمل چه می‌گوید؟

حضور لگاریتم در فرمول یعنی بازده نزولی، و این مهم‌ترین نتیجهٔ عملی کل قانون است. اگر دکمه‌ای را دو برابر کنید، زمان رسیدن به آن نصف نمی‌شود؛ فقط به اندازهٔ یک واحد ثابت کم می‌شود. همان یک واحد، چه از ۱۶ پیکسل بروید به ۳۲، چه از ۱۲۸ به ۲۵۶.

اینجا یک بدفهمی رایج هست که ارزش تصحیح دارد: خیلی‌ها می‌گویند «بزرگ‌کردن دکمه‌های بزرگ فایده‌ای ندارد». دقیق‌تر بگوییم، هر دو برابر شدن همان یک بیت را می‌خرد — چه از ۱۶ به ۳۲ و چه از ۱۲۸ به ۲۵۶. چیزی که فرق می‌کند سود نیست، قیمت است:

• - ۱۶ به ۳۲ پیکسل: شانزده پیکسل می‌دهید، یک بیت می‌گیرید. ارزان‌ترین معاملهٔ ممکن.
• - ۳۲ به ۶۴ پیکسل: همان یک بیت، این‌بار به قیمت سی‌ودو پیکسل.
• - ۱۲۸ به ۲۵۶ پیکسل: باز همان یک بیت، اما حالا صدوبیست‌وهشت پیکسل از صفحه را خورده — فضایی که ناگزیر از سهم چیز دیگری برداشته می‌شود.

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

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

لبه‌ها و گوشه‌ها: هدف‌های بی‌نهایت

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

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

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

دو نکتهٔ کاربردی دیگر که کمتر گفته می‌شود:

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

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

از موس تا انگشت: وقتی مکان‌نما ناپدید می‌شود

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

• - انگشت مکان‌نما نیست، یک لکه است. نوک انگشت سطح تماسی حدود ۸ تا ۱۰ میلی‌متر دارد و کاربر مرکز آن را نمی‌بیند. یعنی حتی هدف «به‌اندازهٔ کافی بزرگ» هم خطای ذاتی دارد؛ برای همین توصیه‌های متعارف دربارهٔ حداقل اندازهٔ لمس، از محاسبهٔ خالص فیتس سخت‌گیرانه‌ترند.
• - دست، خودِ هدف را می‌پوشاند. در موس، مکان‌نما چیزی را پنهان نمی‌کند. انگشت و کف دست، بخشی از صفحه را می‌پوشانند — به‌ویژه ناحیهٔ زیر نقطهٔ لمس. برای همین منوی بازشو در موبایل معمولاً باید بالای نقطهٔ لمس باز شود.
• - لبه‌ها دیگر رایگان نیستند. در صفحهٔ لمسی، لبه مانع فیزیکی حرکت نیست؛ انگشت به‌سادگی از لبه بیرون می‌رود. بدتر اینکه سیستم‌عامل خودش لبه‌ها را برای اشاره‌های سراسری (بازگشت، مرکز کنترل، خانه) رزرو کرده است. آن «پیکسل جادویی» در موبایل عملاً وجود ندارد و اگر هم باشد، مال شما نیست.
• - فاصله دیگر تنها هزینه نیست؛ دسترسی هم هست. در دست گرفتن گوشی با یک دست، شست به بالای صفحه به‌سختی می‌رسد. دو نقطه با فاصلهٔ برابر از انگشت، اگر یکی در قوس راحت شست و دیگری بیرون آن باشد، اصلاً هزینهٔ برابر ندارند — چیزی که فرمول فیتس، که فقط D و W را می‌شناسد، نمی‌بیند.

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

قانون فیتس در رابط راست‌به‌چپ

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

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

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

و اینجا نکته‌ای هست که ارزش تأکید دارد. در سیستم شبکه‌ای دیدیم که آینه‌کردن چیدمان با ویژگی‌های منطقی CSS تقریباً رایگان است: ستون‌ها جابه‌جا می‌شوند بی‌آنکه کسی دست به چیزی بزند. اما رایگان‌بودن و درست‌بودنِ آینه، هیچ تضمینی نمی‌کند که دکمهٔ اصلی در دسترس بماند. شبکه آینه می‌شود؛ قوس شست نمی‌شود. این دو با هم حرکت نمی‌کنند، و دقیقاً به همین دلیل است که یک صفحهٔ کاملاً درست‌آینه‌شده می‌تواند از نظر ارگونومی بدتر از نسخهٔ اصلی باشد.

راه‌حل عملی‌اش این است که آینه‌کردن را یک تصمیم بدانید نه یک عملیات خودکار. چیدمان و ترتیب خواندن آینه می‌شوند؛ اما جای دکمهٔ اصلی در موبایل را باید جداگانه و بر اساس دسترسی دست تصمیم بگیرید. بحث تفصیلی‌تر آینه‌شدن عناصر در آیکون‌نگاری آمده است.

کجا نباید به این قانون استناد کرد

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

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

و یک هشدار دربارهٔ اعداد: در نوشته‌های این حوزه ارقام جسورانه‌ای دربارهٔ تأثیر جای دکمه بر نرخ تبدیل دست‌به‌دست می‌شود. این‌ها معمولاً از یک آزمون A/B در یک محصول خاص می‌آیند و به قانون فیتس نسبت داده می‌شوند، در حالی که ده متغیر دیگر هم هم‌زمان عوض شده بوده. جهت‌گیری‌شان مفید است؛ به عدد‌شان استناد نکنید. جای درست این پرسش‌ها، آزمون A/B روی محصول خودتان است.

جمع‌بندی

• - قانون فیتس می‌گوید زمان رسیدن به یک هدف، تابعی از فاصله تا آن و اندازه‌اش است؛ پاول فیتس آن را در ۱۹۵۴ و پیش از وجود رابط گرافیکی صورت‌بندی کرد.
• - W پهنای هدف در راستای حرکت است، نه مساحت آن. دکمهٔ پهن و کم‌ارتفاع در نوار افقی، هدف آسانی است.
• - لگاریتم یعنی بازده نزولی: سود بزرگ‌کردن فقط در انتهای کوچک ماجراست. کوچک‌ترین هدف‌های پرتکرار را بزرگ کنید، نه همه‌چیز را.
• - قانون دربارهٔ حرکت است نه تصمیم. اگر کاربر گیج است، بزرگ‌کردن دکمه کمکی نمی‌کند.
• - لبه و گوشه هدف بی‌نهایت‌اند، اما چند پیکسل فاصله این مزیت را کاملاً از بین می‌برد. در وب، لبهٔ صفحه معمولاً در اختیار مرورگر است نه شما.
• - در لمس، انگشت یک لکه است، هدف را می‌پوشاند و لبه‌ها را به سیستم‌عامل واگذار می‌کند؛ کنار فیتس به نقشهٔ دسترسی شست هم نیاز دارید.
• - در رابط راست‌به‌چپ، چیدمان و ترتیب خواندن آینه می‌شوند اما ناحیهٔ راحت دست آینه نمی‌شود. آینه‌کردن را تصمیم بگیرید، نه خودکار اجرا کنید.
• - بیرون از حرکت سریعِ نشانه‌روی — کشیدن، جست‌وجو، صفحه‌کلید، صفحه‌خوان — استناد به این قانون بی‌جاست.