آناتومی یک دیزاین سیستم در سطح سازمانی (Enterprise-Grade)

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

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

اجزای دیزاین سیستم (Design system artifacts)

مهم است توجه داشته باشید که لازم نیست هر دیزاین سیستم برای رقابت با سیستم‌هایی مانند Material یا Polaris که هر کدام به میلیون‌ها مشتری خدمات ارائه می‌دهند، ساخته شود.

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

دیزاین سیستم‌ها به عنوان یک زیرشاخه در تجربه کاربری (UX) به سرعت در حال تحول هستند. اگر اجزای دیگری وجود دارد که فکر می‌کنید باید در این لیست قرار بگیرند، لطفاً به ما اطلاع دهید!

طراحی (Design)

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

۱. اصول طراحی (Design principles)

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

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

یک اصل نمونه می‌تواند این باشد: «ما وضوح و قابلیت استفاده را بر زرق و برق طراحی ترجیح می‌دهیم.» اگر تیم در مورد اینکه آیا باید راهنمای نمودار را نشان دهد یا آن را به نفع تعاملات هوشمندانه با راهنمای ابزار (tooltip) پنهان کند، به بن‌بست رسیده باشد، این اصل باید موضوع را روشن کند.

۲. راهنمای سبک (Style guide)

اگر کسی بپرسد (و قطعاً خواهد پرسید) «ما از چه اندازه فونتی استفاده می‌کنیم؟» یا «رنگ خطای ما چیست؟»، راهنمای سبک باید به آن‌ها کمک کند تا پاسخ خود را بیابند.

برخی از مواردی که راهنمای سبک شامل می‌شود:

• فونت‌ها، اندازه‌ها و وزن‌های آن‌ها
• رنگ‌ها
• مقادیر فاصله‌گذاری و اندازه
• یک سیستم گرید (grid system) برای تراز کردن عناصر صفحه
• ارتفاع و اندازه‌های سایه‌ها
• آیکون‌گرافی (Iconography)

راهنمای سبک نوعی مستندسازی است و معمولاً می‌توان آن را در فایل‌های طراحی در کنار جزء بعدی لیست ما یافت.

۳. کامپوننت‌های رابط کاربری (UI components)

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

نمونه‌هایی از کامپوننت‌های UI عبارتند از:

• دکمه‌ها (Buttons)
• فیلدهای ورودی فرم (Form inputs)
• راهنمای ابزار (Tooltips)

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

۴. کتابخانه الگوها (Pattern library)

کتابخانه‌های الگو اغلب با کامپوننت‌های UI اشتباه گرفته یا تلفیق می‌شوند. در واقعیت، الگوها زمانی به وجود می‌آیند که شما چند کامپوننت UI را برای حل یک مشکل در کنار هم قرار می‌دهید.

یک مثال، «الگوی جستجو» است که ممکن است شامل یک فیلد متنی برای وارد کردن عبارت جستجو، یک دکمه برای ارسال جستجو و یک منوی کشویی برای نمایش گزینه‌های پیش‌بینی جستجو (typeahead) باشد.

الگوهای دیگری که ممکن است بخشی از دیزاین سیستم شما باشند:

• فیلترها (Filters)
• جداول (Tables)
• ناوبری (Navigation)
• کشیدن و رها کردن (Drag and drop)

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

۵. مستندات طراحی (Design documentation)

به عنوان یک حامی دیزاین سیستم، اگر شما شخصاً حضور نداشته باشید تا کسی را در استفاده از سیستم راهنمایی کنید، چگونه ممکن است آن‌ها دانش مورد نیاز برای ارائه راه‌حل‌ها را به دست آورند؟

مستندات می‌توانند اشکال مختلفی داشته باشند. بایدها و نبایدها، دستورالعمل‌های کامپوننت‌ها، مثال‌های استفاده و استانداردهای دسترسی‌پذیری. سایر اجزای طراحی در این لیست نیز می‌توانند به عنوان مستندات در نظر گرفته شوند. با وجود تنوع، هدف یکسان است: گسترش دانش طراحی به صورت ناهمزمان (asynchronously) تا کاربران بتوانند حداکثر ارزشی را که هنگام استفاده از دیزاین سیستم به دست می‌آورند، کسب کنند.

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

توسعه (Development)

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

۱. کتابخانه کامپوننت‌ها (Component library)

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

دستیابی و حفظ برابری (parity) بین کتابخانه UI طراحی و کتابخانه کامپوننت‌های کدنویسی شده، بخش مهمی از مدیریت یک دیزاین سیستم است. تفاوت‌ها بین این دو می‌تواند منجر به عدم هماهنگی و ناهماهنگی در همکاری در طول توسعه شود.

۲. توکن‌های طراحی (Design tokens)

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

توکن‌های طراحی اندازه‌گیری‌ها یا مقادیر اصلی اشیاء طراحی منفرد را گرفته و به آن‌ها معنا می‌بخشند. یک کد رنگ هگزادسیمال مانند #FEFFD5 ممکن است بی‌معنی باشد، اما افزودن لایه‌های معنایی با اعمال توکن‌های طراحی می‌تواند آن را به فرمتی خواناتر برای انسان تبدیل کند، مانند color.page.background.subtle.

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

۳. مستندات توسعه‌دهندگان (Developer documentation)

مشابه مستندات طراحی، مستندات توسعه‌دهندگان برای دیزاین سیستم‌ها می‌توانند انواع مختلفی داشته باشند. قطعه کدها (Code snippets)، دستورالعمل‌های استفاده با مثال‌ها، راهنماهای یکپارچه‌سازی API، دستورالعمل‌های دسترسی‌پذیری و تاریخچه تغییرات (changelog) همگی موارد مهمی هستند که باید بدانید. مستندات توسعه‌دهندگان توسط مهندسان نگهداری می‌شود و می‌تواند در کنار مستندات طراحی برای همان کامپوننت ظاهر شود.

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

عملیات طراحی (Design Operations)

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

۱. نقشه راه دیزاین سیستم (Design system roadmap)

با بالغ‌تر شدن دیزاین سیستم شما، مهم است که آنچه را که انجام می‌دهید و تأثیری که انتظار دارید بر سازمان داشته باشید، اطلاع‌رسانی کنید. نقشه راه دیزاین سیستم یکی از راه‌هایی است که می‌توانید این موضوع را به تیم‌های دیگر اطلاع دهید.

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

۲. حاکمیت دیزاین سیستم (System governance)

چه کسی مسئول تصمیم‌گیری‌های دیزاین سیستم است؟ این فرآیند چگونه است؟ پس از اتخاذ یک تصمیم، چه اقدامات پایین‌دستی به دلیل آن آغاز می‌شود؟

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

۳. دستورالعمل‌های مشارکت (Contribution guidelines)

اینکه کاربران دیزاین سیستم ایده‌ها و عناصر جدیدی به آن اضافه کنند، راهی عالی برای تشویق مشارکت و جمع‌سپاری (crowdsource) کارهایی است که در غیر این صورت تیم دیزاین سیستم باید انجام دهد.

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

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

۴. شاخص‌های عملکرد (Performance indicators)

نمونه‌هایی از شاخص‌های عملکرد معیارهایی مانند نرخ پذیرش (adoption rates)، نرخ مشارکت، رضایت کاربر، نرخ استفاده از کامپوننت‌ها، یا هر اندازه‌گیری دیگری است که می‌تواند به نحوه عملکرد دیزاین سیستم مرتبط باشد.

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

۵. آموزش، کارگاه‌ها و ساعات پاسخگویی (Training, workshops, and office hours)

اگر آن را بسازید، آن‌ها خواهند آمد… درست است؟ نه لزوماً.

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

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

استفاده از اجزای دیزاین سیستم در موقعیت‌های واقعی

داشتن کامپوننت‌های قابل استفاده مجدد، مستنداتی برای مراجعه و فرآیندی برای اینکه چگونه چیزها بخشی از دیزاین سیستم می‌شوند، همگی ایده‌های خوبی به نظر می‌رسند، اما این اجزا به دستیابی به چه اهدافی کمک می‌کنند؟ در اینجا چند مثال آورده شده است.

استفاده از دیزاین سیستم برای بهبود عملکرد یا مقیاس‌پذیری صفحات

عملکرد محصول برای کسب‌وکار و معماری فنی کلی محصول شما مهم است. هیچ‌کس تا به حال نگفته است: «ای کاش این صفحه کندتر بود!» بازسازی (Refactoring) کامپوننت‌ها در یک صفحه برای عملکرد بهتر و آسان‌تر کردن پیاده‌سازی در بلندمدت، یک مورد استفاده واقعی از یک دیزاین سیستم است.

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

اجزایی که می‌توانند به این نتیجه کمک کنند:

• اجزای توسعه‌دهنده (Developer artifacts)
  • کتابخانه کامپوننت‌ها: این‌ها نیازی به گره خوردن به کامپوننت‌های UI طراحی ندارند، تا زمانی که کاربردی باشند و بتوانند در سایر بخش‌های محصول اعمال شوند.
  • مستندات: این برای اطمینان از یکپارچگی با کامپوننت‌هایی که توسعه‌دهندگان می‌سازند و مستقر می‌کنند، مفید است.

استفاده از دیزاین سیستم برای به‌روزرسانی ظاهر و حس بصری محصول

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

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

اجزایی که می‌توانند به این نتیجه کمک کنند:

• اجزای طراح (Designer artifacts)
  • اصول طراحی: داشتن چشم‌اندازی از اینکه طراحی قرار است چگونه باشد، به اطمینان از انسجام اجزای پایین‌دستی کمک می‌کند.
  • راهنمای سبک: این امر زبان طراحی را در سراسر محصول یکپارچه نگه می‌دارد.
  • کامپوننت‌های UI: این تفسیر اتمیک و قابل تکرار از راهنمای سبک است.
  • مستندات: هماهنگی در مورد چگونگی اعمال یکپارچه سبک‌ها در سراسر محصول، نیازمند ثبت سوابق و مستندسازی مواردی است که باید به آن‌ها توجه کرد.

استفاده از دیزاین سیستم برای ایجاد نمونه‌های اولیه سریع و مفاهیم طراحی

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

یکی از سریع‌ترین راه‌ها برای دستیابی به این هدف، کاهش زمان توسعه مفهوم در سمت طراحی با کار بر روی طرح‌های اولیه (sketches) یا وایرفریم‌های (wireframes) با وفاداری پایین (low fidelity) است. توسعه باید بتواند طرح‌های با وفاداری پایین را به کامپوننت‌های آماده ترجمه کند و آن نمونه اولیه را با داده‌های واقعی تغذیه کند. ارائه این به کاربران، بینش‌های ارزشمندی را ایجاد می‌کند که هیچ مقدار بحث داخلی بی‌پایان نمی‌تواند تولید کند.

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

اجزایی که می‌توانند به این نتیجه کمک کنند:

• اجزای طراح (Designer artifacts)
  • اصول طراحی: این‌ها اهداف کلی طراحی را هدایت می‌کنند، اما تعاریف سطح UI را ارائه نمی‌دهند.
  • کامپوننت‌های UI: داشتن مواردی مانند فیلدهای ورودی فرم یا کارت‌های محتوا اگر بخشی از مفهوم طراحی باشند، مفید خواهد بود تا عملکرد آن‌ها به تیم توسعه منتقل شود.
  • کتابخانه الگوها: برای نمونه‌های اولیه اکتشافی قطعاً ضروری نیست، اما اگر این‌ها از قبل وجود داشته باشند و بتوان به آن‌ها ارجاع داد، تعریف مفهوم و توسعه را به شدت تسریع می‌کنند.
• اجزای توسعه‌دهنده (Developer artifacts)
  • کتابخانه کامپوننت‌ها: این‌ها لزوماً نیازی به پیوند با یک کامپوننت UI طراحی ندارند، فقط تا زمانی که کاربردی باشند.

استفاده از دیزاین سیستم برای طراحی و ساخت کارآمدتر محصولات

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

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

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

اجزایی که می‌توانند به این نتیجه کمک کنند:

• اجزای طراح (Designer artifacts)
  • اصول طراحی
  • راهنمای سبک
  • کامپوننت‌های UI
  • کتابخانه الگوها
  • مستندات طراحی
• اجزای توسعه‌دهنده (Developer artifacts)
  • کتابخانه کامپوننت‌ها
  • توکن‌های طراحی
  • مستندات توسعه‌دهندگان
• اجزای عملیات طراحی (Design operations artifacts)
  • نقشه راه دیزاین سیستم
  • حاکمیت دیزاین سیستم
  • دستورالعمل‌های مشارکت
  • شاخص‌های عملکرد
  • آموزش، کارگاه‌ها و ساعات پاسخگویی

جمع‌بندی

اجزای دیزاین سیستم برای سازمان‌های بزرگ باید نیازهای گروه‌هایی را که سیستم به آنها خدمت می‌کند، برآورده سازد و بنابراین یک بسته اولیه (starter pack) وجود ندارد که برای هر گروهی کارساز باشد.

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

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

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

حسین اصلانی