
کیس استادی قبلیام درباره رسپی بود. کاربران ایرانی — بهخصوص اونهایی که برای چند خانوار مختلف خرید میکنند — با یک تجربه پراکنده روبرو بودند: رسپی از یک سایت، مواد اولیه از جای دیگه!
در اون کیس استادی یک پلتفرم یکپارچه طراحی کردم که این زنجیره رو در یک تجربه واحد جمع کند.
اما وقتی توی تحقیقات عمیقتر شدم، یک مسئله دیگه آشکار شد — ساکتتر، کمتر واضح، و از بسیاری جهات گرانتر.
وقتی در یک فروشگاه فیزیکی خرید میکنی، عادتهات رو با خودت میبری. میدونی هنوز پیاز داری. یادت هست که برنجت داره تمام میشه. میدونی خانوادهات در یک هفته یا ماه چقدر مصرف مواد غذایی دارن.
سبد خرید آنلاین این حافظه رو نداره. هر بار از صفر شروع میکنه یا پیشنهادایی میده که مرتبط نیست با سلیقه و رفتار خریدت.
تحقیق همون چیزی رو تأیید کرد که مشکوک بودم. ۳۸٪ کاربران گفتن آنلاین بیشتر از نیازشون خرید میکنن. نزدیک به نیمی از اونها مطمئن نبودن چقدر از هر محصول باید بخرن و وقتی به کاربران چند آدرسی — کسانی که برای خودشون، اقوام و نزدیکانشون خرید میکنن — نگاه کردم، مسئله چند برابر شد.
شاید مسئله این نیست که کاربر نمیدونه چه بپزه، مسئله اینه که سبد خرید، او رو نمیشناسه.
این یک چیز رو تغییر داد. به جای اینکه یک فیچر جدید روی تجربه موجود اضافه کنم، تصمیم گرفتم یک لایه هوش مصنوعی رفتاری طراحی کنم که زیر تجربه سبد خرید بشینه — نامرئی برای کاربر، در پسزمینه کار کنه، در طول زمان یاد بگیره.
یک الگوی خاص در تحقیق بود که همه چیز رو برام روشن کرد.
تصور کن کسی در سیوچند سالگی، شاغل، مسئول خانواده. در یک هفته معمولی ممکنه سه سفارش جداگانه ثبت کنه: یکی برای خونه خودش، یکی برای پدر یا مادرش اون طرف شهر، یکی برای اقوام و نزدیکانش.
هر کدوم از این سفارشها کاملا متفاوتند.
سبد خودش: هفتگی، کمحجم، متمرکز.
سبد مادرش: ماهانه، بزرگ، پر از مواد اولیه اصلی.
اقوام و نزدیکان: هر چند روز یکبار، مقدار کم، همیشه تازه.
یک حساب کاربری. سه پروفایل رفتاری. سه آدرس مختلف. سه الگوی خرید کاملا متفاوت
💡 بینش کلیدی
هر آدرس مثل یک انسانه، نه یک موقعیت جغرافیایی. هوش مصنوعی باید برای هر کدوم یک پروفایل مستقل بسازه — و هرگز اونها رو با هم قاطی نکنه.
این پروژه برای بازار ایران طراحی شد، جایی که سه پلتفرم اصلی خرید آنلاین مواد غذایی وجود دارند:
اسنپمارکت، دیجیکالا جت، و اوکالا.
هر کدوم میلیونها کاربر فعال دارند. هر کدام سالها داده تراکنش دارند. این اهمیت داره چون یکی از بزرگترین ریسکهای طراحی AI رو از بین میبره: مشکل شروع سرد (cold start). نیازی به ساختن یک فاز جمعآوری داده نیست و تاریخچه رفتاری از قبل وجود داره.
یک لایه AI. سه اپ مختلف. منطق ثابت میمونه اما ارائه بصری با سیستم طراحی هر اپ، تطبیق پیدا میکند.
یعنی به عنوان طراح محصول، طراحی میکنم — کجا پیام نشان داده بشه، چی باید بگه، کِی سکوت کنه.
تیم مهندسی پلتفرم اون رفتار رو با رنگها، تایپوگرافی و کامپوننتهای از قبل طراحی شده، پیاده میکنه.
قبل از شروع، به یه فریمورک نیاز داشتم که هر تصمیم رو قابل دفاع کنم. به این معنا که هر انتخاب طراحی بتونه سه سوال رو جواب بده:

یک قانون در هر سه لایه جاریه: AI پیشنهاد میده. کاربر تصمیم میگیره. سبد هرگز بدون اجازه تغییر نمیکنه.
اکثر فیچرهای AI خیلی با انرژی شروع میکنن. از همون بار اول با اطمینان پیشنهاد میدن.
کاربران اگر پشنهاد رو رد کنه و بعد از چند بار رد کردن، دیگه دوست نداره از اون پلتفرم یا فیچر استفاده کنه ودر نهایت فیچر تبدیل به نویز میشه.
در مقابل من سیستمی رو در نظر داشتم که بشه با اعتماد ازش استفاده کرد.

وقتی کاربر پیشنهادی رو رد میکنه، پیام بیصدا ناپدید میشه، بدون تایید مجدد یا عذرخواهیای، سبد به حالت عادی برمیگرده: · AI این بار ساکته!
همین. AI برای بقیه اون خرید سکوت میکنه. دفعه بعد — متفاوت — دوباره امتحان میکنه.
یک دسته از وضعیتها وجود دارن که نه در پیشنهاد میگنجه نه در سکوت. این Escalation است — وقتی AI چیزی رو میبینه که به اندازه کافی مطمئن نیست بهتنهایی مدیریتش کنه.
مثلاً ۱۰ کیلو گوشت در سبدی که معمولا یک کیلو میخره. این لزوما اشتباه نیست — شاید کاربر، مهمانی داشته باشه. اما به اندازهای غیرمعمول هست که AI نباید بیصدا مدلش رو بهروز کنه.
به جاش یک بار، ساده، با امکان خروج میپرسه: «۱۰ کیلو گوشت — مهمانی داری یا خرید معمولیه؟»
سه گزینه: مهمانی. خرید معمولی. مهم نیست.
Escalation یک بُعد مهمتر هم داره: تغییر سلیقه در طول زمان.
اگر کاربر سه بار پشت سرهم یک برند جدید خریده، AI مدل رو بهروز میکنه. اما اگر تغییر ناگهانی و همهجانبه بود — مثل اینکه کاربر رژیم گرفته — AI قبل از یادگیری، یکبار میپرسه.
قانون ساده است: یک بار استثناست، سه بار متوالی الگو.
در بالای نردبان اعتماد، Delegation است — لحظهای که کاربر میگه: «این کار رو برام انجام بده.»
طراحی این لحظه بیشتر از هر چیز دیگهای در پروژه دقت میخواست. سه قانون ثابت:

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

این پروژه extension یک کیس استادی قبلی منه — اون کیس استادی مسئله «چی بپزم؟» رو طراحی کرد. این کیس استادی مسئله «چطور درست بخرم» رو حل میکنه. هر دو از یک نقطه شروع شدن: کاربری که میخواهد غذای خونگی بپزه اما فرآیند از ایده تا سفره پر از اصطکاکه.
این مقاله، ارائه من در یک دوره طراحی هوش مصنوعی برای پلتفرمهاست که با استادم خانم فاطمه علیخواه گذروندم. هر بار که روی این پروژه کار میکردم، بیشتر مطمئن میشدم که سوال اصلی در طراحی AI این نیست که سیستم چه کاری میتونه بکنه — بلکه اینه که کِی نباید یه کاری رو انجام بده.
این case study بخشی از پورتفولیوی product design من هست. اگه سوال یا نظری داری — خوشحال میشم برام بنویسی.