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

قانون هیک (Hick's Law) چیست؟

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

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

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

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

قانون هیک چیست؟

در سال ۱۹۵۲، ویلیام ادموند هیک، روان‌شناس بریتانیایی، و کمی بعد ری هایمن در آمریکا، رابطهٔ میان تعداد محرک‌ها و زمان واکنش را اندازه گرفتند. چیزی که پیدا کردند این بود: با افزایش تعداد گزینه‌ها، زمان تصمیم زیاد می‌شود — اما نه به‌تناسب تعداد، بلکه به‌تناسب لگاریتم آن.

RT = a + b · log₂(n)

که RT زمان واکنش است، n تعداد گزینه‌های هم‌ارز، و a و b دو ضریب تجربی. شباهت این فرمول با قانون فیتس اتفاقی نیست: هر دو یک لگاریتم در دل خود دارند و هر دو، هزینه را بر حسب بیت اندازه می‌گیرند. منوی هشت‌گزینه‌ای، سه بیت تصمیم است؛ شانزده‌گزینه‌ای، چهار بیت.

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

نتیجهٔ غافلگیرکننده: منوی سلسله‌مراتبی مجانی نیست

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

• - منوی تخت: یک تصمیم میان ۱۶ گزینه ← log₂(16) = ۴ بیت.
• - منوی دوسطحی: یک تصمیم میان ۴ دسته، بعد یک تصمیم میان ۴ آیتم ← log₂(4) + log₂(4) = ۲ + ۲ = ۴ بیت.

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

پس چرا دسته‌بندی واقعاً کمک می‌کند؟ چون سود واقعی‌اش جای دیگری است و ربطی به این فرمول ندارد:

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

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

شرط‌های ریزی که همیشه حذف می‌شوند

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

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

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

جست‌وجو در برابر تصمیم

پرتکرارترین خطای کاربردی این است که قانون هیک را به مسئله‌ای بچسبانند که اصلاً مسئلهٔ تصمیم نیست. دو موقعیت را از هم جدا کنید:

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

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

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

قانون هیک در رابط فارسی

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

• - برچسب فارسی بلندتر است. بسیاری از اصطلاح‌های تک‌کلمه‌ای انگلیسی در فارسی به ترکیب اضافی تبدیل می‌شوند: Settings می‌شود «تنظیمات» (خوب)، اما Dashboard می‌شود «پیشخوان» یا «داشبورد» و Onboarding می‌شود «فرایند آشناسازی کاربر». فهرستی که در انگلیسی یک ستون باریک بود، در فارسی سطرشکن می‌شود و پویش چشم را کند می‌کند.
• - حرف بزرگ نداریم. در انگلیسی، حرف بزرگِ ابتدای هر آیتم یک نقطهٔ اتکای بصری برای پویش سریع فهرست است. فارسی این نشانه را ندارد، پس تشخیص ابتدای هر آیتم بیشتر به فاصله و ترازبندی وابسته می‌شود — همان بحثی که در فضای منفی داشتیم.
• - مرتب‌سازی الفبایی کمتر کمک می‌کند. کاربر فارسی‌زبان ترتیب الفبای فارسی را به‌اندازهٔ کاربر انگلیسی‌زبان درونی نکرده و معمولاً نمی‌داند «ژ» قبل از «س» است یا بعد از آن. مرتب‌سازی الفبایی در فهرست بلند فارسی، آن پرش سریع به محل تقریبی را که در انگلیسی رایگان است، نمی‌دهد.
• - یک مفهوم، چند املا. «ایمیل / ایمیل / پست الکترونیک»، «موبایل / همراه / تلفن همراه»، فاصله و نیم‌فاصله. کاربری که فهرست را می‌خواند دنبال کلمه‌ای می‌گردد که در ذهنش دارد و ممکن است املای دیگری روی صفحه ببیند و رد شود.

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

پس در عمل چه کار کنیم؟

خلاصهٔ کاربردی، به‌ترتیب اثر:

• - اول تشخیص بدهید مسئله تصمیم است یا جست‌وجو. بیشتر چیزهایی که «قانون هیک» نامیده می‌شوند، مسئلهٔ جست‌وجو هستند و راه‌حلشان کم‌کردن گزینه نیست.
• - روی توزیع کار کنید، نه تعداد. گزینهٔ پرکاربرد را برجسته و پیش‌فرض کنید. این از حذف چند گزینهٔ کم‌کاربرد مؤثرتر است و چیزی را هم از کسی نمی‌گیرد.
• - دسته‌بندی را فقط با برچسب خوب انجام بدهید. اگر برچسب‌ها اجازه نمی‌دهند کاربر با اطمینان بخشی را نخواند، دسته‌بندی وضع را بدتر می‌کند.
• - فرم بلند را بشکنید، ولی به دلیل درست. چندمرحله‌ای‌کردن پرداخت، زمان تصمیم را کم نمی‌کند؛ اضطراب و نرخ رهاکردن را کم می‌کند. سود واقعی است، اما جای دیگری.
• - عدد نسازید. نگویید «با حذف سه گزینه، تصمیم ۲۰٪ سریع‌تر می‌شود». اگر عددی لازم دارید، از آزمون A/B روی محصول خودتان بگیرید.

جمع‌بندی

• - قانون هیک می‌گوید زمان تصمیم با لگاریتم تعداد گزینه‌ها بالا می‌رود؛ هیک و هایمن آن را در ۱۹۵۲ اندازه گرفتند.
• - لگاریتم یعنی هر گزینهٔ اضافه ارزان‌تر از قبلی است؛ پس حذف یک آیتم از منوی کوچک خیلی بیشتر از منوی بزرگ اثر دارد.
• - منوی سلسله‌مراتبی از نگاه خالص این قانون هیچ صرفه‌جویی نمی‌کند: log₂(4) + log₂(4) = log₂(16). سود واقعی دسته‌بندی از حذف شاخه‌های نامربوط می‌آید، نه از تقسیم بیت‌ها.
• - دسته‌بندی با برچسب مبهم، از منوی تخت بدتر است.
• - شرط‌های قانون — گزینه‌های هم‌احتمال، شناخته‌شده، و تصمیم ساده — در رابط واقعی تقریباً هیچ‌وقت برقرار نیستند. جهت‌گیری‌اش را بگیرید، عددش را نه.
• - جست‌وجو مسئلهٔ دیگری است و تقریباً خطی رفتار می‌کند؛ راه‌حلش مرتب‌سازی و جست‌وجوی متنی است، نه کم‌کردن گزینه.
• - در فارسی، برچسب‌های بلندتر و نبود حرف بزرگ و ضعف مرتب‌سازی الفبایی، هزینهٔ خواندن فهرست را بالا می‌برند. اول برچسب‌ها را کوتاه و یکدست کنید.