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

✨ دوره جدید مسابقات طراحی داکس آغاز شد

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

💡این مسابقه مناسب چه کساییه؟

🟡طراحان UI/UX
🟡 طراحان محصول
🟡 علاقه‌مندان به تجربه‌کاربری
🟡 علاقه‌مندان به چالش‌های طراحی
🟡 علاقه‌مندان به حل مسئله

اینجا بیشتر از عنوان شغلی یا میزان سابقه، نحوه فکر کردن به مسئله و رسیدن به راه‌حل اهمیت داره.

💡برای فرد برنده:

💰 ۵۰ میلیون تومان جایزه نقدی
🗓️گواهی برگزیده داکس
🎨 اشتراک یکساله دیزاین سیستم دیگ(DIG)
✍️ امکان انتشار مقاله در داکس
👑تندیس داکس

و برای افراد برتر:

🗓️ گواهی برگزیده داکس
🎨 اشتراک یکساله دیزاین سیستم دیگ(DIG)
✍️ امکان انتشار مقاله در داکس
👑تندیس داکس

🔗 ثبت‌نام از طریق سایت داکس
⭕️ برای ورود به سایت، VPN خود را خاموش کنید.

https://dux.studio | @duxstudio

شاید این دوره، نوبت شما باشه. ثبت‌نام کن و وارد چالش شو😎🏆
این مسابقات به میزبانی استودیو تجربه کاربری داکس برگزار میشه.


❤️این یک تبلیغ نیست، یک حمایت دوستانه از سوده دیزاین است. حمایت از فعالیت‌های ارزشمند جامعه دیزاین، را فراموش نکنیم.

#DUXAwards #Summer1405 #Design
🫶@SodehDesign

✅درس‌هایی از یک تجربه‌ی واقعی: مدیریت استعداد در دیجی‌کالا

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

از سال ۱۳۹۵، از زمانی که پروژه تحول دیجیتال (Digital Transformation) در سازمانی که در آن مشغول بودم آغاز شد و من هم عضو کمیته تحول دیجیتال آن مجموعه بودم، مفهوم استعداد دیجیتال (Digital Talent) و به‌طور کلی مدیریت استعداد (Talent Management) همیشه برایم موضوعی جذاب بوده است.

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


🟢درس آموخته‌ها در اولین راند برگزاری فرایند مدیریت استعداد گروه دیجی‌کالا

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

فارغ از مدل‌ها و تئوری‌های مدیریت استعداد، چیزهایی که من یاد گرفتم:

۱. جاه‌طلبی + چشم‌انداز شغلی مشخص + حوصله‌ی دردسر داشتن، نشانه‌ی پتانسیل است.

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

۳. «وقت نداشتم یاد بگیرم» معمولاً بهانه است. آدم‌های مستعد، برای یادگیری جا باز می‌کنند.

۴. خروج از منطقه امن، استقبال از تجربه‌های جدید و فعالانه بازخورد گرفتن، نشانه‌ی بسیار خوبی است.

۵. درون‌گرا بودن نقطه‌ضعف نیست. اینکه انرژی‌ات را از خلوت می‌گیری مشکلی ندارد؛ مسئله این است که آیا می‌توانی با دیگران ارتباط مؤثر برقرار کنی و آن‌ها را با خودت همراه کنی؟

۶. مدیریت، شغلِ حل مسئله و تصمیم‌گیری است.
کسی که ذهن منظمی ندارد، تفکر منطقی را بلد نیست، خطاهای شناختی خودش را نمی‌شناسد، احتمالاً در تصمیم‌گیری‌های پیچیده‌ی مدیریتی هم به مشکل خواهد خورد.

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

📱 لینک منبع

البته معتقدم با ورود بیشتر به عصر هوش مصنوعی، برخی تعاریف و شاخص‌های «استعداد دیجیتال» نسبت به حتی ۴ سال گذشته تغییر کرده، و باز تعریف نیاز داره که من در این پست به اون‌ها اشاره نمیکنم، چون تخصص من در حوزه HR و Talent Management نیست! اما میتواند یه سرنخ برای جستجوگری بیشتر باشد، و البته شاید شنیدن این پادکست هم برای شما جذاب باشه!

🎙 اپیزود هجده پادکست مدرسه تحول دیجیتال:
استعداد دیجیتال کیست و چه می‌خواهد؟

#استعداد_دیجیتال #مدیریت_استعداد #آینده_شغلی #مسیر_شغلی

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

✅از شش هفته به یک روز: حلقه‌ی تازه‌ی کار مدیر محصول

این ارائه که توسط Samuel Spitz، عضو تیم فنی (Member of Technical Staff) در Replit، در رویداد AI Builder Week 2026 که ماه گذشته توسط تیم Product School برگزار شد ارائه شده، به شخصه برای من خیلی جذاب بود و به طور محوری درباره‌ی این صحبت می‌کند که هوش مصنوعی و به‌خصوص Vibe Coding چطور دارد نقش و ابزارهای روزمره‌ی مدیران محصول (Product Manager) را در دل سیلیکون‌ولی و به‌طور خاص در خود Replit دگرگون می‌کند.

اسپیتز پیش از پیوستن به Replit چند استارتاپ راه‌انداخته و با سرمایه‌ی جسورانه (Venture Capital) به سودآوری میلیونی و صدها هزار مشتری رسانده بود؛ او الان به عنوان اولین نیروی محصول اختصاصی این شرکت فعالیت می‌کند. .

🌟 چالش‌های اساسی معرفی‌شده در این ارائه:

🟡سند نیازمندی‌های محصول (PRD) در حال منسوخ‌شدن است: نوشتنش طاقت‌فرساست، جمع‌آوری اطلاعات از تیم زمان‌بر است و مهم‌تر از همه، ترجمه‌ی تصویر ذهنی محصول به متن و برگردانِ آن به محصول واقعی، فرآیندی به‌شدت ناقص (Lossy) است؛ تیمی که سند را تأیید می‌کند لزوماً همان چیزی را که در نهایت ساخته می‌شود، تأیید نکرده است.
🟡نیازمندی‌ها در طول فاز پیاده‌سازی دائم تغییر می‌کنند و پیچیدگی‌های فنی پیش‌بینی‌نشده، روند هم‌راستاسازی تیم را کند می‌کند.
🟡اکثر PMها پیش‌تر نه پس‌زمینه‌ی طراحی داشتند و نه کدنویسی، و ساخت پروتوتایپ تعاملی (Interactive Prototype) پیش از این عملاً در دسترسشان نبود.

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

🟡«مرگ PRD»: به‌جای نوشتن سند طولانی، تیم محصول ابتدا با زبان طبیعی (Natural Language) در ابزارهایی مثل Replit پروتوتایپ تعاملی می‌سازد، با تیم روی آن تکرار (Iterate) می‌کند و تازه بعد از هم‌راستایی، سند نهایی نوشته می‌شود.
🟡أ Replit Design با قابلیت تازه‌ای به نام Ambient Intelligence، طراحی را از حالت مبتنی بر پرامپت (Prompt-based) به حالت اشاره‌و-کلیک (Point-and-click) تبدیل کرده تا حتی کاربر غیرطراح هم بتواند با یک کلیک، هوش مصنوعی را در نقش دایرکتور خلاقانه (Creative Director) به کار بگیرد و نسخه‌های مختلف بصری را کاوش کند.

🟡ابزارهای داخلی (Internal Tools): با بیش از ۴۰۰ کانکتور و امکان اتصال مستقیم به منابع داده‌ی مختلف (مثل Linear)، هرکسی در سازمان -نه فقط تیم مهندسی- می‌تواند داشبورد، اتوماسیون یا ابزار گردش‌کار (Workflow) بسازد؛ چون افرادی که بیشترین دید را به گلوگاه‌های سازمان دارند، حالا خودشان می‌توانند مشکل را حل کنند.

🟡و Replit Slides: به‌جای ساخت اسلاید با فرمت‌های محدودکننده‌ی آفیس (XML)، اسلایدها را مثل یک وب‌سایت (با HTML/CSS) می‌سازد که همین باعث خلاقیت بصری بسیار بیشتری می‌شود، و در نهایت باز هم قابل خروجی‌گرفتن به‌صورت پاورپوینت یا گوگل‌ اسلایدز است. امکان ذخیره‌ی سیستم طراحی برند سازمان (Design System) برای استفاده‌ی مجدد هم وجود دارد.

🟡مسیریابی هوشمند بین چند مدل و ایجنت مختلف (مثل ایجنت طراحی و ایجنت بازبینی کد) پشت صحنه، حتی وقتی کاربر فقط یک مدل اصلی را انتخاب کرده باشد.

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

✨یک پروتوتایپ کاربردی (که قبلاً شاید هفته‌ها زمان می‌برد) امروز در کمتر از یک ساعت قابل ساخت است؛ طبق گفته‌ی اسپیتز، طراحی‌های ساده حدود ۱ تا ۱٫۵ دقیقه، اپلیکیشن‌های فول‌استک ۵ تا ۱۰ دقیقه و اسلایدها ۴ تا ۶ دقیقه زمان می‌برند.
✨تکیه بر پروتوتایپ به‌جای سند متنی، احتمال سوءتفاهم بین PM، طراح و مهندس را پایین می‌آورد و بازخورد تیم مهندسی درباره‌ی «امکان‌پذیری فنی» را زودتر در فرآیند وارد می‌کند.
✨مهارت‌هایی مثل طراحی و کدنویسی که قبلاً مخصوص متخصصان بود، حالا برای PMها هم در دسترس شده و همین باعث می‌شود جمله‌ی رایج «این کار غیرممکن یا خیلی زمان‌بر است» راحت‌تر به چالش کشیده شود.
✨فراتر از پروتوتایپینگ و ابزارهای داخلی، این‌جور ابزارها برای کارهای حاشیه‌ای هم مفیدند: از پاسخ سریع به یک درخواست داده گرفته تا تحقیق آنلاین برای Go-to-Market یا Recruiting.

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

📱 From Six Weeks to Same Day: The New PM Loop

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

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

✅مروری کوتاه به گزارش «Design Economy 2026»

گزارش «Design Economy 2026» توسط Design Council بریتانیا منتشر شده و به نظرم یکی از مهم‌ترین اسنادی است که این روزها باید در دست مدیران کسب‌وکار، سیاست‌گذاران و به‌طور خاص تصمیم‌گیران حوزه‌ی حکمرانی (governance) در کشورهایی مثل کشور ما قرار بگیرد.

چرا؟ چون این گزارش با عدد و رقم نشان می‌دهد دیزاین دیگر یک «فعالیت جانبی و صرفاً خلاقانه» نیست، بلکه یک زیرساخت اقتصادی (economic infrastructure) است:

🟡ارزش افزوده‌ی اقتصاد دیزاین در بریتانیا به ۱۳۶.۷ میلیارد پوند رسیده؛ رشدی ۴۰ درصدی نسبت به ۲۰۱۹، یعنی تقریباً دو برابر سرعت رشد کل اقتصاد بریتانیا.
🟡 بیش از ۲.۲۷ میلیون نفر در این اکوسیستم مشغول به کارند و سهم اشتغال دیزاین از کل اشتغال کشور به ۶.۲٪ رسیده.
🟡 دو سوم این ارزش اقتصادی نه از «صنایع دیزاینی»، بلکه از حضور دیزاینرها در صنایعی مثل سلامت، مالی، تولید و بخش عمومی ایجاد شده؛ یعنی دیزاین وقتی بیشترین ارزش را خلق می‌کند که در قلب تصمیم‌سازی سازمان‌ها و نهادها بنشیند، نه در حاشیه‌ی آن.
🟡صادرات خدمات دیزاین ۱۷٪ از کل صادرات خدماتی بریتانیا را تشکیل می‌دهد؛ رقمی معادل حدود سه‌چهارم ارزش صادرات خدمات مالی این کشور.

🟡طراحی دیجیتال (Digital Design) بزرگ‌ترین و پررشدترین حوزه‌ی طراحی در این گزارش است، ارزش تولیدی‌اش (GVA) از ۵۳.۹ میلیارد پوند در ۲۰۱۹ به ۸۱ میلیارد پوند در ۲۰۲۳ رسیده (۵۰٪ رشد)، و بیش از ۱ میلیون نفر (۴۸٪ کل شاغلان اقتصاد دیزاین) در این حوزه کار می‌کنند.

🟡۷۶٪ طراحان دیجیتال بیرون از «صنایع دیزاین» کار می‌کنن (یعنی داخل شرکت‌های فناوری، بانکی، سلامت و…) نه در استودیوهای دیزاین، این با روند in-house شدن طراحی محصول همخونی دارد.

🟡در این گزارش فعلا اشاره‌ای به تأثیر منفی AI بر مشاغل دیزاین نکرده است، اما هشدار می‌دهد که ممکنه در آینده تغییر کند، و در کیس Lloyds ذکر شده در گزارش هم آگاهانه سعی می‌کنند رویکردهای انسان‌محور کلاسیک رو با AI ترکیب کنند.

اما بخشی که واقعاً من رو تحت تأثیر قرار داد، آمار رشد نبود، اینکه چه کسانی از این آمار جا مانده‌اند.

زنان هنوز فقط ۲۵٪ از نیروی کار دیزاین را تشکیل می‌دهند، تقریباً بدون تغییر از سال ۲۰۲۰. با این حال، هرجا که حضور دارند، تقریباً به همان نرخ مردان به نقش‌های مدیریتی می‌رسند (۲۰٪ در برابر ۲۲٪ در سطح مدیریت). این یک شکاف در توانمندی نیست. یک شکاف در دسترسی (access) است و ارزش تأمل دارد.


☑️نکته‌ای که پروفسور Mariana Mazzucato در این گزارش مطرح می‌کند برایم کلیدی است: دیزاین امروز صرفاً یک بخش تولیدی دیگر نیست، بلکه قابلیتی راهبردی (strategic capability) است که شیوه‌ی حکمرانی فناوری، عملکرد نهادها و توسعه‌ی مکان‌ها را شکل می‌دهد.

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

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

🔖یادداشت کوتاه من:
این گزارش به شخصه برای من بسیار خواندنی و جذاب بود.
شخصا معتقدم مستندسازی از این دست، حافظه‌ی نهادی یک حوزه تخصصی (همچون دیزاین) است؛ و همان‌طور که این گزارش نشان می‌دهد، در حالی‌که ارزش اقتصادی و اجتماعی دیزاین روزبه‌روز شفاف‌تر اثبات می‌شود، جای گزارش‌های داده‌محور و مستدل از این دست (Evidence-based Reporting) در میان مستندات حوزه‌ی دیزاین (به‌ویژه در سطح ملی) همچنان به‌شدت خالی است.

#DesignEconomy #DesignLeadership #Design #Report
#حکمرانی_دیزاین #دیزاین #گزارش #اقتصاد_دیزاین

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

✅لیست کاربردی وبسایت‌های مفید برای طراحان محصول دیجیتال

مجموعه‌ای از بهترین ابزارها و منابع (اکثراً رایگان یا با نسخه‌ی رایگان) که هر روز می‌تونن به کارتون بیان 👇

🔍 ریسرچ و تحقیق کاربر (UX Research)

Maze — تست یوزیبیلیتی سریع روی پروتوتایپ‌ها
Useberry — تست تعاملی و ضبط رفتار کاربر
UserTesting — دسترسی به کاربران واقعی برای تست
Google Forms — طراحی پرسش‌نامه و نظرسنجی رایگان
Typeform — ساخت فرم و نظرسنجی با تجربه‌ی کاربری بهتر
SurveyMonkey — تحلیل داده‌های نظرسنجی
Hotjar — heatmap و ضبط رفتار کاربران روی سایت

✏️ وایرفریم و پروتوتایپ (Wireframing & Prototyping)

Figma — طراحی، پروتوتایپ و همکاری تیمی (استاندارد صنعت)
Balsamiq — وایرفریم سریع و low-fidelity
Whimsical — وایرفریم، فلوچارت و ذهن‌نگاره در کنار هم
Excalidraw — اسکچ سریع و دست‌نویس‌مانند برای ایده‌پردازی
Marvel — پروتوتایپ ساده و سریع بدون کد

🎨 الهام و رفرنس بصری (Inspiration)

Dribbble — گالری کارهای طراحان برای الهام‌گیری
Behance — نمونه‌کار و پروژه‌های کامل طراحی
Mobbin — رفرنس واقعی از اپ‌های موبایل و وب
Land-book — گالری لندینگ‌پیج‌های الهام‌بخش
Screenlane — رفرنس تعامل و انیمیشن UI
SaaS Landing Page — رفرنس صفحات فرود محصولات SaaS
UI Sources — کالکشن الگوهای UI واقعی

🧩 دیزاین سیستم‌ها (Design Systems)

Material Design (Google) — راهنمای کامل سیستم طراحی گوگل
Human Interface Guidelines (Apple) — استاندارد طراحی اپل
Atlassian Design System — نمونه‌ی یک سیستم طراحی سازمانی
Design Systems Repo — آرشیو بزرگی از سیستم‌های طراحی شرکت‌های مختلف

🖼 آیکون و illustration

Flaticon — آیکون‌های رایگان و متنوع
Iconify — دسترسی به هزاران ست آیکون یکجا
unDraw — تصویرسازی رایگان و قابل تغییر رنگ
Humaaans — تصویرسازی انسانی قابل ترکیب
Blush — تصویرسازی سفارشی‌سازی‌شده و رایگان

📷 عکس و تصویر استوک (Stock Photos)

Unsplash — عکس‌های استوک باکیفیت و رایگان
Pexels — عکس و ویدیوی رایگان بدون کپی‌رایت
Pixabay — عکس، ویدیو و وکتور رایگان

🎨 رنگ و پالت (Color)

Coolors — ساخت سریع پالت رنگی
Adobe Color — استخراج و ساخت پالت از تصویر
Realtime Colors — تست زنده‌ی پالت روی نمونه رابط کاربری
Contrast Checker (WebAIM) — بررسی کنتراست رنگ برای دسترسی‌پذیری

🔤 تایپوگرافی و فونت (Typography & Fonts)

Google Fonts — فونت‌های رایگان برای وب
Fontshare — فونت‌های مدرن و رایگان با کیفیت بالا
Type Scale — محاسبه‌ی مقیاس تایپوگرافی
فونت ایران — منبع فونت‌های فارسی

♿️ دسترسی‌پذیری (Accessibility)

WebAIM — راهنما و ابزارهای ارزیابی دسترسی‌پذیری
A11y Project — چک‌لیست‌ها و منابع آموزشی دسترسی‌پذیری
Stark — پلاگین فیگما برای بررسی کنتراست و دسترسی‌پذیری

🤖 ابزارهای هوش مصنوعی برای طراحی (AI for Design)

Galileo AI — تولید UI اولیه از روی توضیح متنی
Uizard — تبدیل اسکچ یا متن به طرح رابط کاربری
Khroma — پیشنهاد پالت رنگی بر اساس سلیقه‌ی شما
Remove.bg — حذف خودکار بک‌گراند تصاویر

🔗 هندآف و همکاری با تیم فنی (Handoff & Collaboration)

Zeplin — تحویل دقیق مشخصات طراحی به تیم توسعه
Figma Dev Mode — بررسی مستقیم کد و مشخصات در خود فیگما
Notion — مستندسازی پروژه و هماهنگی تیمی

📚 یادگیری و منابع آموزشی (Learning)

Laws of UX — اصول روان‌شناسی کاربردی در طراحی
NN/g (Nielsen Norman Group) — مقالات معتبر UX Research
Growth.Design — آموزش UX از طریق قصه و کیس‌استادی
Refactoring UI — نکات عملی برای بهتر شدن UI

💼 پورتفولیو و شبکه‌سازی (Portfolio & Networking)

Readymag — ساخت پورتفولیوی خلاقانه بدون کد
Notion (به عنوان پورتفولیو) — ساخت سریع صفحه‌ی معرفی کار
ADPList — دریافت منتورشیپ رایگان از طراحان باتجربه

#طراحی_محصول #ابزار #منابع #ToolBox

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

✅دیزاین سیستمی که می‌تونید بهش اعتماد کنید

سال‌هاست که در حوزه دیزاین سیستم (design system) کار می‌شه و همیشه با یک سری مشکل تکراری روبه‌رو می‌شیم: رمپ‌های رنگی (color ramps) که دستی و با آزمون و خطا ساخته می‌شن، تم‌هایی که به‌طور خاموش کنتراست (contrast) رو نقض می‌کنن، توکن‌هایی (tokens) که بین فیگما و ریپو دچار انحراف (drift) می‌شن، و دستیارهای هوش مصنوعی که چون هیچ منبع مشخصی از سیستم ندارن، مجبورن مقادیر هگز (hex) رو از خودشون بسازن.

Escala Tokens دقیقاً برای حل همین مشکلات ساخته شده؛ ابزاری که یک دیزاین سیستم قابل‌اعتماد تولید می‌کنه:

🟡رمپ‌های رنگی که بر اساس دسترس‌پذیری (accessibility) محاسبه می‌شن، نه با چشم تنظیم
🟡 تم‌هایی که به پریمیتیوها (primitives) ارجاع می‌دن، نه اینکه کپی‌شون کنن
🟡 خروجی‌هایی که دقیقاً همون‌جایی می‌شینن که باهاش کار می‌کنید: فیگما، ریپوی خودتون، توکن‌های استاندارد W3C، و CSS

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

همه‌مون این روزها سریع‌تر از همیشه می‌سازیم؛ فقط باید مطمئن بشیم روی چیزی می‌سازیم که پایه محکمی داره.

فعلاً به گفته سازنده اش Cesar Durango در مرحله بتا (beta) هست.

https://escalatokens.com/

#دستیار_هوش_مصنوعی #دیزاین_سیستم #ابزار #دسترسی_پذیری

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

✅ طراحان تجربه فارسی‌زبان، روی یک نقشه

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

🗺این نقشه برای همه‌ی ماست، فرقی نمی‌کنه کدوم نقش رو داشته باشید:

طراح رابط کاربری • طراح تجربه کاربری • طراح UI/UX • طراح محصول • پژوهشگر تجربه کاربری • طراح دیزاین سیستم • طراح تعامل • نویسنده تجربه کاربری • طراح خدمات • متخصص دسترس‌پذیری • استراتژیست تجربه کاربری • طراح تجربه هوش مصنوعی و ایجنت • طراح تجربه کارکنان • طراح تجربه مشتری • طراح تجربه یادگیری • توسعه‌دهنده و برنامه‌نویس • و هر نقش دیگه‌ای که با تجربه سروکار داره

چیزی که این ایده رو برام جذاب کرد، اینه که جای خالیش واقعاً حس می‌شد. ما یه جامعه‌ی بزرگ، رو به رشد و پراکنده‌ایم که توی شهرهای مختلف ایران (و با مهاجرت خیلی‌هامون) کشورهای مختلف کار می‌کنیم، ولی هیچ‌وقت تصویر روشنی از خودمون نداشتیم: کجاییم، چند نفریم، کی نزدیک‌مونه!

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

به نظرم هرچی نقشه پرتر بشه، ارزشش برای همه‌مون بیشتر می‌شه و در آینده هم قراره چیزهای بیشتری بهش اضافه بشه .

خودتون رو ثبت کنید و برای دوست‌ها و همکارهاتون هم بفرستید که اونا هم اضافه بشن!
💎 https://persianuxmap.com/

❤️این یک تبلیغ نیست، یک حمایت دوستانه از سوده دیزاین است. حمایت از فعالیت‌های ارزشمند جامعه دیزاین، را فراموش نکنیم.

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

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

✅رهبری طراحی خدمات (Service Design Leadership)

رهبری در طراحی خدمات شکل‌های متفاوتی دارد. گاهی بخشی از عنوان شغلی رسمی شماست و سازمان آگاهانه آن را از شما انتظار دارد، و گاهی نقشی است که خودتان در نبودِ هر حمایت رسمی به عهده گرفته‌اید. ممکن است تیمی از متخصصان کاربرمحور (User-Centred Practitioners) را هدایت کنید، یا در جایگاهی مسئول ارائه‌ی یک خدمت یا برنامه (Service / Program Delivery) باشید.

💎نقش رهبری طراحی خدمات در کسب‌وکارها

در بسیاری از کسب‌وکارها، تجربه‌ی مشتری حاصل کار ده‌ها تیم جداست: فروش، پشتیبانی، عملیات، فناوری و مالی. هر کدام بخش خودشان را بهینه می‌کنند، اما کسی مسئول «کل خدمت» از نگاه مشتری نیست. رهبر طراحی خدمات دقیقاً همین شکاف را پر می‌کند. او با دیدن خدمت به‌صورت یک سیستم یکپارچه (End-to-End)، فاصله‌ی میان استراتژی و اجرا، و میان تجربه‌ی مشتری (Front-stage) و فرایندهای پشت صحنه (Back-stage) را کم می‌کند. ارزش او برای کسب‌وکار فقط بهبود چند نقطه‌ی تماس (Touchpoint) نیست؛ او بر ساختارها، بودجه، شیوه‌ی تصمیم‌گیری و فرهنگ سازمان اثر می‌گذارد تا خدمات بهتر نه یک پروژه‌ی مقطعی، بلکه نتیجه‌ی طبیعیِ نحوه‌ی کار سازمان باشد. نتیجه‌ی این نقش در عمل، کاهش هزینه‌های ناشی از خطا و دوباره‌کاری، افزایش وفاداری مشتری و سرعت بیشتر در پاسخ به تغییرات بازار است.

طراحان و رهبران فعال این حوزه می‌توانند در چهار تیپ رهبری دسته‌بندی شوند:

🟡 رهبر ایده (Idea Leader): با روایت و استراتژیِ الهام‌بخش، سازمان را به سمت خدمات بهتر هل می‌دهد.
🟡 رهبر فنی (Technical Leader): مشاوره‌ی قابل‌اتکا درباره‌ی بهترین شیوه‌ی طراحی و ارائه‌ی خدمت می‌دهد.
🟡 رهبر افراد (People Leader): جامعه‌ای از طراحان، پژوهشگران و مدیران محصول را حمایت و توانمند می‌کند.
🟡 رهبر اجرا (Delivery Leader): طراحی یا اجرای یک خدمت یا کل یک برنامه را مدیریت می‌کند.

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

💎 دو باور غلط رایج:
۱. رهبری صرفاً حاصل گذر زمان و تجربه است. (نه؛ مهارتی است که باید آموخت.)
۲. با رسیدن به رهبری، کار از ۱۰۰٪ طراحی به ۱۰۰٪ مدیریت تغییر می‌کند. (نه؛ شما هنوز طراحی می‌کنید، فقط متریال طراحی‌تان عوض می‌شود.)

⚡️ هشت حوزه‌ای که رهبر طراحی خدمات «دیزاین» می‌کند:

🟡حاکمیت (Governance): شیوه‌ی تصمیم‌گیری
🟡مالی (Finance): اینکه پول کجا و چطور خرج شود
🟡ساختار (Structures): نقش‌ها و خطوط گزارش‌دهی
توانمندی (Capability): مهارت تیم‌ها و سازمان
🟡ذهنیت (Mindset): روحیه، باورها و انگیزه‌های بلندمدت
🟡حقوقی (Legal): تعامل با قوانین برای ممکن کردن کار بهتر
🟡سیاست و استراتژی (Policy & Strategy)
🟡خدمات (Services): هدایت فنی و استراتژیک طراحی خدمت

رهبر طراحی خدمات همیشه بین تغییرِ عملگرایانه‌ی کوتاه‌مدت و ساختن شرایط بلندمدت برای رشد طراحی خدمات در تعادل است.


#رهبری #طراحی_خدمات #کسب_و_کار

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

✅کلاف سردرگم (Big Ball of Mud) جدید: چرا سیستم‌های ایجنتیک ما شکننده می‌شوند؟

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

امروز داشتم طبق عادت چندین ساله، یک مقاله جدید را قبل از شروع کار مطالعه میکردم و به مقاله جدیدی رسیدم، NN/g در مطالعه‌ای روی کاربران حرفه‌ای AI الگویی آشنا پیدا کرده است. این کاربران معمولاً پیش‌زمینه فنی ندارند و برای کار روزانه‌شان سیستم‌های پیچیده‌ای با ایجنت و کانتکست می‌سازند. NN/g به آن‌ها «معماران وایب» (Vibe Architects) می‌گوید. الگویی که در کارشان دیده شد «کلاف سردرگم» است: سیستمی که سرهم شده تا امروز کار کند، نه این‌که سال‌ها دوام بیاورد.

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

💎 پنج الگویی که در این مطالعه دیده میشه:

۱. کد دورریختنی (Throwaway Code): یک پیش‌نویس سریع، مثلاً یک فایل rules.md، هیچ‌وقت بازنگری نمی‌شود، اما کل گردش‌کار کم‌کم به آن وابسته می‌شود.
۲. رشد وصله‌پینه‌ای (Piecemeal Growth): یک ویجت ساده آرام‌آرام به داشبورد سازمانی تبدیل می‌شود و هیچ‌وقت به نقطه «تمام‌شده» نمی‌رسد.
۳. فقط کار کند (Keep It Working): وقتی سیستم خراب می‌شود، وصله‌اش می‌کنیم و به AI می‌گوییم «هر جا لازم است درستش کن». کم‌کم دیگر نمی‌دانیم چه چیزی کجاست.
۴. زیر فرش جارو کردن (Sweeping It Under the Rug): پوشه‌هایی شبیه کشوی خرت‌وپرت درست می‌شوند که فقط AI می‌تواند چیزی در آن‌ها پیدا کند.
۵. بازسازی (Reconstruction): این مرحله وقتی می‌رسد که سیستم دیگر به نیاز نمی‌خورد، دیگر کسی آن را نمی‌فهمد، یا روش بهتری برای انجام همان کار پیدا شده است.

پ.ن: سعی کردم ترجمه فارسی خوبی براش بنویسیم😃

🌐 یک تست ساده:
اگر بخواهیم رفتار سیستم‌مان را تغییر دهیم، می‌دانیم کدام بخش از کانتکست را باید عوض کنیم؟
اگر جواب «نه» است، AI تنها کسی است که سر کلاف را پیدا می‌کند و ما فقط امیدواریم که سیستم نشکند.

☑️چند عادت کوچک تا کلاف سردرگم نشود:

سه نوع کانتکست را از هم جدا نگه داریم:
◦ سراسری (Global): چیزهایی که برای کل سیستم صدق می‌کنند.
◦ موضعی (Local): چیزهایی که به یک پروژه یا تسک خاص مربوط‌اند.
◦ محیطی (Ambient): جریان‌هایی مثل ایمیل و اسلک که در دسترس AI هستند.
هنگام درخواست تغییر، نوع کانتکست را نام ببریم، به‌جای این‌که بگوییم «هر جا فکر می‌کنی درستش کن».
کانتکست سراسری را هر از گاهی از اول تا آخر مرور کنیم. باید آن‌قدر کوتاه باشد که در یک نشست خوانده شود.
وقتی کیفیت خروجی‌ها افت کرد، کانتکست موضعی را به‌روز کنیم.

💎 از نگاه طراحی محصول می‌توانیم اینطور به این موضوع نگاه کنیم:
این همان بدهی طراحی و فنی (Design/Tech Debt) آشناست، این بار در سیستم شخصی خودمان. ساختن ارزان شده، اما فهمیدن سیستم ارزان نشده است. هدف این نیست که هیچ‌وقت سیستم را از نو نسازیم. هدف این است که وقتی زمانش رسید، خودمان این بازسازی را هدایت کنیم، نه AI. مهم‌ترین انضباط هم پوشه‌های مرتب نیست، بلکه بازاندیشی دوره‌ای است: هر بخش چه کاری می‌کند، هنوز از آن استفاده می‌کنیم یا نه، و اگر از صفر شروع می‌کردیم چه چیزی را جور دیگری می‌ساختیم.

☑️دوست داشتید مقاله کامل را از اینجا مطالعه کنید
https://www.nngroup.com/articles/big-ball-of-mud-ai/


#ProductDesign #AgenticAI #ContextEngineering
#AgenticAIExperienceDesign #AgentExperienceDesign #AX
#طراحی_محصول #هوش_مصنوعی #طراحی_تجربه_ایجنت

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