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

قانون هکل (Heckel’s Law) چیست؟

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

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

و نوازنده‌ها همچنان یادش می‌گیرند — چون هیچ ساز دیگری آن صدا را نمی‌دهد.

تعریف

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

و بیانش را پل هکل، طراح نرم‌افزار فعال از دههٔ ۱۹۶۰، در کتاب «عناصر طراحی نرم‌افزار دوستانه» در ۱۹۸۴ آورد.

و عنوان «قانون» را نایجل درت در مقاله‌ای دانشگاهی در ۲۰۰۴ به آن داد — همان مقاله‌ای که باسون را به‌عنوان مطالعهٔ موردی بررسی کرد.

و استدلال درت همین بود: نوازنده‌ها طراحی پیچیده و منحنی یادگیری تند این ساز را تحمل می‌کنند، به‌خاطر توان بیانی استثنایی‌اش.

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

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

معنایش

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

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

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

چهار نمونه

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

و اگر به این چهارتا دقت کنید، همه یک ویژگی مشترک دارند: در لحظهٔ انتخاب، جایگزین واقعی نداشتند.

و همین، مرز واقعی این قانون است. قانون هکل دربارهٔ تحمل کاربر نیست؛ دربارهٔ نبودِ گزینه است.

چرا این تفکیک مهم است

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

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

و این جمله دو فرض پنهان دارد که هر دو باید بررسی شوند.

فرض اول: ارزش ما واقعاً منحصربه‌فرد است. و در بیشتر محصول‌ها این درست نیست. اکسل و فتوشاپ دهه‌ها بی‌رقیب بودند؛ محصول شما احتمالاً سه ماه بی‌رقیب است.

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

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

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

سه حالتی که با هم اشتباه می‌شوند

و برای اینکه این قانون قابل‌استفاده شود، باید سه وضعیت را از هم جدا کرد. هر سه از بیرون شبیه‌اند — کاربر با وجود سختی می‌ماند — و منشأشان کاملاً فرق می‌کند.

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

دو: هزینهٔ جابه‌جایی. کاربر می‌ماند چون رفتن گران است — داده‌اش اینجاست، تیمش اینجاست، یا یاد‌گرفتن چیز تازه وقت می‌برد.

سه: نبودِ گزینه. کاربر می‌ماند چون باید. سامانهٔ اداری، درگاه اجباری، نرم‌افزاری که کارفرما تعیین کرده.

و تفاوتشان در یک آزمون معلوم می‌شود: اگر فردا رقیبی با همان قابلیت‌ها و رابط بهتر بیاید، چه اتفاقی می‌افتد؟

در حالت اول، کاربران می‌مانند. در حالت دوم، تدریجی می‌روند. و در حالت سوم، همان روز می‌روند.

و بیشتر تیم‌هایی که به قانون هکل استناد می‌کنند، در واقع در حالت دوم یا سوم‌اند — و آن را حالت اول می‌خوانند.

در نسبت با قانون‌های دیگر

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

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

و در ظاهر با اصل کیس در تضاد است. ولی در واقع نیست — کیس می‌گوید در شرایط برابر، ساده‌تر برنده است. هکل می‌گوید شرایط همیشه برابر نیست.

محدودیت‌ها

و منبع خودش صریح است که پیچیدگی نمی‌تواند بهانه باشد.

و یک استدلال فنی هم می‌آورد: رابط رایانه‌ای، برخلاف ساز آکوستیک، محدودیت فیزیکی کمی دارد. باسون به این دلیل سخت است که آکوستیک و مکانیک آن را سخت کرده. نرم‌افزار چنین عذری ندارد.

و رهنمودهایش هم روشن است:

• - هرگز پیچیدگی غیرضروری را نپذیرید.
• - دشواری‌ها را کمینه کنید.
• - الزام‌های دسترس‌پذیری را در نظر بگیرید.
• - به‌یاد داشته باشید کاربران آدم‌هایی با توانایی‌های شناختی متفاوت و فشار زمانی‌اند.
• - و از «پیچیدگی به‌خاطر پیچیدگی» بپرهیزید.

چطور در عمل به‌کارش ببرید

و کاربرد درستش سه چیز است:

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

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

سه: ارزش را صریح بگویید. نه فقط بسازیدش — کاربر باید بداند چه چیزی به‌دست می‌آورد.

و خطاهای رایجش هم مشخص است: پنهان‌کردن قابلیت ارزشمند به‌خاطر سادگی ظاهری · نشان‌ندادن ارزش در ابتدا · آشناسازی سطحی · و ترجیح آسانی کوتاه‌مدت بر قدرت بلندمدت.

سنجیدنش

و روش سنجشش هم متفاوت از سنجش متعارف کاربردپذیری است.

در آزمون کاربردپذیری، ارزش ادراک‌شده را هم بسنجید، نه فقط نرخ موفقیت.

و پافشاری با وجود اصطکاک را مشاهده کنید — یعنی ببینید کاربر با وجود سختی ادامه می‌دهد یا نه. و تکمیل تکلیف را در بلندمدت بسنجید، نه در همان جلسه.

و همین سومی مهم‌ترین است. قانون هکل دربارهٔ رفتار در طول زمان است، و آزمون یک‌ساعته نمی‌تواند آن را ببیند.

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

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

و اگر این الگو را نمی‌بینید، یعنی فرضتان غلط بوده. ریزش بالا بدون ماندگاری بالا، یعنی رابط سخت است و ارزشی هم پشتش نیست.

در بافت فارسی

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

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

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

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

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

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

و همان‌طور که در اثر مالکیت نوشتم، آنچه کاربر را نگه می‌دارد اغلب هزینهٔ جابه‌جایی است نه رضایت. و هزینهٔ جابه‌جایی، با آمدن رقیبِ ساده‌تر، یک‌شبه صفر می‌شود.

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

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

جمع‌بندی

• - قانون هکل: کیفیت رابط در تعیین پذیرش نسبتاً بی‌اهمیت است، اگر ارزش ادراک‌شده بالا باشد
• - پل هکل، «عناصر طراحی نرم‌افزار دوستانه»، ۱۹۸۴ · و نام «قانون» از نایجل درت در ۲۰۰۴، با مطالعهٔ موردی باسون
• - نمی‌گوید رابط بد اشکالی ندارد · می‌گوید رابط بد به‌تنهایی محصول را نمی‌کشد، اگر جایگزینی نباشد
• - چهار نمونه: لینوکس · اکسل · SAP · فتوشاپ — و همه در لحظهٔ انتخاب جایگزین واقعی نداشتند
• - دو فرض پنهان در استفاده‌اش: اینکه ارزش ما واقعاً منحصربه‌فرد است، و اینکه کاربر ارزش را پیش از تحمل پیچیدگی می‌بیند
• - هیک و فیتس دربارهٔ کارایی‌اند و هکل دربارهٔ ادراک ارزش · و کیس می‌گوید در شرایط برابر ساده‌تر برنده است، هکل می‌گوید شرایط همیشه برابر نیست
• - پیچیدگی بهانه نیست · رابط رایانه‌ای برخلاف ساز آکوستیک محدودیت فیزیکی کمی دارد
• - کاربرد درست: ارزش را زود نشان دهید · پیچیدگی را لایه‌لایه بدهید · و ارزش را صریح بگویید
• - سنجشش بلندمدت است · آزمون یک‌ساعته نمی‌تواند رفتار در طول زمان را ببیند
• - و در فارسی: نبودِ جایگزین سنجه‌ها را بی‌معنا می‌کند · پیچیدگی به مانع دسترسی تبدیل می‌شود · ارزش منحصربه‌فرد موقتی است · و ارزش را نشان دهید نه توضیح