دیزاین‌سیستم چیست؟ راهنمای اجزا و کاربردها با مثال واقعی

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

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

دیزاین‌سیستم چیست؟

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

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

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

دیزاین‌سیستم از چه اجزایی تشکیل می‌شود؟

ساختار همهٔ دیزاین‌سیستم‌ها یکسان نیست. برای شناخت آن‌ها می‌توان اجزایشان را در چند لایه بررسی کرد.

۱. اصول و مبانی طراحی

اصول طراحی جهت تصمیم‌گیری را روشن می‌کنند. برای مثال، تیم ممکن است «وضوح در انجام کارهای حساس» را یک اصل بداند و بر همین اساس، متن و مراحل تأیید عملیات را طراحی کند.

مبانی بصری نیز شامل رنگ‌ها، تایپوگرافی، فاصله‌گذاری، چیدمان و سایر تصمیم‌های پایه هستند. در GOV.UK Design System، بخشی مستقل برای راهنمای سبک‌ها در کنار کامپوننت‌ها و الگوها وجود دارد.

۲. دیزاین توکن‌ها

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

مثلاً نام فرضی «رنگ متن خطا» توضیح می‌دهد رنگ برای چه کاری است. در تم روشن و تاریک، مقدار آن می‌تواند متفاوت باشد، درحالی‌که نقش آن ثابت می‌ماند. مستندات توکن‌های رنگ Carbon نمونه‌ای واقعی از این رویکرد است.

۳. کامپوننت‌ها

کامپوننت‌ها اجزای تکرارشوندهٔ رابط کاربری مانند دکمه، فیلد ورودی، چک‌باکس و تب هستند.

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

۴. الگوهای طراحی

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

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

۵. مستندات و راهنمای محتوا

مستندات باید به سؤال‌های عملی تیم پاسخ دهند: این جزء چه زمانی مناسب است؟ چه محدودیت‌هایی دارد؟ متن آن چگونه نوشته می‌شود؟ رفتار آن در شرایط مختلف چیست؟

مثلاً راهنمای دکمه می‌تواند توضیح دهد چرا «ذخیرهٔ تغییرات» در یک موقعیت مشخص از «تأیید» روشن‌تر است. کیفیت این راهنماها تعیین می‌کند اعضای تیم تا چه اندازه می‌توانند بدون حدس‌زدن از سیستم استفاده کنند.

۶. فرایند نگهداری و مشارکت

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

برای نمونه، GOV.UK برای پذیرش کامپوننت‌ها و الگوها معیارهایی مانند مفیدبودن، تکراری‌نبودن، کاربردپذیری و هماهنگی با سیستم دارد. منبع: معیارهای مشارکت GOV.UK

تفاوت دیزاین‌سیستم با UI Kit چیست؟

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

مرز این اصطلاح‌ها در همهٔ محصولات یکسان نیست؛ جدول زیر یک تفکیک کاربردی است.

یک UI Kit می‌تواند بخشی از دیزاین‌سیستم باشد. برای ارزیابی آنچه یک محصول ارائه می‌دهد، بهتر است امکانات و مستنداتش را بررسی کنیم و فقط به نام آن تکیه نکنیم.

دیزاین‌سیستم چه کاربردی دارد؟

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

در عمل، ارزش دیزاین‌سیستم را می‌توان در چند موقعیت دید:

• طراحی صفحات جدید: تصمیم‌های تکراری از قبل مشخص‌اند.

• همکاری طراح و توسعه‌دهنده: نام‌ها، حالت‌ها و رفتارها مرجع مشترک دارند.

• اصلاح اجزای مشترک: تغییرها را می‌توان در یک منبع مدیریت و برای انتشار برنامه‌ریزی کرد.

• ورود اعضای جدید: راهنماها به شناخت تصمیم‌های محصول کمک می‌کنند.

این مزایا به استفادهٔ واقعی تیم از سیستم وابسته‌اند. تغییر یک کامپوننت در فایل طراحی نیز لزوماً نسخهٔ کدنویسی‌شده و همهٔ محصولات را به‌صورت خودکار به‌روز نمی‌کند.

یک مثال واقعی: دکمه در Carbon

Carbon دیزاین‌سیستم متن‌باز IBM برای محصولات و تجربه‌های دیجیتال است و منابع طراحی، راهنما و کد را کنار هم ارائه می‌کند. منبع: Carbon چیست؟

برای دیدن عملکرد یک دیزاین‌سیستم، کافی است مستندات دکمه در Carbon را بررسی کنیم. این صفحه فقط شکل دکمه را نشان نمی‌دهد؛ دربارهٔ نوع دکمه، متن، تعامل و حتی نمایش راست‌به‌چپ توضیح دارد.

حالا یک سناریوی آموزشی فرضی را در نظر بگیرید: در صفحهٔ تنظیمات حساب، کاربر می‌تواند تغییرات را ذخیره کند یا حسابش را حذف کند. این سناریو مطالعهٔ موردی یک محصول واقعی IBM نیست؛ مثالی برای فهم کاربرد مستندات است.

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

آیا استفاده از دیزاین‌سیستم، دسترس‌پذیری را تضمین می‌کند؟

خیر. اجزایی که با توجه به دسترس‌پذیری طراحی شده‌اند می‌توانند نقطهٔ شروع مناسبی باشند، اما نتیجه به نحوهٔ ترکیب و استفاده از آن‌ها هم وابسته است. راهنمای دسترس‌پذیری Carbon نیز این موضوع را در چارچوب طراحی و ساخت تجربه بررسی می‌کند.

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

چه زمانی به دیزاین‌سیستم نیاز داریم؟

برای تصمیم‌گیری، این پرسش‌ها را مطرح کنید:

• آیا اجزای مشابه بارها با تفاوت‌های ناخواسته ساخته می‌شوند؟

• آیا چند نفر یا چند تیم روی بخش‌های مختلف محصول کار می‌کنند؟

• آیا اصلاح یک الگوی مشترک در صفحات متعدد دشوار شده است؟

• آیا اختلاف میان طراحی و پیاده‌سازی به مسئله‌ای تکراری تبدیل شده است؟

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

برای شروع چه کار کنیم؟

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

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

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

منابع و مطالعهٔ بیشتر

این مقاله با تکیه بر مستندات رسمی زیر نوشته شده است. سناریوی تنظیمات حساب و پیشنهاد مسیر شروع، توضیح‌های آموزشی مقاله‌اند.

1. Carbon — What is Carbon?: تعریف و دامنهٔ دیزاین‌سیستم IBM.

2. GOV.UK Design System: نمونهٔ تفکیک سبک‌ها، کامپوننت‌ها و الگوها.

3. Carbon — Color tokens: نمونهٔ واقعی توکن‌های رنگ.

4. GOV.UK — Patterns: نقش الگوها در انجام کارهای کاربر.

5. GOV.UK — Contribution criteria: معیارهای افزودن و ارزیابی اجزا.

6. Carbon — Button usage: نمونهٔ مستندات کاربرد و رفتار کامپوننت.

7. Carbon — Accessibility overview: راهنمای دسترس‌پذیری در سیستم.