🧩 Componentها یکیان، پس چرا تجربه محصولات هنوز با هم فرق داره؟
فرض کنید سه تیم برای حذف اطلاعات، سه تجربه متفاوت طراحی کردن؛ یکی Confirmation نشون میده، یکی قبل از حذف درباره پیامدش توضیح میده و یکی هم بدون Confirmation حذف میکنه و بعد امکان Undo میده.
جالب اینجاست که هر سه تیم هم از Design System استفاده کردن. Button، Dialog، Icon، رنگ و Typography همه از Library مشترک اومدن.
پس چرا تجربهها هنوز متفاوتن؟
چون استفاده از Componentهای یکسان، لزوماً تجربه یکسانی نمیسازه.
Component به تیم میگه یک بخش از Interface رو چطور بسازه؛ اما خیلی وقتها نمیگه چه زمانی و چرا باید از اون استفاده کنه. اینجاست که Patternها وارد ماجرا میشن.
شاید برای Consistency بیشتر، همیشه به Component جدید نیاز نداشته باشیم؛ گاهی چیزی که باید بین تیمها مشترک بشه، منطق پشت تصمیمهای UX ـه.
در مقاله جدید DIG درباره تفاوت Component و Pattern و نقش هرکدوم در ساخت تجربههای Consistent صحبت کردیم.
لینک مقاله:https://shorturl.at/Ez1sx
@digdesign
فرض کنید سه تیم برای حذف اطلاعات، سه تجربه متفاوت طراحی کردن؛ یکی Confirmation نشون میده، یکی قبل از حذف درباره پیامدش توضیح میده و یکی هم بدون Confirmation حذف میکنه و بعد امکان Undo میده.
جالب اینجاست که هر سه تیم هم از Design System استفاده کردن. Button، Dialog، Icon، رنگ و Typography همه از Library مشترک اومدن.
پس چرا تجربهها هنوز متفاوتن؟
چون استفاده از Componentهای یکسان، لزوماً تجربه یکسانی نمیسازه.
Component به تیم میگه یک بخش از Interface رو چطور بسازه؛ اما خیلی وقتها نمیگه چه زمانی و چرا باید از اون استفاده کنه. اینجاست که Patternها وارد ماجرا میشن.
شاید برای Consistency بیشتر، همیشه به Component جدید نیاز نداشته باشیم؛ گاهی چیزی که باید بین تیمها مشترک بشه، منطق پشت تصمیمهای UX ـه.
در مقاله جدید DIG درباره تفاوت Component و Pattern و نقش هرکدوم در ساخت تجربههای Consistent صحبت کردیم.
لینک مقاله:https://shorturl.at/Ez1sx@digdesign
۱
طراحی فقط ساختن صفحههای زیبا نیست؛ بخش مهمی از طراحی، توانایی حل مسئله در شرایط واقعی، شناخت درست مسئله و رسیدن به راهحلیه که بشه ازش دفاع کرد. یکی از چیزهایی که میتونه به رشد جامعه طراحی کمک کنه، ایجاد فرصتهاییه که طراحان رو برای مدتی از فضای روزمره پروژهها خارج کنه و با یک مسئله جدید روبهرو کنه؛ مسئلهای که برای حلش باید تحقیق کنن، فرضیه بسازن، تصمیم بگیرن و در نهایت راهحل خودشون رو ارائه بدن. مسابقه طراحی داکس یکی از همین فرصتهاست؛ فضایی برای محک زدن مهارتهایی مثل UX Research، Problem Solving، طراحی تجربه و تبدیل یک مسئله به یک راهحل کامل و قابل ارائه. خوشحالیم که تیم دیگ هم در این مسیر کنار جامعه طراحی حضور داره و بهعنوان اسپانسر این رقابت از برگزاری چنین فرصتهایی حمایت میکنه. برای ما این همراهی فقط حمایت از یک مسابقه نیست؛ حمایت از فضاییه که طراحان میتونن در اون تجربه کنن، تواناییهاشون رو به چالش بکشن، از هم یاد بگیرن و بیشتر دیده بشن. اگر دنبال فرصتی هستید که مهارتهای طراحی خودتون رو در یک چالش متفاوت محک بزنید، روی یک مسئله واقعی کار کنید، از افراد متخصص بازخورد بگیرید و در جامعه Product و UX بیشتر دیده بشید، مسابقه طراحی داکس میتونه تجربه ارزشمندی براتون باشه. خوشحال میشیم این بار نه فقط بهعنوان تماشاگر، بلکه بهعنوان یکی از شرکتکنندههای این رقابت ببینیمتون.@digdesign
۲
آیا واقعاً همهچیز باید Token بشه؟وقتی Design System رشد میکنه، معمولاً Tokenها هم بیشتر میشن؛ Color، Spacing، Typography، Radius، Shadow و کمکم حتی برای جزئیترین Valueها هم Token میسازیم.
چون یک تصور رایج وجود داره:هر Hard-coded Value یعنی یک Token کم داریم.
اما واقعاً همینطوره؟
فرض کنید یک مقدار `8px` در چند جای محصول تکرار شده. آیا فقط چون تکرار شده باید Token بشه؟ اگر دو مقدار از نظر عددی برابر باشن، لزوماً از نظر معنایی هم یک تصمیم مشترک هستن؟
اینجاست که شاید بهتر باشه نگاهمون به Tokenها رو عوض کنیم:
Token فقط اسم گذاشتن روی یک Value نیست؛ باید نماینده یک تصمیم در سطح سیستم باشه.
پس هدف یک Design System بالغ لزوماً رسیدن به «صفر Hard-code» نیست؛ مهمتر اینه که بفهمیم کدوم تصمیمها ارزش مدیریت شدن در سطح سیستم رو دارن و کدوم Valueها بهتره Local باقی بمونن.
در مقاله جدید DIG بیشتر درباره مرز Tokenization و هزینهای که Tokenهای اضافی میتونن وارد سیستم کنن صحبت کردیم.
لینک مقاله:https://shorturl.at/FSXoQ@digdesign
۱
Documentation کامله؛ پس چرا همه هنوز سؤال میپرسن؟خیلی وقتها تیم Design System کلی وقت میذاره و همهچیز رو مستند میکنه؛ Variantها، Stateها، Props، Accessibility، مثالها و...
اما باز هم سؤالهایی مثل این تکرار میشن:
«برای این سناریو Modal بهتره یا Drawer؟» «کدوم Variant به درد این Use Case میخوره؟» «این Component توی Loading چه رفتاری داره؟»
اینجا شاید مشکل این نباشه که اطلاعات کم داریم؛ شاید مشکل اینه که Documentation رو نوشتیم، اما تجربه استفاده ازش رو طراحی نکردیم.
چون وجود جواب با پیدا کردن جواب فرق داره.
Documentation خوب فقط نباید کامل باشه؛ باید کمک کنه آدمها سریع جواب درست رو پیدا کنن، بفهمنش و بتونن بهش اعتماد کنن.
شاید بهجای اینکه مدام بپرسیم «دیگه چی باید مستند کنیم؟»، بهتر باشه ببینیم تیمها برای چه سؤالهایی هنوز مجبور میشن سراغ یک آدم برن.
در مقاله جدید DIG درباره این موضوع صحبت کردیم که چرا Documentation هم باید مثل یک Product داخلی طراحی و تست بشه.
لینک مقاله:https://shorturl.at/vxMLx@digdesign
۱
معرفی GPT-6 Astra فقط خبر معرفی یک مدل جدید نیست؛ چیزی که برای ما جالبتره، تغییریه که کمکم در تعریف «کار با AI» اتفاق میافته.تا امروز بخش زیادی از ابزارهای AI منتظر بودن ما مرحلهبهمرحله بهشون بگیم چه کاری انجام بدن. اما هرچقدر Agentها مستقلتر میشن، نقش ما هم از «دادن دستور برای هر مرحله» بیشتر به سمت تعریف هدف، تعیین محدودیتها، نظارت و تصمیمگیری در نقاط حساس حرکت میکنه.
و شاید این تغییر برای Designerها از خود قابلیتهای Astra مهمتر باشه.چون اگر Agent قرار باشه واقعاً کاری رو از طرف کاربر انجام بده، فقط خوب انجام دادن Task کافی نیست؛ کاربر باید بدونه چه کاری انجام شده، چرا انجام شده، چه چیزی هنوز قابل تغییر یا برگشته و چه زمانی تصمیم نهایی دست خودشه.
اینجاست که مفاهیمی مثل Trust، Control، Transparency و Recovery از جزئیات UX به بخش مهمی از تجربه محصول تبدیل میشن.
ما جزئیات مهم Astra و تأثیری که این مسیر میتونه روی طراحی محصولات آینده داشته باشه رو در اسلایدها بررسی کردیم.
اگر دوست دارید عمیقتر با این موضوع آشنا شوید، فایل زیر را از دست ندید
به نظرتون اگر Agentها بخش بیشتری از کارهای ما رو انجام بدن، مهمترین چیزی که Designerها باید دوباره طراحی کنن چیه؟
@digdesign
Dig Design System | دیزاین سیستم فارسی دیگ معرفی GPT-6 Astra فقط خبر معرفی یک مدل جدید نیست؛ چیزی که برای ما جالبتره، تغییریه که کمکم در تعریف «کار با AI» اتفاق میافته. تا امروز بخش زیادی از ابزارهای AI منتظر بودن ما مرحلهبهمرحله بهشون بگیم چه کاری انجام بدن. اما هرچقدر Agentها مستقلتر میشن، نقش ما هم از «دادن دستور برای هر مرحله» بیشتر به سمت تعریف هدف، تعیین محدودیتها، نظارت و تصمیمگیری در نقاط حساس حرکت میکنه. و شاید این تغییر برای Designerها از خود قابلیتهای Astra مهمتر باشه. چون اگر Agent قرار باشه واقعاً کاری رو از طرف کاربر انجام بده، فقط خوب انجام دادن Task کافی نیست؛ کاربر باید بدونه چه کاری انجام شده، چرا انجام شده، چه چیزی هنوز قابل تغییر یا برگشته و چه زمانی تصمیم نهایی دست خودشه. اینجاست که مفاهیمی مثل Trust، Control، Transparency و Recovery از جزئیات UX به بخش مهمی از تجربه محصول تبدیل میشن. ما جزئیات مهم Astra و تأثیری که این مسیر میتونه روی طراحی محصولات آینده داشته باشه رو در اسلایدها بررسی کردیم. اگر دوست دارید عمیقتر با این موضوع آشنا شوید، فایل زیر را از دست ندید به نظرتون اگر Agentها بخش بیشتری از کارهای ما رو انجام بدن، مهمترین چیزی که Designerها باید دوباره طراحی کنن چیه؟ @digdesign
معرفی GPT-6 Astra فقط خبر معرفی یک مدل جدید نیست؛ چیزی که برای ما جالبتره، تغییریه که کمکم در تعریف «کار با AI» اتفاق میافته. تا امروز بخش زیادی از ابزارهای AI منتظر بودن ما مرحلهبهمرحله بهشون بگیم چه کاری انجام بدن. اما هرچقدر Agentها مستقلتر میشن، نقش ما هم از «دادن دستور برای هر مرحله» بیشتر به سمت تعریف هدف، تعیین محدودیتها، نظارت و تصمیمگیری در نقاط حساس حرکت میکنه. و شاید این تغییر برای Designerها از خود قابلیتهای Astra مهمتر باشه. چون اگر Agent قرار باشه واقعاً کاری رو از طرف کاربر انجام بده، فقط خوب انجام دادن Task کافی نیست؛ کاربر باید بدونه چه کاری انجام شده، چرا انجام شده، چه چیزی هنوز قابل تغییر یا برگشته و چه زمانی تصمیم نهایی دست خودشه. اینجاست که مفاهیمی مثل Trust، Control، Transparency و Recovery از جزئیات UX به بخش مهمی از تجربه محصول تبدیل میشن. ما جزئیات مهم Astra و تأثیری که این مسیر میتونه روی طراحی محصولات آینده داشته باشه رو در اسلایدها بررسی کردیم. اگر دوست دارید عمیقتر با این موضوع آشنا شوید، فایل زیر را از دست ندید به نظرتون اگر Agentها بخش بیشتری از کارهای ما رو انجام بدن، مهمترین چیزی که Designerها باید دوباره طراحی کنن چیه؟ @digdesignGPT-6 Astrapdf.pdf
۴.۷۵ مگابایت
۱
Contribution در Design System فقط این نیست که چیزی بسازیم و تحویل بدیم.خیلی وقتها Contribution از جایی شروع میشه که یک تیم Component یا Solution آمادهای داره و میخواد اون رو وارد Library کنه.
اما شاید اون موقع کمی دیر شده باشه.
چون Design System قبل از Solution، به Evidence نیاز داره؛ باید بفهمه مسئله واقعاً چقدر تکرار میشه، در چند محصول وجود داره و آیا اصلاً ارزش حل شدن در سطح سیستم رو داره یا نه.
گاهی یک تیم فقط یک Signal مهم پیدا میکنه. تیم دیگه Context بیشتری اضافه میکنه. تیم سوم Evidence از چند Use Case میاره و تازه بعد از اون میشه درباره Solution تصمیم گرفت.
اینجاست که *Contribution Ladder معنا پیدا میکنه: مشارکت میتونه از گزارش یک مسئله شروع بشه و تا Design، Code، Test و Documentation ادامه پیدا کنه؛ اما لازم نیست همه Contributionها به ساختن چیزی ختم بشن.
شاید بهترین سؤال این نباشه که:
«این تیم چه چیزی به Design System اضافه کرد؟»*
بلکه این باشه:
«بعد از این Contribution، چه چیزی رو بهتر از قبل میدونیم و آیا میتونیم تصمیم مطمئنتری بگیریم؟»
چون گاهی بهترین Contribution اینه که کمک کنه چیزی که نباید بسازیم، اصلاً ساخته نشه.
در مقاله جدید DIG درباره همین نگاه به Contribution و اینکه Contribution Ladder چطور میتونه به تصمیمهای بهتر در Design System کمک کنه، صحبت کردیم.
لینک مقاله:https://shorturl.at/sXbfo@digdesign
۱
آیا Consistency یعنی همهچیز باید شبیه هم باشه؟یکی از هدفهای اصلی Design System اینه که تجربه محصولات Consistent باشه. اما مشکل از جایی شروع میشه که هر تفاوتی رو یک ایراد ببینیم.
مثلاً اگر یک Pattern در دو محصول متفاوت اجرا شده، آیا حتماً یکی از اونها اشتباهه؟
نه لزوماً.
بعضی تفاوتها واقعاً باعث سردرگمی، Relearning و رفتار غیرقابلپیشبینی میشن و باید برطرف بشن. اما بعضی تفاوتها نتیجه طبیعی Context متفاوت محصول، نوع کاربر یا Platform هستن.
پس شاید هدف این نباشه که Variation رو حذف کنیم؛ باید بفهمیم کدوم Variation واقعاً هزینه ایجاد میکنه.
در مقاله جدید DIG برای بررسی این موضوع از یک مدل ساده استفاده کردیم:Scope × Cost × Context
یعنی قبل از اینکه یک تفاوت رو Consistency Debt بدونیم، ببینیم این تصمیم اصلاً تا کجا باید مشترک باشه، متفاوت بودنش چه هزینهای داره و آیا Context دلیل قابلدفاعی برای این تفاوت ایجاد کرده یا نه.
چون یک Design System بالغ فقط مشخص نمیکنه چه چیزهایی باید Consistent باشن؛ مرز Consistency رو هم مشخص میکنه.
لینک مقاله:https://shorturl.at/cGgd9@digdesign
۱
دیگچه از امروز رسماً در دسترسه؛ جایی که آیکونها از فایلهای پراکنده، به بخشی از جریان مشترک طراحی، توسعه و کار با AI تبدیل میشن.🧩 دیگچه بخشی از اکوسیستم دیگه و بهعنوان لایه آیکونوگرافی به دیزاین سیستم دیگ متصل میشه؛ یعنی طراح، توسعهدهنده و ایجنت AI میتونن بهجای استفاده از منابع پراکنده، با یک مجموعه مشترک کار کنن. البته دیگچه مستقل از دیگ هم قابل استفادهست.
شروع حضور عمومی دیگچه با مسابقه طراحی DUX همراه شده و دیگچه حامی این دوره از مسابقهست. اگر در داکس شرکت کردید، میتونید برای ساخت یک زبان تصویری منسجم در پروژهتون از آیکونهای دیگچه استفاده کنید. چیزی که امروز منتشر شده یک محصول آماده استفادهست، نه وعدهای برای آینده؛ اما قرار نیست در همین نقطه متوقف بمونه. مجموعه آیکونها، اتصالها و روشهای استفاده از دیگچه بهمرور گستردهتر میشن و این تازه شروع مسیریه که براش در نظر گرفتیم. https://icons.digdesign.ir@digdesign
Design System شما چقدر به تیمش وابستهست؟ ممکنه Library در دهها محصول استفاده بشه، اما اگر برای انتخاب Pattern، مدیریت Exception یا تغییر Component هنوز به نظر تیم مرکزی نیاز باشه، یک Dependency پنهان داریم. در مقاله جدید DIG به *Decision Scalability پرداختیم؛ اینکه چطور با بیشتر شدن مصرفکنندهها، وابستگی به تصمیمگیری مرکزی هم با همون سرعت بیشتر نشه. لینک مقاله:* https://shorturl.at/YVG3R@digdesign