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

طراحی بازیکن‌محور (Player-Centered Design) چیست؟

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

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

فرق این دو فقط در محتوا نیست. در اولی او «کاربر» است و در دومی «بازیکن». طراحی بازیکن‌محور از همین فرق شروع می‌شود.

طراحی بازیکن‌محور چیست؟

طراحی بازیکن‌محور رویکردی است که بازیکن و انگیزه‌هایش را در مرکز فرایند طراحی می‌گذارد. این اصطلاح را جاناکی کومار و ماریو هرگر در کتاب Gamification at Work صورت‌بندی کرده‌اند. موضوع کتاب بازی‌وارسازی نرم‌افزارهای سازمانی است، یعنی بردن عناصر بازی به ابزارهای کاری.

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

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

بازیکن، نه کاربر: فرق در حق انتخاب

اِیمی جو کیم، طراحی که روی The Sims Online و Rock Band کار کرده، روی این کلمه‌ها حساس است. به نظر او «بازیکن» یعنی کسی که با میل خودش آمده. «کاربر» می‌تواند کسی باشد که چاره‌ای جز استفاده ندارد.

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

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

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

سه هدفی که جابه‌جا می‌شوند

طراحی کاربرمحور معمولاً سه هدف را دنبال می‌کند: اثربخشی، کارایی و رضایت. این همان سه‌گانه‌ای است که در کاربردپذیری دیدیم. کاربر باید کارش را درست و سریع انجام دهد و از نتیجه راضی باشد.

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

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

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

پنج گام، و چرا سازوکار گام چهارم است

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

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

منبع تأکید می‌کند که این گام‌ها خطی و یک‌طرفه نیستند. وقتی مأموریت را تعریف می‌کنید، دربارهٔ بازیکن چیز تازه‌ای یاد می‌گیرید و باید برگردید. به تعبیر کومار و هرگر، بازی‌وارسازی «برنامه» است نه «پروژه». تاریخ پایان ندارد.

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

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

کجا اصطکاک خودِ بازی است، کجا فقط رابط بد

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

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

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

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

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

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

در بازی‌وارسازی سازمانی این مرز حساس‌تر است. کار اصلی کارمند، مثلاً ثبت یک سفارش، هرگز نباید سخت‌تر شود تا بازی‌تر به نظر برسد. چالش باید لایه‌ای اختیاری روی کار باشد. مثلاً هدفی داوطلبانه برای یادگرفتن یک قابلیت تازه، یا مأموریتی گروهی که کسی را مجبور به شرکت نمی‌کند.

وقتی «بازیکن» حق انتخاب ندارد

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

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

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

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

در بافت فارسی

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

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

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

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

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

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

جمع‌بندی

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

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

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