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

لین یو‌ایکس (Lean UX) چیست؟

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

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

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

از کجا آمد: ناب، چابک و استارتاپ ناب

لین یو‌ایکس را جف گوتلف و جاش سایدن (Jeff Gothelf & Josh Seiden) در کتابی به همین نام در سال ۲۰۱۳ صورت‌بندی کردند، اما ایده‌هایش از سه جای مختلف آمده است.

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

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

خروجی در برابر نتیجه

محوری‌ترین جملهٔ لین یو‌ایکس این است: تیم باید بر نتیجه متمرکز باشد، نه بر خروجی. خروجی چیزی است که می‌سازیم — یک صفحه، یک قابلیت، یک دکمه. نتیجه تغییری است که در رفتار کاربر یا در کسب‌وکار اتفاق می‌افتد.

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

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

از فرض تا فرضیه

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

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

بخش سوم همان جایی است که بیشتر تیم‌ها کوتاه می‌آیند، و بدون آن کل تمرین بی‌اثر است. «می‌فهمیم درست گفته‌ایم وقتی کاربرها راضی‌تر باشند» فرضیه نیست، چون هیچ‌وقت غلط از آب درنمی‌آید. «وقتی در دو هفته، نرخ تکمیل ثبت‌نام در کاربران تازه از ۴۱ به بالای ۵۰ درصد برسد» فرضیه است، چون ممکن است نرسد و آن‌وقت مجبوریم چیزی را بپذیریم.

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

چرخهٔ فکر، ساخت، سنجش

موتور اجرایی لین یو‌ایکس یک حلقهٔ سه‌مرحله‌ای است:

• - ۱. فکر: مسئله را می‌فهمیم، آنچه می‌دانیم و آنچه فقط فرض کرده‌ایم را جدا می‌کنیم، و فرضیه می‌نویسیم. طراحی روی وایت‌برد و اسکیس در همین مرحله است، نه در فایل نهایی.
• - ۲. ساخت: کوچک‌ترین چیزی را می‌سازیم که برای آزمودن آن فرضیه کافی است. گاهی یک نمونهٔ اولیه کاغذی بس است، گاهی یک صفحهٔ ساده، و گاهی حتی چیزی که پشتش را آدم انجام می‌دهد نه سامانه.
• - ۳. سنجش: با کاربر واقعی می‌آزماییم. یک آزمون کاربردپذیری کوتاه با پنج نفر معمولاً بیشتر از یک جلسهٔ دوساعتهٔ بحث داخلی روشن می‌کند.

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

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

‏MVP واقعاً یعنی چه

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

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

جایی که لین یو‌ایکس خراب می‌شود

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

• - لین به‌عنوان بهانهٔ حذف پژوهش: شایع‌ترین سوءاستفاده. «ما لین کار می‌کنیم» تبدیل می‌شود به «ما پژوهش نمی‌کنیم و مستقیم می‌سازیم». لین یو‌ایکس پژوهش را حذف نمی‌کند، آن را کوچک و مکرر می‌کند؛ حذف پژوهش، حدس‌زدن سریع‌تر است نه یادگیری سریع‌تر.
• - نمایش سرعت: تیم هر دو هفته چیزی منتشر می‌کند و هیچ‌کدام از انتشارها به فرضیه‌ای وصل نیست. سرعت بالا در جهت نامعلوم، فقط زودتر شما را به جای اشتباه می‌رساند.
• - حلقهٔ نیمه‌کاره: فکر و ساخت انجام می‌شود، سنجش نه. این متداول‌ترین حالت است، چون سنجش تنها مرحله‌ای است که ممکن است بگوید کاری که کردیم بی‌فایده بوده.
• - تیم بدون اختیار: اگر نقشهٔ راه از بالا به‌شکل فهرست قابلیت‌ها آمده باشد، فرضیه‌نویسی یک تشریفات است. لین یو‌ایکس بدون اجازهٔ تغییر راه‌حل، اجرا نمی‌شود.
• - مناسب نبودن موقعیت: در حوزه‌هایی که خطا گران است — سلامت، پرواز، زیرساخت مالی — «سریع بساز و ببین چه می‌شود» پاسخ درستی نیست. آنجا هم می‌شود لین کار کرد، اما آزمایش باید در محیط کنترل‌شده انجام شود نه روی کاربر واقعی.

لین یو‌ایکس در تیم‌های ایرانی

این بخش هم در منبع نیست و از کار با تیم‌های فارسی‌زبان می‌آید.

ساختار سفارش‌محور. بخش بزرگی از کار طراحی در ایران در قالب پروژه‌ای با دامنه و تحویل‌شدنی مشخص تعریف می‌شود؛ قرارداد می‌گوید چند صفحه تحویل داده شود. این ساختار ذاتاً با «نتیجه به‌جای خروجی» در تضاد است. راه عملی‌اش این است که در قرارداد، به‌جای فهرست صفحه‌ها، تعداد دورهای یادگیری و آزمون را تعریف کنید — سخت‌تر است، اما شدنی.

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

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

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

جمع‌بندی

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

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