ترجمه کتاب: Designing for Behavior Change
Applying Psychology and Behavioral Economics
Stephen Wendel
حلما بهبود
طراحی رابط کاربری و پیاده‌سازی آن
در فصل‌های بعدی، ما طرح مفهومی محصول را دریافت کرده و آن را به چیزی واقعی و ملموس تبدیل می‌کنیم که افراد بتوانند آن را ببینند و به آن واکنش نشان دهند و از فرآیند طراحی بسیار مشابهی استفاده خواهیم کرد که در فصل‌های ۶ تا ۸ انجام دادیم و زمانی که برای اولین‌بار طرح مفهومی را توسعه دادیم شکل Part IV-1:
- ساختاربندی اقدام به طوری‌که انجام آن برای کاربر امکان‌پذیر و جذاب باشد،
- ساختن محیط برای حمایت از اقدام و
- آماده‌سازی کاربر برای انجام اقدام.
اما این بار به جای طراحی عملکردهای سطح بالا، از این تکنیک‌ها برای طراحی رابط کاربری و پیاده‌سازی خود محصول استفاده خواهیم کرد. از دید فرآیند توسعه‌ی محصول که در مقدمه هم آورده شده بود، ما اکنون در اواسط مرحله‌ی سوم هستیم.
فصل ۹ توضیح می‌دهد که چگونه داستان‌های کاربر را (در محیط توسعه‌ی چابک یا رسمی) در توسعه‌ی محصول به صورت ترتیبی استخراج کنیم و چگونه طرح‌های اولیه‌ی رابط کاربری را بر اساس آن‌ها ایجاد کنیم.
فصل ۱۰ به جزئیات تنظیم طرح‌های رابط کاربری برای تأثیر رفتاری می‌پردازد و در نهایت، فصل ۱۱ درباره‌ی این صحبت می‌کند که چگونه تیم محصول واقعی را می‌سازد.
شکل PARTIV-1
بخش چهارم شامل داستان‌های کاربر، طراحی رابط کاربری و ساخت محصول واقعی است.
ارزیابی وضعیت
اکنون ما یک طرح رفتاری داریم که مشخص می‌کند محصول باید چه کاری را انجام دهد. اقدام حداقلی قابل‌اجرا (Minimum Viable Action) را پیدا کرده‌ایم، آن را بر اساس تجربیات قبلی کاربران تنظیم کرده‌ایم، بخش‌هایی از آن را خودکار کرده‌ایم و باقی‌مانده را قابل‌درک‌تر و آسان‌تر کرده‌ایم و به این فکر کرده‌ایم که چگونه محیط (محصول و زمینه واقعی زندگی کاربر) انگیزه‌های آگاهانه و احساسی ایجاد می‌کند و سرنخ‌ها (Cues) را شکل و ارائه می‌دهد، بازخورد ایجاد می‌کند و رفتارهای رقابتی را دور می‌زند. در نهایت، ما به اطلاعات و آمادگی که کاربر برای موفقیت نیاز دارد، اندیشیده‌ایم.
راهی که اکنون در پیش رو داریم، ایجاد یک فهرست کارهای اساسی، حیاتی و اجتناب‌ناپذیر است که هم برای کاربر و هم برای محصول لازم است. تیم طراحی باید اکنون توالی گام‌ها را از یک فهرست کارهای کسل‌کننده به چیزی تبدیل کند که افراد بخواهند با آن تعامل کنند. من برنامه‌های زیادی را دیده‌ام که فهرست کارهای کاربران موجب شده تعامل لازم بینشان شکل بگیرد، آن‌ها را به هم وصل کرده و آن را به یک “محصول” تبدیل کرده است.
متأسفانه، اکثر مردم واقعاً از یک فهرست کارها هیجان‌زده نمی‌شوند. با این وجود، نتیجه‌ی نهایی ممکن است اصلاً شبیه یک توالی گام‌ها نباشد. برای مثال، آن اقدامات می‌توانند به طور دقیق در یک بازی، در ماژول‌های خود خدمت‌رسان، یا در یک اپلیکیشن موبایل ساده با یک صفحه که به مرور زمان تکامل می‌یابد، جای‌گذاری شوند. هیچ ایرادی در تدوین توالی گام‌ها وجود ندارد ولی این تنها شکلی نیست که یک اپلیکیشن تغییر رفتار، می‌تواند به خود بگیرد. بیایید بررسی کنیم که چگونه می‌توان از فهرست گام‌ها به سمت یک محصول جذاب حرکت کرد.
استخراج داستان‌ها یا مشخصات
برای حرکت از سطح مفهومی به طراحی رابط کاربری، ما باید طرح رفتاری را به قطعاتی تقسیم کنیم که تیم محصول و طراحان رابط کاربری بتوانند از آن‌ها استفاده کنند. این قطعات به نوعی مشابه منبع اولیه (مواد خام) برای تیم عمل می‌کنند تا دقیقاً مشخص کنند محصول چه ساختاری خواهد داشت و چگونه وظایف خود را انجام خواهد داد. هر روش توسعه محصول و هر تیم محصول، راهکار خاص خود را برای انجام این کار دارد (Cagan 2008). برای مثال، برخی از افراد محصول به شدت از مشخصات مکتوب متنفرند، بعضی به آن‌ها وابسته‌اند و بدون آن نمی‌توانند با محصول کار کنند. در ادامه متن دو روش الگوی توسعه محصول را به عنوان مثال توضیح خواهد داد:
- دنیای محصول چابک+ناب (Agile+Lean): در این روش، توسعه به دوره‌های زمانی کوتاه (معروف به “اسپرینت‌ها”) تقسیم می‌شود. نقش‌های مختلف عملکردی در تیم به صورت موازی کار می‌کنند و فرض بر این است که تکرار سریع محصول در چرخه‌های توسعه انجام می‌شود.
- دنیای توسعه ترتیبی (Sequential Development): که به طور طعنه‌آمیزی به عنوان “روش آبشاری” (Waterfall) نیز شناخته می‌شود. در این روش، توسعه در مراحل متوالی و مجزا در بازه‌های زمانی طولانی‌تر انجام می‌شود. هر تیم، محصولات کاری خود را به مرحله بعدی توسعه (طراحی، مهندسی، آزمایش و غیره) به ترتیب از پیش تعیین شده تحویل می‌دهد.
این دو روش از متداول‌ترین متدولوژی‌های موجود در این حوزه هستند و از جمله روش‌هایی هستند که من با آن‌ها آشنایی بیشتری دارم. از آن جا که نمی‌توانم همه تنوع‌های موجود را پوشش دهم، احتمالاً باید این مثال‌ها را با توجه به نیازها و تیم خود تنظیم کنید. برای هر مثال، فرآیند تقسیم طرح رفتاری و توسعه طراحی‌های رابط کاربری را به صورت گام‌به‌گام توضیح خواهم داد.
چابک + ناب (Agile+Lean)
در دنیای توسعه چابک+ناب (که من اکنون در آن فعالیت می‌کنم)، داستان‌های کاربر (User Stories) ایده‌های محصول را به صورت طرح کلی منتقل می‌کنند (Cohn 2010; Rubin 2012). تیم توسعه این آزادی را دارد که در چارچوب این طرح‌ها، توضیحات بیشتری ارائه دهد و نوآوری کند. این داستان‌ها، جملات کوتاه و ساده‌ای را به زبان انگلیسی هستند بیان می‌کنند تا متوجه شویم کاربر چه می‌خواهد انجام دهد. در حالت ایده‌آل، این داستان‌ها همچنین شامل دلیل انجام آن کار توسط کاربر نیز می‌شوند.
برای مثال: به عنوان یک کاربر، می‌خواهم ردیاب ورزشی خود را به سرعت با گوشی‌ام همگام‌سازی کنم، تا بتوانم ببینم امروز چگونه عمل کرده‌ام.
داستان‌های کاربر می‌توانند مستقیماً از طرح رفتاری استخراج شوند. هر گام در توالی اقداماتی که کاربر برای رسیدن به اقدام هدف انجام می‌دهد، یک داستان کاربر به دست می‌آورد. برای مثال:
- اگر محصول باید کاربر را برای اقدام تحریک کند، مانند ارسال پیامک برای یادآوری دویدن، این یک داستان کاربر است که به این صورت می‌آید: ” به عنوان یک کاربر، می‌خواهم وقتی زمان دویدن فرا می‌رسد به نوعی یادآوری دریافت کنم، تا تعلل نکنم.“
- اگر محصول بایستی به کاربران کمک کند تا یک روایت شخصی خاص ایجاد کنند، مانند فکرکردن به دفعات قبلی که دویده‌اند، داستان کاربر می‌تواند این‌گونه باشد:
“به‌عنوان یک کاربر، می‌خواهم به دفعات قبلی که در دویدن موفق بوده‌ام فکر کنم، تا چالش جدید برایم چندان ترسناک نباشد.“ - اگر در مرحله اقدام به آموزشی نیاز است، مانند نحوه‌ی همگام‌سازی ردیاب، داستان کاربر اینطور است: “به عنوان یک کاربر، می‌خواهم بدانم چگونه لاگ‌های خود را به صورت آنلاین به‌روزرسانی کنم، تا دوستانم بتوانند واکنش نشان دهند.“
هر گام در توالی باید از قبل با انگیزه‌های کاربر حاشیه‌نویسی و لحاظ شده باشد، این انگیزه‌ها به بخش “چرا”ی هر داستان کاربر تبدیل می‌شود. متوجه شدید؟ داستان‌های کاربر نشان می‌دهند که کاربر برای انجام یک کار خاص چه باید بکند. داستان‌ها بسیار مفید هستند، تا حدی‌که تیم محصول را مجبور می‌کنند به اقدامات خاصی که کاربر از دیدگاه خودش انجام می‌دهد فکر کنند، نه آن که از یک تحلیل از بالابه‌پایین که شرکت فکر می‌کند کاربر باید انجام دهد، استفاده کند. همان‌طور که تیم داستان‌های کاربر را استخراج می‌کند، به طور طبیعی برخی از آن‌ها را اضافه، حذف یا تغییر می‌دهد زیرا به فرآیند از زاویه‌ی جدیدی فکر می‌کند. با این حال، اگر تیم در مورد روح داستان‌ها و آنچه که داستان‌ها می‌خواهند منتقل کنند مطمئن نباشند، می‌تواند به طرح رفتاری مراجعه کنند و از آن استفاده کنند.
توسعه ترتیبی (Sequential Development)
در دنیای توسعه ترتیبی، مشخصات رسمی (Formal Specs) نیازهای محصول را به تیم توسعه منتقل می‌کنند. هر بخشی از شرکت ممکن است الگوی خاص خود را برای لحاظ این نیازها داشته باشد اما به طور کلی، این مشخصات مستلزم دقیق بودن است و آن‌را تشویق می‌کنند و نسبت به داستان‌های کاربر در یک محیط توسعه چابک، انعطاف‌پذیری بسیار کمتری دارند و فضای کمتری برای ابهام باقی می‌گذارند. برای مثال: می‌گوید که این برنامه به کاربران اجازه می‌دهد تا جهت دریافت پیام‌های متنی ثبت‌نام کنند که به آن‌ها در مورد تعهدشان برای دویدن هشدار می‌دهد.
این مشخصات به تیم می‌گویند که محصول برای انجام اقدام به چه مواردی نیاز دارد. معمولاً این مشخصات از دیدگاه محصول/شرکت حاصل می‌شود، نه از دیدگاه کاربر. در این مرحله از یک فرآیند ترتیبی استفاده می‌شود، ما فقط می‌خواهیم طرح کلی مشخصات را ایجاد کنیم بخش‌هایی که مستقیماً از طرح رفتاری استخراج می‌شوند ولی ما نمی‌خواهیم هنوز مشخصات کاملاً دقیق را توسعه دهیم. چرا؟ چون معمولاً مشخصات بسیار دقیق‌تر از داستان‌های کاربر هستند؛ آن‌ها نه تنها می‌گویند چه چیزی نیاز است، بلکه در مورد چگونگی ارائه آن هم به ما اطلاعات لازم را ارائه می‌دهند. ما هنوز اطلاعات مربوط به بخش “چگونه” را نمی‌دانیم؛ طرح رفتاری فقط اطلاعات مرتبط با “چه چیزی” را ارائه می‌دهد، به زودی در مورد بخش “چگونه” صحبتمان را گسترش خواهیم داد.
فعلاً رابط کاربری را مشخص نکنید
هنگامی که داستان‌های کاربر یا طرح کلی مشخصات از طرح رفتاری استخراج می‌شوند، در مورد این‌که چگونه محصول باید به نظر برسد (و نه فقط این‌که چه کاری باید انجام دهد) گرایشی طبیعی به افراط در مشخص‌سازی و تعریف وجود دارد، با این وجود فعلاً در برابر این وسوسه مقاومت کنید! یک تنش بین برنامه‌ریزی ساختارمند و خلاقیت وجود دارد. تا به این‌جا، ما از یک فرآیند برنامه‌ریزی سنگین در مورد فکرکردن به این‌که کاربر چه کاری باید انجام دهد، محیط چه کاری انجام می‌دهد و چگونه باید کاربر آماده شود، استفاده کردیم. بسیار وسوسه‌انگیز است که فکر کنیم چیزهایی که می‌خواهیم کاربران انجام دهند و به چه طریقه‌ای می‌خواهیم رفتار کنند و (آیا) همان‌طور که تصور می‌کنیم، اقدام اتفاق می‌افتد؟
اما در واقعیت، به چیزهای بیشتری نیاز است. کاربران باید بخواهند رفتار خود را تغییر دهند. هنگامی که یک محصول به آن‌ها در تغییر کمک می‌کند، زمانی معنا دارد که آن‌ها باید بخواهند از محصول استفاده کنند. محصول نباید آن‌ها را از اقدام مدنظر دور کند: هیچ محصولی نمی‌تواند در تغییر رفتار مؤثر باشد اگر مردم هرگز از آن استفاده نکنند. میل به تغییر اکثر مردم را از طریق یک محصول زشت و بی‌روح کاری را پیش نمی‌برد. توسعه محصولی که مردم از استفاده از آن لذت ببرند نیاز به چیزی بیشتر از یک طرح رفتاری با دیدی از بالابه‌پایین دارد؛ نیاز به خلاقیت دارد و همچنین نیاز است از تخصص تیم در توسعه محصول و طراحی تعامل بهره‌مند شود.
چگونه می‌توان برنامه‌ریزی و خلاقیت را با هم ترکیب کرد؟ بخشی از راه‌حل در فلسفه توسعه نهفته است: به برنامه‌ریزی برای تغییر رفتار که تا به این‌جا انجام داده‌ایم به عنوان تعیین عملکرد مطلوب محصول فکر کنید، نه به عنوان تعیین نحوه دستیابی به آن. بخش دیگری از راه‌حل که ظریف‌تر است، این است که با جداکردن طرح رفتاری از فرآیند طراحی رابط کاربری، از ایجاد یک نقطه مرجع قوی جلوگیری کنید. هدف این است که از استفاده از طرح به عنوان نقطه شروع ضمنی و ناخواسته برای چیزی که باید به نظر برسد، اجتناب کنید؛ چرا که این امر می‌تواند به شدت بر شکل نهایی طراحی رابط تأثیر بگذارد.
چگونه می‌توان راه را برای فرآیند طراحی باز کرد و از ایجاد یک محصول یک‌شکل و تکراری جلوگیری کرد؟ سعی نکنید یک طراحی رابط را به داستان‌های کاربر یا طرح‌های مشخصات تحمیل کنید. آن‌ها را بر روی “چه چیزی” متمرکز نگه دارید، نه “چگونه”، سپس اجازه دهید تیم طراحی (اعضای تیم محصول که در حال تکمیل نیازها هستند) برای مدتی طرح رفتاری را کنار بگذارند و فقط از داستان‌های کاربر یا طرح‌های مشخصات و پرسوناهای از قبل توسعه‌یافته استفاده کنند. در مورد این‌که محصول ممکن است چگونه به نظر برسد ایده‌پردازی کنید؛ آن‌ها را طرح‌ریزی کنید. نمونه‌سازی کنید. این فرآیند نوعی جادوگری خاص است.
ساختاری را برای وقوع جادو شکل دهید
با داشتن داستان‌های کاربر یا طرح کلی مشخصات رسمی در دست، اکنون زمان آن است که تیم دقیقاً شکل ویژگی‌های محصول و محتوای هر صفحه را مشخص کند. این‌جا هیچ قانون سخت و سریعی وجود ندارد، کتاب‌های بسیاری از قبل درباره نحوه طراحی معماری اطلاعات یک برنامه و طراحی تجربه کاربری و طراحی تعامل نوشته شده است که می‌توانید از آن‌ها استفاده کنید (Cooper et al. 2007; Saffer 2010). از آن‌جا که این کتاب درباره طراحی تعامل یا طراحی تجربه کاربری نیست، این موضوع را به منابع دیگر واگذار می‌کنم. به فرآیند طراحی رابط کاربری به عنوان نوعی جادوی ساختارمند فکر کنید که تفکر خلاق، محتوای جالب و قابل‌استفاده و تعاملات را در چارچوب محدودیت‌های تعریف شده می‌چیند. گفتنی است که این محدودیت‌ها، اگر بیش از حد محدودکننده نباشند، امکان وقوع فرآیند خلاقانه را فراهم می‌کنند؛ در غیر این صورت اگر دامنه گزینه‌های ممکن زیاد شود، برای کاربر گیج‌کننده خواهد بود.
طراحی برای تغییر رفتار سه نوع محدودیت را اعمال می‌کند تا جادو را درون خود شکل می‌دهند:
- محدودیت‌های عملکردی
- ارائه مدل از نحوه تصمیم‌گیری ذهن
- الگوهای طراحی محصول: قالب‌هایی برای این‌که محصول چگونه ممکن است به نظر برسد.
مقداری محدودیت عملکردی، یک مدل تصمیم‌گیری و یک یا دو الگوی طراحی محصول را با هم ترکیب کنید. عالی شد! “
محدودیت‌های عملکردی نشان می‌دهند که محصول بایستی چه کاری را انجام دهد. ما قبلاً این محدودیت‌ها را، ابتدا در طرح رفتاری و سپس در داستان‌های کاربر یا طرح کلی مشخصات که در اوایل این فصل ایجاد شده‌اند، توسعه داده‌ایم. در فصل‌های 1 تا 3، دریافتیم که ذهن چگونه تصمیم می‌گیرد (ساده نگه‌داشتن موارد، فرض‌نکردن توجه مداوم به صورت آگاهانه، استفاده از تداعی‌های قبلی کاربر و غیره) و همچنین این موضوع برای تغییر رفتار چه معنایی دارد (قیف ایجاد اقدام (Create Action Funnel) و سه استراتژی برای عبور از آن). با این حال، الگوهای محصول نیاز به توضیح بیشتری دارند.
الگوهای طراحی محصول برای تغییر رفتار
یک سوال که ممکن است هنگام شروع طراحی ساختار برنامه از خود بپرسید این است: چه نوع برنامه‌ای برای تغییر رفتار بهترین است؟ یک بازی مناسب است؟ یا یک آموزش جدی؟ من به شدت معتقدم که هیچ “بهترین” راهی برای ساختاردهی یک محصول به منظور تغییر رفتار وجود ندارد. در عوض روانشناسی مهم است و بسیاری از انواع محصولات می‌توانند مؤثر باشند. اگر نمی‌دانید از کجا شروع کنید، مجموعه‌ای از قالب‌ها وجود دارد که می‌توانید از آن‌ها استفاده کنید. محصولات نرم‌افزاری، مانند محصولات فیزیکی، معمولاً در دسته‌بندی‌های مشخصی قرار می‌گیرند. افرادی که در حوزه توسعه محصول فعالیت می‌کنند می‌دانند که یک اپلیکیشن جدید چگونه به نظر می‌رسد و چه کاری انجام می‌دهد، حتی قبل از این‌که اولین خط کد نوشته شود. ما می‌دانیم که یک برنامه آموزشی سرگرم‌کننده برای کودکان چه کاری انجام می‌دهد. می‌دانیم که یک بازی تیراندازی چگونه به نظر می‌رسد یا یک برنامه برای یادداشت‌برداری به چه صورت است.
این دسته‌بندی‌ها یا ژانرهای محصول، یک مجموعه کلی از انتظارات را در مورد محصول ارائه می‌دهند، هر محصول جدید معمولاً در حاشیه‌ها این انتظارات دست به نوآوری می‌زند. تنها در موارد نادر است که یک محصول واقعاً یک ژانر جدید ایجاد می‌کند و می‌تواند در میان کاربران جا بیافتد و معمولاً پس از ساخت چندین نمونه است که متوجه می‌شویم یک ژانر جدید به وجود آمده است.
در فضای تغییر رفتار، مجموعه‌ای از قالب‌ها قبلاً وجود داشتند که می‌توان از آن‌ها برای برنامه‌های موبایل و اپلیکیشن‌های آنلاین استفاده کرد و اغلب یک محصول خاص از قبل از یکی از این قالب‌ها در بخش‌های مختلف برنامه استفاده کرده است. به این صورت، می‌توان قالب‌ها را نه تنها به عنوان ژانرهای محصولات، بلکه به عنوان الگوهای طراحی قابل‌استفاده مجدد برای تغییر رفتار در نظر گرفت که می‌توان آن‌ها را در صورت نیاز در برنامه خود پیاده‌سازی کرد (Gamma et al. 1994; Alexander et al 1977(.
هر الگو دستورالعمل‌هایی را برای ترویج تغییر رفتار در یک زمینه خاص ارائه می‌دهد و یک قالب برای ظاهر و حس آن بخش از برنامه را فراهم می‌کند. جعبه ابزار طراحی با لحاظ قصد و نیت (Design with Intent Toolkit) از دن لاکتون (2010) و دسته کارت‌های یادداشت ذهنی (Mental Notes Deck) از استیون اندرسون (2013) نمونه‌هایی از این الگوهای تغییر رفتار را ارائه می‌دهند. مجموعه الگوهای تغییر رفتار می‌توانند برای برنامه‌های آنلاین یا موبایل با تعاملی بالا و عملکرد غنی به کار گرفته شوند، به ویژه در مواردی که تصمیمات بزرگی لحاظ شوند یا رفتارهایی به طور مکرر تکرار شوند. این الگوها فرصت‌های زیادی برای تعامل با کاربران فراهم می‌کنند و زمینه تصمیم‌گیری و اقدام را طوری تغییر می‌دهند که بهترین تناسب را با کاربر خاص داشته باشد.
مجموعه متفاوت از الگوها می‌تواند برای مداخلات محدود و کم تماس (مانند ارسال ایمیل یا پیامک) به کار گرفته شود. در این‌جا مثال‌هایی از الگوهای طراحی با تماس (مراجعه) زیاد (High-Touch) و با تماس (مراجعه) کم (Low-Touch) ارائه شده است.
رویکردهای با تماس (مراجعه) زیاد (High-Touch Approaches)
پشتیبانی در تصمیم‌گیری
به یک کاربر که در حال برنامه‌ریزی برای مخارج تحصیلات فرزند خود است اپلیکیشنی کمک می‌کند تا گزینه‌های پس‌انداز برای این هدف را ارزیابی کند، این اپلیکیشن می‌تواند تجزیه و تحلیل کند و اطلاعات مورد نیاز را به کاربر ارائه دهد، بخشی از فرآیند را خودکار کند و کاربر را از اولویت‌ها و چالش‌های دیگر آگاه سازد. HelloWallet یک نمونه از این محصولات است.
بازی‌های تغییر رفتار
کاربران در محیط کلاس درس هستند و می‌خواهند شیوه‌های همکاری را یاد بگیرند و از طریق بازی دو نفره‌ای که نیاز به همکاری و ارتباط دارد و به واسطه تجربه به یادگیری می‌پردازند Way یک نمونه از این بازی‌هاست. این موارد تحت عنوان بازی‌های تغییر رفتار (بازی‌های جدی و بازی‌های باهدف خاص) شناخته می‌شوند، طراحان بدین منظور بازی‌هایی را برای ارائه و آموزش مسائل اجتماعی یا رفتاری مشخص توسعه داده‌اند. کاربران ممکن است این بازی‌ها را به عنوان بخشی از نیاز شغلی خود بداند (مانند شبیه‌سازی‌های نظامی یا بازی‌های آموزشی شغلی) که به آموزش‌های جسمی یا ذهنی از این طریق می‌پردازد.
بازی‌وارسازی (Gamification)
یک کاربر می‌خواهد از طریق تغذیه بهتر و ورزش بیشتر به سلامتی دست یابد. به همین منظور او یک تیم تشکیل می‌دهد و در یک سیستم امتیازدهی مشترک با دیگران رقابت می‌کند برنامه Keas، به همین منظور ساخته شده است. با وجود آن‌که بازی‌های تغییر رفتار، بازی‌های کامل هستند، بازی‌وارسازی و استفاده از عناصر طراحی بازی در زمینه‌های غیر بازی استفاده می‌کند و معمولاً با پاداش‌های اجتماعی و عناصر رقابتی حول مجموعه‌ای از اقدامات هدفمند همراه است (برای مطالعه در مورد دیدگاه‌های مختلف در مورد بازی‌وارسازی، به Deterding 2011 و Zichermann and Cunningham 2012 مراجعه کنید.)
برنامه‌ریزها (Planners)
هنگامی که کاربران می‌خواهند تغذیه سالم‌تری داشته باشند و یک باغچه سبزیجات برای این منظور ایجاد کنند. آن‌ها تصمیم می‌گیرند یک برنامه مشخص برای این‌که چه چیزهایی باید در باغشان کاشته شود، زمان کاشت و نحوه طراحی باغ برای رشد و زیبایی بهینه تنظیم کنند. با هدفی مشابه Mother Earth News یک اپلیکیشن است که برنامه‌ریز ایجاد یک باغ سبزیجات است.
تغییر رفتار کم تماس (Low-Touch Behavior Change)/ (مراجعه کم)
تعاملات پر تماس و مراجعه همیشه امکان‌پذیر نیستند و ممکن است تنها یک فرصت برای تعامل با کاربر داشته باشید و به یک رسانه غیرفعال (مانند ایمیل یک‌طرفه یا چاپ) محدود باشید یا بدانید که فرصت جلب‌توجه کاربر کوتاه است. در این‌جا الگوهایی وجود دارند که برای یک محیط کم تماس مناسب‌تر هستند (یک ایمیل واحد، چند پیامک، یک صفحه وب یا یک آگهی چاپی):
درخواست برای “فکرکردن متفاوت“
کاربران پول زیادی برای برق خرج می‌کنند و ترجیح می‌دهند کمتر خرج کنند. هزینه‌های خود با همسایگانشان مقایسه می‌کنند و می‌بینند که بایستی به طور متفاوتی درباره میزان هزینه‌ای که صرف کنند، فکر کنند. برنامه Opower این کار را با یک نامه فیزیکی ساده به نتیجه می‌رساند.
فراخوان به اقدام (Call to Action)
یک کاربر در مورد یک مسئله سیاسی بزرگ، مانند خط لوله کی‌استون XL) چه موافق و چه مخالف آن) نگران است. او یک ایمیل دریافت می‌کند که حاوی لینکی برای ارسال سریع نامه یا کمک مالی به موضوع است، کاربر می‌تواند در چند ثانیه اقدام کند و مسیر را ادامه دهد. ایمیل و صفحه فوروارد اقدامی بیشتر از این نیاز نیست. بسیاری از سازمان‌های حمایتگر مانندSierra Club این کار را انجام می‌دهند.
نکات آموزشی (How-to Tips)
یک زن در شرف داشتن اولین فرزند خود است و نمی‌داند برای آماده‌شدن چه باید بکند. از طریق تلفن همراه خود، هر هفته نکات ساده و کوتاهی در مورد کارهایی که باید انجام دهد، دریافت می‌کند. برنامهText4Baby این کار را انجام می‌دهد.
یادآوری‌های ساده و پیشنهادهای برنامه‌ریزی (Simple Reminders and Planning Prompts)
کارمندان یک شرکت نمی‌خواهند به آنفولانزا مبتلا شوند (خانواده‌هایشان را بیمار کنند). آن‌ها نامه‌های ساده‌ای دریافت می‌کنند که به آن‌ها یادآوری می‌کند چه زمانی و کجا واکسینه شوند و یک پیشنهاد برای برنامه‌ریزی زمانی که خودشان می‌توانند واکسینه شوند دریافت می‌کنند. Milkman et al (2011) . این کار را انجام دادند و تا 8 درصد افزایش در نرخ واکسیناسیون به دست آوردند.
گزارش‌های وضعیت (Status Reports)
کاربری که تازه‌وارد یک شهر است و می‌خواهد با افراد جدید آشنا شود، به طور منظم اعلان‌هایی در مورد رویدادهای آینده در زمینه‌های مورد علاقه خود دریافت می‌کند. Meetup. om این کار را انجام می‌دهد و بسیاری از مؤسسه‌هایی که رویدادهای حضوری برگزار می‌کنند پوشش می‌دهد.
من هیچ مطالعه دقیقی را نمی‌شناسم که این رویکردهای پر تماس و کم تماس را مقایسه کند، اما حس شهودی و تجربه شخصی من می‌گوید که در رویکردهای پر تماس آزادی بیشتری برای نوآوری دارید و تأثیر بیشتری می‌توانید داشته باشید.
ترسیم کنید (Draw It Out)
در حین طراحی تعاملات و ظاهر و حس محصول، تیم محصول وایرفریم‌ها (یا ماکاپ‌ها یا پروتوتایپ‌ها، بسته به سبک‌کاری‌شان) را شکل می‌دهد تا نشان دهد که کاربر واقعاً چه چیزی را می‌بیند و با چه چیزی تعامل دارد. در حین توسعه این وایرفریم‌ها، تیم باید بر ارزش اصلی و قابلیت استفاده محصول تمرکز کند و باید به سؤالات زیر پاسخ دهند:
آیا تجربه کاربری واقعاً منطقی است (به ویژه با توجه به تحقیقات کاربر)؟
چگونه می‌توان محتوا را به شکلی واضح به کاربر ارائه داد که با تجربیات قبلی او سازگار باشد؟
چه راهی برای تعامل با کاربر جذاب و جالب است؟
فردی که دیدگاه رفتاری را به تیم محصول می‌آورد (چه دانشمند علوم اجتماعی رفتاری، طراح تعامل، مدیر محصول یا هر فرد دیگری) باید به عنوان یک منبع در حین به تصویرکشیدن ایده‌ها نقش‌آفرینی کند و می‌تواند به سوالات مربوط به رفتار و عملکرد مطلوب محصول پاسخ دهد (مشابه نقش مالک محصول در محیط اسکرام). او می‌تواند بازخوردهای رفتاری را ارائه دهد و کارشناس UX و مدیر محصول در تلاش‌اند تا استراتژی‌های رفتاری را به ویژگی‌های جذاب و معقول برای کاربر تبدیل کنند.
با این وجود، فراتر از این بازخورد، به یاد داشته باشید که فرآیند خلاقانه باید پیش برود تا یک محصول خوب و تمیز ایجاد شود. رفتار انسانی و احساسات پیچیده هستند درک آن‌ها به تنهایی دشوار است، چه برسد به تغییر دادنشان. با توجه به تجربه من تمرکز بر تغییر رفتار نیاز به انرژی زیادی دارد؛ طراحی یک محصول منطقی و تواما زیبا کار بسیار دشواری است. اگر متخصص رفتاری یک فرد جدا در تیم محصول باشد در این مواقع زمان آن است که کار را به متخصصان غیر رفتاری و محصول بسپارد و اگر متخصص رفتاری چندین نقش دارد و مدیر محصول یا کارشناس تجربه کاربری است، بایستی تمرکز خود برای تغییر رفتار را بردارد. برای مدتی به محصولات زیبا نگاه کنید تا ذهنتان آزاد شود. سپس یکی از آن‌ها را طراحی کنید، بعداً زمان برای بازگشت به لحاظ ملاحظات رفتاری وجود دارد.
یک داستان هشداردهنده: دستبند ورزشی من در سال 2012
در سال 2012، یک دستبند رایانشی پوشیدنی جدید به بازار آمد. این محصول ترکیبی از ردیابی ورزش و خواب بود، یک بند داشت که در شب می‌پوشیدید و یکی که در طول روز استفاده می‌کردید. ایده بسیار عالی به نظر می‌رسید و من یکی از آن‌ها را پیش‌خرید کردم و درست قبل از کریسمس آن را دریافت کردم. این محصول در نهایت به یک مثال عالی از آنچه اتفاق می‌افتد وقتی یک شرکت محصولی می‌سازد که به شدت بر تغییر رفتار تمرکز دارد اما از ساخت یک محصول خوب غافل می‌شود، تبدیل شد. (نام شرکت را ذکر نمی‌کنم، زیرا شرکت همچنان در حال بازنگری و بهبود محصولات خود است و تنها شرکتی نیست که یک بند ورزشی ساخته که در مراحل اولیه مشکلاتی داشت!)
من و همسرم این محصول را به عنوان یک هدیه دونفره در نظر گرفتیم: من از دستبند ورزشی استفاده می‌کردم و همسرم از ردیاب خواب؛ بنابراین، در روز کریسمس، برنامه را نصب کردم و شروع به امتحان دستبند ورزشی کردم. از منظر رفتاری، محصول کارهای زیادی را به درستی انجام می‌داد.
این دستگاه به صورت خودکار خواب و ورزش را ردیابی می‌کرد که انجام این موارد به صورت دستی دشوار است. رابط کاربری ساده و تمیز داشت که به من کمک می‌کرد تا اهداف منطقی برای شروع تعیین کنم و سپس بازخورد مداوم و پاداش‌های کوچک (آیکون‌های کوچک روی صفحه) ارائه داد که با پیشرفت من ظاهر می‌شدند.
روز بعد به دفتر رفتم. بعد از یک روز طولانی نشستن روی صندلی، بررسی کردم که چقدر ورزش کرده‌ام. صفحه‌ای که دیدم مانند شکل 9-1 بود.
شکل 9-1: گزارش ورزش روزانه من در حالی که پشت کامپیوتر نشسته بودم.
باور کنید یا نه من آن روز 38 مایل راه نرفته بودم و پشت میز نشسته بودم. ای کاش اینطور بود. ناامیدی شماره یک: واضحاً یک اشکال در سیستم ردیابی وجود داشت.
وقتی آماده رفتن به خانه شدم، کت خود را پوشیدم. دستبند از دستم افتاد. قفل مغناطیسی کوچک که آن را در جای خود نگه می‌داشت، به‌اندازه کافی قوی نبود. (در روزهای بعدی هم چندین بار به طور تصادفی افتاد؛ خوش‌شانس بودم که آن را گم نکردم.) ناامیدی شماره دو: مشکل در طراحی صنعتی. روز بعد، آن را روی میز جا گذاشتم. کمی بعد از ناهار، صفحه‌ای که دیدم مانند شکل 9-2 بود.
شکل 9-: یکم قضاوت گرایانه است نه؟
تجربه چندان خوبی نبود. اگر محصول کاملاً درست بود و من واقعاً غیرفعال بودم، شاید پیام را راحت‌تر می‌پذیرفتم. اما به دلیل عدم آگاهی از من، نتیجه گرفت که داده صفر به معنای مشکل در رفتار من است، نه کمبود اطلاعات خودش و یک طراح تعامل خوب باید این مسئله را متوجه می‌شد. خب، به هر حال، من آن را سریعاً پس دادم. هنوز هم از مفهوم کلی محصول واقعاً هیجان‌زده‌ام و مشتاقانه منتظر نسخه بعدی هستم.
اما در حال حاضر، این یک داستان هشداردهنده است در مورد این‌که وقتی فقط بر تغییر رفتار تمرکز می‌کنید و به اندازه کافی بر ساخت یک محصول خوب توجه نمی‌کنید، چه اتفاقی می‌افتد. به یاد داشته باشید که محصولات مؤثر از نظر رفتاری باید جذاب و قابل‌استفاده نیز باشند.
جمع‌بندی نکات روی یک دستمال‌کاغذی (On a Napkin)
مواردی که باید انجام دهید:
- طرح رفتاری را به منبع و مواد اولیه برای طراحی محصول تبدیل کنید. در دنیای چابک (Agile)، این یعنی داستان‌های کاربر. در دنیای توسعه ترتیبی (Sequential Development)، این یعنی طرح کلی نیازمندی‌های کامل محصول.
- در ابتدا، سعی کنید طراحی رابط کاربری را بر اساس طرح رفتاری مشخص نکنید. بر روی آنچه محصول باید انجام دهد تمرکز کنید، نه این‌که چگونه باید انجام شود.
- به تیم خلاق اجازه دهید با ایده‌پردازی یک تجربه جذاب برای محصول جادو کنند.
- می‌توانید از الگوهای طراحی برای تغییر رفتار که برای کاربران آشنا هستند استفاده کنید، مانند ردیاب‌ها (Trackers) یا یادآورها (Reminders).
- وایرفریم‌ها (Wireframes) یا ماکاپ‌ها (Mockups) را توسعه دهید.
چگونه متوجه می‌شوید که مشکلی وجود دارد:
- وقتی تیم محصول بیش از حد بر ساخت محصولی که به رفتار می‌پردازد تمرکز می‌کند و اصول طراحی محصول (مانند قابلیت استفاده، امکان‌پذیری و غیره) را فراموش می‌کند.
خروجی‌ها:
- وایرفریم‌های تجربه کاربری
