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

نیازهای کاربر (User Needs) چیست؟

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

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

تعریف

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

دامنه‌اش پهن است. کارکرد، کاربردپذیری، زیبایی، دسترس‌پذیری و رضایت عاطفی همه در همین دامنه می‌نشینند.

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

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

نیاز، خواسته، انتظار

این سه واژه به هم می‌چسبند و کار اولویت‌گذاری را خراب می‌کنند. تفکیکشان صریح است.

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

دسترس‌پذیری در سطح انتظار می‌نشیند، نه در سطح خواسته.

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

هشت نیاز رایج در محصول دیجیتال

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

• - ۱. کارایی: کاربر می‌خواهد کار را سریع تمام کند. در یک ابزار مدیریت پروژه، ساختن و واگذاری یک وظیفه با چند کلیک همین نیاز را جواب می‌دهد.
• - ۲. سادگی استفاده: رابطی با ناوبری بدیهی و راهنمای روشن. نمونه‌اش اپ بانکی است که انتقال پول را از یک رشتهٔ گام به دو گام کوتاه می‌کند.
• - ۳. شخصی‌سازی: محصول ترجیح و سابقهٔ کاربر را به یاد داشته باشد. سرویس پخش ویدئو بر پایهٔ تماشای گذشته پیشنهاد می‌دهد.
• - ۴. دسترس‌پذیری: محصول برای همه قابل استفاده باشد. تبدیل متن به گفتار، و بازشناسی گفتار برای کسی که ورودی متعارف را نمی‌تواند به کار ببرد.
• - ۵. امنیت و حریم خصوصی: ورود امن و سیاست حریم خصوصی شفاف. کاربر باید مطمئن شود اطلاعاتش جای امنی نشسته است.
• - ۶. سرگرمی و درگیرشدن: بازی و شبکهٔ اجتماعی و ویدئو باید محتوایی بدهند که کاربر را برگرداند.
• - ۷. یادگیری: اپ آموزشی باید محتوای ارزشمند را به شکلی جذاب بدهد تا مهارتی به کاربر برساند.
• - ۸. ارتباط اجتماعی: کاربر می‌خواهد راحت وصل شود، محتوا را به اشتراک بگذارد و در لحظه گفت‌وگو کند.

پنج چیزی که شناختن نیاز را سخت می‌کند

طراحی بر پایهٔ نیاز، دشواری‌های خودش را دارد. پنج مورد از بقیه سرسخت‌ترند.

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

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

پژوهش، و چهار کاری که با نیاز می‌کند

پژوهش کاربر دو شاخهٔ اصلی دارد: نگرشی و رفتاری. یکی می‌پرسد کاربر چه می‌گوید و دیگری می‌بیند کاربر چه می‌کند.

هر دو شاخه در نهایت چهار کار مشخص با نیاز می‌کنند.

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

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

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

از درخواست تا نیاز: چهار پله

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

یک جملهٔ واقعی را بگذارید وسط: «یک دکمهٔ خروجی اکسل بگذارید».

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

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

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

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

پس نیاز نه بالاترین پلهٔ این نردبان است و نه پایین‌ترینش. جایی وسط می‌نشیند.

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

آن وقت طراحی را به کسی واگذار کرده‌اید که کل محصول را نمی‌بیند و لازم هم نیست ببیند.

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

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

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

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

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

یک نیاز چند راه‌حل دارد، یک درخواست فقط یکی

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

هر پله را با یک عدد بسنجید: شمار راه‌حل‌های متفاوتی که آن پله اجازه می‌دهد.

درخواست: این عدد یک است. درخواست خودش یک راه‌حل است، پس تنها راه‌حلش خودش است.

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

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

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

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

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

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

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

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

بیشتر چیزی که در جلسه‌ها اسمش تعارض نیاز می‌شود، تعارض دو درخواست است. یک پله پایین‌تر، دعوا اغلب تمام می‌شود.

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

اگر نیازمندی‌ها را بدون گذر از نیاز بنویسید، یک شعبه را انتخاب کرده‌اید بی‌آنکه بقیه را دیده باشید.

در بافت فارسی

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

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

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

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

می‌نویسد «جست‌وجو کار نمی‌کند» یا «اسمم را پیدا نمی‌کنم». پشت این جمله‌ها اغلب «ی» و «ک» غیراستاندارد و نیم‌فاصله و ارقام مخلوط نشسته است.

پس این دسته را باید از سمت علت دسته‌بندی کرد، نه از سمت جمله‌ای که کاربر نوشته. دسترس‌پذیری در این بازار بیشتر شبیه یک باگ دیده می‌شود تا یک نیاز.

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

همین عادت به مصاحبه هم می‌آید و نیاز را زیر یک تأیید کلی پنهان می‌کند. پس پرسش را از قضاوت به واقعه بچرخانید.

«آخرین باری که این کار طول کشید کِی بود؟» تعارف‌بردار نیست، چون پاسخش یک تاریخ است نه یک نظر.

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

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

نتیجه‌اش یک قاعدهٔ ساده است: نبودِ درخواست، نبودِ نیاز نیست. سکوت یک بخش از بازار، خودش یک داده است.

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

جمع‌بندی

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