درسهای یک طراح UX که با AI اپ ساخت
خلاصهٔ کاملتر
دریک انجی طراح UX تو GovTech سنگاپوره و تا حالا کد پروداکشن ننوشته. تو این مقاله اومده که اون چند ماه با Lovable (یعنی ابزاری که از توضیح متنیِ ساده برات اپ میسازه) چند تا اپ کوچیک ولی واقعاً کارکننده رو تنهایی بالا آورده. اولیش یه نسخهٔ ساده از Planning Poker بود، همون روش تخمین چابک که تیمها باهاش به تسکها story point میدن. دلیلش هم ساده بود: دورهٔ رایگان ابزاری که تیمش استفاده میکرد تموم شده بود و نمیخواست اشتراک بخره.
کار دقیقاً جایی خوابید که اپ باید real-time میشد، یعنی چند نفر همزمان تو یه جلسه باشن و تخمینهاشون رو با هم نشون بدن. به گفتهٔ نویسنده، ابزار هی راهحلهای بیفایده میداد و خودش اسم این وضعیت رو گذاشته «error loop of death». گره وقتی باز شد که یه توسعهدهنده بهش گفت چیزی که لازم داره WebSocket ـه، یعنی یه اتصال باز بین مرورگر و سرور که داده رو لحظهای رد و بدل میکنه. با همون یه کلمه، ابزار راه افتاد.
درس دوم اینه که کیفیت خروجی به کیفیت بریف بستگی داره. نویسنده میگه وقتی میخواسته گزینههای مختلف رو بگرده، از زاویهٔ jobs-to-be-done جلو رفته: اول مسئلهٔ کاربر رو تعریف کرده و بعد گذاشته AI راهحل پیشنهاد بده. ولی وقتی مسیر روشن بوده، یه PRD دقیق (سندی که میگه محصول چی کار میکنه، برای کیه و چه محدودیتهایی داره) نتیجهٔ خیلی بهتری داده. یعنی قضاوت محصولی و اصول طراحی هنوز سر جاشن.
درس سومی که نویسنده روش تأکید داره، مرز بین پروتوتایپ و محصوله. با این ابزارها میشه تو چند روز چند تا اپ کارکننده ساخت و ایده رو سر تا ته نشون داد، ولی معماری، امنیت و پایداریِ لازم برای سرویسی که مردم بهش تکیه میکنن از توش درنمیاد. حرف آخرش اینه که مرزِ کاری که یک نفر تنها میتونه تا پروتوتایپ جلو ببره جابهجا شده، نه اینکه پاک شده باشه.
نکات کلیدی:
- ابزار استفادهشده Lovable بود و سازندهش یک طراح UX بدون سابقهٔ کد پروداکشن
- گیر اصلی روی قابلیت real-time بود و با دونستن اسم WebSocket حل شد
- برای کاوش، بریف مسئلهمحور (jobs-to-be-done) جواب میده؛ برای اجرا، یک PRD دقیق
- پروتوتایپ AI معماری، امنیت و پایداریِ لازم برای سرویس عمومی رو نداره
- نسخهٔ کامل این تجربه با ۱۵ درس، تو انتشارات Medium گاوتک منتشر شده




