مقالات تجربه کاربری - کارکردپذیری
کارکردپذیری
کارکردپذیری 
کارکردپذیری (Functionality) چیست؟
💡 این متن «بازنویسی آزاد» است: ایدهها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثالهای تازه بازگو شدهاند و ترجمهٔ کلمهبهکلمه نیست. بخشهای افزودهٔ مترجم در جعبهٔ منبع مشخص شدهاند.
یک صفحه میتواند زیبا باشد، سریع باشد، و در همان حال کار کاربر را انجام ندهد. آن صفحه شکست خورده است.
کارکردپذیری، پایینترین لایهٔ این ماجراست: پیش از هر چیز، آیا این چیز کار میکند؟
تعریف
کارکردپذیری یعنی اینکه آیا یک طرح کار میکند و به کاربر کمک میکند به هدف و نیازش برسد.
و وقتی طرحی کارکردپذیری بالایی دارد، همان کاری را میکند که از آن انتظار میرود، و خوب انجامش میدهد.
دو نیمهٔ این تعریف مهماند. اولی میگوید کار درست را انجام میدهد و دومی میگوید قابلاتکا انجامش میدهد.
پنج لایهٔ گرت
جسی جیمز گرت در «عناصر تجربهٔ کاربری» پنج جزء را از هم جدا میکند، و کارکردپذیری در همهٔ آنها نقش دارد.
- - راهبرد. نیاز کاربر را با پژوهش بفهمید، نه فقط با هدفگذاری.
- - دامنه. میان قابلیتها توازن برقرار کنید و از فلج تحلیلی پرهیز کنید.
- - ساختار. طراحی تعامل شهودی و معماری اطلاعات.
- - اسکلت. وایرفریم و نمونهٔ اولیه، برای ناوبری روان و بیپیچیدگی.
- - سطح. توازن میان کارکرد و جذابیت بصری.
و این پنجتا ترتیب دارند، نه فقط دستهبندی. هر لایه روی لایهٔ زیرینش میایستد — و بههمین دلیل، مشکل سطح را نمیشود در سطح حل کرد اگر ریشهاش در دامنه باشد.
و برای اینکه این ترتیب ملموس شود، ارزش دارد هر لایه را جدا نگاه کنیم.
راهبرد پرسش «برای چهکسی و چرا» است. اگر اینجا اشتباه کنید، همهٔ لایههای بالا با دقت روی مسئلهٔ غلط ساخته میشوند — و هیچ آزمون کاربردپذیریای این را نشان نمیدهد، چون کاربرِ اشتباه دارد کارِ اشتباه را روان انجام میدهد.
دامنه پرسش «چه چیزی داخل و چه چیزی بیرون» است. این لایه بیشترین فشار سیاسی را تحمل میکند، چون هر ذینفعی چیزی برای اضافهکردن دارد و کسی برای کمکردن انگیزه ندارد.
ساختار پرسش «چهچیزی کجاست و از کجا به کجا میرود» است. مشکلهای این لایه معمولاً بهشکل «کاربر پیدایش نمیکند» گزارش میشوند و بهاشتباه با تغییر رنگ و اندازه درمان میشوند.
اسکلت پرسش «در همین صفحه چه چیزی کجا مینشیند» است. این تنها لایهای است که با وایرفریم قابل بحث است و بههمین دلیل بیشترین وقت جلسهها را میگیرد.
و سطح پرسش «چه شکلی است» است — لایهای که همه دربارهٔ آن نظر دارند، و کمترین ظرفیت را برای جبران خطای لایههای پایینتر دارد.
وقتی کار نمیکند
نمونههای منفیاش را همه دیدهایم:
- - سبد خریدی که برای هر تغییر، کل صفحه را دوباره بارگذاری میکند.
- - فرمی که بازخورد اعتبارسنجی ندارد.
- - داشبوردی که باید دستی تازهسازی شود.
و وجه مشترکشان این است که هیچکدام «خراب» نیستند. همهشان کار میکنند — فقط کار کاربر را انجام نمیدهند.
و همین سختترین نوع مشکل کارکردی است، چون در هیچ گزارش خطایی ظاهر نمیشود.
و هر سه نمونه یک ویژگی مشترک دیگر هم دارند: هزینهشان به گردن کاربر است، نه به گردن سیستم.
سبد خریدی که کل صفحه را دوباره بار میکند، از نظر سرور کار درستی میکند. فقط چند ثانیه از وقت کاربر را در هر تغییر میگیرد و او را وامیدارد جای خودش در صفحه را دوباره پیدا کند.
فرمِ بی بازخورد هم داده را درست ذخیره میکند. فقط کاربر تا لحظهٔ ثبت نمیداند اشتباه کرده، و بعد باید برگردد و دنبال جای خطا بگردد.
و داشبوردی که دستی تازه میشود، عدد درست را نشان میدهد. فقط کاربر باید بداند که باید تازهاش کند — و کسی این را به او نگفته.
و همین است که این دسته را در تیمها بیصاحب میگذارد: مهندسی میگوید کار میکند، و راست میگوید. طراحی میگوید زشت نیست، و آن هم راست میگوید. مسئله در فاصلهٔ میان این دو زندگی میکند.
و یک الگوی تکراری هم هست که ارزش نامبردن دارد. مشکل کارکردی معمولاً بهشکل مشکل بصری گزارش میشود.
کاربر نمیگوید «این جریان یک قدم اضافه دارد»؛ میگوید «این صفحه شلوغ است». و تیم هم صفحه را تمیز میکند، قدم اضافه سر جایش میماند، و شکایت شش هفته بعد با عبارت دیگری برمیگردد.
و راه تشخیصش این است که به کاری که کاربر میکرد نگاه کنید، نه به جملهای که گفت. اگر همان کار را دو بار انجام داده، یا وسط راه به صفحهٔ دیگری رفته، یا از پشتیبانی پرسیده، مشکل کارکردی است — هرچقدر هم که شکایتش دربارهٔ ظاهر باشد.
دامنه، و مسئلهٔ قابلیت زیاد
یک هشدار صریح در این بحث هست: انتخاب زیاد و گزینهٔ زیاد، بهدلیل فلج تحلیلی و تردید، علیه تجربه کار میکند.
و قاعدهٔ کنارش هم صریح است: هر قابلیت باید با بقیه منسجم کار کند، و هر چیزی که «قشنگ» است ولی هدفی ندارد، بیرون میماند.
و این را میشود به یک پرسش تبدیل کرد که در جلسهٔ اولویتبندی کار میکند: «این قابلیت کدام کار کاربر را تمام میکند؟»
اگر پاسخ «هیچکدام، ولی خوب است داشته باشیمش» بود، آن قابلیت هزینهٔ دامنه دارد و فایدهٔ کارکردی ندارد.
سنجیدنش
- - آزمون کاربردپذیری، با ابزارهایی مثل کریزیاگ و هاتجار.
- - مصاحبه و نظرسنجی با کاربر.
- - وایرفریم و نمونهٔ اولیه، در وفاداری کم و زیاد.
- - بازخورد ذینفعان و کاربران روی نمونههای اولیه.
- - تکرار پیوسته بر پایهٔ دادهٔ واقعی کاربر.
- - و آزمون انطباق با دسترسپذیری، یعنی WCAG و ARIA.
و مورد آخر عددی هم دارد که ارزش دیدن دارد. طبق گزارش «یک میلیون» وبایم در ۲۰۲۶، ۹۵٫۹ درصد از یک میلیون وبسایت برتر، شکستهای دسترسپذیری قابلتشخیص دارند.
یعنی برای بخش بزرگی از کاربران، این سایتها اصلاً کار نمیکنند — و این یک مشکل کارکردی است، نه یک مسئلهٔ اخلاقی جداگانه.
و میان این روشها یک تقسیمبندی مفید هست. بعضیشان میگویند چه اتفاقی افتاد و بعضیشان میگویند چرا.
نقشهٔ حرارتی و تحلیل داده و نرخ تکمیل، دستهٔ اولاند: ارزاناند، مقیاسپذیرند، و به شما میگویند کجا را نگاه کنید. مصاحبه و مشاهده و آزمون کاربردپذیری، دستهٔ دوماند: گراناند، کوچکاند، و میگویند آنجا چه خبر است.
و ترتیب استفادهشان همین است. با دادهٔ کمّی جای مشکل را پیدا کنید و با روش کیفی بفهمیدش. برعکسش — شروع با مصاحبه بی هیچ سرنخی — وقت زیادی میبرد و بهندرت به همان جایی میرسد که داده در ده دقیقه نشان میداد.
مرزش با کاربردپذیری
این بخش افزودهٔ من است، چون این دو مدام با هم اشتباه میشوند.
- - کارکردپذیری: آیا میشود این کار را انجام داد؟
- - کاربردپذیری: آیا میشود آسان انجامش داد؟
- - سودمندی: آیا اصلاً کسی این کار را میخواهد؟
و ترتیبشان اهمیت دارد. محصولی که کار نمیکند، کاربردپذیریاش بیمعناست. و محصولی که کسی نمیخواهدش، هر دوی اینها را بیفایده میکند.
و بیشتر تیمها وقتشان را روی لایهٔ میانی میگذارند، چون همان لایهای است که در جلسه دیده میشود.
و این ترجیح دلیل سادهای دارد. کاربردپذیری تنها لایهای است که میشود در یک جلسه دربارهٔ آن نظر داد. هر کسی میتواند به یک صفحه نگاه کند و بگوید این دکمه گیجکننده است.
سودمندی داده لازم دارد و کارکردپذیری تعامل با محصولِ واقعی. هیچکدام در یک جلسهٔ یکساعته با اسکرینشات قابل بررسی نیستند — و بههمین دلیل، در همان جلسهها هم بررسی نمیشوند.
و پیامد عملیاش این است: اگر بازبینی طراحی تنها جایی است که محصولتان قضاوت میشود، فقط لایهٔ میانی را قضاوت کردهاید. دو لایهٔ دیگر جای دیگری باید سنجیده شوند — یکی با پژوهش پیش از ساخت و دیگری با آزمون روی نسخهٔ کارکننده.
کارکرد فرسوده میشود
یک نکتهٔ آخر که در بحث کارکردپذیری کم گفته میشود: کارکرد یک ویژگی ثابت نیست. چیزی که امروز کار میکند، ممکن است بدون آنکه کسی خطی از کدش را عوض کند، دیگر کار نکند.
و دلیلهایش بیرونیاند. سرویسی که به آن وابستهاید قاعدهاش را عوض میکند · مرورگرها رفتار پیشفرضشان را تغییر میدهند · حجم داده از آنچه طراحی برایش ساخته شده بود بیشتر میشود · و انتظار کاربر بالا میرود.
مورد آخر ظریفترین است. «کند» یک عدد ثابت نیست؛ نسبت به چیزهایی است که کاربر هر روز استفاده میکند. صفحهای که پنج سال پیش سریع حساب میشد، امروز با همان زمان بارگذاری، کند است.
و نتیجهٔ عملیاش این است که کارکردپذیری یک آزمون یکباره نیست. یک پرسش ساده بپرسید: آخرین بار کِی جریان اصلی محصولتان را از اول تا آخر با یک کاربر واقعی رفتید؟ اگر بیش از یک سال گذشته، دیگر نمیدانید کار میکند یا نه. فقط میدانید که آن موقع کار میکرد.
در بافت فارسی
یک: بیثباتی شبکه، کارکردپذیری را به مسئلهٔ اول تبدیل میکند. اتصال قطع میشود، درخواست نیمهکاره میماند، و کاربر نمیداند سفارشش ثبت شده یا نه.
پس در بافت ما، «کار میکند» یعنی «در شرایط بد هم کار میکند»: تلاش دوباره، وضعیت روشن، و جلوگیری از ثبت دوتایی.
دو: وابستگی به سرویسهای بیرونی، کارکرد را شکننده میکند. درگاه پرداخت، پیامک، نقشه، احراز هویت — هر کدام میتوانند قطع شوند.
و همانطور که در جلوی صحنه و پشت صحنه نوشتم، این خرابیها را کاربر به حساب شما میگذارد. پس مسیر جایگزین بخشی از کارکرد است، نه یک قابلیت اضافه.
سه: دسترسپذیری اینجا هنوز اختیاری تلقی میشود. در بیشتر پروژههای ما نه بودجهای برایش هست و نه کسی مسئولش است.
و اگر بخواهید از جایی شروع کنید، سه چیز بیشترین اثر را دارند: کنتراست کافی · قابلیت پیمایش با صفحهکلید · و برچسب درست روی فیلدهای فرم.
چهار: پشتیبانی، جای کارکرد نبوده را پر میکند. وقتی چیزی در محصول کار نمیکند، کاربر زنگ میزند و کسی دستی حلش میکند.
و این باعث میشود مشکل کارکردی هرگز در داده دیده نشود. پس تیکتهای پشتیبانی را بهعنوان فهرست نقصهای کارکردی بخوانید، نه بهعنوان هزینهٔ عملیات.
پنج: نسخهٔ موبایل اینجا نسخهٔ اصلی است. سهم بزرگی از کاربران ما فقط با گوشی وارد میشوند، و اغلب با گوشیهای میانرده و شبکهٔ ناپایدار.
و این یعنی کارکردپذیری را باید روی همان دستگاه سنجید، نه روی دسکتاپ توسعهدهنده. صفحهای که روی لپتاپ کار میکند و روی گوشی سهساله کند است، برای بخش بزرگی از کاربران کار نمیکند.
و سادهترین اقدامش این است: یک گوشی ارزان و قدیمی در تیم داشته باشید و هر تغییر مهم را یک بار روی همان باز کنید. این تنها آزمونی است که همیشه در دسترس است و تقریباً هرگز انجام نمیشود.
جمعبندی
- - کارکردپذیری یعنی اینکه طرح کار میکند و به کاربر کمک میکند به هدفش برسد · و طرح کارکردپذیر همان کاری را میکند که انتظار میرود و خوب انجامش میدهد
- - گرت پنج لایه را جدا میکند: راهبرد · دامنه · ساختار · اسکلت · سطح — و هر لایه روی لایهٔ زیرینش میایستد
- - نمونههای شکست: سبد خریدی که صفحه را دوباره بار میکند · فرم بی بازخورد · داشبورد دستی — هیچکدام «خراب» نیستند و در گزارش خطا هم دیده نمیشوند
- - انتخاب زیاد علیه تجربه کار میکند · هر چیزی که قشنگ است ولی هدفی ندارد بیرون میماند · و پرسشش: این قابلیت کدام کار کاربر را تمام میکند؟
- - سنجش: آزمون کاربردپذیری · مصاحبه · نمونهٔ اولیه · بازخورد · تکرار · و انطباق با WCAG و ARIA
- - ۹۵٫۹ درصد از یک میلیون سایت برتر شکست دسترسپذیری دارند · یعنی برای بخشی از کاربران اصلاً کار نمیکنند
- - کارکردپذیری یعنی میشود انجامش داد · کاربردپذیری یعنی میشود آسان انجامش داد · سودمندی یعنی اصلاً کسی میخواهدش
- - و در فارسی: «کار میکند» یعنی در شرایط بد هم کار میکند · مسیر جایگزین بخشی از کارکرد است · دسترسپذیری را از کنتراست و صفحهکلید و برچسب شروع کنید · و تیکت پشتیبانی را فهرست نقص بخوانید
منبع
این نوشته «بازنویسی آزاد» است از مطلب What is Functionality? در وبسایت بنیاد طراحی تعامل (Interaction Design Foundation — IxDF؛ بدون نام نویسندهٔ مشخص). مفاهیم پایه — تعریف کارکردپذیری و گزارهٔ اینکه طرح کارکردپذیر همان کاری را میکند که انتظار میرود و خوب انجامش میدهد، معرفی جسی جیمز گرت و کتاب «عناصر تجربهٔ کاربری» و هر پنج جزء راهبرد و دامنه و ساختار و اسکلت و سطح بههمراه توضیح هر کدام، هر سه نمونهٔ منفی یعنی سبد خرید با بارگذاری دوبارهٔ صفحه و فرم بی بازخورد اعتبارسنجی و داشبورد نیازمند تازهسازی دستی، هشدار دربارهٔ انتخاب زیاد و فلج تحلیلی و قاعدهٔ انسجام قابلیتها و بیرونماندن چیزهای بیهدف، همهٔ روشهای سنجش شامل آزمون کاربردپذیری با کریزیاگ و هاتجار و مصاحبه و نظرسنجی و وایرفریم و نمونهٔ اولیه و بازخورد ذینفعان و تکرار پیوسته و آزمون انطباق با WCAG و ARIA، و عدد ۹۵٫۹ درصد از گزارش یک میلیون وبایم در ۲۰۲۶ — از این منبع گرفته شده. متن فارسی، ساختار بخشها و همهٔ تحلیلها کاملاً مستقل نوشته شدهاند.
متن مطلب اصلی تحت هیچ لایسنس بازی منتشر نشده است؛ به همین دلیل اینجا ترجمهٔ کلمهبهکلمه ارائه نشده و متن کامل انگلیسی (بههمراه همهٔ منابع مرتبط) در لینک زیر در دسترس است.
بخشهای افزودهٔ مترجم: صورتبندی آغازین دربارهٔ صفحهای که زیبا و سریع است و کار کاربر را انجام نمیدهد؛ تفکیک دو نیمهٔ تعریف یعنی کار درست و قابلاتکا بودن؛ خواندن پنج جزء گرت بهعنوان لایههای رویهم بهجای دستهبندی و نتیجهاش دربارهٔ ناممکنبودن حل مشکل سطح در سطح؛ تشخیص وجه مشترک سه نمونهٔ منفی یعنی خرابنبودنشان و دیدهنشدنشان در گزارش خطا؛ تبدیل قاعدهٔ دامنه به پرسش «این قابلیت کدام کار کاربر را تمام میکند؟»؛ خواندن عدد دسترسپذیری بهعنوان یک مشکل کارکردی نه یک مسئلهٔ اخلاقی جداگانه؛ کل بخش «مرزش با کاربردپذیری» شامل تفکیک سهگانهٔ کارکردپذیری و کاربردپذیری و سودمندی و ترتیب وابستگیشان و اینکه چرا تیمها روی لایهٔ میانی متمرکز میشوند؛ و کل بخش بافت فارسی شامل بیثباتی شبکه و بازتعریف «کار میکند» به «در شرایط بد هم کار میکند»، شکنندگی ناشی از سرویسهای بیرونی و کارکردبودن مسیر جایگزین، اختیاری تلقیشدن دسترسپذیری و سه نقطهٔ شروعش، و خواندن تیکتهای پشتیبانی بهعنوان فهرست نقصهای کارکردی؛ بازکردن هر پنج لایهٔ گرت بهعنوان یک پرسش جداگانه و توضیح اینکه خطای هر لایه چطور بروز میکند؛ بخش «مشکل کارکردی بهشکل مشکل بصری گزارش میشود» و راه تشخیصش از راه نگاهکردن به کارِ کاربر بهجای جملهاش؛ تقسیم روشهای سنجش به «چه اتفاقی افتاد» و «چرا» و ترتیب درست استفادهشان؛ توضیح اینکه چرا تیمها روی کاربردپذیری متمرکز میشوند و پیامدش برای جلسهٔ بازبینی طراحی؛ و نکتهٔ پنجم بافت فارسی دربارهٔ اصلیبودن نسخهٔ موبایل و سنجش روی دستگاه واقعی؛ تحلیل وجه مشترک دوم سه نمونهٔ منفی یعنی افتادن هزینه به گردن کاربر و بیصاحبماندنشان میان مهندسی و طراحی؛ و بخش «کارکرد فرسوده میشود» شامل دلیلهای بیرونی فرسایش، نسبیبودن مفهوم «کند» نسبت به انتظار روز، و نتیجهاش دربارهٔ یکبارهنبودن آزمون کارکردپذیری
تصاویر: هیچ تصویری از مطلب اصلی بازتولید نشده است. هر سه نمودار این صفحه طراحی مستقل مترجم است.
مشاهدهٔ مطلب اصلی
مترجم: سپنتا پویا
طراح ارشد محصول. مقالات تخصصی UI/UX را با حفظ ساختار و لحن نسخهٔ اصلی به فارسی برمیگردانم.
دربارهٔ من