یه مجموعه‌رنگ خوب، لزوماً یه سیستم رنگ خوب نیست

(UI NOTES / COLOR — 02)

یادداشت‌های رابط کاربری / رنگ — ۰۲

قسمت قبل رو با یه سؤال تموم کردم:
«یه مجموعه‌رنگ (Palette) خوب، چه فرقی با یه سیستم رنگ (Color System) خوب داره؟»

چون فرض کنیم مرحله‌ی انتخاب رنگ‌ها رو رد کردیم.
یه رنگ اصلی (Primary) داریم.
چندتا رنگ خنثی (Neutral) داریم.
رنگ‌های مربوط به موفقیت (Success)، هشدار (Warning) و خطا (Error) رو هم انتخاب کردیم.
همه‌شون کنار هم خوب به نظر می‌رسن.

ولی وسط طراحی هنوز به سؤال‌هایی شبیه این می‌رسیم:
این دکمه (Button) کدوم آبی باشه؟
این خاکستری برای متن (Text) بود یا حاشیه (Border)؟
این سبز فقط برای موفقیت (Success)ـه یا می‌تونم جای دیگه هم ازش استفاده کنم؟
برای حالت انتخاب‌شده (Selected State) از همون رنگ اصلی استفاده کنم یا یه نسخه‌ی آروم‌ترش؟

اگه هر بار مجبور باشیم جواب این سؤال‌ها رو از نو پیدا کنیم، شاید چیزی که داریم هنوز بیشتر یه مجموعه‌رنگ باشه تا یه سیستم رنگ.

یه مجموعه‌رنگ خوب، هنوز یه سیستم رنگ نیست

به نظرم تفاوت اصلی خیلی ساده‌ست:
مجموعه‌رنگ (Palette) بهمون می‌گه:
«چه رنگ‌هایی داریم؟»

ولی سیستم رنگ (Color System) باید یه سؤال مهم‌تر رو جواب بده:
«هرکدوم از این رنگ‌ها کجا و چرا استفاده می‌شن؟»

مثلاً ممکنه توی مجموعه‌رنگ چند درجه خاکستری داشته باشیم.
ولی خود اون رنگ‌ها بهمون نمی‌گن:
کدوم برای متن اصلیه؟
کدوم برای متن فرعیه؟
کدوم برای حاشیه (Border)ـه؟
کدوم برای حالت غیرفعال (Disabled State)ـه؟

اینجاست که فقط داشتن رنگ کافی نیست.
به یه لایه‌ی دیگه احتیاج داریم که درباره‌ی نقش رنگ‌ها تصمیم بگیره.

مجموعه‌رنگ (Palette) می‌گه چه رنگ‌هایی داریم.
سیستم رنگ (Color System) می‌گه هر رنگ کجا، چرا و با چه شدتی استفاده می‌شه.

شاید قبل از «کدوم رنگ؟» بهتره بپرسیم «چه نقشی؟»

این یکی از تغییرهایی بود که برای خود من خیلی کمک‌کننده بود.
به‌جای اینکه وسط طراحی اول بپرسم:
«کدوم آبی رو استفاده کنم؟»

اول بپرسم:
«این رنگ قراره چه نقشی داشته باشه؟»

قراره یه اقدام (Action) مهم رو مشخص کنه؟
برای متن (Text)ـه؟
روی سطح (Surface) استفاده می‌شه؟
یه وضعیت (State) رو منتقل می‌کنه؟
بخشی از برند (Brand)ـه؟
یا فقط قراره یه تفاوت بصری ایجاد کنه؟

وقتی این سؤال جواب داده می‌شه، انتخاب خود رنگ هم خیلی محدودتر و راحت‌تر می‌شه.

توی مستندات سیستم طراحی اتلسیَن (Atlassian Design System) هم رنگ فقط بر اساس مقدارش تعریف نمی‌شه.
نقش (Role)، میزان تأکید (Emphasis) و وضعیت تعاملی (Interaction State) بخشی از تصمیم رنگ هستن.

یعنی انتخاب رنگ بیشتر از اینکه جواب سؤال «چه رنگی؟» باشه، جواب سؤال «برای چه کاری؟»ـه.

رنگ اصلی فقط یه کد رنگ نیست

یه چیزی که من قبلاً خیلی ساده‌تر بهش نگاه می‌کردم همین رنگ اصلی (Primary Color) بود.
مثلاً:
«این رنگ اصلی محصولمونه.»

و بعد همون رنگ تقریباً همه‌جا استفاده می‌شد.

ولی توی یه رابط کاربری (UI) واقعی معمولاً یک مقدار ثابت از رنگ برای همه‌ی موقعیت‌ها جواب نمی‌ده.
ممکنه از همون خانواده یه نسخه‌ی قوی‌تر برای اقدام اصلی (Primary Action) لازم داشته باشیم.
یه نسخه‌ی آروم‌تر برای پس‌زمینه (Background).
یه نسخه برای حالت انتخاب‌شده (Selected State).
و یه نسخه‌ی متفاوت وقتی کاربر با عنصر در تعامل (Interaction)ـه.

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

این نگاه یه مزیت دیگه هم داره:
برای ایجاد تفاوت لازم نیست هر بار یه رنگ جدید وارد رابط کنیم.
گاهی همون خانواده، با میزان تأکید (Emphasis) متفاوت، نیازمون رو حل می‌کنه.

شاید رنگ‌های خنثی بیشتر از چیزی که فکر می‌کنیم مهم باشن

وقتی درباره‌ی رنگ یه محصول حرف می‌زنیم، ذهنمون معمولاً سریع می‌ره سمت رنگ برند.

ولی اگه یه صفحه‌ی واقعی رو نگاه کنیم، بیشتر اون صفحه احتمالاً با رنگ برند ساخته نشده.
متن‌ها.
پس‌زمینه‌ها (Background).
کارت‌ها (Card).
سطح‌ها (Surface).
حاشیه‌ها (Border).
جداکننده‌ها (Divider).
حالت‌های غیرفعال (Disabled State).

بخش بزرگی از رابط روی دوش رنگ‌های خنثی (Neutral)ـه.

برای همین به نظرم یه مجموعه‌ی خوب از رنگ‌های خنثی، خیلی وقت‌ها بیشتر از اضافه‌کردن یه رنگ تأکیدی (Accent) جدید به من کمک می‌کنه رابط آروم‌تر و منظم‌تری داشته باشم.

حتی این خاکستری‌ها لزوماً نباید کاملاً بدون رنگ باشن.
گاهی یه خاکستری متمایل (Tinted Gray)، یعنی خاکستری‌ای که یه ته‌رنگ خیلی کم از فضای رنگی محصول داره، می‌تونه کنار رنگ برند هماهنگ‌تر بشینه.
البته تا جایی که هنوز بتونه نقش خنثی خودش رو حفظ کنه.

نکته برای من اینه که:
رنگ خنثی فقط «رنگی که Primary نیست» نیست.

بخش بزرگی از سلسله‌مراتب بصری (Hierarchy) رابط با همین رنگ‌ها ساخته می‌شه.

یه رنگ می‌تونه قشنگ باشه، ولی معنی اشتباهی بده

فرض کن توی محصولمون قرمز برای خطا (Error) استفاده می‌شه.
سبز برای موفقیت (Success).
زرد برای هشدار (Warning).

بعد یه جایی صرفاً چون قرمز کنار بقیه‌ی رنگ‌های یه کارت (Card) خوب به نظر می‌رسه، ازش برای تزئین استفاده کنیم.

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

اینجاست که فرق بین رنگ معنایی (Semantic Color) و رنگ تأکیدی (Accent Color) برام مهم می‌شه.

یه سؤال ساده:
«اگه این رنگ رو با یه رنگ دیگه عوض کنم، معنی تجربه تغییر می‌کنه؟»

اگه جواب نه باشه، احتمالاً بیشتر یه رنگ تأکیدیه.
ولی اگه با تغییرش معنی عنصر عوض بشه، اون رنگ بخشی از زبان محصول شده.

مثلاً:
موفقیت (Success)
هشدار (Warning)
خطا (Error)
اطلاعات (Information)

این رنگ‌ها دیگه صرفاً برای زیباتر کردن رابط (Interface) نیستن.
دارن اطلاعات منتقل می‌کنن.

توی سیستم طراحی اتلسیَن هم برای رنگ تأکیدی تقریباً همین مرز وجود داره:
اگه یه رنگ تأکیدی رو با یه رنگ تأکیدی دیگه عوض کنیم، معنی تجربه نباید تغییر کنه.
اگه تغییر می‌کنه، احتمالاً دیگه صرفاً Accent نیست.

البته معنی نباید فقط روی رنگ سوار باشه

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

اون‌وقت داریم بخش زیادی از معنی (Meaning) رو فقط روی رنگ (Color) سوار می‌کنیم.

راهنمای دسترس‌پذیری وب (WCAG) هم روی همین موضوع تأکید می‌کنه:
رنگ نباید تنها نشانه‌ی بصری برای انتقال اطلاعات یا مشخص‌کردن یه وضعیت باشه.

برای همین می‌شه کنار رنگ از چیزهای دیگه هم کمک گرفت:
آیکون (Icon)
متن (Text)
حاشیه (Border)
شکل (Shape)

یا هر نشانه‌ی دیگه‌ای که باعث بشه معنی فقط به تشخیص رنگ وابسته نباشه.

این یه جورایی ادامه‌ی همون بحث آزمون خاکستری (Grayscale Test) قسمت قبله.

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

فقط نقش کافی نیست؛ میزان تأکید هم مهمه

فرض کنیم مشخص کردیم یه رنگ برای موفقیت (Success)ـه.
هنوز یه سؤال باقی می‌مونه:
این موفقیت چقدر باید دیده بشه؟

مثلاً یه پیام موفقیت مهم بعد از پرداخت داریم.
یه نشان (Badge) کوچیک داخل جدول داریم.
یه نقطه‌ی وضعیت کنار اسم کاربر داریم.

هر سه ممکنه یه معنی داشته باشن.
ولی قرار نیست هر سه با یه شدت دیده بشن.

یکی ممکنه به یه پس‌زمینه (Background) واضح احتیاج داشته باشه.
یکی فقط به یه رنگ ملایم.
یکی شاید فقط یه آیکون (Icon) کوچیک بخواد.

پس معنی یکیه، ولی وزن بصری (Visual Weight) یکی نیست.

اینجاست که میزان تأکید (Emphasis) وارد تصمیم می‌شه.

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

یه رنگ، توی همه‌ی وضعیت‌ها هم قرار نیست یکسان بمونه

فرض کن یه دکمه (Button) داریم.
رنگش رو مشخص کردیم.
ولی داستان همون‌جا تموم نمی‌شه.

حالت عادی (Default)
حالت هاور (Hover)
حالت فشرده‌شده (Pressed)
حالت تمرکز (Focus)
حالت انتخاب‌شده (Selected)
حالت غیرفعال (Disabled)

همه‌شون ممکنه نیاز داشته باشن به شکلی با هم متفاوت باشن.

و اینجا دوباره فرق مجموعه‌رنگ و سیستم رنگ مشخص می‌شه.

مجموعه‌رنگ (Palette) فقط چندتا آبی بهمون می‌ده.
ولی سیستم رنگ (Color System) مشخص می‌کنه:
کدوم آبی برای چه وضعیتی (State)ـیه؟

و حتی کجا اصلاً قرار نیست با تغییر رنگ، وضعیت رو نشون بدیم.

برای همین وقتی سیستم بزرگ‌تر می‌شه، اسم رنگ کم‌کم اهمیت کمتری پیدا می‌کنه.
نقشش مهم‌تر می‌شه.

اگه بخوام خیلی ساده‌ش کنم

برای خودم این مسیر کمک‌کننده‌تره:

اول، نقش (Role)
این رنگ چه کاری انجام می‌ده؟

بعد، کاربرد (Usage)
روی چی استفاده می‌شه؟
متن (Text)؟
پس‌زمینه (Background)؟
حاشیه (Border)؟
آیکون (Icon)؟

بعد، میزان تأکید (Emphasis)
چقدر باید دیده بشه؟

بعد، وضعیت (State)
عنصر الان تو چه وضعیتی قرار داره؟

و تازه بعد از این‌ها، رنگ (Color)
خود رنگ چی باشه؟

نقش → کاربرد → میزان تأکید → وضعیت → رنگ
(Role → Usage → Emphasis → State → Color)

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

پس سیستم رنگ دقیقاً چی به ما اضافه می‌کنه؟

به نظرم چیزی که اضافه می‌کنه فقط «رنگ بیشتر» نیست.
اتفاقاً شاید برعکس باشه.

یه سیستم خوب می‌تونه کمک کنه با رنگ‌های کمتری تصمیم‌های بیشتری بگیریم.

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

این همون چیزیه که لایه‌ی معنایی (Semantic Layer) انجام می‌ده.

یه مجموعه‌رنگ پایه (Core Palette) می‌تونه تمام رنگ‌های در دسترس رو داشته باشه.
ولی لایه‌ی معنایی مشخص می‌کنه:
کدومش برای متن (Text)ـه؟
کدومش برای پس‌زمینه (Background)ـه؟
کدومش برای حاشیه (Border)ـه؟
کدومش برای موفقیت یا خطا استفاده می‌شه؟

این تفکیک یه مزیت خیلی مهم دیگه هم داره.

اگه بعداً مقدار یه رنگ عوض بشه، قرار نیست منطق استفاده‌ش هم عوض بشه.

مثلاً ممکنه رنگی که پشت نقش «متن اصلی» (Text Primary) قرار گرفته تغییر کنه.
ولی نقش همچنان همونه: متن اصلی.

همین موضوع برای حالت تاریک (Dark Mode)، تم‌های مختلف (Theme) یا تغییر رنگ برند هم خیلی کمک‌کننده می‌شه.

چیزی که برای من عوض شد، این بار ترتیب تصمیم‌ها بود

توی قسمت اول به این رسیدم که قبل از اضافه‌کردن یه رنگ بپرسم:
«اصلاً چرا به این رنگ نیاز دارم؟»

اینجا سؤال یه قدم جلوتر می‌ره:
«اگه بهش نیاز دارم، دقیقاً چه نقشی توی سیستم داره؟»

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

یکی بهمون یه مجموعه انتخاب می‌ده.
اون یکی کمک می‌کنه بدونیم چطور از اون انتخاب‌ها استفاده کنیم.

و اینجا برای من یه سؤال دیگه شروع شد.

چی می‌شه اگه خود رنگ برند درست باشه...
ولی نحوه‌ی استفاده‌ش توی محصول دیگه جواب نده؟

این دقیقاً چیزیه که توی قسمت بعدی یادداشت‌های رنگ می‌خوام برم سراغش:

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

منابع

سیستم طراحی اتلسیَن، بخش رنگ:
Atlassian Design System — Color

سیستم طراحی اتلسیَن، رنگ‌های تأکیدی:
Atlassian Design System — Accents

سیستم طراحی اتلسیَن، توکن‌های طراحی:
Atlassian Design System — Design Tokens

الکساندرا باسوا، مقاله‌ی لایه‌ی معنایی مجموعه‌رنگ:
The Semantic Interface Palette Is Simple — UX Collective — 2024

راهنمای دسترس‌پذیری W3C درباره‌ی استفاده از رنگ:
WCAG 2.2 — Understanding Use of Color

بنیاد طراحی تعامل، رنگ در طراحی تجربه کاربری:
Interaction Design Foundation — Color in UX Design