سیستمهای طراحی: چرا بیشترشان شکست میخورند و چگونه سیستمی بسازیم که کار کند
بیشتر سیستمهای طراحی در عرض یک سال از بین میروند. در اینجا دلایل شکست آنها، ویژگیهای مشترک سیستمهای موفق، و نحوه ساخت سیستمی که تیم شما واقعاً از آن استفاده کند، آورده شده است.
هر تیمی که به اندازه مشخصی میرسد، در نهایت یک چیز را میگوید: "ما به یک سیستم طراحی نیاز داریم." سپس بیشتر آنها شش ماه را صرف ساخت سیستمی میکنند که هیچکس از آن استفاده نمیکند، و یک سال بعد دوباره به همان ناسازگاری اولیه بازمیگردند.
مشکل هرگز کامپوننتها نیستند. مشکل این است که یک سیستم طراحی را به جای یک محصول، مانند یک پروژه در نظر میگیریم. پروژهها به پایان میرسند. محصولات تکامل مییابند. یک سیستم طراحی که از تکامل بازمیایستد، از همان روز راهاندازی شروع به مردن میکند.
سیستم طراحی واقعاً چیست؟
یک سیستم طراحی، کتابخانه کامپوننت نیست. کتابخانه کامپوننت، پوشهای از قطعات رابط کاربری قابل استفاده مجدد است. یک سیستم طراحی، مجموعه کاملی از استانداردها، مستندات و ابزارهایی است که نحوه طراحی و ساخت یک محصول را کنترل میکند.
این شامل موارد زیر است:
- توکنهای طراحی. مقادیر اتمی (رنگها، فواصل، تایپوگرافی، سایهها) که همه چیز به آنها ارجاع میدهد.
- کامپوننتها. عناصر رابط کاربری قابل استفاده مجدد که از توکنها ساخته شدهاند.
- الگوها. راهحلهای مستند شده برای مشکلات طراحی تکراری (فرمها، ناوبری، حالتهای خطا).
- دستورالعملها. قوانینی برای زمان و نحوه استفاده از هر قطعه.
- حاکمیت. چه کسی مالک سیستم است، چگونه تغییرات پیشنهاد میشوند، و چگونه تصمیمگیریها انجام میشوند.
هر یک از این موارد را حذف کنید، یک سیستم ناقص خواهید داشت. سیستمهای ناقص، پذیرش ناقص ایجاد میکنند. پذیرش ناقص، همان ناسازگاری را ایجاد میکند که شما سعی در حل آن داشتید.
چرا بیشتر سیستمهای طراحی شکست میخورند
شکست ۱: ساخت در انزوا. یک تیم کوچک برای سه ماه ناپدید میشود، یک سیستم زیبا میسازد و آن را به سازمانی ارائه میدهد که هیچ ورودی در آن نداشته است. سیستم، فرضیات سازندگان را منعکس میکند، نه واقعیت کاربران را. پذیرش در ابتدا مودبانه است، سپس به آرامی کنار گذاشته میشود.
شکست ۲: بیش از حد سفت و سخت در اوایل کار. سیستم با قوانین سختگیرانه برای هر سناریو راهاندازی میشود. طراحان و مهندسانی که با موردی مواجه میشوند که سیستم پیشبینی نکرده است، دو گزینه دارند: با سیستم مبارزه کنند یا آن را دور بزنند. بیشتر آنها دور زدن را انتخاب میکنند. سیستم به مرجعی تبدیل میشود که هیچکس به آن مراجعه نمیکند.
شکست ۳: عدم مالکیت اختصاصی. سیستم در طول یک اسپرینت ساخته شد. هیچکس برای نگهداری آن تعیین نشده است. توکنها از کدبیس فاصله میگیرند. کامپوننتها از محصول عقب میمانند. مستندات منسوخ میشوند. شش ماه بعد، سیستم تصویری از آنچه محصول سال گذشته به نظر میرسید، است.
شکست ۴: تفکر کامپوننت-محور. تیم قبل از تعریف حتی یک توکن یا نوشتن حتی یک دستورالعمل، ۴۷ کامپوننت میسازد. کامپوننتها در فایل Figma کار میکنند اما در محیط تولید خراب میشوند، زیرا مقادیر زیربنایی هرگز سیستماتیک نشده بودند.
شکست ۵: فلج کمالگرایی. تیم سعی میکند قبل از راهاندازی هر چیزی، هر مورد خاص را حل کند. سیستم هرگز منتشر نمیشود. در همین حال، محصول روزانه بدون آن منتشر میشود.
سیستمهای موفق چه ویژگیهای مشترکی دارند
پس از مطالعه سیستمهایی که واقعاً دوام میآورند (Shopify Polaris, Atlassian Design System, IBM Carbon, GitHub Primer)، سه الگو پدیدار میشوند:
آنها کوچک شروع کردند و رشد کردند. هیچکدام از آنها با ۲۰۰ کامپوننت راهاندازی نشدند. آنها با توکنها، چند کامپوننت اصلی و مستندات واضح شروع کردند. سپس بر اساس نیازهای واقعی محصول گسترش یافتند، نه بر اساس کمال نظری.
آنها تیمهای اختصاصی دارند. نه یک نفر. یک تیم. سیستمهای طراحی در مقیاس بزرگ حداقل به یک طراح، یک مهندس، یک نویسنده مستندات و یک مالک محصول نیاز دارند. Shopify دهها نفر را روی Polaris دارد. شما به دهها نفر نیاز ندارید، اما به بیش از صفر نفر نیاز دارید.
آنها مشارکتها را به عنوان یک ویژگی در نظر میگیرند. بهترین سیستمها این امکان را برای تیمهای محصول فراهم میکنند که به راحتی اضافات را پیشنهاد دهند، مشکلات را گزارش کنند و کامپوننتها را مشارکت دهند. سیستم از لبهها رشد میکند، نه فقط از مرکز. سیستمی که فقط از تصمیمات یک تیم رشد میکند، همیشه از محصول عقب خواهد ماند.
توکنهای طراحی، پایه و اساس واقعی هستند
توکنها مقادیر اولیه هستند که همه چیز از آنها به ارث میبرد. یک توکن را تغییر دهید، و هر کامپوننتی که به آن ارجاع میدهد، به طور خودکار بهروزرسانی میشود. این چیزی است که یک سیستم را به جای یک مجموعه، به یک سیستم تبدیل میکند.
سطوح توکن:
| سطح | مثال | هدف |
|---|---|---|
| سراسری | color-blue-500: #3B82F6 | مقادیر خام پالت |
| معنایی | color-primary: {color-blue-500} | نامهای مستعار مبتنی بر معنی |
| کامپوننت | button-bg: {color-primary} | پیوندهای خاص کامپوننت |
توکنهای سراسری مقادیر خام را تعریف میکنند. توکنهای معنایی معنی (اصلی، خطر، سطح) را اختصاص میدهند. توکنهای کامپوننت آن معانی را به عناصر رابط کاربری خاصی پیوند میدهند. این ساختار سهلایه به این معنی است که میتوانید با تغییر توکنهای معنایی، بدون دست زدن به حتی یک کامپوننت، برند خود را تغییر دهید.
انواع توکنهایی که ابتدا باید تعریف شوند:
- رنگها (پسزمینه، متن، حاشیه، حالتهای تعاملی)
- فواصل (شبکه ۴ پیکسلی: ۴، ۸، ۱۲، ۱۶، ۲۴، ۳۲، ۴۸، ۶۴)
- تایپوگرافی (خانواده، مقیاس اندازه، وزن، ارتفاع خط)
- شعاع حاشیه (هیچ، کوچک، متوسط، بزرگ، کامل)
- سایهها (سطوح ارتفاع)
- حرکت (مدت زمان، منحنیهای تسهیل)
اگر هیچ چیز دیگری را تعریف نمیکنید، اینها را تعریف کنید. آنها ۹۰٪ از تصمیمات بصری تیم شما را که روزانه گرفته میشوند، پوشش میدهند.
ساخت کامپوننتهایی که دوام میآورند
کامپوننتهایی که بر اساس توکنها ساخته شدهاند، ذاتاً مقاومتر از کامپوننتهایی هستند که بر اساس مقادیر کدگذاری شده سخت ساخته شدهاند. اما حتی کامپوننتهای مبتنی بر توکن نیز اگر اشتباه ساخته شوند، شکست میخورند.
قوانین برای کامپوننتهایی که دوام میآورند:
ترکیب بر پیکربندی. یک دکمه با ۱۴ ویژگی (props) انعطافپذیر نیست. شکننده است. به جای ساخت یک مگا-کامپوننت که هر نوع را از طریق ویژگیها مدیریت میکند، قطعات کوچک و قابل ترکیب بسازید که به الگوها تبدیل شوند. یک کارت یک کامپوننت نیست. بلکه یک کانتینر کارت، یک سربرگ کارت، یک بدنه کارت و یک پاورقی کارت است که با هم ترکیب میشوند.
حالتها اختیاری نیستند. هر کامپوننت تعاملی به حالتهای: پیشفرض، هاور، فعال، فوکوس، غیرفعال، بارگذاری و خطا نیاز دارد. انتشار یک کامپوننت بدون هر هفت حالت به این معنی است که کسی آن حالتها را به صورت موقت خواهد ساخت، و آنها با هم مطابقت نخواهند داشت.
"چه زمانی" را مستند کنید، نه فقط "چه چیزی" را. مستندات دکمه شما نباید فقط نشان دهد که چگونه به نظر میرسد. باید بگوید چه زمانی از دکمه اصلی در مقابل دکمه ثانویه در مقابل دکمه شبح استفاده کنید. چارچوب تصمیمگیری مهمتر از مرجع بصری است.
الگوها مشکلاتی را حل میکنند که کامپوننتها نمیتوانند
یک کامپوننت دراپداون به شما میگوید که یک دراپداون چگونه به نظر میرسد. اما به شما نمیگوید چه زمانی از دراپداون در مقابل گروه رادیویی در مقابل کنترل سگمنتی استفاده کنید. این تصمیم یک الگو است.
الگوهایی که باید زودتر مستند شوند:
- طرحبندی فرمها. جایگذاری برچسب، نمایش خطا، نشانگر فیلد اجباری، جریانهای چند مرحلهای.
- ناوبری. چه زمانی از تبها در مقابل نوار کناری در مقابل بردکرامبها استفاده کنیم. رفتار جمعشدن ناوبری موبایل.
- حالتهای خالی. چه چیزی نمایش داده شود وقتی دادهای وجود ندارد. تصویرسازی؟ فراخوان به عمل؟ محتوای آموزشی؟
- حالتهای بارگذاری. صفحههای اسکلتی در مقابل اسپینرها در مقابل بارگذاری تدریجی. چه زمانی هر کدام مناسب است.
- مدیریت خطا. اعتبارسنجی درون خطی در مقابل اعلانهای توست در مقابل حالتهای خطای تمام صفحه.
این الگوها از مشکل "ما همان فرم را به پنج روش مختلف ساختیم" که تیمهای بدون سیستم را آزار میدهد، جلوگیری میکنند.
حاکمیت، پذیرش را میسازد یا از بین میبرد
یک سیستم طراحی بدون حاکمیت، فقط یک پیشنهاد است. حاکمیت به سه سوال پاسخ میدهد:
۱. چه کسی تصمیم میگیرد؟ آیا هیئت بازبینی وجود دارد؟ یک مالک واحد؟ یک رایگیری دموکراتیک؟ هر چه را انتخاب میکنید، آن را صریح بیان کنید. ۲. تغییرات چگونه اتفاق میافتند؟ فرآیند RFC؟ مشکل GitHub؟ رشته Slack؟ مسیر را از "فکر میکنم به یک کامپوننت جدید نیاز داریم" تا "آن در سیستم است" تعریف کنید. ۳. استراتژی نسخهبندی چیست؟ نسخهبندی معنایی برای بسته توکن؟ گزارش تغییرات برای هر انتشار؟ سیاست تغییرات مخرب؟
تیمهایی که از حاکمیت صرفنظر میکنند، در نهایت سیستمی دارند که شاخه شاخه میشود. طراحی از نسخه ۲.۳ استفاده میکند. مهندسی از نسخه ۱.۸ استفاده میکند. سایت بازاریابی از نسخه ۲.۰ با تغییرات محلی استفاده میکند. در آن مرحله، شما سه سیستم طراحی و صفر سازگاری دارید.
سوالات متداول
ساخت یک سیستم طراحی چقدر طول میکشد؟
پایه و اساس اولیه (توکنها، ۱۰-۱۵ کامپوننت اصلی، مستندات پایه) با یک تیم اختصاصی ۲-۴ ماه طول میکشد. اما یک سیستم طراحی هرگز "تمام شده" نیست. برای سرمایهگذاری مداوم ۱۵-۲۵٪ از ظرفیت تیم مهندسی طراحی برنامهریزی کنید.
آیا تیمهای کوچک به سیستم طراحی نیاز دارند؟
بله، اما متناسب با اندازه خود. یک تیم ۳ نفره به Polaris نیاز ندارد. آنها به یک کتابخانه مشترک Figma با توکنها، ۸-۱۰ کامپوننت اصلی و یک راهنمای تصمیمگیری یک صفحهای نیاز دارند. با آنچه بیشترین مشکل را ایجاد میکند (معمولاً فواصل و استفاده ناسازگار از رنگ) شروع کنید و از آنجا گسترش دهید.
تفاوت بین سیستم طراحی و کتابخانه کامپوننت چیست؟
کتابخانه کامپوننت مجموعهای از عناصر رابط کاربری قابل استفاده مجدد است. یک سیستم طراحی شامل کتابخانه کامپوننت به علاوه توکنهای طراحی، دستورالعملهای استفاده، الگوها، مستندات و حاکمیت است. کتابخانه یک لایه از سیستم است.
با درد شروع کنید، نه با جاهطلبی
یک سیستم طراحی را به این دلیل که حرفهای به نظر میرسد، نسازید. آن را بسازید چون تیم شما وقت خود را صرف حل مکرر مشکلات مشابه میکند. با سه چیزی شروع کنید که در حال حاضر بیشترین ناسازگاری را ایجاد میکنند. آنها را سیستماتیک کنید. منتشرشان کنید. سپس بر اساس آنچه تیم در مرحله بعد درخواست میکند، گسترش دهید، نه بر اساس آنچه در یک مطالعه موردی چشمگیر به نظر میرسد.
Need a design system that scales with your product? We build those.
Get Started
