مرز Consistency کجاست؟

یکی از وعده‌های اصلی Design System، ایجاد Consistency است. وقتی Functionهای مشابه به‌شکل قابل‌پیش‌بینی ارائه می‌شوند، کاربر می‌تواند بخشی از چیزی را که قبلاً یاد گرفته دوباره استفاده کند و لازم نیست رفتار Interface را در هر بخش از نو کشف کند. همین منطق در Accessibility هم اهمیت دارد؛ Functionهایی که در مجموعه‌ای از صفحات تکرار می‌شوند باید به‌شکل Consistent شناسایی شوند تا تجربه برای کاربر قابل‌پیش‌بینی باقی بماند.

اما یک سؤال کمتر مطرح می‌شود: این Consistency دقیقاً تا کجا باید ادامه پیدا کند؟

آیا اگر یک Pattern در یکی از محصولات اکوسیستم استفاده شد، تمام محصولات باید از همان Pattern استفاده کنند؟ آیا Navigation در Mobile و Desktop باید تا جای ممکن مشابه باشد؟ آیا تمام Dashboardها باید ساختار مشترکی داشته باشند؟

اگر پاسخ پیش‌فرض ما به این سؤال‌ها «بله» باشد، کم‌کم Uniformity جای Consistency را می‌گیرد. هر تفاوتی به‌عنوان نقص دیده می‌شود و Standardization از یک ابزار برای کاهش ابهام، به هدفی مستقل تبدیل می‌شود.

درحالی‌که Consistent بودن الزاماً به معنی Identical بودن نیست. دو Label می‌توانند متن یکسانی نداشته باشند اما همچنان Consistent باشند؛ چیزی که اهمیت دارد حفظ معنای قابل‌پیش‌بینی Function است.

پس شاید مسئله اصلی حذف تفاوت نباشد؛ مسئله این باشد که تشخیص دهیم کدام تفاوت Predictability را از بین می‌برد و کدام تفاوت پاسخ منطقی به Context است.

شاید چیزی که باید Consistent بماند، Rule باشد نه همیشه Result

فرض کنید دو محصول در یک اکوسیستم داریم. محصول اول ابزاری تخصصی است که کاربران حرفه‌ای روزانه چند ساعت با آن کار می‌کنند. محصول دوم سرویسی است که کاربران شاید ماهی یک‌بار برای انجام Task مشخصی وارد آن شوند.

هر دو محصول ممکن است Action مشابهی داشته باشند، اما این الزاماً به معنی نیاز به Interaction کاملاً یکسان نیست. در محصول اول، Efficiency می‌تواند اهمیت بیشتری داشته باشد و Shortcutها یا تراکم بالاتر اطلاعات منطقی باشند. در محصول دوم، همان تصمیم‌ها ممکن است باعث سردرگمی شوند و کاربر به Guidance یا Confirmation بیشتری نیاز داشته باشد.

اگر Design System بگوید «این Action همیشه باید با همین Pattern پیاده‌سازی شود»، خروجی را Consistent کرده‌ایم، اما ممکن است Context را از تصمیم حذف کرده باشیم.

راه دیگر این است که Consistency را یک لایه عقب‌تر ببریم و به‌جای یک Result ثابت، Decision Rule مشترک تعریف کنیم.

برای مثال، به‌جای اینکه بگوییم «تمام Delete Actionها باید Confirmation Dialog داشته باشند»، می‌توانیم انتخاب Interaction را براساس عواملی مثل Reversibility، شدت پیامد و دامنه اثر تصمیم بگیریم. در این مدل ممکن است یک Delete با Undo مدیریت شود و Delete دیگری به Confirmation نیاز داشته باشد. Result متفاوت است، اما هر دو تصمیم از منطق مشترکی پیروی می‌کنند.

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

اما همه Ruleها هم Scope یکسانی ندارند

اینجا می‌توانیم یک مفهوم تحلیلی برای خودمان تعریف کنیم: Consistency Boundary.

منظور از این اصطلاح این است که هر تصمیم یک محدوده دارد که انتظار داریم داخل آن Consistent باقی بماند. نکته مهم اینجاست که این محدوده برای همه تصمیم‌ها الزاماً «کل اکوسیستم» نیست.

مثلاً بعضی تصمیم‌ها ممکن است System-wide باشند. معنای Stateهایی مثل Error، بعضی Semantic Tokenها یا برخی قواعد Accessibility نمونه‌هایی هستند که تفاوت کنترل‌نشده در آن‌ها می‌تواند رفتار سیستم را غیرقابل‌پیش‌بینی کند.

در مقابل، بعضی تصمیم‌ها ممکن است فقط در یک Product Family نیاز به هماهنگی داشته باشند. چند محصول سازمانی Data-heavy احتمالاً مسائل مشترکی درباره Data Table، Filtering و Bulk Actions دارند که الزاماً در یک محصول Consumer وجود ندارد.

در سطح سوم، بعضی تصمیم‌ها می‌توانند Product-level باقی بمانند. Information Architecture، ساختار Dashboard یا Workflowهای تخصصی ممکن است آن‌قدر به Context محصول وابسته باشند که یکسان کردن آن‌ها در کل اکوسیستم ارزش چندانی ایجاد نکند.

این سه سطح یک استاندارد رسمی نیستند؛ بلکه Framework ساده‌ای هستند برای اینکه قبل از Standardization یک سؤال مهم بپرسیم:

این تصمیم اساساً در چه محدوده‌ای باید Consistent باشد؟

همه Inconsistencyها Debt نیستند

این تفاوت نگاه در Auditهای Design System اهمیت زیادی پیدا می‌کند.

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

اما تعداد تفاوت‌ها به‌تنهایی اطلاعات کافی در اختیار ما نمی‌گذارد.

ممکن است یک تفاوت به این دلیل ایجاد شده باشد که تیم Component موجود را نمی‌شناخته است و تفاوت دیگری از یک Implementation قدیمی باقی مانده باشد. در مقابل، Implementation سوم شاید به دلیل تفاوت واقعی در Platform، نوع کاربر یا Business Rule ایجاد شده باشد.

برای تفکیک این دو وضعیت می‌توانیم از دو برچسب استفاده کنیم: Accidental Inconsistency برای تفاوتی که دلیل محصولی مشخصی پشت آن وجود ندارد و Intentional Variation برای تفاوتی که آگاهانه و براساس Context ایجاد شده است.

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

حتی یک Icon یکسان می‌تواند در Contextهای مختلف Label متفاوتی داشته باشد، اگر Function آن متفاوت باشد. یعنی شباهت ظاهری به‌تنهایی دلیل کافی برای رفتار یکسان نیست؛ Function و Context هم اهمیت دارند.

برای همه تفاوت‌ها هم نباید انرژی یکسانی صرف کنیم

فرض کنید Radius کارت‌ها در دو محصول کمی متفاوت است. هم‌زمان، رفتار یک Action مشابه در دو Workflow نتیجه متفاوت و غیرمنتظره‌ای برای کاربر ایجاد می‌کند. هر دو را می‌توان Inconsistency نامید، اما اثرشان یکسان نیست.

برای اولویت‌بندی بهتر، به‌جای اینکه فقط میزان تفاوت ظاهری را بسنجیم، می‌توانیم به Cost of Inconsistency نگاه کنیم.

یکی از سؤال‌های مفید این است:

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

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

اما اگر تفاوت فقط در Layout یا جزئیاتی باشد که مدل ذهنی و رفتار کاربر را تغییر نمی‌دهد، ممکن است اولویت بسیار پایین‌تری داشته باشد.

بنابراین شاید سؤال بهتر در Audit این نباشد که «چند Inconsistency داریم؟» بلکه این باشد که «کدام Inconsistency بیشترین هزینه را برای کاربر یا تیم ایجاد می‌کند؟»

یک مدل ساده برای تصمیم‌گیری درباره Consistency

از بحث‌های بالا می‌توانیم یک Framework ساده برای Audit یا تصمیم‌گیری استخراج کنیم. این مدل استاندارد رسمی Design System نیست، بلکه ابزاری پیشنهادی برای بررسی تفاوت‌هاست:

Scope × Cost × Context

Scope مشخص می‌کند این تصمیم تا کجا باید مشترک باشد. آیا انتظار داریم در کل System یکسان باشد، در یک Product Family هماهنگ بماند یا تصمیم آن در اختیار Product است؟

Cost بررسی می‌کند متفاوت بودن چه پیامدی دارد. آیا تفاوت فقط Visual است یا باعث Relearning، خطا، سردرگمی و کاهش Predictability می‌شود؟

Context از ما می‌خواهد دلیل تفاوت را بررسی کنیم. آیا Platform، نوع کاربر، Frequency of Use، Business Rule، Accessibility Requirement یا Constraint مشخصی این Variation را توجیه می‌کند؟

ترکیب این سه سؤال تصویر دقیق‌تری نسبت به شمارش ساده Inconsistencyها ایجاد می‌کند.

اگر یک تفاوت خارج از Scope مورد انتظار اتفاق افتاده، هزینه قابل‌توجهی ایجاد می‌کند و Context قابل‌دفاعی هم پشت آن وجود ندارد، احتمالاً با Consistency Debt مواجهیم.

اما اگر Variation در محدوده‌ای اتفاق افتاده که Product اختیار تصمیم‌گیری دارد و Evidence یا Constraint مشخصی پشت آن وجود دارد، شاید اصلاً Debt نباشد.

Design System باید مرز تفاوت را هم مشخص کند

یک Design System نمی‌تواند تمام Contextهای آینده را با یک Solution از پیش تعیین‌شده پوشش دهد. اگر برای حفظ Consistency تلاش کنیم تمام نیازهای محصولات را داخل یک Pattern واحد جا دهیم، ممکن است خود سیستم به‌مرور پر از Variant و Exception شود.

راه‌حل مقابل هم این نیست که همه‌چیز Flexible باشد و هر تیم آزادانه رفتار متفاوتی ایجاد کند.

بعضی نقاط باید سخت‌گیرانه باقی بمانند؛ مخصوصاً جایی که تفاوت می‌تواند Accessibility، Meaning یا Predictability را مختل کند.

اما خارج از چنین نقاطی، Design System باید مشخص کند تیم محصول کجا اختیار تصمیم دارد، چه چیزی قابل تغییر است و چه Evidenceای می‌تواند تفاوت با Pattern مشترک را توجیه کند.

در چنین سیستمی سؤال Audit از این:

چرا این دو محصول یکسان نیستند؟

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

آیا این دو محصول جایی متفاوت شده‌اند که Consistency در آن واقعاً ارزش ایجاد می‌کند؟

این دو سؤال شبیه‌اند، اما اولی Uniformity را نقطه شروع قرار می‌دهد و دومی ابتدا ارزش Consistency را بررسی می‌کند.

جمع‌بندی

Consistency زمانی ارزشمند است که تجربه را Predictable کند، هزینه یادگیری را کاهش دهد و اجازه دهد کاربران از چیزی که قبلاً یاد گرفته‌اند دوباره استفاده کنند. Consistency به‌عنوان الزام برای یکسان بودن تمام Interfaceها تعریف نمی‌شود.

بنابراین یک Design System بالغ فقط نباید مشخص کند چه چیزی باید Consistent باشد؛ لازم است درباره Scope و دلیل آن Consistency هم تصمیم بگیرد و مشخص کند در چه نقاطی Variation قابل قبول است.

برای همین هنگام Audit کردن سیستم، به‌جای شمارش ساده تفاوت‌ها می‌توانیم از سه سؤال استفاده کنیم:

Scope × Cost × Context

چون مسئله اصلی این نیست که همه‌چیز یکسان باشد؛ مسئله این است که تفاوت‌هایی را که Predictability را از بین می‌برند، از تفاوت‌هایی که Context واقعاً به آن‌ها نیاز دارد تشخیص دهیم.