آینده سیستم های طراحی

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

ساخت یک پایه مشترک

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

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

نمونه ایی از اهداف متفاوت طراحی

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

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

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

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

اما در استاندارد سیستم طراحی چه چیز هایی باید باشد؟

تصور کنید یک ابزار است که می تواند مشخص کند که کدام یک از طرح های اولیه (به عنوان مثال، فونت، فاصله، رنگ و غیره)، کامپوننت ها (و وضعیت آنها)، پلتفرم ها، و چه مستندات و تستی مورد نیاز است تا یک سیستم طراحی کاملا تشکیل شده باشد. این ابزار همچنین به طراح اجازه می دهد تا مشخص کند که چه اجزایی هنوز مورد نیاز نیست و چه پلتفرم هایی می تواند بعدا اضافه شود. با استفاده از این ابزار، طراح چارچوبی دارد مشخص کند که چه جنبه هایی از سیستم طراحی کامل شده است یا باقی مانده است. مدیر محصول می تواند مستندات را استخراج کند و یک توسعه دهنده می تواند به راحتی UI را Export و تست کند، و دیگر نیازی به ترجمه UI از Sketch به کد یا از کد وب به پیاده سازی بومی نیست.

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

اول، سیستم طراحی را از هر پیاده سازی خاص جدا می کند. ما در حال ایجاد اجزایReact  یا پیاده سازی های دیگر وب، یا رابط کاربری Android، iOS UI، و یا حتی اسکچ کردن فایل ها نیستیم. در عوض، سیستم ما یک انتزاع است که می تواند برای اجرای هر هدف مورد استفاده قرار گیرد. برای توصیف این سیستم طراحی انتزاعی، ما نیاز به فرمت فایل داریم . فرمت صادر شده می تواند به View ها با ماژول های منبع باز مخصوص اهداف پیاده سازی ترجمه شود.

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

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

بعدا، ما باید تمام اجزای مشترک UI را که امروزه استفاده می شود، فهرست کنیم. درست همانطور که یک فونت ممکن است با حفظ معنا تایپ فایس های متفاوتی داشته باشد. یک فایل .dang می تواند یک کامپوننت متن داشته باشد که با ویژگی ها نمایش تصویری متفاوت است، اما عملکرد آن متفاوت نیست. کاتالوگ نیاز به گروه بندی اجزای همراه با حالت های خود (انتخاب شده، فکوس شده،  خطا و غیره) و تعامل جزئیات برای تشخیص بین موبایل، دسکتاپ و UI تلویزیون دارد.

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

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

ایجاد یک منبع منحصر به فرد

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

برای رسیدن به یک منبع (Source of Truth)، دو مانع وجود دارد. اول، ابزار طراحی کنونی ما ناقص است. اغلب به ما فقط اجازه می دهند تا تصاویر UI تولید کنیم و از طراحان برای دستیابی به سطح وفاداری محصول جلوگیری می کنند. دوم اینکه اگر پیاده سازی یک سیستم طراحی در چندین مخازن (آندروید، iOS، React Native، React و غیره)، در یک فایل Sketch جمع آوری شده و در یک وب سایت مستند شده باشد، در واقع، هیچ پایگاه کد برای نشان دادن یک منبع درست وجود ندارد. بدون یک منبع منحصر به فرد، سیستم طراحی – گسترش بیش از چند پایگاه های کدبندی – تبدیل به یک ملغمه از منابع است که به راحتی  همگام سازی نمی شود.

ابزارهای طراحی سیستم

طراحان از ابزارهایی مانند Sketch، Illustrator یا Photoshop استفاده می کنند تا تصاویر UI ها را طراحی کنند، اما این ها در واقع فقط نمایه های اجزای تعاملی هستند که متفاوت به نظر می رسند، متفاوت رفتار می کنند و حاوی داده های متفاوتی هستند که بسته به وضعیت برنامه در یک زمان معین عمل می کنند. که گاه دیده می شود تعدادی از تعاملات ساده که در تقریبا تمام محصولات رایج هستند، نمی توانند از طریق ابزار طراحی ما ارتباط برقرار کنند.

Sketch های برنامه ها به توسعه دهندگان منتقل می شود که باید آنها را به UI قابل استفاده تبدیل کنند. طراح و 4 توسعه دهنده تا تبدیل طراحی به اندروید، iOS، React Native و React نیاز است. پنج عضو مختلف از تیم شروع به ساخت طراحی می کنند تا به سطح صحت محصول برسند. از آنجا که طرح اولیه اطلاعات مربوط به وضعیت و تعاملات را از قلم انداخته است، برای ایجاد طرح آماده سازی، یک مکالمه مدار و بین طراح و چند توسعه دهنده مورد نیاز است. و چون اجرای آن توسط 4 انسان متفاوت است، احتمال دارد که به تغییرات ناخواسته در هر یک از پیاده سازی ها منجر شود.

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

پیاده سازی چندگانه

تلاش برای رسیدن به یک منبع صحیح، هنگام کار بر روی سیستم های طراحی چندین پلتفرم پیچیده تر است. با استفاده از React Sketch.app، فایل های Sketch  لایه ای را می توان از کدبندی React ایجاد کرد. این بدان معنی است که اجزاء موجود در Airbnb React repo، که قبلا دارای سطح صحت (fidelity) محصول هستند، می توانند با داده های واقعی ذخیره شوند و به یک فایل Sketch رندر شوند. پاداش دیگری برای طراحان ماجراجو است که مایل به یادگیری React هستند.

این همچنین یک سنگ محک تکنولوژی است که ما را به سمت فهمیدن مدل ها به عنوان منبع صحیح هدایت می کند، اما در عوض  به عنوان هدف دیگری برای خروجی خودکار است. با استفاده از این فایل های تولید شده، ما یک تصویر واضح داریم که نشان می دهد که اجزای سازنده در repo چه هستند. از همه مهمتر، یک طراح محصول با تکیه بر Sketch، مجبور نیست که جریان کاری خود را تغییر دهد و می تواند از فایل های دقیق تر (تولید شده توسط codebase ، نه به صورت دستی) برای ساختن کارشان استفاده کند. در نهایت، ما می توانیم اعتماد کنیم که چگونه اجزاء به سطح صحت محصول نگاه می کنند و چگونه این اجزاء با داده های واقعی رفتار می کنند.

React Sketch.app عالی است، زیرا فایلهای طراحی React and React Native Syntax و طراحی سیستم Airbnb را طراحی می کند. اما در مورد پیاده سازی Android و iOS چه؟ طراحان چگونه می توانند مطمئن شوند که این همگام هستند؟ React Sketch.app راه را نشان می دهد، اما ما باید بیشتر پیش برویم.

در اینجا می توانیم از ابزار ها و WYSIWYG های اخیر مانند Dreamweaver و Interface Builder یاد بگیریم. ابزارهای این گروه به کاربران اجازه می دهند تا عناصری از رابط کاربر را ترکیب کنند، UI را به اطلاعات و تعامل متصل کنند، و سپس کد قابل استفاده را صادر کنند. متاسفانه، این نرم افزارها تولید کننده کد هستند که توسط انسان قابل نگهداری نیست و بنابراین تعداد کمی از شرکت ها از آنها به عنوان بخشی رسمی از فرآیند آنها استفاده می کنند. آیا این ابزارها بیش از حد وعده داده اند و خیلی کم بر آورده کرده اند؟

خوشبختانه، اجزای سیستم طراحی، نمایش ساده با حداقل منطق است. بر خلاف وعده ابزارهایی مانند Dreamweaver و Interface Builder، اجزاء به راحتی فایل های View صادر می شوند که شرکای توسعه دهنده می توانند در جریان کار موجود قرار بگیرند.

حل دو مشکل با یک ابزار

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

همانطور که در بخش بالا مشخص شده است، اگر ما یک فرمت خروجی که حاوی وفاداری سطح تولید برای اجزای سازنده است، استاندارد کنیم، سپس دیگر ماژول های مترجم را می توان آزادانه برای کامپایل کردن یک فایل تک مؤلفه در تمام موارد مختلف تولید ایجاد کرد. پس از آن، پیاده سازی های متنوع هر مؤلفه ای از یک منبع جریان می گیرد و به جریان کاری موجود اضافه می شود – صرفه جویی در منابع انسانی و تفسیر خطا از تفکر انسانی از مدل UI. طراحان محصول و طراحان سیستم طراحی در نهایت کنترل UI را که همیشه مسئول آن هستند، کنترل می کنند.

چرخه حلقه بازخورد

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

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

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

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

طرح بندی آگاهانه

یکی دیگر از جهت گیری های امیدوار کننده برای اجزای سازنده این است که تا حدودی layout aware باشد و پس از آن، قصد استفاده از این دو سیستم به طور گسترده و همچنین اجزای هم نیا مشخص شود. با توجه به این سیستم طراحی فوق العاده قدرتمند، اجزای سیستم طراحی می توانند در جایی که به طور کلی از آنها استفاده می شود و سپس اطلاعات مربوط به نوع داده هایی که آنها معمولا شامل می شوند، را به اشتراک بگذارند. حتی یک پیاده سازی ساده از این قابلیت به طراحان کمک می کند فورا مجموعه داده های انتزاعی را مبادله کنند برای مثال، ببینید که چگونه ترجمه ممکن است روی طرح یک مؤلفه خاص با توجه به زبان مانند زبان آلمانی (طولانی تر) و یا زبان راست به چپ مانند عربی تاثیر گذارد.

این آگاهی حتی می تواند یک گام به جلو تر رود. با یک مؤلفه مشخص نشان دهد که چه نوع صفحه نمایش یا تعاملات نمایشگری ممکن است. این آگاهی امکان مونتاژ پیش بینی شده را فراهم می کند.

نتیجه

از طراحان محصول دیجیتال خواسته شده تا امواج تغییر در صنعت سوار شوند. افرادی که سوار این موج بودند به تیم های توسعه کوچک کمک کردند تا برنامه های کاربردی برای رایانه های رومیزی را در دهه 1980 ایجاد کنند. در اواخر دهه 1990، طراحان دیگر، ائتلافی را تشکیل دادند که به شرکتهای بزرگ نرم افزاری برای ایجاد یکپارچه سازی وب سایت از طریق پروژه استاندارد وب کمک کردند. در اواسط سال 2000، در هنگام ایجاد الگوهای برای ایجاد برنامه های وب، روی ارتباطات و محتوای تولید شده کاربر تمرکز کردند، و فقط کمی بعد، تمام کارها در فاکتورهای فرم موبایل مثل آیفون موجود بود. اکنون، پس از تقریبا 4 دهه از محاسبات طراحی شده، سیستم های طراحی و AI دست به دست هم می دهند – ما فرصت های جدیدی برای نوآوری داریم.

چگونه می توانیم با هم کار کنیم تا جریان های کاری را بهبود بخشیم و طرح های مقیاس پذیر را بهتر کنیم؟ چه چیزی باید در یک سیستم استاندارد طراحی و چه نوع ابزارهایی در صورت وجود چنین استانداردهایی وجود داشته باشد؟ چگونه سیستم ها و AI را طراحی می کنند تا تعاملات بسیار سفارشی برای کاربران نهایی ایجاد کنند؟ سوالات زیادی وجود دارد، و هر پاسخ به یک آینده احتمالی اشاره دارد. چیزی که من در مورد طراحی آن را دوست دارم، این است که هر یک از ما را قادر می سازد تا ایده هایی که احساس می کنیم بیشترین تأثیر را داشته باشند، کشف کنیم و ایده هایمان را به سمت بیرون و آینده انتقال دهیم. چون نوآوری ناگزیر است.