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

تحلیل وظیفه (Task Analysis) چیست؟

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

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

و به همین دلیل، تحلیل وظیفه‌ای که به هیچ پرسشی نرسیده، احتمالاً انجام نشده — فقط مستند شده.

تعریف

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

دو نوع

• - تحلیل وظیفهٔ سلسله‌مراتبی — شکستن وظیفه به زیروظیفه‌های کوچک‌تر.
• - تحلیل وظیفهٔ شناختی — تمرکز بر تصمیم‌گیری، حل مسئله، حافظه، توجه و قضاوت.

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

شش گام اجرا

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

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

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

گام پنجم و ششم، مهم‌ترین گام‌ها

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

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

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

«۴ تا ۸ زیروظیفه» یک محدودیت مفید است

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

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

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

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

خروجی واقعی: ستون پرسش‌ها

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

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

پس سه توصیه:

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

در برابر جریان کاربر و نقشهٔ سفر

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

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

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

و کارهایی که بیرون از محصول شما انجام می‌شوند

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

در حالی که وظیفهٔ واقعی معمولاً پیش از آن شروع شده و پس از آن ادامه دارد:

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

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

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

جمع‌بندی

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