زمانی که در حال استفاده از توسعهی نرم افزاری چابک (Agile) برای کار روی پروژه‌هایتان هستید، تجربه کاربری Lean UX می‌تواند یک تکنیک بسیار سودمند باشد. تکنیک‌های مرسوم تجربه کاربری معمولا زمانی که توسعه در حالت بسیار سریعی انجام می‌شود پاسخگو نیستند. در واقع زمان کافی برای ارائه‌ی تجربه کاربری از همان طریق وجود ندارد. اساساً Lean UX و دیگر فرم‌های تجربه کاربری، همگی هدف مشترکی را در سر می‌پرورانند: هدف آن‌ها ارائه‌ی یک تجربه کاربری عالی است، هرچند نحوه‌ی کار شما در یک پروژه متفاوت است.
پس بیایید نگاه کنیم که این تجربه کاربری چگونه کار می‌کند.
Lean UX چیست؟
Lean UX بر روی تجربه تحت طراحی متمرکز است و کمتر بر روی موارد خروجی در دیگر تجربه‌های کاربری متمرکز خواهد بود. در واقع آن به سطح بالایی از همکاری با کل تیم نیازمند است. هدف اصلی این است که باید بر روی بازخورد اولیه‌ای که دریافت می‌شود، در سریع‌ترین زمان ممکن تمرکز شود تا بتوان تصمیمات سریعی گرفت. اساس توسعهی نرم افزاری چابک این است که باید در چرخه‌های سریع و تکرارپذیر کار کند و تجربه کاربری Lean UX از این چرخه‌ها تقلید می‌کند تا مطمئن شود داده‌ی به وجود آمده می‌تواند در هر تکرار، مورد استفاده قرار گیرد.
نیاز به فرضیه‌ها در Lean UX
در تجربه کاربری سنتی، پروژه بر اساس ثبت الزامات و نتایج ساخته می‌شود. هدف این است که مطمئن شوید خروجی‌ها تا حد ممکن دقیق بوده و به اندازه‌ی کافی به احتیاجاتی که در آغاز پروژه تعیین شده، واکنش نشان می‌دهند.
Lean UX کمی متفاوت است. شما بر روی جزئیات خروجی‌ها متمرکز نمی‌شوید. شما باید به دنبال تولید تغییراتی باشید که به بهبود محصول می‌انجامند. این روش اساساً برای به دست آمدن نتیجه‌ای در جهت بهتر شدن است. این روش با صرف نظر از «الزامات» و استفاده از «مشکلات» عمل می‌کند و باید مجموعه‌ای از تصورات که می‌توانند برای ساخت Hypothesisاستفاده شوند را رهبری کند.
فرضیه چیست؟ یک فرضیه بیان چیزیست که ما فکر می‌کنیم درست است. آن‌ها برای ایجاد یک درک مشترک از ایده‌ای که همه قصد شروع آن را دارند ساخته شده‌اند. قابل درک است که فرضیه‌ها می‌توانند درست نباشند و شاید در طول پروژه برای درک بهتر تیم تغییر کنند.
فرضیه‌ها معمولا بر اساس یک کارگاه تولید می‌شوند. شما اعضای تیم را دور هم جمع می‌کنید و مشکل را مطرح می‌کنید و سپس به تیم اجازه دهید تا ایده‌هایشان را برای حل مشکل با هم درمیان بگذارند. در این فرآیند شما باید به سوال‌های خاصی که از فرضیه‌های شما به وجود آمده‌اند، پاسخ دهید.
این سوال‌ها معمولا عبارتند از:
- کاربران ما چه کسانی هستند؟
- از محصول ما چه استفاده‌ای می‌شود؟
- چه زمانی از آن استفاده می‌شود؟
- در چه شرایطی استفاده می‌شود؟
- مهم‌ترین قابلیت آن چیست؟
- بزرگ‌ترین ریسک برای تحویل محصول چیست؟
ممکن است برای هر یک از پرسش‌های فوق بیشتر از یک پاسخ وجود داشته باشد. این به ما فرضیه‌های بهتری را ارائه می‌کند که ممکن است برای رسیدن به هدف مناسب باشند. اگر اینگونه باشد، تیم می‌تواند خیلی سریع فرضیه‌های ایجاد شده را اولویت بندی کند. در واقع شما باید فرضیه‌های خود را با توجه به ریسکی که به همراه دارند اولویت بندی کنید (عواقب این کار بد است؟ هرچه اهمیت بیشتری داشته باشد، در اولویت بالاتری قرار می‌گیرد). از طرفی دیگر، سطح درک از موضوع نیز مهم است (هرچه کمتر می‌دانید، در اولویت بالاتری است).
ساخت Hypothesis در Lean UX
Hypothesis یا همان فرضیه‌ی ایجاد شده در Lean UX با هدف آزمایش فرضیه‌های ما طراحی شده‌اند. یک فرمت ساده وجود دارد که شما می‌توانید خیلی سریع و آسان برای ساخت Hypothesis مدنظر خود از آن استفاده کنید. به طور مثال:
ما معتقدیم که قادر ساختن مردم برای صرفه جویی در زمانشان، برای تمام کاربران گوشی‌های هوشمند ضروری است. این می‌تواند سطح بالاتری از تکمیل ثبت نام را به همراه داشته باشد. ما این را زمانی نشان خواهیم داد که بتوانیم بهبود ۲۰ درصدی را در نرخ تکمیل فعلی به دست آوریم.
ما به این حرف و اینکه چرا مهم است و برای چه کسی مهم است، باور داریم. سپس آن را با همان نتیجه‌ای که انتظار به دست آوردنش را داریم دنبال می‌کنیم. سرانجام، ما تعیین می‌کنیم که چه مدارکی باید جمع آوری شود تا ثابت کنیم اعتقاد ما درست است. اگر متوجه شویم که راهی برای اثبات Hypothesis یا همان فرضیه‌ی ما وجود ندارد، ممکن است در مسیر اشتباهی قدم برداریم، زیرا نتایج ما در حال حاضر مشخص نیستند.
یکی از بزرگ‌ترین مزیت‌های کار کردن اینچنینی، این است که سوا‌ل پرتکرار «من فکر نمی‌کنم ایده‌ی خوبی باشد» و درگیری‌های مدبرانه در فرآیند طراح تجربه کاربری را حذف می‌کند. اگر همه بتوانند یک فرضیه و انتظارات از آن را درک کنند، به جای آنکه با شدت از دیدگاه ذهنی خود دفاع کنند، با تمایل صبر خواهند کرد تا ببینند نتیجه‌ی حاصل از آن درست است یا خیر.
کمینه محصول پذیرفتنی (MVP) و تجربه کاربری Lean UX
کمینه محصول پذیرفتنی (MVP) یک مفهوم اصلی در تجربه کاربری Lean UX است. ایده این است که ساده‌ترین نسخه‌ی مفهومی ممکن ساخته شود، آزمایش شود و اگر نتایج ارزشمندی حاصل نشد، رها شود. MVP ها به شما وعده می‌دهند که می‌توانند بدون دردسر در مراحل طراحی و توسعه جای بگیرند.
این یک راه عالی برای رساندن منابع شما به حداکثر ممکن و یکی از دلایلیست که که باعث می‌شود Lean UX به خوبی با توسعهی نرم افزاری چابک در تعامل باشد. آن اجازه می‌دهد بسیاری از آزمایش‌ها بدون انتقادهای زمان‌گیر انجام شوند.
انجام تحقیق و آزمایش در Lean UX
تحقیق و آزمایش کاربر با توجه به ماهیت Lean UX، بر اساس همان اصولی است که در محیط‌های تجربه کاربری سنتی استفاده می‌شود. با این حال، این رویکرد تمایل دارد «سریع و ناپاکیزه» باشد. نتایج لازم باید پیش از آغاز توسعهی چابک بعدی به دست آیند؛ بنابراین تمرکز کمتری بر روی خروجی‌های دقیق انجام می‌شود و بیشتر تمرکز بر روی داده‌های خام است.
مسئولیت‌های تحقیق نیز در کل تیم پخش می‌شود، به طوری که هیچ «تنگنایی» با در اختیار داشتن یک منبع واحد از طراحی تجربه کاربری ایجاد نشود تا فرد مجبور باشد به تنهایی در زمانی اندک، کل کار را به تنهایی انجام دهد. این روش اغلب، منابع توسعه را برای نگاه نزدیک به UX ارائه می‌کند و سطح درک و پشتیبانی برای کار با UX را در تیم توسعه افزایش می‌دهد.
خلاصه‌ی مطلب
یک نمای کلی سطح بالایی از تجربه کاربری Lean UX وجود دارد و موارد به قدری زیاد است که نمی‌توان آن‌ها را در یک پاراگراف خلاصه کرد. با این حال، مفاهیم اولیه‌ی ذکر شده در این مطلب می‌توانند شما را قادر بسازند وقتی قصد دارید از Lean UX در توسعهی نرم افزاری چابک استفاده کنید، در راه درستی گام بردارید.
منبع: Interaction Design Foundation (IDF)