سیستمهای طراحی در حال تبدیل شدن به زیرساخت محصول هستند، نه صرفاً کتابخانههای UI
سیستمهای طراحی قبلاً به عنوان پروژهای برای ایجاد یکپارچگی مطرح میشدند. یک کتابخانه کامپوننت مشترک بسازید، برخی اختلافات تایپوگرافی را حل کنید، دکمهها را استاندارد کنید و صفحات یکبار مصرف کمتری منتشر کنید. این رویکرد دیگر کافی نیست. در سازمانهای نرمافزاری مدرن، سیستم طراحی در حال تبدیل شدن به زیرساخت است: لایهای که تصمیمات طراحی، پیادهسازی مهندسی، قوانین دسترسیپذیری، تمسازی، تولید کد با کمک هوش مصنوعی و حاکمیت انتشار را به هم متصل میکند.
این تغییر اهمیت دارد زیرا تیمهای محصول اکنون در سطوح، برندها و وضعیتهای بیشتری نسبت به آنچه یک راهنمای استایل ثابت میتواند به طور واقعبینانه مدیریت کند، محصول میسازند. آنها وباپلیکیشنها، اپلیکیشنهای موبایل، جریانهای تعبیهشده، سطوح بازاریابی، ابزارهای مدیریتی و به طور فزایندهای رابطهای کاربری تولید شده یا با کمک هوش مصنوعی را منتشر میکنند. سوال این نیست که آیا یک دکمه در همه جا یکسان به نظر میرسد. سوال این است که آیا سازمان محصول یک منبع حقیقت قابل خواندن توسط ماشین دارد که بتواند تیمهای زیادی را در حالی که نرمافزار به طور مداوم تغییر میکند، همسو نگه دارد.
کامپوننتها فصل اول بودند، نه تمام داستان
یک کتابخانه کامپوننت هنوز اهمیت دارد، اما فقط لایه قابل مشاهده است. ارزش عمیقتر در design tokenها، معناشناسی و محدودیتها نهفته است. هنگامی که یک شرکت شروع به توصیف رنگ، فاصله، حرکت، تایپوگرافی، وضعیتها و رفتار دسترسیپذیری به عنوان دادههای سیستمی ساختاریافته به جای ترجیحات بصری پراکنده میکند، سیستم طراحی بسیار قدرتمندتر میشود. دیگر یک کیت نیست و شروع به تبدیل شدن به یک قرارداد میکند.
به همین دلیل است که حرکت رو به رشد پیرامون استانداردهای design token اهمیت دارد. گروه جامعه Design Tokens در W3C در حال کار بر روی یک فرمت مستقل از فروشنده برای تصمیمات طراحی قابل حمل بوده است، و صنعت به طور فزایندهای design tokenها را به عنوان بافت همبند بین Figma، Frameworkهای فرانتاند، پایگاههای کد موبایل و سیستمهای مستندسازی در نظر میگیرد. این یکی از آن داستانهای استانداردهای خستهکننده است که بیسروصدا نحوه کار تیمها را تغییر میدهد. یک design token مفیدتر از یک اسکرینشات است زیرا نرمافزار واقعاً میتواند آن را اعمال کند.
تبدیل طراحی به کد، کیفیت سیستم را به یک عامل چندبرابرکننده تبدیل میکند
ابزارهای هوش مصنوعی و محصولاتی مانند Figma Make، گردش کار بهبود یافته Dev Mode و پلتفرمهای طراحی آگاه به کد، این انتقال را تسریع میکنند. هنگامی که تیمها میتوانند از قصد طراحی ساختاریافته به نمونههای اولیه کارآمد یا پیشنهادهای کد سریعتر حرکت کنند، کیفیت سیستم زیربنایی اهمیت بیشتری پیدا میکند. یک سیستم طراحی نامرتب اکنون آسیبهای پاییندستی بزرگتری ایجاد میکند، زیرا اتوماسیون ناهماهنگی را به همان اندازه کارآمدی که کیفیت را مقیاسپذیر میکند، مقیاسپذیر میکند.
این دلیل استراتژیک تبدیل شدن سیستمهای طراحی به زیرساخت است. آنها دیگر فقط برای انسانهایی که دستورالعملها را میخوانند نیستند. آنها به طور فزایندهای ورودی برای ابزارها هستند. اگر یک دستیار کدنویسی هوش مصنوعی، یک تولیدکننده کد، یا یک فرآیند همگامسازی طراحی به توسعه قرار است UI را با سرعت تولید کند، به یک واژگان قابل اعتماد برای اینکه محصول چگونه باید به نظر برسد و کامپوننتها چگونه باید رفتار کنند، نیاز دارد.
دسترسیپذیری و تمسازی تنها زمانی آسانتر میشوند که سیستم واقعی باشد
سازمانها اغلب درباره دسترسیپذیری و تمسازی چندبرندی طوری صحبت میکنند که گویی ابتکارات جداگانهای هستند. در عمل، هر دو آزمونی هستند برای اینکه آیا سیستم طراحی یک زیرساخت واقعی است یا فقط یک اثر هنری مشترک. یک سیستم واقعی الزامات کنتراست، رفتار فوکوس، ترجیحات حرکتی، محدودیتهای چیدمان و نامگذاری معنایی را به اندازه کافی خوب کدگذاری میکند تا تیمها بتوانند با اطمینان در زمینههای مختلف سازگار شوند. یک سیستم سطحی هر تیم محصول را مجبور میکند تا آن قوانین را به صورت دستی دوباره کشف کند.
این امر به ویژه برای نرمافزارهای سازمانی (enterprise software) مهم است، جایی که محصولات اغلب به پشتیبانی white-label، حالت تاریک (dark mode)، برندسازی منطقهای، فرمهای پیچیده و صفحات داخلی با عمر طولانی که در طول سالها تکامل مییابند، نیاز دارند. بدون یک لایه سیستمی محکم، هر تنوع به یک انشعاب محلی (local fork) تبدیل میشود. با گذشت زمان، این انشعابات به بدهی نگهداری تبدیل میشوند. یک سیستم طراحی قوی، تنوع را به پیکربندی (configuration) تبدیل میکند به جای تکهتکه شدن (fragmentation).
مدل قدیمی تحویل (handoff) در حال فروپاشی است
یکی از دلایلی که این دسته اکنون فوریت بیشتری پیدا کرده است، این است که آیین قدیمی تحویل طراحی (design handoff) در حال کمفایده شدن است. در بسیاری از تیمها، گلوگاه دیگر این نیست که مهندسی نمیتواند یک ماکت را بررسی کند. گلوگاه این است که قصد طراحی بین ابزارها، فشارهای اسپرینت و تصمیمات محلی تکراری گم میشود. تحویل استاتیک برای آن محیط بسیار کند است.
تفکر زیرساختی هدف را تغییر میدهد. به جای پرسیدن اینکه آیا مهندس آخرین فایل را دارد، تیمها میپرسند که آیا قوانین طراحی، کامپوننتهای کد، مستندات و معیارهای پذیرش به اندازه کافی به هم متصل هستند تا تفسیر را کاهش دهند. این کمتر از "همکاری بهتر" رمانتیک به نظر میرسد، اما بسیار عملیتر است. بهترین سیستمها تعداد تصمیمات قضاوتی را که افراد باید تحت فشار مهلت انجام دهند، کاهش میدهند.
حاکمیت اکنون به اندازه مهارت مهم است
اینجاست که بسیاری از شرکتها هنوز با مشکل مواجه هستند. آنها در اولین نسخه پر زرق و برق یک سیستم طراحی سرمایهگذاری میکنند، سپس در حاکمیت کمسرمایهگذاری میکنند. اما زیرساخت بدون نظارت به سرعت از بین میرود. کسی باید مالکیت نسخهبندی، مهاجرت، منسوخسازی، بررسی کامپوننت، قوانین مشارکت و معیارهای پذیرش را بر عهده بگیرد. کسی باید تصمیم بگیرد که چه زمانی یک استثنای محلی توجیه میشود و چه زمانی بدهی سیستمی ایجاد میکند.
آن کار حاکمیتی پر زرق و برق نیست، با این حال اینجاست که سیستمهای طراحی ارزش تجاری خود را به دست میآورند. یک سیستم تنها زمانی زیرساخت است که مردم به اندازه کافی به آن اعتماد کنند تا به آن وابسته باشند. اعتماد از قابلیت اطمینان، مدیریت تغییر و مستنداتی حاصل میشود که به تیمها کمک میکند بدون باز کردن یک Slack thread دیگر تصمیم بگیرند.
تیمهای نرمافزاری چه کارهایی را باید متفاوت انجام دهند
اگر سیستم طراحی شما هنوز مانند یک وبسایت گالری رفتار میکند، گام بعدی این است که با آن مانند یک محصول با رابطها و مصرفکنندگان رفتار کنید. بررسی کنید که چه چیزی واقعاً به عنوان منطق قابل استفاده مجدد کدگذاری شده است. تصمیمات بصری را در صورت امکان به design tokenها و لایههای معنایی منتقل کنید. مستندات سیستم را به پیادهسازی گره بزنید به جای اینکه آن را به عنوان یک جهان موازی رها کنید. پذیرش را در سطح کامپوننت و گردش کار اندازهگیری کنید، نه فقط با شمارش داراییهای Figma.
همچنین ارزش دارد که سیستم را به صراحت برای اتوماسیون طراحی کنید. بپرسید که آیا یک دستیار کدنویسی یا تولیدکننده میتواند از قوانین شما بدون ترجمه انسانی استفاده کند. اگر پاسخ منفی است، سیستم احتمالاً بیش از حد به دانش قبیلهای (tribal knowledge) وابسته است. در عصر ایجاد نرمافزار با کمک هوش مصنوعی، قضاوت مستند نشده به یک مشکل مقیاسپذیری تبدیل میشود.
چرا این موضوع اکنون بیش از پنج سال پیش اهمیت دارد
تیمهای نرمافزاری سریعتر، در کانالهای بیشتر، با مشارکتکنندگان بیشتری که ممکن است زمینه مهارت یکسانی نداشته باشند، محصول منتشر میکنند. در همین حال، ابزارهای طراحی و ابزارهای توسعهدهنده در حال ادغام با یکدیگر هستند. در چنین محیطی، هزینه نداشتن یک سیستم واقعی به سرعت افزایش مییابد. UI drift به نویز عملیاتی تبدیل میشود. باگهای دسترسیپذیری تکثیر میشوند. تمسازی خراب میشود. کد تولید شده به اندازه کافی خوب به نظر میرسد که از بررسی عبور کند تا زمانی که ناهماهنگیها انباشته شوند.
به همین دلیل است که سیستمهای طراحی دیگر به راحتی در دسته "داشتن خوب است" قرار نمیگیرند. آنها به طور فزایندهای بخشی از پشته تولید (production stack) هستند. شرکتهایی که این را درک میکنند، فقط اپلیکیشنهای زیباتری نمیسازند. آنها تغییر محصول را ایمنتر، سریعتر و منسجمتر خواهند کرد.
نکات عملی
با سیستم طراحی خود مانند زیرساخت رفتار کنید: نگهداری را تامین مالی کنید، مالکیت را تعیین کنید، design tokenها را استاندارد کنید و مستندات را در هر کجا که ممکن است قابل خواندن توسط ماشین کنید. از آن برای کاهش تصمیمات محلی تکراری استفاده کنید، نه برای برنده شدن در بحثهای زیباییشناختی. اگر سازمان شما در طراحی با کمک هوش مصنوعی یا تولید کد سرمایهگذاری میکند، این کار حتی فوریتر میشود. اتوماسیون نشان خواهد داد که آیا سیستم شما واقعی است یا خیر.