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

تحلیل وظیفهٔ شناختی (Cognitive Task Analysis) چیست؟

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

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

تحلیل وظیفهٔ شناختی دقیقاً برای همان فاصله ساخته شده — و در محصولاتی که کاربرشان خبره است، معمولاً همان فاصله است که تمام مسئله را نگه داشته.

تعریف

تحلیل وظیفهٔ شناختی (به‌اختصار CTA) رویکردی پژوهشی است که فرایندهای ذهنی کاربر را هنگام انجام یک وظیفه بررسی می‌کند: تصمیم‌گیری، حافظه، توجه، و راهبردهایی که به‌کار می‌برد. منبع می‌گوید کار این روش، بیرون‌کشیدن دشواری‌های پنهان، اصلاح گردش‌کار و هم‌ترازکردن طراحی با مدل ذهنی کاربر است.

و یک تفکیک را همان اول روشن می‌کند: در برابر تحلیل وظیفهٔ سلسله‌مراتبی که گام‌های مشاهده‌پذیر را ترسیم می‌کند، تحلیل شناختی به فرایندهای ذهنیِ زیر هر گام می‌پردازد — قضاوت‌ها، انتخاب‌ها و راهبردها.

یک نکتهٔ کوچک ولی مفید هم می‌گوید: سرواژهٔ CTA در دنیای طراحی معنای دیگری هم دارد (Call To Action، یعنی فراخوان کنش)، و بهتر است در گفت‌وگو مشخص کنید کدام را می‌گویید.

از کجا آمد: اتاق کنترلی که خوانده نمی‌شد

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

و رویدادی که بیشتر از همه این نیاز را فوری کرد، حادثهٔ تری مایل آیلند در ۱۹۷۹ بود: طراحی اتاق کنترل آن‌قدر بد بود که اپراتورهای باکفایت هم نتوانستند جلوی حادثه را بگیرند. همان مثالی که در طراحی انسان‌محور هم برمی‌گردد، اینجا از زاویهٔ دیگری خوانده می‌شود: مسئله این نبود که اپراتور اطلاعات نداشت؛ اطلاعات بود و خوانده نمی‌شد.

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

دو لایهٔ یک وظیفه

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

مثال: کارشناس پشتیبانی یک درگاه پرداخت می‌خواهد بفهمد تراکنشی که «ناموفق» ثبت شده واقعاً پول را برگردانده یا نه.

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

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

چهار چیزی که دنبالشان می‌گردید

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

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

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

سه روش، از ارزان به گران

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

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

محدودیت‌ها: چرا این روش کم اجرا می‌شود

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

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

در بافت فارسی: دانشی که فقط در سر سه نفر است

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

سه موقعیتی که مرتب تکرار می‌شوند:

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

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

جمع‌بندی

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