🎞 فیلم Mercy (2026) | فیلمی درباره اعتماد در طراحی محصولات هوش مصنوعی

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

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

فیلم Mercy (2026) هم از همین زاویه ارزش تماشا دارد. فارغ از جنبه‌های سینمایی، این فیلم پرسش‌های مهمی درباره اعتماد به سیستم‌های هوش مصنوعی، واگذاری تصمیم‌گیری به ماشین‌ها و مسئولیت انسان در برابر خروجی‌های AI مطرح می‌کند.

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


🎬معرفی فیلم‌های سینمایی و مستند حوزه دیزاین:
✔️فیلم مستند طراحی برای همه: گامی به سوی دنیای بهتر
✔️مستند قدرت بینش از جول بارکر ( THE POWER OF VISION)
✔️ فیلم Swiped: روایتی از محصول، کارآفرینی و پیچیدگی روابط انسانی
✔️مستند "Eternal You" | اثرات طراحی محصولات مبتنی بر هوش مصنوعی در حوزه مرگ
✔️معرفی مستند Design Disruptors
✔️مستند‌ طراحان تنها، مجموعه‌ای ارزشمند از تاریخ شفاهی طراحی صنعتی در ایران

⭕️ #فیلم_و_دیزاین #سینما_برای_طراحان

🫶@SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

🚀 انتشار نتایج یک پژوهش عملی با موضوع اعتماد در طراحی محصولات هوش مصنوعی

سال گذشته، افتخار همکاری با شمیم سلوکی عزیز را داشتم؛ شمیم در مقطع کارشناسی‌ارشد University of Europe for Applied Sciences (کشور آلمان) مشغول به تحصیل بود و من به عنوان منتور و مشاور صنعت پروژه‌ی پایان‌نامه‌‌اش همراه بودم.

💬موضوع پایان‌نامه‌ پرسشِ کلیدی و به‌روزی بود:
«چگونه طراحی تجربه‌ی کاربری (UX) می‌تواند به افزایش اعتماد مردم به سیستم‌های هوش مصنوعی کمک کند؟»

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

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

☑️توضیحات تکمیلی شمیم:

طراحی تجربه کاربری چطور می‌تواند به اعتماد مردم به سیستم‌های هوش مصنوعی کمک کند؟
برای پاسخ به این پرسش، ابتدا سه حوزهٔ پژوهشی مرتبط با هم را بررسی کردم: تجربه کاربری (UX)، تعامل انسان با هوش مصنوعی (HAI) و هوش مصنوعی قابل توضیح (XAI). با تلفیق این سه حوزه، موفق شدم هم یک شکاف تحقیقاتی را شناسایی کنم و هم شش اصل کلیدی برای طراحی رابط‌های کاربری قابل‌اعتماد در سیستم‌های هوش مصنوعی تدوین نمایم.

در گام بعد، این اصول را روی پنج نمونهٔ متفاوت از کاربردهای هوش مصنوعی پیاده‌سازی کردم: اسپاتیفای (Spotify)، چت‌جی‌پی‌تی (ChatGPT)، نقشه گوگل (Google Maps)، گرامرلی (Grammarly) و آمازون (Amazon)؛ و هرکدام را از نو طراحی کردم.
برای اینکه خروجی این پروژه صرفاً به یک پایان‌نامهٔ مکتوب محدود نشود، یک نمونهٔ اولیهٔ تعاملی دیجیتال (Interactive Digital Prototype) ساختم که تمام این پنج مطالعهٔ موردی (Case Studies) را در یک محیط یکپارچه گرد هم آورده است.

آنچه از این مسیر یاد گرفتم این بود که چالش اصلی در اعتمادسازی نسبت به هوش مصنوعی، بیش از آنکه فنی (Technical) باشد، دیزاین است. به نظرم طراحیِ یک هوش مصنوعی قابل‌اعتماد یعنی اینکه به کاربران کمک کنیم از طریق تجربه‌های کاربری شفاف و هوشمندانه، بتوانند سیستم را بهتر درک کنند، با آن کنکاش کنند و آن را به‌دقت ارزیابی نمایند.

خوشحالم که حالا این پروژه را با شما به اشتراک می‌گذارم و اگر نظرات یا بازخوردی داشته باشید، استقبال می‌کنم! 
 
برای دیدن و کاوش پروژهٔ تعاملی + سند تکمیلی، روی لینک‌ها زیر کلیک کنید:
✔️ https://talkabouttrust.netlify.app
✔️https://talkabouttrust-projectdocumentation.netlify.app/

📱 Shamim Solooki

#اعتماد #هوش_مصنوعی #طراحی_محصول #پایان_نامه #پژوهش


🫶@SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

🚀 مدل‌های Open Weights، پایه رقابت آینده هوش مصنوعی

امشب جمعی از شرکت‌ها و سازمان‌های بزرگ فناوری از جمله Meta، Microsoft، NVIDIA، IBM، Hugging Face، Mozilla و Mistral در بیانیه‌ای مشترک تأکید کرده‌اند که آینده رهبری آمریکا در هوش مصنوعی، تنها به ساخت قدرتمندترین مدل‌ها وابسته نیست؛ بلکه به ایجاد یک اکوسیستم باز و رقابتی بستگی دارد.

✅مهم‌ترین نکات این بیانیه:

🟡همان‌طور که نرم‌افزار متن‌باز، زیرساخت اینترنت و نوآوری دیجیتال را شکل داد، مدل‌های Open Weights نیز می‌توانند زیرساخت نسل بعدی هوش مصنوعی باشند.
🟡مدل‌های Open Weights به شرکت‌ها، دانشگاه‌ها و استارتاپ‌ها اجازه می‌دهند بدون وابستگی کامل به ارائه‌دهندگان بزرگ، مدل‌ها را دانلود، اجرا، سفارشی‌سازی و توسعه دهند.
🟡این رویکرد رقابت را افزایش می‌دهد، هزینه توسعه محصولات هوش مصنوعی را کاهش می‌دهد و از انحصار چند شرکت بزرگ جلوگیری می‌کند.
🟡سازمان‌ها کنترل بیشتری بر داده‌ها، دانش و زیرساخت‌های خود خواهند داشت و ریسک وابستگی به یک ارائه‌دهنده کاهش می‌یابد.
🟡اگرچه مدل‌های باز ریسک‌هایی مانند سوءاستفاده یا تغییرات غیرقابل‌کنترل دارند، اما نویسندگان معتقدند شفافیت، بررسی عمومی، Red Teaming و ارزیابی مستقل، امنیت و ایمنی بیشتری نسبت به مدل‌های کاملاً بسته ایجاد می‌کند.
🟡در پایان نیز از سیاست‌گذاران خواسته شده است به‌جای محدود کردن مدل‌های باز، دسترسی به توان پردازشی، داده‌ها و ابزارهای ارزیابی را گسترش دهند تا نوآوری و رقابت حفظ شود.

🟢این بیانیه یک پیام روشن دارد:
«رقابت آینده هوش مصنوعی فقط بر سر ساخت بزرگ‌ترین مدل نیست؛ بر سر ساخت بازترین و فراگیرترین اکوسیستم هوش مصنوعی است.»


⭕️یک نکته قابل‌توجه: این بیانیه را عمدتاً شرکت‌هایی امضا کرده‌اند که از اکوسیستم Open Weight یا Open Source منتفع می‌شوند. در مقابل، نام بازیگران اصلی مدل‌های بسته مانند OpenAI، Anthropic، Google DeepMind و xAI در میان امضاکنندگان دیده نمی‌شود. این اختلاف دیدگاه نشان می‌دهد رقابت آینده هوش مصنوعی فقط بر سر فناوری نیست؛ بلکه بر سر سیاست‌گذاری، مقررات و مدل حکمرانی نیز خواهد بود.

آپدیت جدید: شرکت‌هایی مثل OpenAI هم به جمع امضا کنندگان این بیانیه پیوستند.

‌+‌ منبع

به نظرم در آینده برای ما انتخاب بین Open و Closed Models دیگر یک تصمیم فنی نیست؛ یک تصمیم استراتژیک است که روی تجربه کاربر، هزینه، امنیت، مقیاس‌پذیری و استقلال محصول اثر مستقیم می‌گذارد.

#هوش_مصنوعی #اکوسیستم_هوش_مصنوعی

🫶@SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

🚀 مدل الماس سه‌گانه در عصر هوش مصنوعی

آیا متوجه هستید در حال ساختن چه نوع سیستمی هستید؟
اگر «الماس سه‌گانه» (Triple Diamond) را مدلی مفید برای مدیریت فرایندهای انسان‌محور می‌دانستیم، در سازمان‌های AI-First باید نگاه متفاوتی به آن داشته باشیم.

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

اما در مدل جدید، نقش انسان تغییر می‌کند.

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

در این مدل، تلاش انسان از تولید بینش به نگهداری و غنی‌سازی Context منتقل می‌شود و بینش، به جای اینکه محصول نهایی باشد، به خروجی دائمی سیستم تبدیل می‌شود.

🟢چند نمونه از این تغییر:

• قبلاً برای کشف مسئله، هر بار پروژه‌ای مستقل اجرا می‌شد. امروز یک مدل از سفر مشتری یا Journey Model ساخته می‌شود و به‌صورت مستمر با داده‌های جدید تکامل پیدا می‌کند.

• قبلاً برای پاسخ به هر سؤال باید دوباره میان اسناد و تحقیقات جست‌وجو می‌کردیم. امروز داده‌ها یک‌بار ساختاردهی می‌شوند و هر فرد با یک پرسش، پاسخ متناسب خود را دریافت می‌کند.

• قبلاً برای ارزیابی نتایج باید دوباره تحلیل و گزارش تهیه می‌شد. امروز Agentهای هوش مصنوعی می‌توانند به‌صورت مداوم عملکرد را پایش کرده و تغییرات را گزارش دهند.

✅ تفاوت اصلی فقط در ابزارها نیست؛ در معماری فرایند است.

در مدل قدیمی، فرایند بر پایه تحویل کار بین تیم‌ها (Hand-off) شکل می‌گرفت. هر تیم کارش را تمام می‌کرد، خروجی را تحویل تیم بعدی می‌داد و فرایند دوباره از نو آغاز می‌شد.

اما در سازمان‌های AI-First، فرایند به یک چرخه بازخورد (Feedback Loop) تبدیل می‌شود:

Context → Intelligence → Impact → Context

زمینه، هوش را تغذیه می‌کند؛ هوش، اثر ایجاد می‌کند؛ و نتایج دوباره به زمینه بازمی‌گردند تا سیستم هوشمندتر شود.

در چنین سیستمی، بسیاری از فعالیت‌های تکرارشونده انسانی جذب خود سیستم می‌شوند. کار دیگر مجموعه‌ای از پروژه‌های جداگانه نیست؛ بلکه به یک موتور دائماً در حال حرکت تبدیل می‌شود.

شاید مهم‌ترین تغییر ذهنیت همین باشد:

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

📱 یادداشت کامل

#تفکردیزاین #دیزاین #هوش_مصنوعی #طراحی_خدمات

🫶@SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

🚀 بومِ مسئله‌یابی و اولویت‌بندی ایده‌های هوش مصنوعی

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

با این بوم (Canvas) عالی، می‌تونید:
✅ همه‌ی ایده‌هارو با یه معیار واحد بسنجید
✅ به‌سرعت ایده‌های ضعیف رو حذف کنید
✅ ارزش، امکان‌پذیری و ریسک رو شفاف ببینید
✅ تیم رو روی مسیری مشخص و درست همراه کنید

به‌جای کلی ایده‌ی مبهم، روی چند فرصت واقعی متمرکز بشید.

📥 فایل The AI Problem Framing Canvas رو همینجا دریافت کنید.

#هوش_مصنوعی #بوم #طراحی_کسب‌وکار #مدیریت_محصول

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

رویداد آنلاین و رایگان AI Builder Week ۲۰۲۶ از امشب آغاز می‌شود

📅 تاریخ: ۳ تا ۷ آگوست ۲۰۲۶ (۱۲ تا ۱۶ مرداد ۱۴۰۵)
📍 مکان: آنلاین

این یک رویداد ۵ روزه کاملاً عملی است، نه یک کنفرانس صرفاً سخنرانی! هدف این است که شما از تماشاگر بودن خارج شوید و خودتان دست به کار شوید. هر روز به یک موضوع خاص می‌پردازد:

🟡روز اول (دوشنبه): اتصال MCP (مدل Claude) به سرویس‌های گوگل (Gmail، Drive، Calendar)
🟡روز دوم (سه‌شنبه): ساخت اولین محصول هوش مصنوعی شما با ابزارهایی مثل Lovable و v0
🟡روز سوم (چهارشنبه): از ایده تا محصول نهایی در ۳۰ دقیقه!
🟡روز چهارم (پنج‌شنبه): روز عامل‌ها و اتوماسیون هوش مصنوعی
🟡روز پنجم (جمعه): ساخت‌وساز کامل با هوش مصنوعی و بررسی نقش مدیر محصول در سال ۲۰۲۶

📥 کسب اطلاعات بیشتر و ثبت نام


#محصول #مدیریت_محصول #هوش_مصنوعی
#وبینار #کنفرانس

🫶@SodehDesign
🔘 Sodeh.me
👩🏻‍💻 https://linktr.ee/irSodeh

🚀 دیزاینر بودن، دیگر فقط مهارت نیست؛ سرمایه می‌خواهد

امروز در کانال احسان عزتی یک نظرسنجی جالب برگزار شده با این سؤال: «حقوق دریافتی شما از UI/UX در حال حاضر چقدر است؟»

البته این آمار فقط بخشی از بازار متخصصان طراحی دیجیتال در ایران را نشان می‌دهد و هنوز داده‌ای از وضعیت Product Design و Service Design نداریم.
تا لحظه‌ای که این متن را می‌نویسم، ۷۷۸ نفر در نظرسنجی شرکت کرده‌اند. از این تعداد، ۳۸۵ نفر؛ یعنی تقریباً نیمی از شرکت‌کنندگان، گزینه‌ی «حقوق ندارم» را انتخاب کرده‌اند.
از میان نیمه‌ی دیگر که درآمدی دارند، حدود ۵۸ درصد کمتر از ۴۵ میلیون تومان دریافت می‌کنند و تنها ۸۵ نفر از مجموع ۷۷۸ نفر، درآمدی بالاتر از ۷۰ میلیون تومان دارند.

حالا این اعداد را کنار هزینه‌های واقعی به‌روز ماندن در این حرفه بگذارید.

امروز اگر بخواهید به‌عنوان یک Product Designer یا UI/UX Designer رقابتی بمانید، حداقل باید هزینه‌ی این موارد را ماهانه بپردازید بخصوص اگر فریلنسرید و باید خودتان به تنهایی روی خودتان سرمایه‌گذاری کنید :

🟡اشتراک ابزارهای هوش مصنوعی؛ از Claude و Figma گرفته تا ابزارهای دیگر. هرکدام حدود ۲۰ دلار در ماه و واقعیت این است که کمتر کسی امروز فقط با یک ابزار کار می‌کند.
🟡اینترنت، که عملاً به‌دلیل نیاز دائمی به VPN، چند برابر هزینه‌ی واقعی تمام می‌شود.
🟡خرید اشتراک VPN با IP ثابت، برای جلوگیری از مسدود شدن حساب‌های کاربری.
🟡خرید، ارتقا و استهلاک لپ‌تاپ و تجهیزات.
🟡دوره‌های آموزشی داخلی/ خارجی و گواهینامه‌های بین‌المللی.
🟡کتاب‌ها و سرویس‌های آموزشی و تخصصی مثل Mobbin و Uxcel.
🟡هزینه‌ی برق
🟡و گران‌ترین مورد؛ زمانی که برای مطالعه، آزمایش ابزارهای جدید، دیدن ویدئوها و یادگیری صرف می‌شود.

معادله ساده است؛ هزینه‌ی به‌روز ماندن دلاری است، اما درآمد همچنان ریالی. فاصله‌ی این دو هر ماه بیشتر می‌شود.

البته این فقط مسئله‌ی هزینه‌ها نیست.
جنگ، قطعی‌های اینترنت، تغییر استراتژی کسب‌وکارها، محتاط‌تر شدن سازمان‌ها در سرمایه‌گذاری روی طراحی و توسعه‌ی محصول و کاهش فرصت‌های شغلی، کاهش جذب نیروی متخصص، قراردادهای کوتاه مدت، رقابت بیشتر کارجویان، و یا حتی نابرابری تعداد متخصص با نیاز بازار ایران، مخصوصاً برای کسانی که تازه وارد این مسیر شده‌اند، همگی بخشی از همین تصویر هستند.

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

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

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

منتظر ماندن برای بهتر شدن شرایط، خودش یک تصمیم است؛ تصمیمی که معمولاً موضوع و چالش‌های اصلی را تغییر نمی‌دهد.

⚡️ما دیزاینریم و خودمان مهم‌ترین محصول زندگی‌مان که باید دیزاین‌اش کنیم.
کاری که هر روز برای محصولات دیگران انجام می‌دهیم، دقیقاً همان چیزی است که امروز باید برای زندگی خودمان انجام دهیم؛

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

🫶 این پست را نوشتم که بدونید تنها نیستید
و لازمه کمی واقع‌بینانه به مسائل نگاه کنیم و براش راه‌حل مناسب خودمون رو پیدا کنیم.

🙏 ضمنا جا داره از احسان عزتی @theehsanez عزیز هم برای برگزاری این نظرسنجی‌های دوره‌ای که جامعه آماری خوبی هم داره تشکر کنم، باعث میشه واقعیت‌های بازار کار در ایران در حوزه ما شفاف تر بشه.

#بازارکار #طراحی_محصول #هوش_مصنوعی #دیزاین_زندگی


🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅ عنوان‌ها در دیزاین عوض شده‌اند، ولی مسئله چیز دیگری است

چند سال پیش تخصص‌های ما بر اساس «چه چیزی می‌سازیم» تقسیم می‌شد: وب، موبایل، دسکتاپ. بعد بر اساس «کدام لایه»: UI، UX Research، Service Design.

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

تا دیروز ما رابط‌های قطعی (deterministic) طراحی می‌کردیم؛ کاربر دکمه را می‌زد و خروجی مشخص بود. امروز روی سیستمی کار می‌کنیم که خروجی‌اش احتمالی است، گاهی اشتباه می‌کند، گاهی خودش تصمیم می‌گیرد و گاهی به‌جای کاربر عمل می‌کند.

هر عنوان جدیدی که این روزها (بخصوص در مارکت بین‌المللی) می‌بینیم، در واقع پاسخی به یک وجه از همین تغییر است. اگر دسته‌بندی‌شان کنیم، منطق‌شان روشن‌تر می‌شود:

۱. لایه تعامل: چطور با سیستم حرف می‌زنیم

🟡Multimodal Interaction Design
وقتی ورودی و خروجی همزمان متن، صدا، تصویر و اشاره است، «صفحه» دیگر واحد طراحی نیست.
🟡Conversation Design (CxD)
طراحی جریان گفت‌وگو، نه چیدمان عناصر.
🟡Voice UX (VUX/VUI)
طراحی برای جایی که هیچ چیزی دیده نمی‌شود.
🟡Agent Experience (AX)
مهم‌ترین پرسش تازه‌ی این حوزه: عامل کجا خودش اقدام کند، کجا اجازه بگیرد، و کجا کنترل را به آدم برگرداند.

۲. لایه اعتماد: چرا کاربر باید حرف سیستم را باور کند

🟡Human-AI Interaction (HAII)
چارچوب علمیِ زیر همه‌ی این حوزه‌ها.
🟡AI Feedback Design
بازخورد کاربر دیگر فقط نظرسنجی نیست؛ سوخت بهبود مدل است.
🟡Trust & Explainability Design
طراحی برای «اعتماد کالیبره‌شده»؛ نه اعتماد کور، نه بی‌اعتمادی کامل.
🟡Error & Uncertainty Design
طراحی برای لحظه‌ای که مدل اشتباه می‌کند. این دیگر یک حالت لبه (edge case) نیست، یک حالت عادی است.

۳. لایه سنجش: از کجا بفهمیم کار می‌کند

🟡AI UX Evaluation
معیارها عوض شده‌اند: کیفیت خروجی، نرخ اصلاح توسط کاربر، میزان واگذاری کار به سیستم؛ نه صرفاً نرخ تکمیل تسک.
🟡AI UI Accessibility
رابط‌های تولیدشونده و متغیر، دسترس‌پذیری را از یک چک‌لیست ثابت به یک مسئله‌ی پویا تبدیل کرده‌اند.

۴. لایه ساخت: فاصله‌ی طراحی تا محصول

🟡AI Native Product Design
محصولی که از روز اول حول قابلیت‌های مدل ساخته شده، نه محصولی که AI بعداً به آن اضافه شده. تفاوت در ظاهر نیست، در معماری تصمیم است: اینجا مدل یکی از اجزای اصلی محصول است، نه یک قابلیت جانبی در گوشه‌ی رابط.
🟡Design Engineer
پروتوتایپِ یک تجربه‌ی مبتنی بر مدل، با ابزارهای استاتیک قابل نمایش نیست. باید ساختش.
🟡Context Design
فراتر از prompt: تصمیم درباره‌ی اینکه سیستم چه چیزی را، چه زمانی، درباره‌ی کاربر بداند.

۵. لایه سیستم و سازمان: جایی که کمتر درباره‌اش حرف می‌زنیم

🟡AI Service Design
وقتی AI در چند نقطه از سفر مشتری / کارکنان می‌نشیند، مسئله سیاست‌گذاریِ تجربه است.
🟡Responsible AI / AI Governance
حکمرانی داده و مدل، دارد به یک «محدودیت طراحی» تبدیل می‌شود، درست مثل محدودیت فنی یا بودجه.

و دو نکته که فکر می‌کنم مهم‌تر از خودِ فهرست است:

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

✅دوم: عنوان جدید بدون تغییر در جنسِ کار، چیزی جز تورم رزومه نیست. تفاوت واقعی آنجاست که شما شروع کنید به طراحی برای رفتار یک سیستم، نه برای ظاهر یک صفحه.


✔️ سؤالی که برای خودم هم باز است:

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

به نظرم اضافه‌کردن «AI» به ابتدای یک عنوان شغلی، ساده‌ترین بخش ماجراست.

#بازارکار #طراحی_محصول #هوش_مصنوعی #آینده_دیزاین

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

Evidence Clipper: افزونه‌ای برای مستندسازی شواهد پژوهشی ✅

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

برای حل این مسئله، افزونه‌ای طراحی کرده‌ام به نام Evidence Clipper.

🟢عملکرد: با یک کلید، هر بخش هایلایت‌شده از هر صفحه‌ی وب ذخیره می‌شود؛ آدرس منبع و زمان ثبت، به‌صورت خودکار ضبط می‌گردد.

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

🟢مخاطب:
پژوهشگران، طراحان و مدیران محصول و تمام کسانی که نیاز دارند منشأ تصمیمات طراحی خود را با استناد به شواهد مستند ارائه دهند.

🟢 امکانات:
🟡ثبت با یک کلید از هر صفحه
🟡ثبت خودکار منبع و زمان
🟡تگ پایه به‌همراه امکان افزودن تگ اختصاصی، در مرحله‌ای جدا
🟡امکان ثبت نظرات و نکات ما
🟡امکان جستجو و دسته‌بندی
🟡کتابخانه در یک تب مستقل مرورگر
🟡رابط کاربری دوزبانه (فارسی و انگلیسی)
🟡خروجی در قالب CSV، JSON و Markdown

❤️این افزونه رایگان و متن‌باز است؛
بدون نیاز به حساب کاربری، بدون سرور، بدون اشتراک.
تمام داده‌ها در همان مرورگر کاربر باقی می‌مانند.

📱 لینک دانلود رایگان از Chrome Web Store

📱 لینک دانلود رایگان و اطلاعات‌ بیشتر در Github

⭕️ امیدوارم این ابزار کوچک که از دل نیاز یک پروژه بیرون آمد برایتان مفید باشد. خوشحال می‌شوم نظرات و پیشنهادهای تکمیلی خود را از طریق ایمیل Sodeh.Abadi@gmail.com با من در میان بگذارید.

#افزونه_مرورگر #طراحی_محصول #طراحی_خدمات #پژوهش #ابزار

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅ چطور در Claude مصرف توکن (token) رو کم کنیم؟

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

۱. برای هر موضوع، چت جدید بزن هر پیام توی یک مکالمه، کل تاریخچه‌ی قبلی رو هم با خودش حمل می‌کنه. وقتی موضوع عوض می‌شه ولی همون چت رو ادامه می‌دی، داری بی‌دلیل تاریخچه‌ی قدیمی رو دوباره «پردازش» می‌کنی.

۲. دستورالعمل‌های Project رو کوتاه و دقیق بنویس هر چی توی System Prompt یا Project instructions بذاری، با تک‌تک پیام‌ها ارسال می‌شه. یک دستورالعمل ۵۰۰ توکنیِ متمرکز، بهتر از یک متن ۳۰۰۰ توکنیِ پر از مثال تکراری عمل می‌کنه.

۳. ا Connector هایی که لازم نداری رو خاموش کن اگه Google Drive، Slack یا هر اتصال دیگه‌ای فعاله ولی به کارت مربوط نیست، محتوای اضافه‌ای وارد مکالمه می‌کنه که فقط توکن مصرف می‌کنه بدون این‌که ارزشی اضافه کنه.

۴. فرمت پاسخ رو از اول مشخص کن بگو «فقط bullet point»، «کوتاه»، «زیر ۱۰۰ کلمه». هر چی خروجی دقیق‌تر خواسته بشه، Claude کمتر پرحرفی می‌کنه و توکن کمتری برای پاسخ صرف می‌شه.

۵. به‌جای پیام جدید، پیام قبلی رو ویرایش کن وقتی می‌خوای بگی «نه، منظورم این بود...»، از دکمه‌ی Edit روی همون پیام استفاده کن نه این‌که پیام تازه بفرستی. این کار از انباشته‌شدن تاریخچه‌ی مکالمه جلوگیری می‌کنه.

۶. مدل مناسب کار رو انتخاب کن برای سؤال‌های ساده لازم نیست از قوی‌ترین مدل استفاده کنی؛ مدل‌های سبک‌تر (مثل Haiku) سریع‌تر و کم‌مصرف‌ترن، و مدل‌های قوی‌تر رو برای کارهای پیچیده نگه دار.

۷. فقط بخش مرتبط رو بفرست، نه کل سند اگه داری روی یک متن یا کد ویرایش می‌کنی، فقط همون بخشی که تغییر می‌کنه رو Paste کن، نه کل فایل رو هر بار.

۸. از خلاصه‌سازی و حافظه (memory) به‌جای نگه‌داشتن کل تاریخچه استفاده کن در پایان یک کار طولانی، از Claude بخواه خلاصه‌ی تصمیم‌ها و مراحل بعدی رو بنویسه؛ دفعه‌ی بعد با همون خلاصه شروع کن، نه با بازخوانیِ کل مکالمه.

۹. از آپلود بی‌دلیل فایل و تصویر حجیم پرهیز کن اسکرین‌شات‌ها، فایل‌های Word/PowerPoint و اسناد حجیم، متادیتای زیادی با خودشون میارن و فضای زیادی از context رو اشغال می‌کنن.

۱۰. فشرده‌سازی خروجی ابزارها با RTK وقتی از Claude Code استفاده می‌کنی، خروجی دستورات ترمینال (مثل جست‌وجو توی کد یا اجرای یک فرمان) می‌تونه هزاران خط باشه که مستقیم وارد context می‌شه. ابزارهایی مثل RTK این خروجی‌های شلوغ رو قبل از ورود به مکالمه فشرده می‌کنن؛ مثلاً هزار خط رو به ۲۰۰ خط مفید تبدیل می‌کنن.

۱۱. حالت Caveman برای پاسخ‌های خیلی خلاصه با یک دستورالعمل خاص (system prompt یا skill) می‌شه از Claude خواست مثل «آدم غارنشین» جواب بده: بدون مقدمه، بدون حرف اضافه، فقط اسم و فعل. این روش می‌تونه توکن‌های خروجی رو تا ۷۰ درصد کم کنه، اما نکته‌ی مهم اینه که خودِ دستورالعمل هم چند توکن اضافه به هر پیام تحمیل می‌کنه؛ برای کارهای کوتاه و ساده (مثل خلاصه‌ی یک تابع یا یک پاسخ سریع) به‌صرفه‌ست، ولی برای مکالمه‌های طولانی یا وقتی می‌خوای یک مفهوم رو یاد بگیری، بهتره خاموش بمونه چون کیفیت توضیح رو پایین میاره.


✔️ و این سه ابزار رایگان
Headroom / Graphify / CodeBurn

⭕️این موضوع صرفه‌جویی در مصرف توکن در Claude برای من به شخصه یک چالش بزرگ بود(مخصوصا در انجام پروژه‌ها و محدودهایی که حتی در نسخه Pro باهاش مواجه می‌شدم)، امیدوارم با این جمع‌بندی برای شما هم مفید واقع بشه!😎

#هوش_مصنوعی #نکات_آموزشی #توکن

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅دیگر فقط کاربر نیست که سیستم را تجربه می‌کند؛ عامل هم تجربه می‌کند. معرفی مرز بعدی دیزاین

در ۶ ماه گذشته، عمیقاً درگیر پژوهش، کاوش، و کار عملی در حوزه‌ای بوده‌ام (و همچنان هستم) که باور دارم به‌زودی حوزه ما را دگرگون خواهد کرد: طراحی تجربه‌ی هوش مصنوعی عامل‌محور (Agentic AI Experience Design) و به طور مشخص‌تر طراحی تجربه‌ی عامل (Agent Experience Design یا AX).

این اولین پست من برای به‌اشتراک‌گذاری این مسیر با شماست.

هم‌زمان با اینکه هوش مصنوعی از یک قابلیت درون محصولات به یک مشارکت‌کننده فعال در جریان‌های کاری تبدیل می‌شود (برنامه‌ریزی می‌کند، تصمیم می‌گیرد، و از طرف ما اقدام می‌کند) پرسش جدیدی برای طراحان در حال شکل‌گیری است: دیگر فقط این نیست که «یک انسان چگونه از این رابط و محصول استفاده می‌کند؟» بلکه این است که «یک عامل یا Agent چگونه این سیستم را تجربه می‌کند، و یک انسان تجربه کار کردن با یک عامل را چگونه دارد؟»

🟡این هسته AX است: طراحی برای اعتماد، شفافیت، و کنترل، زمانی که «کاربر» آن سوی یک تعامل ممکن است یک سیستم خودمختار باشد، و طراحی تجربه انسانیِ همکاری با آن.

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

این تازه آغاز چیزهایی است که می‌خواهم اینجا به‌اشتراک بگذارم. به‌زودی افکار، چارچوب‌ها، و درس‌آموخته‌های بیشتری از این مسیر در راه است.

#AgenticAIExperienceDesign #AgentExperienceDesign #AX
#هوش_مصنوعی #آینده_دیزاین #طراحی_تجربه_ایجنت

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅طراحی اعتماد؛ چالش بعدی صنعت هوش مصنوعی

طبق گزارش جدید TechCrunch، نگرانی عمومی نسبت به هوش مصنوعی از ۳۷٪ در سال ۲۰۲۱ به ۵۲٪ در سال ۲۰۲۶ رسیده، پس یعنی چالش این صنعت دیگر «ساختن» نیست، بلکه «متقاعد کردن مردم» است.

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

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

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

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

#آینده_دیزاین #هوش_مصنوعی #طراحی_تجربه #اعتماد

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅ اطلاعیه درباره تبلیغات تلگرامی نمایش‌داده‌شده در کانال

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

با تشکر
سوده

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅همکاری چند نفره هوش مصنوعی در سراسر چرخه عمر محصول

این ارائه که توسط Head of Product at Miro در رویداد AI Builder Week 2026 که ماه گذشته توسط تیم Product School ارایه شد و به شخصه برای من خیلی جذاب بود، و به طور محوری درباره همکاری چندنفره مبتنی بر هوش مصنوعی (AI Multiplayer Collaboration) در طول چرخه توسعه محصول (PDLC) و چگونگی حل چالش‌های هماهنگی تیمی با استفاده از بسترهای مشترک بصری صحبت می‌کند.
.
🌟چالش‌های اساسی معرفی‌شده در این ارائه:

🟡رکود بهره‌وری تیمی با وجود افزایش بهره‌وری فردی: آمارهای تحقیقاتی نشان می‌دهد ۷۵٪ از رهبران محصول، مهندسی و طراحی متوجه شده‌اند که ابزارهای هوش مصنوعی فعلی عمدتاً بر کارایی فردی تمرکز دارند. این تمرکز تک‌نفره باعث می‌شود افراد کارهای بسیار صیقل‌خورده اما بدون بافت و زمینه تیمی (مانند یک نمونه اولیه یا استراتژی بدون هماهنگی) تولید کنند، که در نهایت منجر به هدر رفتن کل زمان ذخیره‌شده می‌شود.
🟡تشدید و تسریع ناهماهنگی (Misalignment): هوش مصنوعی ناهماهنگی‌های موجود در سازمان را سرعت می‌بخشد و وضعیتی ایجاد می‌کند که اعضا سریع‌تر از همیشه روی یک نقطه می‌دوند بدون اینکه تصمیمی واقعی گرفته شود.
🟡گلوگاه شدن فرآیند تصمیم‌گیری: با ورود هوش مصنوعی تولید کارها به شدت مقیاس گرفته، اما فرآیند تصمیم‌گیری مقیاس‌پذیر نشده است و مدیران یا رهبران به گلوگاه‌های سازمانی تبدیل شده و دچار فرسودگی شغلی می‌شوند.

🌟مفاهیم جدید و راه‌حل‌های کلیدی ارائه‌شده:

راه‌حل پیشنهادی برای عبور از این چالش‌ها، استفاده از بستر بصری و مشترک «بوم عامل‌محور» (Agentic Canvas) در میرو (Miro) است. سه ابزار و قابلیت محوری در این بستر عبارتند از:

🟡دستیارهای عامل‌محور (Agentic Sidekicks): این عامل‌ها برخلاف ابزارهای دیگر که فایل‌های یک‌بار مصرف تولید می‌کنند، می‌توانند مستقیماً روی بوم مشترک بنویسند و بخوانند و اسلایدها، اسناد یا پروتوتایپ‌ها را جلوی چشم همه اعضا ایجاد کنند.
🟡جریان‌های کاری خودکار (Flows): ابزارهای مبتنی بر نود که به شما اجازه می‌دهند فرآیندهای تکراری مانند تولید نقشه راه، برنامه‌های بهبود و کارهای روتین روزمره را خودکارسازی کنید.
🟡 اتصال‌دهنده‌ها (Connectors): قابلیت کشیدن اطلاعات از ابزارهای خارجی نظیر Slack، Google Drive و Confluence به درون میرو و تبدیل سریع و بدون تأخیر آن‌ها به عناصر بصری.

🟢نکات کاربردی و درس‌های مهمی که می‌توان یاد گرفت:

این ویدیو با ارائه دو مورد مطالعاتی و عملی، نشان می‌دهد که چطور این تکنولوژی‌ها کار را متحول می‌کنند:

🟡سناریوی اول: خودکارسازی کامل چرخه محصول از بازخورد تا نمونه اولیه: شما یاد می‌گیرید که چگونه داده‌های خام نامنظم (مثل فایل CSV بازخوردهای مشتریان و گزارش‌های PDF تحقیقات کیفی) را همراه با فایل استراتژی و حتی تصویر پروتوتایپ فعلی وب‌سایت به هوش مصنوعی بدهید. هوش مصنوعی با درک بصری پروتوتایپ، یک بک‌لاگ اولویت‌بندی‌شده، یک برنامه بهبود استراتژیک هماهنگ با اهداف شرکت، یک ارائه اسلایدی برای ذینفعان و حتی سه نسخه پروتوتایپ بهبودیافته جدید را به طور مستقیم روی بوم تولید می‌کند.

🟡سناریوی دوم: هم‌راستایی تیمی و ساخت خودکار کارگاه‌ها (Workshops): یاد می‌گیریم چطور با استفاده از اتصال‌دهنده‌ها، پیام‌های پراکنده یک هفته اخیر در Slack و زمان‌بندی‌های موجود در Confluence را در یک جدول و خط زمانی مشترک جمع‌آوری کنیم. سپس هوش مصنوعی با ویژگی «چیدمان بوم» (Board Layout) یک کارگاه تعاملی کامل همراه با Stickies برای هم‌ترازی اعضا، سنجش میزان اطمینان تیم و شناسایی تداخل‌های زمانی پروژه‌ها ایجاد می‌کند.

🌟تغییر نگرش اساسی (Mindset Shift): بزرگ‌ترین درس این ارائه به نظرم تغییر تفکر از هوش مصنوعی تک‌نفره به هوش مصنوعی چندنفره و تیمی است. وقتی روند کار هوش مصنوعی به صورت بصری روی بوم قرار می‌گیرد، ذینفعان مسیر رسیدن به نتایج را می‌بینند که این امر اعتماد تیمی را به شدت افزایش می‌دهد. همچنین همه اعضای تیم (طراح، مهندس و مدیر) می‌توانند به طور مشترک روی خروجی‌های هوش مصنوعی کار کرده و آن‌ها را اصلاح کنند.

پیشنهاد میکنم این ویدیو رو از یوتیوب با زیرنویس فارسی و یا با پلاگین (با دوبله فارسی) ببینید.

📱 AI Multiplayer Collaboration Across the Product Lifecycle


#مدیریت_محصول #هوش_مصنوعی #گردش_کار #چرخه_محصول #ویدیو

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅درباره نقش AI Native Product Designer در تیم‌های محصول

طی یکی دو سال اخیر یک عنوان شغلی جدید در آگهی‌های استخدام شرکت‌های بزرگ و پیشرو زیاد دیده می‌شود: AI Native Product Designer. این فقط یک لیبل تزئینی روی همان کار قدیمی نیست؛ شرح وظایف و انتظارات این نقش واقعاً فرق دارد. دراین پست تلاش کردم از آنچه در بازار واقعی(حتی الزاما نه مارکت ایران) زیر این عنوان تعریف می‌شود(تا جایی که میدانم) بنویسم.

🌟تفاوت نقش Digital Product Designer و AI Native Product Designer

در واقع تفاوت این دو نقش بیشتر در نقطه‌ی شروع و محل تصمیم‌گیری است تا در ابزار. یک Digital Product Designer معمولاً مسئله را در چارچوب رابط و تجربه‌ی کاربر حل می‌کند: کشف نیاز، طراحی جریان کاربری (user flow)، پروتوتایپ در Figma، و هماهنگی با مهندسی برای پیاده‌سازی یک محصول با رفتار قابل‌پیش‌بینی. اما یک AI Native Product Designer روی محصولی کار می‌کند که خودِ رفتارش غیرقطعی و پویاست، چون یک مدل هوش مصنوعی در دل تجربه تصمیم می‌گیرد، پاسخ می‌دهد یا حتی اقدام می‌کند. به همین دلیل مسئولیت او فراتر از چیدمان رابط می‌رود: باید prompt و لحن پاسخ AI را طراحی کند، برای رفتارهای غیرمنتظره‌ی مدل (edge cases) طرح جایگزین بسازد، شفافیت و کنترل کاربر روی تصمیم‌های خودکار را تضمین کند، و سیستم طراحی را طوری مستند کند که هم انسان و هم مدل بتوانند از آن پیروی کنند. به زبان ساده: Digital Product Designer تجربه‌ای برای یک سیستم قابل‌پیش‌بینی طراحی می‌کند؛ AI Native Product Designer تجربه‌ای برای یک سیستم می‌سازد که خودش هم یکی از تصمیم‌گیرندگان تجربه است.

🌟این عنوان دقیقاً یعنی چه؟

طراح AI Native کسی نیست که فقط از ابزارهای هوش مصنوعی (AI tools) در کارش استفاده می‌کند. تفاوت اصلی در نقطه‌ی شروع فرآیند طراحی است:
طراح سنتی معمولاً کار را در Figma شروع می‌کند و بعد در جایی از مسیر، AI را وارد می‌کند.
طراح AI Native کار را با یک مدل زبانی (LLM) شروع می‌کند، برای شفاف‌سازی مسئله، کشف فرضیات پنهان (assumptions)، و هم‌راستا شدن با تیم محصول (Product) پیش از هر خط طراحی بصری.
شرح وظایف واقعی (بر اساس آگهی‌های استخدام)

🌟بر اساس نمونه‌های واقعی بازار، مسئولیت‌های اصلی جدید این نقش معمولاً شامل این‌هاست:
در واقع اکثر هسته‌ی وظایف طراح محصول (Digital Product Designer) دست‌نخورده باقی مانده، چیزی که عوض شده لایه‌ای است که رویش اضافه شده، نه جایگزینی آن. چیزی که واقعاً فرق کرده، نقطه‌ی شروع فرآیند و ابزار میانی است، نه ماهیت وظایف، طراح دیجیتال قبلی مسئله را در Figma شروع می‌کرد و در انتها احتمالاً AI را وارد می‌کرد؛ طراح AI Native همان زنجیره‌ی «تحقیق → تعریف مسئله → طراحی → تست» را طی می‌کند، اما مرحله‌ی اول را با یک LLM شروع می‌کند و در میانه هم باید برای Agent UX و سیستم‌های خوانا برای AI طراحی کند.

🟡طراحی رابط برای عامل‌های هوشمند (Agent UX): طراحی تجربه‌هایی که در آن‌ها AI به‌جای منتظر ماندن برای دستور کاربر، خودش اقدام می‌کند. این نیازمند الگوهای جدیدی است: نمایش شفاف اینکه عامل (agent) چه کاری دارد انجام می‌دهد، چرا آن تصمیم را گرفته، امکان override توسط کاربر، و بازیابی روان از خطا (error recovery).

🟡طراحی سیستم‌های طراحی هوشمند (AI-native design systems): توکن‌ها، کامپوننت‌ها، قوانین حرکت (motion)، الزامات دسترسی‌پذیری (accessibility) و لحن محتوا باید در قالبی نوشته شوند که هم انسان و هم مدل‌ها/عامل‌ها بتوانند آن را بخوانند و اجرا کنند.

🟡همکاری عمیق‌تر با مهندسی: مرز کلاسیک «طراح اسپک می‌دهد، مهندس پیاده می‌کند» کم‌رنگ شده. چون AI بخش زیادی از تولید کد را سریع‌تر کرده، طراح باید درک فنی واقعی از state، data flow و معماری داشته باشد تا بتواند در این گفت‌وگو شریک باشد، نه فقط تحویل‌دهنده.

🟡قضاوت و مسئولیت‌پذیری روی خروجی AI: هوش مصنوعی بر اساس الگو تولید می‌کند، نه درک. این طراح است که باید تشخیص دهد خروجی تولیدشده با جهت بلندمدت محصول هم‌خوان است یا نه، یعنی نقش quality gatekeeper پررنگ‌تر شده، نه کم‌رنگ‌تر.

🟡پروتوتایپ سریع و مشارکت در استراتژی محصول: در بسیاری از آگهی‌ها (به‌خصوص در استارتاپ‌ها)، این نقش با GTM و استراتژی محصول هم تلاقی دارد؛ یعنی از طراح انتظار می‌رود در تصمیم‌های محصول هم نقش پررنگ داشته باشد.

⭕️ نکته مهم:
ما با اضافه کردن عنوان AI به ابتدای عنوان شغلی‌مان الزاما تبدیل به AI Native Product Designer نمی‌شویم.

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

#عنوان_شغلی #طراحی_محصول #مدیریت_محصول #هوش_مصنوعی

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅تصمیم‌گیری در عصر AI: از انسان به انسان+AI

✔️تا قبل از هوش مصنوعی:
Information → Human → Decision

☑️اما اکنون:
Information → AI → Recommendation → Human → Decision

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

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

🟡در سطح تجربه (experience):

طراحی تجربه دیگر فقط طراحی «مسیر تصمیم انسان» نیست، طراحی «نحوه‌ی مواجهه‌ی انسان با recommendation ماشین» هم هست.
اعتماد (trust) دیگر فقط بین انسان و برند شکل نمی‌گیرد؛ بین انسان، AI، و برند شکل می‌گیرد.
شفافیت (transparency) در این‌که recommendation از کجا آمده، تبدیل می‌شود به یک نیاز طراحی، نه یک ویژگی اختیاری.

🟡در سطح فرایند کاری (workflow):

فرایندهایی که قبلاً خطی بودند (بررسی داده، تحلیل، تصمیم)، حالا یک checkpoint اضافه دارند: تفسیر ماشین. این checkpoint اگر طراحی‌شده نباشد، خودش تبدیل به یک گلوگاه (bottleneck) پنهان می‌شود؛ چون آدم‌ها یا کورکورانه به recommendation اعتماد می‌کنند، یا وقت زیادی صرف اعتبارسنجی آن می‌کنند.
مستندسازی تصمیم (decision log) پیچیده‌تر می‌شود؛ دیگر کافی نیست بنویسیم «چرا این تصمیم گرفته شد»، باید مشخص شود «AI چه پیشنهادی داد، انسان چه بخشی از آن را پذیرفت یا رد کرد، و چرا». این لایه‌ی اضافه برای accountability و برای بازبینی بعدی تصمیم حیاتی است.
نقش‌های تیمی جابه‌جا می‌شوند: بخشی از کاری که قبلاً «تحلیل‌گر» انجام می‌داد الان به AI منتقل شده، و نقش انسان بیشتر به سمت validation، judgment، و context-setting می‌رود. اگر این جابه‌جایی نقش صریح تعریف نشود، تیم‌ها دچار ابهام مسئولیت می‌شوند.

🟡در سطح تصمیم‌گیری کسب‌وکاری (business decision-making):

سرعت تصمیم بالا می‌رود اما ریسک «تصمیم‌گیری تنبل» (accepting the recommendation بدون تأمل کافی) هم بالا می‌رود؛ سازمان باید صریحاً تعیین کند کجا AI فقط پیشنهاد می‌دهد و کجا انسان موظف است استدلال مستقل خودش را ثبت کند.
تصمیم‌های کسب‌وکاری که قبلاً بر پایه‌ی consensus بین چند نفر یا چند تیم شکل می‌گرفت، الان یک ورودی مشترک اضافه دارد (خروجی AI) که می‌تواند consensus را سریع‌تر بسازد یا برعکس، اختلاف‌نظر را دور بزند و باعث شود مسائل واقعی زیر سؤال نروند.
حاکمیت داده و مدل (governance) دیگر صرفاً یک موضوع فنی نیست، بلکه بخشی از استراتژی تصمیم‌گیری کسب‌وکار می‌شود: چه کسی می‌تواند منطق recommendation را ببیند، تغییر بدهد، یا رد کند؟


💬سوالی که این روزها بیشتر از قبل با آن درگیرم:
وقتی AI بین «داده» و «تصمیم انسان» می‌نشیند، مسئولیت طراحی آن لایه‌ی واسط با کیست، و چطور باید طراحی شود که کنترل تصمیم واقعاً دست انسان و دست تیم بماند، نه اینکه فقط شکل ظاهری تصمیم‌گیری حفظ شود؟

#تصمیم_گیری #حل_مسئله #طراحی_محصول #مدیریت_محصول #هوش_مصنوعی

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

☑️درباره مهارت‌های AI Native Product Designer

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

و به این سوال مهم پاسخ بدیم (تا حد امکان و سواد من): از دانش و مهارتی که به‌عنوان Digital Product Designer ساختیم، چقدرش هنوز به کار میاد؟ و کجاها باید عمیق‌تر یاد بگیریم؟

بر اساس چیزی که این روزها در بازار جهانی (از تحلیل نقش‌های استخدامی گرفته تا گفت‌وگو با طراحانی که همین الان داخل تیم‌های AI-native کار می‌کنن) دیده می‌شه، تصویر روشنه:

⚙️هسته‌ی کار عوض نشده، محل تمرکز عوض شده

۱. مهارت‌هایی که همچنان پایه‌ی کارمون هستن

🟡Design Thinking:
به‌عنوان طرز فکر، نه فقط یک فرایند، توانایی رفت‌وبرگشت بین واگرایی (ایده‌های زیاد) و همگرایی (انتخاب درست)، حتی وقتی AI بخشی از تولید ایده‌ها رو انجام می‌ده
🟡User research و empathy:
هنوز شرط اول دیزاین خوبه؛ فقط روش جمع‌آوری داده تغییر کرده
🟡Product sense:
یعنی از بین ده تا خروجی که هوش مصنوعی تولید می‌کنه، بفهمی کدوم واقعاً مسئله‌ی کاربر رو حل می‌کنه، نه کدوم زیباتره یا سریع‌تر قابل‌ساختنه
🟡Problem framing:
چون تولید راه‌حل ارزون شده، چارچوب‌بندی درست مسئله ارزش بیشتری پیدا کرده
🟡Systems thinking:
طراحی دیگه «صفحه به صفحه» نیست؛ باید کل سفر کاربر رو در نظر بگیری، جایی که توصیه‌ها، onboarding و پیام‌رسانی همه با هم و گاهی به‌صورت خودکار تغییر می‌کنن
🟡Craft و taste
جایی که AI هنوز ضعیفه: motion، micro-interaction، و اون حس «سنجیده و هدفمند بودن» طراحی، همچنان امضای طراح انسانیه

۲. مهارت‌هایی که کمی شکل عوض کردن

🟡Prototyping:
مسیر کار داره از «شروع در Figma» به «شروع در LLM، پروتوتایپ در ابزارهای AI code (مثل Cursor + Claude Code یا v0)، و Figma به‌عنوان لایه‌ی نهایی و سیستم‌سازی» تغییر می‌کنه
🟡Research:
از مطالعات رسمی و زمان‌بر به‌سمت self-serve research با کمک AI حرکت کرده، سرعت بالا رفته، ولی مهارت طراحی سؤال درست و نقد داده همچنان دست طراحه
🟡Ideation:
چیزی به اسم vibe coding داره جای بخشی از exploration دستی رو می‌گیره؛ طراح سریع‌تر جهت‌های مختلف رو امتحان می‌کنه

۳. مهارت‌های نسبتاً تازه که باید اضافه کنیم

🟡Tool orchestration:
نه یادگیری صد تا ابزار AI، بلکه توانایی چیدن چند ابزار کنار هم برای یک نتیجه‌ی مشخص
🟡Prompting:
در حد کار واقعی، نه دمو، یعنی prompt قابل‌اتکا، قابل‌تکرار، و قابل‌استفاده برای بقیه‌ی تیم
🟡Evaluation / judgment
نقد و انتخاب از میان خروجی‌های AI، به‌جای تولید از صفر؛ این شده مهم‌ترین مهارت روز
🟡System behavior design:
طراحی رفتار AI در طول زمان: کِی توضیح بده، کِی کنترل رو به کاربر برگردونه، کِی محدودیت‌هاش رو شفاف کنه
🟡Human–agent interaction patterns:
الگوهای جدید تعامل انسان با ایجنت‌ها، چیزی که هنوز داره شکل می‌گیره و استاندارد قطعی نداره
جمع‌بندی

☑️نکته‌ی کلیدی به نظرم اینه:
عنوان شغلی عوض شده، ولی چیزی که یک طراح رو باارزش می‌کنه عوض نشده، قضاوت (judgment). فقط حالا قضاوت باید سریع‌تر، روی حجم بیشتری از گزینه‌ها، و در سیستمی که بخشی از تصمیم‌هاش رو خود AI می‌گیره اعمال بشه.

اگه داری از Digital Product Designer به AI Native Product Designer مهاجرت می‌کنی، لازم نیست از صفر شروع کنی؛ باید بدونی کدوم دانشت رو عمیق‌تر کنی و کجا مهارت جدید اضافه کنی.

🗓️پ.ن: مطمئنا این پست کامل و جامع نیست و در آینده مجددا باید اصلاح و تکمیل‌تر شود
اما برای شناخت بیشتر و شفاف‌تر می‌توانیم از آن استفاده کنیم

#عنوان_شغلی #طراحی_محصول #مدیریت_محصول #هوش_مصنوعی


🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅ یه Skill کاربردی برای طراحان محصول: AI Native Product Designer

این چند مدت در حوزهٔ طراحی محصول و UX یه سؤال جدی مطرح هست: طراح محصول «AI-native» یعنی چی، دقیقاً چه فرقی با طراح محصول دیجیتال دارد؟
من تلاش کردم در دو پست جداگانه به این نقش بپردازم.

اما به تازگی یک اسکیل (Agent Skill) به همین اسم منتشر شده که این نقش رو خیلی دقیق تعریف می‌کنه. خلاصه‌ی مدلش را میتوانیم اینطوری توضیح دهیم:

☑️ لایه ۱ - LLM: کار طراحی از فیگما شروع نمی‌شه، از یک مدل زبانی (مثل Claude یا ChatGPT) شروع می‌شه؛ برای شفاف کردن مسئله، نوشتن پیش‌نویس PRD، و پیدا کردن edge caseها

☑️لایه ۲ - ابزارهای کد AI: بعد با ابزارهایی مثل Cursor یا Claude Code یه پروتوتایپ تعاملی (interactive prototype) ساخته می‌شه تا فرضیه‌ها سریع تست بشن

☑️ لایه ۳ - فیگما: فیگما دیگه الزاما نقطه‌ی شروع نیست؛ برای پوشش کامل state ها و آماده‌سازی برای هندآف به تیم مهندسی

🔴نکته‌ی جالب‌ترش یه چک‌لیست ۱۰ سؤالی خودارزیابی هست، مثلاً:
🟡قبل از فیگما، سراغ LLM می‌ری؟
🟡تو ۳۰ روز گذشته با ابزار کد AI پروتوتایپ تعاملی ساختی؟
🟡بدون تیم ریسرچ، مستقیم با کاربر صحبت کردی؟

به نظرم این چارچوب می‌تواند ازش به عنوان یک معیار واقعی استخدام و آمادگی خودمون هم استفاده بشه؛ خیلی از آگهی‌های شغلی طراح محصول این روزها دقیقاً همین استک رو می‌خوان.

اطلاعات بیشتر رو میتونید از اینجا ببینید

⭕️نکته: این Skill رو میتونیم در Claude نصبش کنیم که ازش به‌عنوان یک چارچوب ثابت (framework) برای کارها استفاده کنیم.

#AgentSkill #طراحی_محصول #هوش_مصنوعی

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅ به یاد کیوان خُسرُوانی(۱۳۱۷-۱۴۰۵)

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

با این حال او با نقّادی تمام معتقد است «ایران همیشه در فرهنگش یک جور تخریب بوده. و همینطور یک جور عبودیت. چه در دوره هخامنشی‌اش و چه حالا. این فرق دارد با سیستم‌هایی مثل فرهنگ یونان قدیم که همان موقعی که ایرانیان می ‌رفتند می‌جنگیدند و آتن را آتش می‌زدند، یونانیان هر جا می‌رفتند، یک تئاتر یونانی می‌ساختند. اگر در بالا سقراط و افلاطون و اینها بودند ولی در پایین هم مردم عادی می‌نشستند پی‌اس‌هایی را نگاه می‌کردند که {کارِ} سوفکل بوده. آنتیگون بوده؛ اینها را نگاه می‌کردند. یعنی بالاترین مغز در رابطه بوده با پایین‌ترین. که می‌بینیم معماری‌شان هم تبدیل می‌شود به علم معماری؛ که جلوی دید اشتباه چشم را می‌گیرد. چیزی که هرگز در معماری ایران وجود نداشته. یا ورزششان را می‌بینیم که تبدیل می‌شود به ورزش المپیک و شهرسازی‌شان هم همینطور. این است که حساب‌کردن روی قوم مخربی که ما باشیم، خیلی کار ساده‌ای نیست! مثلاً من سیستم‌های سیاسی تاریخ ایران را که می‌بینم خیلی ربط پیدا می‌کند به فرهنگ ایران؛ {و اگر ناکارآمد یا بد است} درست آن چیزی است که شالوده فرهنگ ایران است. متاسفم که این را می‌گویم ولی واقعیت دارد...» کیوان بدون تعارف از جمله شخصیت هایی‌ست که شناخت افکار و زندگی‌اش به ما یاری می‌دهد تا نقبی بزنیم به عمق جامعهٔ ایرانی و دوباره و دوباره به نقد خود بنشینیم و به عینک شک خویشتن را باز ببینیم، تا بلکه دست آخر بتوانیم به درستی خود را بازبیابیم. باید بدانیم که جز از درست "پرسیدن" و در پیِ پاسخِ درست برآمدن راهی نیست که به قول ابراهیم گلستان، « ... شک عنصر حیاتی اندیشه است. شک شرط بررسی و کشف و درک و ایمان است. شک شرط آزادی است ».

🟡گزیده ای از آثار و تصاویر کیوان خسروانی
🟡 کیوان خسروانی پدر طراحی مُد ایران
🟡نقدِ معماری از نگاهِ کیوان خسروانی: بخش نخست
🟡دیزاین ایران از دریچهٔ فرهنگ: روایتِ کیوان خسروانی، چهل سال بعد

سپاس فراوان از کامیونیتی زاین و به ویژه مازیار رضایی عزیز
@zignchannel

یاد کیوان خسروانی همیشه زنده و میراثش جاودان است🇮🇷

#دیزاین #دیزاینر #کیوان_خسروانی

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh

✅ساخت معکوس: قانون جدید توسعه محصول در عصر AI

این ارائه که توسط Ben Haefele (Chief Product Officer/ Webflow) ، در رویداد AI Builder Week 2026 که ماه گذشته توسط تیم Product School برگزار شد ارائه شده، و به‌طور محوری درباره‌ی این صحبت می‌کند که چطور ظهور توسعه‌ی agentic (Agentic Development) دارد کل چرخه‌ی توسعه‌ی محصول (Software Development Life Cycle) را که از دهه‌ی ۷۰ میلادی رایج بوده، معکوس می‌کند.
.
🌟 چالش‌های اساسی معرفی‌شده در این ارائه:

۰ فرآیند سنتی (ایده ← نیازمندی ← طراحی ← کد ← تست) که برای دنیایی طراحی شده بود که نوشتن کد کند و پرهزینه بود، دیگر با واقعیت امروز همخوانی ندارد.
۰ تیم‌های محصول باید شهود قدیمی خود درباره‌ی «چه‌چیزی سخت است و چه‌چیزی آسان» را رها کنند، چون این مرز هر ماه با پیشرفت مدل‌ها جابه‌جا می‌شود.
• ریسک واقعی تبدیل‌شدن محصولات به AI slop اگر این گذار بدون برنامه‌ریزی انجام شود.
۰ وقتی همه‌ی اعضای تیم محصول شروع به نوشتن کد می‌کنند، ظرفیت ریویو تیم مهندسی به یک گلوگاه (bottleneck) جدی تبدیل می‌شود.

🌟مفاهیم جدید و راه‌حل‌های کلیدی ارائه‌شده:

• مفهوم Building Backwards (ساخت معکوس): مسیر حالا برعکس شده — ایده ← کد اجرا‌شده (deployed code) ← تست و بازی با آن ← طراحی و شکل‌دهی عمدی ← و در نهایت، مستندسازی و نیازمندی‌ها در انتهای مسیر شکل می‌گیرند.

• این رویکرد در واقع تحقق کامل‌تر مانیفست Agile است: working software over documentation، customer collaboration، و پاسخ سریع به تغییر، همگی حالا واقعی‌تر از همیشه اجرا می‌شوند.

• شباهت مستقیم با روش TDD (Test-Driven Development) و چرخه‌ی red-green-refactor، با این تفاوت که این چرخه حالا در سطح فیچر تکرار می‌شود، نه فقط واحدهای کد.

• تغییر نقش PM و طراح از «تولید» به «کیوریشن، سلیقه و قضاوت» (curation, taste, judgment)؛ طراحان بیشتر روی سیستم طراحی (design system)، توکن‌ها، فاصله‌گذاری و استانداردهای accessibility کار می‌کنند تا قوانینی که ایجنت‌ها بر اساس آن تولید می‌کنند.

🟢 نکات کاربردی و درس‌های مهمی که می‌توان یاد گرفت:

• شروع کار با پروتوتایپ‌های کدمحور (code-backed prototypes) به‌جای مستندات یا مدل‌های استاتیک Figma.
• ساخت ابزار داخلی (مثل ابزار Atrium در وب‌فلو) برای سازمان‌دهی و کاتالوگ‌کردن حجم بالای artifactهای تولیدشده توسط تیم.
• بازنویسی career ladder برای گنجاندن انتظارات AI-native در سه محور: تسریع کار اصلی با AI، ساخت تجربه‌های محصول مبتنی بر AI، و تبدیل‌شدن اعضای تیم به builder واقعی.
• اختصاص زمان ثابت هفتگی در تقویم (مثل Builder Wednesday در وب‌فلو) برای تمرین واقعی ساختن.
تعیین هدف قابل‌اندازه‌گیری و شفاف: رساندن ۱۰۰٪ تیم محصول به شیپ‌کردن کد در پروداکشن.
• ساخت harness های داخلی (مثل Flower در وب‌فلو) برای تزریق best practiceها و یکپارچگی با ابزارهایی مثل Slack.
• زمان صرفه‌جویی‌شده باید صرف تحقیق بیشتر با کاربران (user research) شود، نه کمتر، این‌جا اهمیت discovery بیشتر از همیشه است.

💎درس مهم از شکست:
پروژه‌های بزرگ agentic باید طوری سازمان‌دهی شوند که برای انسان قابل ریویو باشند؛ در غیر این‌صورت هفته‌ها کار اضافه برای بازسازی به‌وجود می‌آید.

پیشنهاد میکنم این ویدیو رو از یوتیوب با زیرنویس فارسی و یا با پلاگین (با دوبله فارسی) ببینید.

📱 Building Backwards: The New Rules of AI-Native Product Development

#مدیریت_محصول #هوش_مصنوعی #گردش_کار #چرخه_محصول #ویدیو

🫶 @SodehDesign
☝️ Sodeh.me
⚙️ https://linktr.ee/irSodeh