پروژهای که هیچوقت لانچ نشد رو چطور تعریف کنیم؟
خلاصهٔ کاملتر
این مقاله با نقل حرف یه طراح شروع میشه که دو سال و نیم روی پروژهای کار کرده بود و درست قبل از لانچ، کرونا همهچی رو از بین برد. حس اینکه کل کار آب شده و رفته توی زمین. نویسنده، کریستوفر کِی وانگ، میگه این حس اصلاً نادر نیست: نقشهٔ راه عوض میشه، ذینفع تغییر میکنه، بودجه قطع میشه، و یهو یه فایل فیگما میمونه و داستانی که آخرش میشه «هیچوقت لانچ نشد».
به گفتهٔ نویسنده، بیشتر طراحها اینجا فرض میکنن پروژه اثرگذاری رو هم با خودش برده. ولی اثر اولیه اونجا بوده؛ فقط شواهدش جمع نشده بود. و این یه مشکل کاملاً متفاوته، چون این یکی رو میشه قبل از اینکه پروژهٔ بعدی هم بپره حل کرد. شکاف واقعی همون لحظهای شکل گرفته که کار شروع شده و کسی نپرسیده: اگه این چیز کار کنه، انتظار داریم چی ببینیم؟
نویسنده معتقده ریشهٔ ماجرا توی آموزش طراحهاست: یاد گرفتیم بر اساس تحویلدادنی فکر کنیم — مسئله رو تعریف کن، راهحل رو طراحی کن، تحویل بده، لانچ کن — و نتیجه جای دیگهای زندگی میکنه؛ توی دادهای که مال یکی دیگهست. اون هم اضافه میکنه که این یه شکست شخصی نیست: متریک دست PMه، داده دست تحلیلگر، و تا وقتی چیزی جدی تکون بخوره تو رفتی سراغ بریف بعدی.
بعد سراغ یه تفکیک مفید میره. عددهای بزرگ مثل درآمد و ریتنشن و چرن، متریکهای تأخیریان؛ آخر زنجیرهن و اگه پروژه لانچ نشه اصلاً دستنیافتنیان. یه پله جلوتر متریکهای پیشرو مثل نرخ فعالسازی یا تعامل اولیهان که به کار نزدیکترن ولی هنوز محصول زنده میخوان. چیزی که حتی زودتر از اینها میشه جمع کرد، سیگناله — و سیگنال اصلاً به لانچ نیاز نداره.
سیگنال در تعریف نویسنده یعنی یه رفتار کاربر که اگه طراحیت درست کار کنه، انتظار داری بیشتر یا کمتر اتفاق بیفته. آنبوردینگ رو بازطراحی کردی؟ سیگنال میتونه این باشه که کاربرهای بیشتری بدون ریزش توی مرحلهٔ دو، آنبوردینگ رو تموم کنن. فرم رو ساده کردی؟ سیگنال میشه ریزش کمتر وسط تکمیل فرم. هیچکدوم از اینها برای دیده شدن به لانچ کامل نیاز ندارن؛ توی تست پروتوتایپ یا یه جلسهٔ یوزبیلیتی با پنج نفر هم قابل مشاهدهان.
نویسنده میگه اسمگذاری روی سیگنال مجبورت میکنه دقیق باشی: بهجای اینکه ریدیزاین رو بفرستی و امیدوار باشی یه چیزی بهتر بشه، یه شرط مشخص میبندی که این رفتار بهخاطر این تغییر جابهجا میشه. برای اجراش هم لازم نیست بودجهٔ تحقیق یا اجازهٔ PM داشته باشی؛ کافیه سه سؤال بپرسی: کاربرها دارن چه کاری میکنن (یا نمیکنن) که برای کسبوکار هزینه داره، چرا این اتفاق میافته، و اگه طراحی درستش کنه چی باید ببینی.
مثالش هم سادهست: توی جلسه پنج کاربر مسیر آنبوردینگ رو میرن، چهار نفرشون بدون برگشت به عقب به داشبورد میرسن، در حالی که توی مسیر قبلی فقط دو نفر میرسیدن. رفتار جابهجا شده. همین رو مستند کن؛ نه توی یه چارچوب متریک قلمبهسلمبه، فقط یه یادداشت که بعداً پیداش کنی: چی انتظار داشتی و چی دیدی. اون یادداشت با تو جابهجا میشه و با تغییر نقشهٔ راه از بین نمیره.
جمعبندی نویسنده اینه که لانچ شدن دست تو نیست، ولی شواهد هست. طراحهایی که روشنتر از همه دربارهٔ کارشون حرف میزنن لزوماً اونهایی نیستن که پروژههاشون همیشه لانچ شده؛ اونهاییان که میدونستن حین کار باید دنبال چی بگردن.
نکات کلیدی:
- کنسل شدن پروژه یعنی نبودِ شواهد، نه نبودِ اثرگذاری
- متریک تأخیری (درآمد، ریتنشن) آخر زنجیرهست و بدون لانچ در دسترس نیست
- سیگنال = رفتار مشخص کاربر که با تست پروتوتایپ یا جلسهٔ پنجنفره هم دیده میشه
- سیگنال باید قبل از شروع کار تعریف بشه، نه بعد از کنسل شدن
- یه یادداشت سادهٔ «چی انتظار داشتم / چی دیدم» با تو میمونه
