چگونه فعالیت‌های تجربه کاربری (UX) را در یک پروژهٔ چابک مدیریت کنیم؟

بر اساس یک تحقیق جدید، ۶۹٪ از پروژه‌های دارای کار طراحی تجربه کاربری (UX) هم ، از رویکرد چابک استفاده می‌کنند. اما از طرف دیگه، طراحی UX و روش‌های چابک همیشه متناسب باهم نیستند، چون فرایندهای چابک در اصل با در نظر گرفتن نیازمندی‌های UX  ساخته نشده‌اند. به همین خاطر هم متخصص‌های UX همیشه مجبور بودند که انعطاف پذیر باشند، و کار‌شون رو با قواعد و سرعت تیم توسعه چابک هماهنگ کنند.

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

معیارهای روش چابک: داستان کاربر، کار (task) و استوری پوینت

در خیلی از تیم‌های چابک، برنامه‌ریزی برای ویژگی‌ها و قابلیت‌ها به شکل داستان کاربر (user story)  ثبت می‌شه. یعنی برای عملکرد هر ویژگی، یک تعریف مختصر از دیدگاه  کاربر می‌نویسند. در این تعریف باید روی کارهایی که کاربر می‌خواد انجام بده و اینکه اون ویژگی به چه درد کاربر می‌خوره، تمرکز بشه. شکل رایج داستان کاربری به‌صورت یک جمله است: «من به‌عنوان یک [نوع کاربر] می‌خواهم که [هدف]، تا [مزیت]». برای مثال: «من به‌عنوان صاحب حساب بانکی، می‌خوام پرداختهای بانکی را با استفاده از موبایلم انجام بدم، تا نیاز به مراجعه حضوری به بانک نداشته باشم.»

داستان‌های کاربر معمولا در یک لیست به نام بَک‌لاگ (backlog)  جمع‌آوری می‌شن. در این لیست، داستان‌ها اولویت‌بندی می‌شن و هزینه‌ یا نیازمندی‌های پیاده‌سازی اون‌ها برآورد و تخمین زده می‌شه. سپس تیم برنامه‌ریزی می‌کنه که دفعه بعد روی کدوم داستان کاربر (که همون طور که گفتیم، یکی از ویژگی‌های محصول یا خدماتشونه) کار کنه. تیم مقدار فعالیت‌های مورد نیاز برای ایجاد و پیاده‌سازی هر داستان کاربر رو تخمین می‌زنه و معمولا به شکل استوری پوینت (story points)  ثبت می‌کنه. استوری پوینت‌ها معیارهایی نسبی هستند و نه مطلق. در استوری پوینت به جای اینکه تعیین کنیم برای اتمام یک کار چند ساعت نیاز داریم، مشخص می‌کنیم که یک کار در مقایسه با کارهای دیگه چقدر کار بیشتری نیاز داره. برای مثال، یک داستان با ۵ استوری پوینت بیش از دو برابر یک داستان ۲ پوینتی کار داره.

درنهایت معیارهای پذیرش (acceptance criteria) برای یک داستان کاربری به‌وضوح مشخص می‌کنند که اون داستان باید چه مشخصات و ویژگی‌هایی داشته باشه تا بتونیم بگیم اون داستان کاربری «کامل» شده.

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

پیشنهاد اول: گزارش فعالیت‌های UX به‌عنوان زیرمجموعه داستان‌های کاربری

هر داستان کاربر معمولا در یک اسپرینت انجام می‌شه، هرچند که تیم‌ها اغلب روی چند داستان کاربری به‌صورت هم‌زمان کار می‌کنند. اسپرینت (sprint) یک بازهٔ زمانیه که تیم برای انجام کارهای انتخاب شده، در نظر می‌گیره. این زمان معمولا یک تا دوهفته است. زمانی که تیم UX یک یا چند اسپرینت جلوتر از تیم توسعه است، کوتاه بودن این بازه‌ی زمانی ممکنه برنامه‌ریزی و پیگیری کار رو با چالش مواجه کنه. برای خیلی از تیم‌ها، مسئله چالش برانگیز اینه که جای فعالیت‌های UX  کجای داستان‌های کاربریه.

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

اگر تیم شما داستان‌های کاربر رو به کارهای کوچک (task) تقسیم می‌کنه، فعالیت‌های UX رو هم  در لیست کارها قرار بدید تا تلاش‌های تیم طراحی تجربه کاربری در بک‌لاگ داستان‌های کاربر به درستی منعکس بشه. این کار به اعضای طراحی UX فرصت می‌ده درباره فعالیت‌های جاری و در حال انجامِ UX به بقیه اعضای تیم آگاهی بده. مزیت دیگهٔ این کار اینه که جلسه‌های بعدی تحقیقِ کاربر برای تمام اعضای تیم قابل مشاهده می‌شه، و توسعه‌دهنده‌ها، صاحب محصول و مدیران کسب و کار را تشویق می‌کنه که جلسه‌های تست رو هم دنبال کنند.

برای اینکه این رویکرد رو در مدیریت پروژه‌هاتون داشته باشید، باید ابتدا یک بک‌لاگ مناسب از داستان‌های کاربری تهیه کنید و سپس کسایی مانند صاحب محصول (Product Owner)، اسکرام مَستر و تیم توسعه، داستان‌ها را برای اسپرینت‌های آینده به دقت اولویت‌بندی کنند.

پیشنهاد دوم: قابل مشاهده کردن فعالیت‌های UX با استفاده از مراحل کانبان

تیم‌هایی که علاقه ندارند داستان‌های کاربری رو به ساب‌تسک بشکنند، می‌تونند از لیست کاری کانبان برای نمایش فعالیت‌های طراحی تجربه کاربری استفاده کنند. کانبان (Kanban) روشیه برای مصوّر کردن و پیگیری مراحل مختلف تکمیل کارها. مراحل تکمیل کارهای UX باید روی لیست کاری کانبان نمایش داده بشن. لیست کاری کانبان رو می‌تونید برای فعالیت‌های طراحی UX به‌صورت زیر تقسیم‌بندی کنید:
۱. تعریف (Definition)
۲. طراحی (Design)
۳. تست کاربردپذیری (Usability testing)
۴. آماده برای توسعه‌دهنده‌ها (Ready for Developers)
۵. پیاده‌سازی (Implementation)
۶. تست تضمین کیفیت (QA) یا یونیت (QA/Unit testing)
۷. آمادهٔ ارائه (Ready to ship)
۸. ارائه شده (Shipped)

یک تسک (داستان کاربری) باید از تمام این مراحل بگذره تا بتونیم بگیم به اتمام رسیده و کامل شده. این طور استفاده از لیست کاری کانبان باعث می‌شه فعالیت‌های طراحی تجربه کاربری به‌صورت واضح و الزام‌آور پیش بره.

این لیست هشت‌تایی برای خیلی از تیم‌ها مناسبه اما ممکنه تیم شما با توجه به نیازهاتون مجموعه مراحل دیگری را ترجیح بده. برای مثال، ممکنه بعضی از تیم‌ها ترجیح بدن طراحی UX رو تنها در یک مرحله انجام بدن. درحالی‌که سایر تیم‌ها فعالیت‌های طراحی تجربه کاربری را به چندین مرحله تقسیم می‌کنند. (برای مثال: نیازمندی‌ها requirements، جریان‌کاری workflow، ساختن نمونه prototyping، ایجاد تسک task creation، تست کاربردپذیری usability testing، تحلیل و آنالیز، تکرار iteration، ساختن مدل mockup creation)

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

برای فعالیت‌های UX داستان‌های کاربری جداگانه در نظر نگیرید!

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

معیارهای پذیرش UX را در داستان‌های کاربری دخالت دهید

در فرایندهای چابک رایج، وقتی‌که تیم، داستان‌های کاربری را تعریف می‌کنه، اینکه معیار تکمیل و پذیرش (completion or acceptance criteria) اون داستان کاربری چیست رو هم تعریف می‌کنه. معیارهای پذیرش از قدیم متمرکز بودند بر تست‌های تضمین کیفیت QA / unit با هدف اینکه مطمئن بشن در پیاده‌سازی باگ وجود نداره. ولی نکته مهم اینه که باید در این معیارها، تجربه کاربری رو هم در نظر بگیریم. معیارهای پذیرش تجربه کاربری در شروع می‌تونند تابع استانداردهای واسط کاربر (UI)  باشند. برای مثال، «تمام عناصر واسط کاربر به ظاهر، حس و رفتاری که در راهنمای سبک فرانت-اند مشخص کردیم، پایبند باشند» و یا «محصول نهایی تا ۱۰ پیکسل پس و پیش، مطابق مدل طراحی (mockups) باشد». علاوه بر اینها معیارهای کاربردپذیری را هم به معیارهای پذیرش تجربه کاربریتان اضافه کنید، مانند اینکه «طی تکمیل تسک الف، کاربر با هیچ‌گونه مشکل کاربردپذیری مواجه نشود.»

در سازمان‌هایی که طراحی تجربه کاربری به بلوغ کافی رسیده و مدیریت هم اعتماد کاملی به تیم UX داره، حتی معیارهای کمّی هم می‌تونند به‌عنوان معیارهای پذیرش در نظر گرفته بشن، مانند « کاربران، فرایند پرداخت را در دو دقیقه یا کمتر انجام دهند». ممکنه کامل کردن تست‌های بنچمارکِ کمّی (quantitative benchmarking tests) در طول یک اسپرینتِ چابک تا حدودی سخت باشه، و یا نتایج آماریِ به‌دست‌آمده از یک تحقیق کوچک ممکن است آن‌چنان هم قابل استناد نباشه. اما افراد حرفه‌ای UX  می‌تونند تشخیص بدن که آیا فرایند طراحی در مسیر درست و رضایت‌بخشی قرار داره یا نه. این معیارها باعث ایجاد استانداردهای باکیفیت می‌شند. همچنین تیم رو مجبور می‌کنند قبل از ارائه محصول، در تست‌های کاربردپذیری شرکت داشته باشند.

برآورد استوری پوینت‌های تجربه کاربری

خیلی از تیم‌هایی که از فرمت یوزر استوری برای رهگیری کار استفاده می‌کنند، از استوری پوینت (story point) برای برآورد تلاش‌ها و فعالیت‌ها بهره می‌گیرند؛ اما چون طراحی تجربه کاربری معمولا پیش از توسعه فنی انجام می‌شه، بیشتر متخصص‌های UX که در تحقیق بالا باهاشون صحبت شده ترجیح می‌دن که فعالیت‌هاشون رو جدا از تیم توسعه برآورد کنند. دو برآورد جداگانه (یکی برای توسعه و یکی برای UX) به هر یک از زیرتیم‌ها اجازه می‌ده که کارایی خودشون رو بالا ببرند و از تمام ظرفیت‌ها استفاده کنند. به‌طور خاص، تیم طراحی تجربه کاربری می‌تونه برنامه‌ریزی کنه که روی چند داستان کاربری به طور همزمان کار کنه و یا بیش از یک اسپرینت به بعضی از داستان‌های کاربری اختصاص بده.

توسعه‌دهنده‌ها برای برآورد فعالیت‌هاشون چند سیستم‌ محبوب دارند ازجمله، سری‌های اعداد صحیح، سری فیبوناچی و توان‌های دوم. اما افراد حرفه‌ای طراحی تجربه کاربری ترجیح می‌دن که از فرمت‌هایی مانند سایزبندی تی‌شرت (S, M, L, XL) استفاده کنن. این سیستم به تیم UX اجازه می‌ده تلاش‌هاشون رو به شیوه‌ای برجسته و بدون تاثیر روی معیارهای سرعت سایر تیم‌ها، نشون بدن. البته این را هم باید مدنظر داشته باشید که استوری‌پوینت‌های جداگانه برای UX می‌تونه روی انسجام تیم تاثیر منفی بگذاره و باعث شه تیم UX به‌عنوان یک واحد کاری جداگانه در نظر گرفته شه، شبیه چیزی که در فرآیندهای توسعه آبشاری می‌بینیم. اگر می‌خواید استوری‌پوینت‌های UX  رو به‌صورت جداگانه برآورد کنید، باید درنهایت برآوردهای جداگانهٔ تیم طراحی تجربه کاربری را با برآوردهای سایر تیم‌ها یک کاسه کنید.

نتیجه‌گیری

یکپارچه کردن تجربه کاربری و رویکرد چابک یک فرآیند پیچیده است. اما انعکاس فعالیت‌های UX در داستان‌های کاربری، به برنامه‌ریزی و زمان‌بندی کارها کمک می‌کند و همچنین همکاری میان اعضای تیم را بهبود می‌دهد.

منبع: Nielsen Norman Group