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

طراحی انسان‌محور (Human-Centered Design) چیست؟

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

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

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

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

چهار اصل

نورمن این رویکرد را با چهار اصل توصیف می‌کند:

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

اصل سوم توضیح می‌دهد چرا نورمن این را «یک پله بالاتر» از طراحی کاربرمحور می‌داند: در نگاه سامانه‌ای، فقط کاربرِ روبه‌روی صفحه اهمیت ندارد؛ اپراتور، پشتیبان، کسی که داده را وارد می‌کند و کسی که تحت تأثیر تصمیم محصول قرار می‌گیرد بی‌آنکه هرگز از آن استفاده کند، همه در تصویرند.

تفاوتش با طراحی کاربرمحور

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

Norman و Stephen Draper در ۱۹۸۶ کتاب User Centered System Design را منتشر کردند و همان‌جا نگاه «اول کاربر» را وارد ادبیات مهندسی کردند. اما نورمن بعدها خودش نسبت به کلمهٔ کاربر منتقد شد و اصطلاح «تجربهٔ کاربری» را تا حدی برای همین ساخت: «کاربر» آدم را به نقشش در برابر محصول تقلیل می‌دهد.

تفاوت عملی‌اش را می‌شود این‌طور گفت:

• - طراحی کاربرمحور می‌پرسد: کسی که این محصول را به‌کار می‌برد چه نیازی دارد؟
• - طراحی انسان‌محور می‌پرسد: همهٔ آدم‌هایی که این محصول به آن‌ها مربوط می‌شود چه کسانی‌اند، و این تصمیم بر آن‌ها چه اثری دارد؟

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

سخت‌ترین اصل: پیدا کردن مسئلهٔ درست

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

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

چرا تیم‌ها این مرحله را رد می‌کنند؟ دلایلش ساختاری‌اند، نه فکری:

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

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

کم‌محبوب‌ترین اصل: مداخلهٔ کوچک

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

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

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

فرهنگ سرزنش و نگاه سامانه‌ای

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

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

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

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

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

جمع‌بندی

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