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

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

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

اشتباه اول: ساختن دقیقاً همان چیزی که تایپ کرده‌اند

یک کاربر می‌گوید «کاش یک دکمه‌ی حالت تاریک توی هدر بود». پس شما چت ساخت را باز می‌کنید و تایپ می‌کنید: «یک دکمه‌ی حالت تاریک به هدر اضافه کن». سازنده این کار را انجام می‌دهد. تیکت بسته شد، درست است؟

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

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

درخواست، داده است. مشخصات فنی نیست. کار شما مرحله‌ی ترجمه‌ی میان این دو است، و رد شدن از این مرحله رایج‌ترین راهی است که بازخورد به تورم ویژگی‌ها تبدیل می‌شود.

اشتباه دوم: سکوت کردن، بعد یکجا تخلیه کردن همه چیز

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

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

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

اشتباه سوم: اجازه دادن به صداهای بلندتر برای تعیین نقشه‌راه

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

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

پرامپت درست واقعاً چه شکلی است

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

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

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

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