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

طراحی کاربرمحور (UCD) چیست؟

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

طراحی کاربرمحور (User-Centered Design یا به‌اختصار UCD) یک فرایند طراحیِ تکرارشونده است که در آن، کاربر و نیازهایش در همهٔ مراحل کار حضور دارند — نه فقط در ابتدا برای گرفتن ایده و نه فقط در انتها برای گرفتن تأیید. در UCD تیم طراحی با ترکیبی از روش‌های اکتشافی (نظرسنجی، مصاحبه، مشاهده) و روش‌های زایشی (طوفان فکری، طرح‌زدن، ساخت نمونهٔ اولیه) می‌کوشد بفهمد آدم‌ها واقعاً چه می‌خواهند، و بعد چیزی بسازد که برایشان هم قابل‌استفاده باشد و هم در دسترس.

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

این ایده از کجا آمد؟

اصطلاح «طراحی کاربرمحور» در دههٔ ۱۹۷۰ ساخته شد، اما آنچه آن را به یک جریان فکری تبدیل کرد، کار دان نورمن بود؛ دانشمند علوم شناختی که در آزمایشگاه خودش در دانشگاه کالیفرنیا، سن‌دیگو، به این نتیجه رسیده بود که بسیاری از «خطاهای انسانی» در واقع خطاهای طراحی‌اند. اگر آدم‌ها مدام دکمهٔ اشتباهی را فشار می‌دهند، مشکل از آدم‌ها نیست؛ مشکل از دکمه‌ای است که به آن‌ها دروغ می‌گوید.

دو اثر، این نگاه را به بیرون از دانشگاه برد: کتاب User Centered System Design که نورمن با Stephen W. Draper نوشت، و کتاب مشهورتر The Design of Everyday Things (که نخستین بار با عنوان The Psychology of Everyday Things منتشر شده بود). همان کتابی که مفهوم افوردنس و «درهای نورمن» را وارد واژگان روزمرهٔ طراحان کرد. نکتهٔ جالب اینکه خود نورمن بعدها اسمی که ساخته بود را نقد کرد — به این موضوع در بخش تفاوت‌ها برمی‌گردیم.

چهار فاز حلقهٔ UCD

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

• - ۱. فهم زمینه (Context of Use): اول باید بفهمید چه کسانی، کجا و تحت چه شرایطی قرار است از این چیز استفاده کنند. یک اپلیکیشن انبارداری که در دفتر مرکزی عالی به‌نظر می‌رسد، ممکن است در انبار واقعی — با دست‌های پر، نور کم و آنتن ضعیف — بی‌استفاده باشد. ابزارهای این فاز همان روش‌های تحقیق کاربر است: مصاحبه، مشاهدهٔ میدانی و نقشهٔ همدلی.
• - ۲. تعیین الزامات (Requirements): یافته‌های خام را به گزاره‌های روشن تبدیل می‌کنید: چه نیازی، چه نقطهٔ دردی و چه محدودیتی را قرار است حل کنیم؟ اینجا همان‌جایی است که تعریف مسئله اتفاق می‌افتد و اگر بد انجام شود، بقیهٔ فازها با دقت بالا به سمت جواب اشتباه می‌روند.
• - ۳. طراحی (Design): تیم راه‌حل می‌سازد — از طرح‌های سرانگشتی روی کاغذ تا وایرفریم و نمونهٔ اولیه. قاعدهٔ مهم این فاز: تا وقتی نمی‌دانید ایده‌تان درست است، ارزان بسازید. نمونهٔ اولیهٔ گران، تیم را عاطفی و لجباز می‌کند.
• - ۴. ارزیابی (Evaluation): طرح را در برابر همان زمینه و الزامات فاز یک و دو می‌سنجید. تست کاربردپذیری، ارزیابی اکتشافی و تست A/B هرکدام جای خودشان را دارند، اما یک شرط حیاتی وجود دارد: ارزیابی نباید فقط توسط متخصص‌ها انجام شود؛ کاربر واقعی باید در آن حضور داشته باشد.

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

چرا «تکرار» قلب ماجراست

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

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

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

UCD کل تجربه را می‌بیند، نه فقط صفحه را

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

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

استاندارد ISO 9241-210 — که تعریف رسمی «طراحی انسان‌محور» را ارائه می‌کند — همین نگاه را با زبان استاندارد بیان کرده است: هدف، توسعهٔ سامانه‌های تعاملی با تمرکز بر کاربران و نیازهایشان و با به‌کارگیری دانش ارگونومی و کاربردپذیری است؛ رویکردی که اثربخشی و کارایی را بالا می‌برد، رضایت و دسترس‌پذیری و پایداری را بهبود می‌دهد و اثرهای منفی احتمالی استفاده بر سلامت، ایمنی و عملکرد انسان را خنثی می‌کند.

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

چهار اصلی که کار را کاربرمحور می‌کند

پشت این فرایند، چند اصل ساده اما سخت‌گیرانه نشسته است:

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

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

هزینه‌اش را می‌دهد؟ بله

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

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

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

UCD، HCD، تفکر طراحی، تفکر سیستمی و دیزاین اسپرینت

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

• - طراحی انسان‌محور (HCD) نام تازه‌تر همان UCD است، نه چیزی متفاوت. دلیل تغییر نام هم آموزنده است: خودِ نورمن معتقد است کلمهٔ «کاربر» آدم‌ها را به یک شیء تقلیل می‌دهد. وقتی به‌جای «کاربر» بگویید «انسان»، همدلی راحت‌تر اتفاق می‌افتد. نورمن یک قدم جلوتر رفته و اصطلاح «طراحی مردم‌محور» (People-Centered Design) را ترجیح می‌دهد.
• - تفکر طراحی (Design Thinking) دامنهٔ گسترده‌تری دارد. HCD یک رشتهٔ رسمی با فرایند مشخص است که عمدتاً طراحان و مهندسان کاربردپذیری برای ساختن محصول از آن استفاده می‌کنند؛ اما تفکر طراحی همان روش‌ها را برمی‌دارد و به مسائل عمومی — از بازطراحی یک خدمت شهری تا حل یک مسئلهٔ سازمانی — تعمیم می‌دهد. به همین دلیل تفکر طراحی را به تیم‌های غیرطراح هم آموزش می‌دهند.
• - دیزاین اسپرینت (Design Sprint) نسخهٔ فشردهٔ تفکر طراحی است که گوگل ونچرز آن را در قالب یک کارگاه پنج‌روزه بسته‌بندی کرده: دوشنبه باز کردن مسئله، سه‌شنبه طرح‌زدن، چهارشنبه تصمیم‌گیری، پنجشنبه ساخت نمونهٔ اولیه و جمعه تست با کاربر. مزیتش سرعت و تعهد زمانی مشخص است؛ محدودیتش این است که جای پژوهش عمیق را نمی‌گیرد.
• - تفکر سیستمی (Systems Thinking) اصلاً از خانوادهٔ طراحی نیست؛ یک رشتهٔ مستقل است که به‌جای اجزای جدا، «کل‌های به‌هم‌پیوسته» را می‌بیند و در پزشکی، محیط‌زیست، سیاست، اقتصاد و آموزش هم به کار می‌رود. تفاوت مقیاس روشن است: HCD می‌خواهد محصول را بهتر کند، تفکر سیستمی می‌خواهد کل سیستم را عوض کند. نورمن اصرار دارد طراحان هر دو عینک را هم‌زمان بزنند.

خلاصهٔ یک‌خطی: UCD و HCD یک چیزند (دومی عبارت ترجیح‌داده‌شده است)، تفکر طراحی چارچوبی گسترده‌تر است که از روش‌های HCD وام می‌گیرد، دیزاین اسپرینت نسخهٔ یک‌هفته‌ایِ تفکر طراحی است، و تفکر سیستمی رویکردی متفاوت برای دیدن تصویر بزرگ‌تر.

از فردا چطور شروع کنیم؟

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

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

جمع‌بندی

• - طراحی کاربرمحور فرایندی تکرارشونده است که کاربر را در همهٔ مراحل — نه فقط ابتدا و انتها — درگیر می‌کند تا محصولی قابل‌استفاده و در دسترس ساخته شود.
• - اصطلاح در دههٔ ۱۹۷۰ ساخته شد و با کارهای دان نورمن، به‌ویژه The Design of Everyday Things، به جریان اصلی طراحی راه یافت.
• - حلقهٔ UCD چهار فاز دارد: فهم زمینه، تعیین الزامات، طراحی و ارزیابی — و تا رسیدن به نتیجهٔ رضایت‌بخش تکرار می‌شود.
• - هدف پوشش‌دادن کل تجربه است، پس تیم باید چندرشته‌ای باشد و ارزیابی حتماً با حضور کاربر واقعی و با پایش بلندمدت انجام شود.
• - چهار اصل راهنما: تمرکز بر آدم‌ها، حل مسئلهٔ درست، دیدن همه‌چیز به‌عنوان سیستم، و عجله‌نکردن برای رسیدن به راه‌حل.
• - سرمایه‌گذاری روی UCD از چهار مسیر برمی‌گردد: تناسب بهتر با بازار و هزینهٔ پشتیبانی کمتر، ایمنی بیشتر، طراحی اخلاقی‌تر و کسب‌وکار پایدارتر.
• - UCD و HCD یک چیزند؛ تفکر طراحی چارچوبی گسترده‌تر، دیزاین اسپرینت نسخهٔ فشردهٔ یک‌هفته‌ای، و تفکر سیستمی رشته‌ای مستقل با نگاه به تصویر بزرگ است.