SODΞH DΞSIGN

✅وقتی ساختن محصول با AI آسان‌تر شده، مزیت رقابتی کجاست؟ با ورود ابزارهای هوش مصنوعی، ساخت پروتوتایپ و توسعه نرم‌افزار سریع‌تر و ارزان‌تر شده است. اما این به معنای آسان‌تر شدن ساخت یک محصول موفق نیست. ⭐️چند نکته مهم درباره طراحی و توسعه محصولات AI: 🟡پروتوتایپ، محصول نهایی نیست. ساخت یک نمونه اولیه جذاب با AI ساده‌تر شده، اما تبدیل آن به محصولی پایدار، قابل اعتماد و آماده استفاده در دنیای واقعی همچنان به تصمیم‌های فنی و طراحی جدی نیاز دارد. 🟡 برای همه طراحی نکنید. به‌جای تلاش برای جذب تمام کاربران، یک گروه مشخص را انتخاب کنید و نیازهای واقعی آن‌ها را عمیق‌تر بشناسید. تمرکز روی یک مسئله مشخص می‌تواند مزیتی ایجاد کند که تقلید از آن دشوارتر است. 🟡عمق راهکار از تعداد قابلیت‌ها مهم‌تر است. اضافه‌کردن قابلیت‌های بیشتر یا استفاده از مدل‌های پیشرفته‌تر، لزوماً محصول بهتری نمی‌سازد. حل دقیق یک مسئله در بستر گردش کار واقعی کاربر، ارزش بیشتری ایجاد می‌کند. 🟡 زیرساخت، مزیتی است که ممکن است دیرتر دیده شود. بعضی فرصت‌های بزرگ محصولی، نتیجه سرمایه‌گذاری‌های بلندمدت روی فناوری و زیرساخت‌هایی هستند که در ابتدا کاربرد تجاری مشخصی ندارند. توانایی تشخیص و بهره‌برداری از این ظرفیت‌ها می‌تواند مسیر رشد یک کسب‌وکار را تغییر دهد. 🟡رشد سریع با موفقیت پایدار متفاوت است. افزایش سریع درآمد یا تعداد کاربران فقط بخشی از تصویر است. حفظ مشتری، هزینه ارائه خدمات، کیفیت تجربه و توانایی ایجاد ارزش مستمر، تعیین می‌کنند که یک محصول تا چه اندازه می‌تواند دوام بیاورد. 🟡با عمومی‌شدن AI، محل رقابت تغییر می‌کند. وقتی ابزارها و مدل‌های قدرتمند در دسترس افراد و شرکت‌های بیشتری قرار می‌گیرند، صرف استفاده از AI دیگر تمایز کافی نیست. شناخت حوزه تخصصی، کیفیت تجربه کاربری، یکپارچگی با گردش کار و ارزش واقعی برای مشتری اهمیت بیشتری پیدا می‌کنند. 💎این تغییر چه معنایی برای طراحان محصول دارد؟ ارزش طراح دیگر صرفاً در توانایی تبدیل ایده به صفحه، وایرفریم یا پروتوتایپ نیست. ⚡️ارزش اصلی در توانایی‌های زیر شکل می‌گیرد: ☑️ تشخیص مسئله‌ای که واقعاً ارزش حل‌کردن دارد. ☑️شناخت عمیق کاربران و زمینه استفاده از محصول. ☑️طراحی گردش کار متناسب با نیازهای واقعی. ☑️تبدیل خروجی AI به تجربه‌ای قابل اعتماد و قابل استفاده. ☑️اتصال تصمیم‌های طراحی به اهداف کسب‌وکار. ☑️ایجاد تمایز فراتر از قابلیت‌های عمومی ابزارهای هوش مصنوعی. ✨ به نظرم نکته مهم این است که هرچه ساختن محصول آسان‌تر شود، کیفیت تصمیم‌گیری درباره اینکه چه چیزی، برای چه کسی و چرا باید ساخته شود، اهمیت بیشتری پیدا می‌کند. در عصر AI، مزیت رقابتی فقط در سرعت ساخت نیست؛ در انتخاب مسئله درست و خلق ارزش متمایز است. به نظرم حتی با آمدن هوش مصنوعی و سونامی ساخت ابزارها و محصولات هوش مصنوعی، بار دیگر باید کتاب تست مامان را بازخوانی کنیم😁️️️️️️ #هوش_مصنوعی #طراحی_محصول #مدیریت_محصول #حل_مسئله 🫶 @SodehDesign | @SodehTransform ☝️ Sodeh.me ⚙️ https://linktr.ee/irSodeh

✅ا Figma Agent؛ از نسخه آزمایشی خارج شد فیگما اخیراً Figma Agent را از مرحلهٔ آزمایشی خارج کرده و برای کاربران (غیر رایگان) در دسترس قرار داده است. این ابزار هوش مصنوعی مستقیماً درون محیط طراحی کار می‌کند و به شما کمک می‌کند تا در جریان کار باقی بمانید. 💎 اما Figma Agent چیست؟ یک دستیار هوشمند است که درست در کنار شما، درون بوم رسم فیگما (Canvas) کار می‌کند. برخلاف ابزارهای چت معمول، این Agent واقعاً متوجه جریان کار شما است و با شما همکاری می‌کند. 💎کارهایی که انجام می‌دهد: 🟡ویرایش و بهبود طراحی‌ها: تغییر المان‌های طراحی و بهینه‌سازی لایه‌ها 🟡ایجاد نسخه‌های جدید: کاوش ایده‌های متنوع و راهکارهای مختلف 🟡استفادهٔ خودکار از معیارهای طراحی: اعمال خودکار Components و استانداردهای تیمی شما 🟡ادغام بازخورد: جمع‌آوری نظرات و بهبود طراحی بر اساس آنها 🟡حذف کارهای تکراری: خودکارسازی کارهایی که هر روز تکرار می‌شود قابلیت‌های پیشرفته 🟡ایجاد ابزارهای سفارشی: بدون نیاز به برنامه‌نویسی، می‌توانید از Agent بخواهید ابزارهایی بسازد که نیاز تیم شما را برطرف کند (مثلاً وارد کردن HTML یا ایجاد طرح‌بندی برای داشبورد). 🟡جلوه‌های بصری پیشرفته: ایجاد افکت‌های زیبای طراحی صرفاً با دستورات متنی، بدون خستگی‌ناپذیر تنظیمات دستی. 🟡درک بهتر سیاق: می‌توانید اسناد تحقیق، متون محصول، و حتی فایل‌های Figma دیگر را به گفتگو اضافه کنید تا Agent بهتر بفهمد منظور شما چیست. 🌱نکته مهم: Figma Agent تنها برای کاربران این طرح‌های پولی در دسترس است و کاربران پلن رایگان (Free Plan) به این ابزار دسترسی ندارند. 💎چرا این بهتر است؟ Agent نه‌تنها یک ابزار هوشمند است؛ بلکه متوجه Design System و منطق کارکردی تیم شما است. شما و Agent می‌توانید به‌طور هم‌زمان روی یک پروژه کار کنید و یکدیگر را تکمیل کنید. در حالی‌که شما بر روی تصمیم‌های حیاتی تمرکز می‌کنید، Agent کارهای ساده و تکراری را بر عهده می‌گیرد. #هوش_مصنوعی #طراحی_محصول #فیگما 🫶 @SodehDesign ☝️ Sodeh.me ⚙️ https://linktr.ee/irSodeh

📣 آغاز پذیرش چهارمین دوره مدیریت حرفه‌ای کسب‌وکار با گرایش دیزاین دانشگاه تهران ✅آخرین مرحله اخذ پذیرش با افزایش محدود ظرفیت این دوره با تمرکز بر مدیریت، دیزاین و کسب‌وکار و با رویکردی تجربه‌محور برگزار می‌شود و در دوره چهارم، توجه ویژه‌ای به کاربردهای هوش مصنوعی در کسب‌وکار و مدل‌های کسب‌وکار جدید و تاب‌آور در شرایط بحران خواهد شد. 🟢 مهم‌ترین ویژگی‌های دوره: 🟡 شبکه‌سازی حرفه‌ای و شکل‌گیری ارتباطات کاری مؤثر 🟡 آموزش بین‌رشته‌ای، مبتنی بر نقد، گفتگو و یادگیری جمعی 🟡 انتقال تجربه‌های عملی طراحان، معماران، کارآفرینان و اساتید شاخص داخلی و بین‌المللی 🟡امکان حضور حضوری، آنلاین یا ترکیبی از سراسر ایران و جهان 🟡 اعطای مدرک معتبر دوره جامع «مدیریت حرفه‌ای کسب‌وکار با گرایش دیزاین» دانشگاه تهران 📅 شروع دوره: ۲۳ مهرماه ۱۴۰۵ ✔️این دوره تنها یک‌بار در سال برگزار می‌شود. ☑️ متقاضیان می‌توانند برای بررسی در کمیته پذیرش، پورتفولیو و سوابق کاری و حرفه‌ای خود را از طریق تلگرام، واتس‌اپ یا بله ارسال کنند: 📲 09001160230 📱 @DesignMBA 📱 @ut.design.mba #دوره_آموزشی #دیزاین #دانشگاه_تهران #ADV

✅چک لیست: قبل از اینکه AI را وارد ساخت محصول کنید یکی از نکات مهمی که در اپیزود اخیر پادکست AI Product Leader (که امروز صبح گوش دادم) مطرح شد، این بود که سرعت ساخت محصول با AI نباید ما را از Product Thinking دور کند. امروز با ابزارهایی مثل Coding Agents می‌توانیم در مدت بسیار کوتاهی یک محصول یا Feature بسازیم. اما مسئله اصلی دیگر این نیست که «چقدر سریع می‌توانیم بسازیم؟» 💎مسئله این است: آیا داریم چیز درستی را می‌سازیم؟ در Product Development سنتی، مسیر معمولاً چیزی شبیه این است: Problem → Research → Decision → Design → Engineering → Ship اما در AI-native Product Development، بخش زیادی از implementation می‌تواند توسط Agentها انجام شود. بنابراین ارزش تصمیم‌هایی که قبل از ساخت گرفته می‌شوند، بیشتر می‌شود. قبل از اینکه از AI بخواهیم چیزی بسازد، باید مشخص کنیم: 🟡دقیقاً چه مسئله‌ای را حل می‌کنیم؟ 🟡ا Outcome مورد انتظار چیست؟ 🟡 ا Happy Path چیست؟ 🟡اگر AI اشتباه کند چه اتفاقی می‌افتد؟ 🟡ا Worst-case scenario چیست؟ 🟡ا Edge Caseها کدام‌اند؟ 🟡محصول حداقلیِ قابل‌استفاده و ارزشمند ما چیست؟ 🟡خروجی AI چگونه باید Review و Test شود؟ 🟡در کدام تصمیم‌ها همچنان Human باید مسئول نهایی باشد؟ 💎نکته مهم دیگر این است که AI-generated ≠ production-ready. هوش مصنوعی می‌تواند کد تولید کند، تست بنویسد، راه‌حل پیشنهاد دهد و iteration را سریع‌تر کند؛ اما همچنان باید کیفیت، امنیت، reliability و پیامدهای تصمیم‌ها بررسی شوند. در واقع، با قدرتمندتر شدن AI، نقش Product Manager و Designer لزوماً کوچک‌تر نمی‌شود؛ بخش مهمی از کار آنها از ساختن مستقیم به سمت تعریف مسئله، تعیین محدودیت‌ها، طراحی سیستم تصمیم‌گیری و ارزیابی خروجی Agentها حرکت می‌کند. 🌱چک‌لیست کوتاه این فرایند را در فایل پیوست گذاشته‌ام. #هوش_مصنوعی #طراحی_محصول #مدیریت_محصول 🫶 @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

✅رهبری طراحی خدمات (Service Design Leadership) رهبری در طراحی خدمات شکل‌های متفاوتی دارد. گاهی بخشی از عنوان شغلی رسمی شماست و سازمان آگاهانه آن را از شما انتظار دارد، و گاهی نقشی است که خودتان در نبودِ هر حمایت رسمی به عهده گرفته‌اید. ممکن است تیمی از متخصصان کاربرمحور (User-Centred Practitioners) را هدایت کنید، یا در جایگاهی مسئول ارائه‌ی یک خدمت یا برنامه (Service / Program Delivery) باشید. مدرسه‌ی Good Services پیش از راه‌اندازی دوره‌ای برای رهبران طراحی خدمات، ابتدا باید به همین پرسش پاسخ می‌داد؛ برای همین با شرکت‌کنندگان دوره‌های مقدماتی درباره‌ی آرزوهای شغلی‌شان و با رهبران باتجربه درباره‌ی نقش‌هایی که امروز ایفا می‌کنند گفت‌وگو کرد. حاصل این گفت‌وگوها، شناسایی چهار تیپ رهبری بود: 💎نقش رهبری طراحی خدمات در کسب‌وکارها در بسیاری از کسب‌وکارها، تجربه‌ی مشتری حاصل کار ده‌ها تیم جداست: فروش، پشتیبانی، عملیات، فناوری و مالی. هر کدام بخش خودشان را بهینه می‌کنند، اما کسی مسئول «کل خدمت» از نگاه مشتری نیست. رهبر طراحی خدمات دقیقاً همین شکاف را پر می‌کند. او با دیدن خدمت به‌صورت یک سیستم یکپارچه (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

✅ طراحان تجربه فارسی‌زبان، روی یک نقشه یه پروژه‌ی جالب و عمومی جدیدا لانچ شده که طراح‌های تجربه‌ی فارسی‌زبان، از داخل ایران تا هر گوشه‌ی دنیا، می‌تونن خودشون رو روی نقشه‌ی جهان ثبت کنن 🌍 🗺این نقشه برای همه‌ی ماست، فرقی نمی‌کنه کدوم نقش رو داشته باشید: طراح رابط کاربری • طراح تجربه کاربری • طراح UI/UX • طراح محصول • پژوهشگر تجربه کاربری • طراح دیزاین سیستم • طراح تعامل • نویسنده تجربه کاربری • طراح خدمات • متخصص دسترس‌پذیری • استراتژیست تجربه کاربری • طراح تجربه هوش مصنوعی و ایجنت • طراح تجربه کارکنان • طراح تجربه مشتری • طراح تجربه یادگیری • توسعه‌دهنده و برنامه‌نویس • و هر نقش دیگه‌ای که با تجربه سروکار داره چیزی که این ایده رو برام جذاب کرد، اینه که جای خالیش واقعاً حس می‌شد. ما یه جامعه‌ی بزرگ، رو به رشد و پراکنده‌ایم که توی شهرهای مختلف ایران (و با مهاجرت خیلی‌هامون) کشورهای مختلف کار می‌کنیم، ولی هیچ‌وقت تصویر روشنی از خودمون نداشتیم: کجاییم، چند نفریم، کی نزدیک‌مونه! ✨ چرا ارزش داره ثبت کنید: 🟡 شبکه‌سازی: پیدا کردن هم‌زبان‌هایی که تو شهر یا کشور شما کار می‌کنن 🟡 شناخت جامعه: دیدن اینکه طراح‌های فارسی‌زبان کجای دنیا پخش شدن 🟡دیده شدن: کنار بقیه‌ی همکارها، روی نقشه‌ای که مال همه‌ست 🟡 پروژه‌ی عمومی: برای جامعه‌ست و با حضور همین جامعه کامل می‌شه 🟡و حتی در آینده گزارش‌های وضعیت کاری، فعالیت‌ها و.. این حوزه به نظرم هرچی نقشه پرتر بشه، ارزشش برای همه‌مون بیشتر می‌شه و در آینده هم قراره چیزهای بیشتری بهش اضافه بشه . خودتون رو ثبت کنید و برای دوست‌ها و همکارهاتون هم بفرستید که اونا هم اضافه بشن! 💎 https://persianuxmap.com/ ❤️این یک تبلیغ نیست، یک حمایت دوستانه از سوده دیزاین است. حمایت از فعالیت‌های ارزشمند جامعه دیزاین، را فراموش نکنیم. #طراحی_محصول #طراحی_خدمات #حمایت #پروژه عمومی 🫶 @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

✅لیست کاربردی وبسایت‌های مفید برای طراحان محصول دیجیتال مجموعه‌ای از بهترین ابزارها و منابع (اکثراً رایگان یا با نسخه‌ی رایگان) که هر روز می‌تونن به کارتون بیان 👇 🔍 ریسرچ و تحقیق کاربر (UX Research) Maze — تست یوزیبیلیتی سریع روی پروتوتایپ‌ها Useberry — تست تعاملی و ضبط رفتار کاربر UserTesting — دسترسی به کاربران واقعی برای تست Google Forms — طراحی پرسش‌نامه و نظرسنجی رایگان Typeform — ساخت فرم و نظرسنجی با تجربه‌ی کاربری بهتر SurveyMonkey — تحلیل داده‌های نظرسنجی Hotjar — heatmap و ضبط رفتار کاربران روی سایت ✏️ وایرفریم و پروتوتایپ (Wireframing & Prototyping) Figma — طراحی، پروتوتایپ و همکاری تیمی (استاندارد صنعت) Balsamiq — وایرفریم سریع و low-fidelity Whimsical — وایرفریم، فلوچارت و ذهن‌نگاره در کنار هم Excalidraw — اسکچ سریع و دست‌نویس‌مانند برای ایده‌پردازی Marvel — پروتوتایپ ساده و سریع بدون کد 🎨 الهام و رفرنس بصری (Inspiration) Dribbble — گالری کارهای طراحان برای الهام‌گیری https://dribbble.com Behance — نمونه‌کار و پروژه‌های کامل طراحی https://www.behance.net Mobbin — رفرنس واقعی از اپ‌های موبایل و وب https://mobbin.com Land-book — گالری لندینگ‌پیج‌های الهام‌بخش https://land-book.com Screenlane — رفرنس تعامل و انیمیشن UI https://screenlane.com SaaS Landing Page — رفرنس صفحات فرود محصولات SaaS https://www.saaslandingpage.com UI Sources — کالکشن الگوهای UI واقعی https://www.uisources.com 🧩 دیزاین سیستم‌ها (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 https://www.refactoringui.com 💼 پورتفولیو و شبکه‌سازی (Portfolio & Networking) Readymag — ساخت پورتفولیوی خلاقانه بدون کد Notion (به عنوان پورتفولیو) — ساخت سریع صفحه‌ی معرفی کار ADPList — دریافت منتورشیپ رایگان از طراحان باتجربه #طراحی_محصول #ابزار #منابع #ToolBox 🫶 @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

✅درس‌هایی از یک تجربه‌ی واقعی: مدیریت استعداد در دیجی‌کالا امروز صبح طبق عادت همیشگی، لینکدین رو باز کردم تا از اتفاقات و پست‌های جدید باخبر بشم. اولین پستی که در فید دیدم، پست جدید آقای محمدمهدی زارعی، مدیر ارشد منابع انسانی گروه دیجی‌کالا بود. از سال ۱۳۹۵، از زمانی که پروژه تحول دیجیتال (Digital Transformation) در سازمانی که در آن مشغول بودم آغاز شد و من هم عضو کمیته تحول دیجیتال آن مجموعه بودم، مفهوم استعداد دیجیتال (Digital Talent) و به‌طور کلی مدیریت استعداد (Talent Management) همیشه برایم موضوعی جذاب بوده است. این پست به‌طور خاص برایم بیشتر جالب بود، چون بر پایه‌ی نتایج واقعی، جدید و البته از دل یک سازمان ایرانی نوشته شده بود. به همین دلیل دوست داشتم آن را با شما هم به اشتراک بگذارم؛ فکر می‌کنم برای شما هم خواندنی باشد. 🟢درس آموخته‌ها در اولین راند برگزاری فرایند مدیریت استعداد گروه دیجی‌کالا تو این فرایند، با تک‌تک نفرات منتخب مصاحبه کردم، در جلسات IDP شون حضور داشتم و پای داستان زندگی، مسیر شغلی، هدف‌ها و آرزوهایی که برای خودشون ساخته بودند نشستم. فارغ از مدل‌ها و تئوری‌های مدیریت استعداد، چیزهایی که من یاد گرفتم: ۱. جاه‌طلبی + چشم‌انداز شغلی مشخص + حوصله‌ی دردسر داشتن، نشانه‌ی پتانسیل است. ۲. انگیزه‌ای که به عمل منجر نشود، انگیزه نیست. در بهترین حالت ادعاست و در بدترین حالت، انتظار برای اینکه چیزی مفت به دست بیاید. ۳. «وقت نداشتم یاد بگیرم» معمولاً بهانه است. آدم‌های مستعد، برای یادگیری جا باز می‌کنند. ۴. خروج از منطقه امن، استقبال از تجربه‌های جدید و فعالانه بازخورد گرفتن، نشانه‌ی بسیار خوبی است. ۵. درون‌گرا بودن نقطه‌ضعف نیست. اینکه انرژی‌ات را از خلوت می‌گیری مشکلی ندارد؛ مسئله این است که آیا می‌توانی با دیگران ارتباط مؤثر برقرار کنی و آن‌ها را با خودت همراه کنی؟ ۶. مدیریت، شغلِ حل مسئله و تصمیم‌گیری است. کسی که ذهن منظمی ندارد، تفکر منطقی را بلد نیست، خطاهای شناختی خودش را نمی‌شناسد، احتمالاً در تصمیم‌گیری‌های پیچیده‌ی مدیریتی هم به مشکل خواهد خورد. در کنار همه این‌ها، یک ویژگی را در افراد با پتانسیل خیلی پررنگ دیدم: ۷. نسبت به ناکارآمدی بی‌تفاوت نیستند. وقتی چیزی درست کار نمی‌کند، نمی‌توانند به‌سادگی از کنارش عبور کنند. پس برای بهتر کردنش دست به عمل می‌زنند. 📱 لینک منبع البته معتقدم با ورود بیشتر به عصر هوش مصنوعی، برخی تعاریف و شاخص‌های «استعداد دیجیتال» نسبت به حتی ۴ سال گذشته تغییر کرده، و باز تعریف نیاز داره که من در این پست به اون‌ها اشاره نمیکنم، چون تخصص من در حوزه HR و Talent Management نیست! اما میتواند یه سرنخ برای جستجوگری بیشتر باشد، و شاید شنیدن این پادکست هم برای شما جذاب باشه! 🎙انتشار اپیزود هجده پادکست مدرسه تحول دیجیتال: استعداد دیجیتال کیست و چه می‌خواهد؟ #استعداد_دیجیتال #مدیریت_استعداد #آینده_شغلی #مسیر_شغلی 🫶 @SodehDesign ☝️ Sodeh.me ⚙️ https://linktr.ee/irSodeh

✨ دوره جدید مسابقات طراحی داکس آغاز شد تا روز دوشنبه این هفته، یعنی ۱۶ شهریور ماه فرصت دارید وارد سایت داکس بشی و برای شرکت در مسابقه ثبت‌نام کنی. اگه می‌خوای خودت و مهارت‌هات رو توی یک چالش طراحی محک بزنی، حالا وقت ثبت‌نامه🧩 💡این مسابقه مناسب چه کساییه؟ 🟡طراحان UI/UX 🟡 طراحان محصول 🟡 علاقه‌مندان به تجربه‌کاربری 🟡 علاقه‌مندان به چالش‌های طراحی 🟡 علاقه‌مندان به حل مسئله اینجا بیشتر از عنوان شغلی یا میزان سابقه، نحوه فکر کردن به مسئله و رسیدن به راه‌حل اهمیت داره. 💡برای فرد برنده: 💰 ۵۰ میلیون تومان جایزه نقدی 🗓️گواهی برگزیده داکس 🎨 اشتراک یکساله دیزاین سیستم دیگ(DIG) ✍️ امکان انتشار مقاله در داکس 👑تندیس داکس و برای افراد برتر: 🗓️ گواهی برگزیده داکس 🎨 اشتراک یکساله دیزاین سیستم دیگ(DIG) ✍️ امکان انتشار مقاله در داکس 👑تندیس داکس 🔗 ثبت‌نام از طریق سایت داکس ⭕️ برای ورود به سایت، VPN خود را خاموش کنید. https://dux.studio | @duxstudio شاید این دوره، نوبت شما باشه. ثبت‌نام کن و وارد چالش شو😎🏆 🟡این یک تبلیغ نیست، یک حمایت دوستانه از سوده دیزاین است ❤️حمایت از فعالیت‌های ارزشمند جامعه دیزاین، را فراموش نکنیم #DUXAwards #Summer1405 #Design 🫶@SodehDesign

✅ساخت معکوس: قانون جدید توسعه محصول در عصر 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

✅ به یاد کیوان خسروانی (۱۳۱۷-۱۴۰۵) کیوان خسروانی طراح، معمار، تهیه‌کننده و نظریه‌پرداز معاصر است. کسی که لقب "پدرِ طراحی مُد ایران" برایش زیاده گویی نیست. مجموعه آثار او در مُد و معماری از جمله موفق‌ترین نمونه‌های دیزاین در ایران معاصر است که نشان از شناخت دقیق او از فرهنگ ایرانی دارد. با این حال او با نقّادی تمام معتقد است «ایران همیشه در فرهنگش یک جور تخریب بوده. و همینطور یک جور عبودیت. چه در دوره هخامنشی‌اش و چه حالا. این فرق دارد با سیستم‌هایی مثل فرهنگ یونان قدیم که همان موقعی که ایرانیان می ‌رفتند می‌جنگیدند و آتن را آتش می‌زدند، یونانیان هر جا می‌رفتند، یک تئاتر یونانی می‌ساختند. اگر در بالا سقراط و افلاطون و اینها بودند ولی در پایین هم مردم عادی می‌نشستند پی‌اس‌هایی را نگاه می‌کردند که {کارِ} سوفکل بوده. آنتیگون بوده؛ اینها را نگاه می‌کردند. یعنی بالاترین مغز در رابطه بوده با پایین‌ترین. که می‌بینیم معماری‌شان هم تبدیل می‌شود به علم معماری؛ که جلوی دید اشتباه چشم را می‌گیرد. چیزی که هرگز در معماری ایران وجود نداشته. یا ورزششان را می‌بینیم که تبدیل می‌شود به ورزش المپیک و شهرسازی‌شان هم همینطور. این است که حساب‌کردن روی قوم مخربی که ما باشیم، خیلی کار ساده‌ای نیست! مثلاً من سیستم‌های سیاسی تاریخ ایران را که می‌بینم خیلی ربط پیدا می‌کند به فرهنگ ایران؛ {و اگر ناکارآمد یا بد است} درست آن چیزی است که شالوده فرهنگ ایران است. متاسفم که این را می‌گویم ولی واقعیت دارد...» کیوان بدون تعارف از جمله شخصیت هایی‌ست که شناخت افکار و زندگی‌اش به ما یاری می‌دهد تا نقبی بزنیم به عمق جامعهٔ ایرانی و دوباره و دوباره به نقد خود بنشینیم و به عینک شک خویشتن را باز ببینیم، تا بلکه دست آخر بتوانیم به درستی خود را بازبیابیم. باید بدانیم که جز از درست "پرسیدن" و در پیِ پاسخِ درست برآمدن راهی نیست که به قول ابراهیم گلستان، « ... شک عنصر حیاتی اندیشه است. شک شرط بررسی و کشف و درک و ایمان است. شک شرط آزادی است ». 🟡گزیده ای از آثار و تصاویر کیوان خسروانی 🟡 کیوان خسروانی پدر طراحی مُد ایران 🟡نقدِ معماری از نگاهِ کیوان خسروانی: بخش نخست 🟡سرآغاز گفت‌وگوهای زاین، با حضور کیوان خسروانی و نیما بهنود 🟡نقدِ معماری از نگاهِ کیوان خسروانی: بخش نخست سپاس فراوان از کامیونیتی زاین و به ویژه مازیار رضایی عزیز @zignchannel یاد کیوان خسروانی زنده و میراثش جاوان است🇮🇷 #دیزاین #دیزاینر #کیوان_خسروی 🫶 @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

✅تصمیم‌گیری در عصر 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