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

طراحی برای همه (Design for All) چیست؟

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

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

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

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

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

طراحی برای همه چیست؟

طراحی برای همه، تلاشی آگاهانه و نظام‌مند برای ساختن محصولات و خدمات فناوری اطلاعات است که برای همهٔ شهروندان قابل استفاده باشند. کلیدواژهٔ تعریف، «پیش‌دستانه» است.

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

این مفهوم در اواخر دههٔ ۱۹۹۰ و پس از مجموعه‌ای از پژوهش‌های عمدتاً تأمین‌مالی‌شده توسط کمیسیون اروپا وارد ادبیات تعامل انسان و رایانه شد. نامی که بیش از همه با آن گره خورده، Constantine Stephanidis است.

به تفاوت ظریف نام دقت کنید. بحث بر سر «یک طراحی برای همه» نیست، بلکه «طراحی کردن برای همه» است. اولی یک محصول را توصیف می‌کند و دومی یک روش را.

سه سنتی که در آن به هم می‌رسند

طراحی برای همه از صفر ساخته نشد. سه خط فکری مستقل را کنار هم گذاشت:

• - ۱. طراحی کاربرمحور: کاربر را در مرکز فرایندی تکرارشونده می‌گذارد و او را واقعاً وارد کار می‌کند، نه فقط در پایان برای تأیید.
• - ۲. دسترس‌پذیری و فناوری‌های یاری‌رسان: برای موانع کاربران دارای معلولیت راه‌های تعامل جایگزین می‌سازد، از صفحه‌خوان تا کلید تک‌دکمه‌ای.
• - ۳. طراحی همگانی: از معماری و محصولات فیزیکی می‌آید و می‌گوید یک مصنوع را تا حد ممکن برای بیشترین افراد بسازید. هفت اصل مشهورش در سال ۱۹۹۷ در دانشگاه ایالتی کارولینای شمالی تدوین شد.

نکتهٔ مهم این است که هیچ‌کدام به‌تنهایی کافی نیست. طراحی کاربرمحور برای همان کاربرانی بهینه می‌شود که شما دعوتشان کرده‌اید. دسترس‌پذیری به‌تنهایی به یک سیاههٔ وارسی در انتهای کار میل می‌کند.

طراحی همگانی هم فرض می‌کند یک مصنوع واحد می‌تواند به همه خدمت کند. برای یک رمپ ورودی ساختمان این فرض درست است؛ رمپ برای همه یکی است. برای یک رابط دیجیتال معمولاً درست نیست.

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

جای آن میان سه اصطلاح همسایه

چهار اصطلاح اینجا در کارند و تفاوتشان عملی است، نه لفظی:

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

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

ایدهٔ اصلی: فضای طراحی به‌جای یک طرح

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

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

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

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

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

این خط پژوهشی نمونه‌های واقعی هم ساخت. یکی مرورگری وب به نام AVANTI بود که رابطش را با کاربر تطبیق می‌داد. دیگری PALIO بود، برای سازگاری با بافت استفاده. سومی UA-Chess بود، نسخه‌ای چندحسی از شطرنج. انصاف حکم می‌کند بگوییم این‌ها نمونه‌های پژوهشی بودند، نه محصولاتی که به بازار رسیدند.

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

پرسش بدیهی این است: مگر استانداردهای دسترس‌پذیری همین کار را نمی‌کنند؟ پاسخ این رویکرد منفی است، و دلیلش شنیدنی است.

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

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

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

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

کجا وفق‌دادن خودکار می‌شکند

تا اینجا ایده جذاب به نظر می‌رسد. حالا به بخشی برسیم که در منبع اصلی کمتر به آن پرداخته شده: هزینه‌های تعاملیِ رابطی که خودش را عوض می‌کند.

• - ۱. یادگیری می‌شکند: بخش بزرگی از مهارت کاربر، حافظهٔ مکانی است. او یاد گرفته دکمه کجاست. اگر رابط هر بار خودش را بچیند، این سرمایه هر بار صفر می‌شود.
• - ۲. حس کنترل از بین می‌رود: وقتی چیزی بدون توضیح تغییر می‌کند، کاربر نمی‌پرسد «چه خوب»؛ می‌پرسد «کی این را برای من تصمیم گرفت؟».
• - ۳. استنتاج، برچسب‌زدن است: سامانه‌ای که از رفتار کاربر حدس می‌زند او محدودیت حرکتی دارد، دارد یک گمانهٔ پزشکی می‌زند و احتمالاً ذخیره‌اش می‌کند. این یک مخاطرهٔ حریم خصوصی است، نه یک ویژگی.
• - ۴. هزینهٔ ساخت و آزمون: فضای طراحی با چند بُعد، ترکیب‌های زیادی می‌سازد و همه باید آزموده شوند. در عمل تیم‌ها دو حالت می‌سازند و اسمش را سازگاری می‌گذارند.

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

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

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

در بافت فارسی

این بحث در محصول فارسی چند جای مشخص به زمین می‌خورد.

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

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

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

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

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

جمع‌بندی

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

ضعفش هم روشن است. سازگاری کاملاً خودکار، از نمونه‌های پژوهشی فراتر نرفت و در مقیاس صنعتی تقریباً هیچ‌وقت ساخته نشد. پیچیدگی ساخت و آزمونش واقعی است.

اما ایدهٔ مرکزی‌اش بدون آن ماشین‌آلات هم کار می‌کند. تنوع کاربران را از ابتدا یک ورودی طراحی بدانید، گزینه‌های واقعی بدهید، و آن گزینه‌ها را آشکار و برگشت‌پذیر کنید.

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