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

طراحی تجربهٔ کاربری (UX Design) چیست؟

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

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

تکهٔ اول را نمی‌شود طراحی کرد. تکهٔ دوم را می‌شود. و تقریباً هر بریف بی‌فایده‌ای که دیده‌ام، تکهٔ اول را به‌عنوان خواسته نوشته است.

تعریف

طراحی تجربهٔ کاربری فرایندی است که تیم طراحی با آن محصولاتی می‌سازد که تجربه‌ای معنادار و مرتبط به کاربر می‌دهند. و دامنه‌اش کل فرایند به‌دست‌آوردن و یکی‌شدن با محصول است — از برند و طراحی تا کاربردپذیری و کارکرد.

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

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

تعریف رسمی و تفکیک بنیادی‌اش

ایزو ۹۲۴۱-۲۱۰ تجربهٔ کاربری را چنین تعریف می‌کند: «ادراک‌ها و واکنش‌های یک شخص که از استفاده یا استفادهٔ پیش‌بینی‌شدهٔ یک محصول، سامانه یا خدمت حاصل می‌شود.» و منبع درست تفکیکش می‌کند:

• - ادراک‌ها و واکنش‌های یک شخص — طراح کنترل چندانی رویش ندارد. نمی‌شود تعیین کرد کسی چه احساسی کند یا انگشتش را چطور حرکت دهد.
• - محصول، سامانه یا خدمت — این را می‌شود کنترل کرد: اینکه چطور رفتار کند و چطور به‌نظر برسد.

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

ساده‌ترین راه فکر‌کردن به این حوزه هم همین است: طراحی تجربهٔ کاربری، یک فعل است و یک اسم. طراح چیزهایی را طراحی می‌کند (فعل) که بر تجربهٔ کاربری اثر می‌گذارند (اسم).

چه چیزهایی زیر کنترل ماست

منبع برای محصول فیزیکی — مثلاً یک ماوس — این‌ها را می‌شمارد: نحوهٔ جا‌گرفتن در دست · وزن و اثرش بر حرکت‌دادن · و آسانی استفاده (خودکار به‌کارش می‌برد یا باید فکر کند؟). و برای محصول دیجیتال: چقدر شهودی می‌شود در سامانه حرکت کرد · نشانه‌هایی که به هدف راهنمایی می‌کنند · و مرئی‌بودن جنبه‌های ضروری یک کار در لحظهٔ درست.

چرا، چه، چگونه

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

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

انسان‌محوری

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

هر خواسته را باید به یک ویژگی سامانه ترجمه کرد

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

مثال: «کاربر باید حس اطمینان کند» یک هدف نیست؛ یک واکنشِ امیدواری‌شده است. نسخهٔ قابل طراحی‌اش این است:

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

این سه قلم را می‌شود ساخت، آزمود و در بازبینی نشان داد. «حس اطمینان» را نمی‌شود.

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

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

«چرا» را از آخر بخوانید

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

آزمونی که برای تشخیصش پیشنهاد می‌کنم: سند آخرتان را از آخر به اول بخوانید.

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

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

«تجربهٔ خوب» بی نام‌بردن بافت، مدعای آزمون‌ناپذیر است

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

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

• - «این برای چه کسی، در حال انجام چه کاری، تحت چه محدودیتی بهتر است؟» سه جای خالی، و هر سه باید پر شود.
• - و اگر نمی‌توانید پرشان کنید، آن جمله یک ترجیح است نه یک یافته — که اشکالی ندارد، به شرط اینکه اسمش را درست بگذارید.

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

درزها را کسی مالک نیست

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

چهار درزی که به‌نظرم بیشترین آسیب را می‌زنند:

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

و توصیهٔ عملی: برای هر درز یک نام بنویسید. نه یک تیم — یک نفر. درزی که دو تیم «مشترکاً» مالکش‌اند، مالک ندارد.

«استفادهٔ پیش‌بینی‌شده» یعنی تجربه پیش از نخستین لمس شروع شده

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

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

و از این دو نتیجه درمی‌آید:

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

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

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

جمع‌بندی

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