Система автоматического проектирования: системы автоматизированного проектирования: что такое САПР, разновидности, применение, функционал

Система автоматизированного проектирования

Интернет магазин китайских планшетных компьютеров

Компьютеры – Система автоматизированного проектирования 22 января 2011 Оглавление: 1. Система автоматизированного проектирования 2. Цели создания и задачи 3. Состав и структура САПР 4. Классификация САПР автоматизированная система, реализующая информационную технологию выполнения функций проектирования, представляет собой организационно-техническую систему, предназначенную для автоматизации процесса проектирования, состоящую из персонала и комплекса технических, программных и других средств автоматизации его деятельности. Так же для обозначения подобных систем широко используется аббревиатура САПР. Расшифровки и толкования аббревиатуры САПР САПР — система автоматизированного проектирования. Наиболее популярная расшифровка. В современной технической, учебной литературе и государственных стандартах аббревиатура САПР раскрывается именно так. САПР — система автоматизации проектных работ. Такая расшифровка точнее соответствует аббревиатуре, однако более тяжеловесна и используется реже. САПР — система автоматического проектирования. Это неверное толкование. Понятие «автоматический» подразумевает самостоятельную работу системы, без участия человека. А в САПР часть функций выполняет человек, а автоматическими являются только отдельные проектные операции и процедуры. Слово «автоматизированный», по сравнению со словом «автоматический», подчёркивает участие человека в процессе. САПР — программное средство для автоматизации проектирования. Это излишне узкое толкование. В настоящее время часто понимают САПР лишь как прикладное программное обеспечение для осуществления проектной деятельности. Однако в отечественной литературе и государственных стандартах САПР определяется как более ёмкое понятие, включающее не только программные средства. Английский эквивалент Для перевода САПР на английский язык зачастую используется аббревиатура CAD, подразумевающая использование компьютерных технологий в проектировании. Однако в ГОСТ 15971-90 это словосочетание приводится как стандартизированный англоязычный эквивалент термина «автоматизированное проектирование». Понятие CAD не является полным эквивалентом САПР, как организационно-технической системы. Термин САПР на английский язык может также переводится как CAD system, automated design system, CAE system. В ряде зарубежных источников устанавливается определенная соподчиненность понятий CAD, CAE, CAM. Термин CAE определяется как наиболее общее понятие, включающее любое использование компьютерных технологий в инженерной деятельности, включая CAD и CAM. Для обозначений всего спектра различных технологий автоматизации с помощью компьютера, в том числе средств САПР, используется термин CAx. Просмотров: 13284 Фоновая задача ADEM >>>

НОУ ИНТУИТ | Лекция | Системы автоматизированного проектирования (САПР) РЭС

< Лекция 6 || Лекция 7: 12 || Лекция 8 >

Аннотация: В лекции приводятся основные определения, назначение и принципы систем автоматизированного проектирования (САПР). Даются сущность и схема функционирования САПР. Показано место САПР РЭС среди других автоматизированных систем. Рассматриваются структура и разновидности САПР.

Ключевые слова: ПО, САПР, проектная организация, автоматизация, работ, очередь, опыт, проектная операция, объект автоматизации проектирования, объект проектирования, технологический процесс, операции, средства автоматизации, эскизный проект, процесс управления, компоновка, интерактивный режим, мощность, имитационное моделирование, Макетирование, критерий эффективности, АСУТП, связность, информационное согласование, технические характеристики, контроль, ветвь, интегральная схема, страта, MCAD, CAE, CAD, CAM, software, hardware, конструирование, ACI, логическое проектирование, VHDL-T, MathCAD, функциональная схема, топология, проектная процедура, проектирующие подсистемы, обслуживающие подсистемы, аппаратные средства, периферийное устройство, линия связи, математическое обеспечение, этап жизненного цикла, технологическая подготовка производства, минимизация, удобство эксплуатации, автоматизированная система, АС, координация, component, supplier, SCM, ERP, MRP, MES, покупатель, e-crm, t-commerce, управление данными, PDM

intuit.ru/2010/edi”>Основное назначение лекции – показать сущность процесса проектирования РЭС, основные принципы проектирования. Особенное внимание уделяется системному подходу к проектированию конструкции и технологии производства РЭС.

7.1. Определение, назначение, цель

По определению САПР – это организационно-техническая система, состоящая из совокупности комплекса средств автоматизации проектирования и коллектива специалистов подразделений проектной организации, выполняющая автоматизированное проектирование объекта, которое является результатом деятельности проектной организации.

Из этого определения следует, что САПР – это не средство автоматизации, а система деятельности людей по проектированию объектов. Поэтому автоматизация проектирования как научно-техническая дисциплина отличается от обычного использования ЭВМ в процессах проектирования тем, что в ней рассматриваются вопросы построения системы, а не совокупность отдельных задач.

Эта дисциплина является методологической, поскольку она обобщает черты, являющиеся общими для разных конкретных приложений.

Идеальная схема функционирования САПР представлена на рис. 7.1.

Эта схема идеальна в смысле полного соответствия формулировке согласно существующим стандартам и несоответствия реально действующим системам, в которых далеко не все проектные работы выполняются с помощью средств автоматизации и не все проектировщики пользуются этими средствами.

Рис. 7.1. Схема функционирования САПР; КСА – комплекс технических средств

Проектировщики, как следует из определения, относятся к САПР. Это утверждение вполне правомерно, т. к. САПР – это система автоматизированного, а не автоматического проектирования. Это значит, что часть операций проектирования может и всегда будет выполняться человеком.

При этом в более совершенных системах доля работ, выполняемых человеком, будет меньше, но содержание этих работ будет более творческим, а роль человека в большинстве случаев – более ответственной.

Из определения САПР следует, что целью ее функционирования является проектирование. Как уже было сказано, проектирование – это процесс переработки информации, приводящий, в конечном счете, к получению полного представления о проектируемом объекте и способах его изготовления.

В практике неавтоматизированного проектирования полное описание проектируемого объекта и способов его изготовления содержит проект изделия и техническую документацию. Для условия автоматизированного проектирования еще не узаконено название конечного продукта проектирования, содержащего данные об объекте, и технологии его создания. На практике его называют по-прежнему “проектом”.

Проектирование – это один из наиболее сложных видов интеллектуальной работы, выполняемой человеком. Более того, процесс проектирования сложных объектов не под силу одному человеку и выполняется творческим коллективом. Это, в свою очередь, делает процесс проектирования еще более сложным и трудно поддающимся формализации. Для автоматизации такого процесса необходимо четко знать, что в действительности он собой представляет и как выполняется разработчиками. Опыт свидетельствует, что изучение процессов проектирования и их формализация давались специалистам с большим трудом, поэтому автоматизация проектирования всюду осуществлялась поэтапно, охватывая последовательно все новые проектные операции. Соответственно, поэтапно создавались новые и совершенствовались старые системы. Чем на большее число частей разбита система, тем труднее правильно сформулировать исходные данные для каждой части, но тем легче провести оптимизацию.

Объектом автоматизации проектирования являются работы, действия человека, которые он выполняет в процессе проектирования. А то, что проектируют, называют объектом проектирования.

Человек может проектировать дом, машину, технологический процесс, промышленное изделие. Такие же объекты призвана проектировать САПР. При этом разделяют САПР изделия (САПР И) и САПР технологических процессов (САПР ТП).

Следовательно, объекты проектирования не являются объектами автоматизации проектирования. В производственной практике объектом автоматизации проектирования является вся совокупность действий проектировщиков, разрабатывающих изделие или технологический процесс, или то и другое, и оформляющих результаты разработок в виде конструкторской, технологической и эксплуатационной документаций.

Разделив весь процесс проектирования на этапы и операции, можно описать их с помощью определенных математических методов и определить инструментальные средства для их автоматизации. Затем необходимо рассмотреть выделенные проектные операции и средства автоматизации в комплексе и найти способы сопряжения их в единую систему, отвечающую поставленным целям.

При проектировании сложного объекта различные проектные операции многократно повторяются. Это связано с тем, что проектирование представляет собой закономерно развивающийся процесс. Начинается он с выработки общей концепции проектируемого объекта, на ее основе – эскизного проекта. Далее приближенные решения (прикидки) эскизного проекта уточняются на всех последующих стадиях проектирования. В целом такой процесс можно представить в виде спирали. На нижнем витке спирали находится концепция проектируемого объекта, на верхнем – окончательные данные о спроектированном объекте. На каждом витке спирали выполняют, с точки зрения технологии обработки информации, идентичные операции, но в увеличивающем объеме. Следовательно, инструментальные средства автоматизации повторяющихся операций могут быть одни и те же.

Практически решить в полном объеме задачу формализации всего процесса проектирования очень сложно, однако если будет автоматизирована хотя бы часть проектных операций, это себя все равно оправдает, т.

к. позволит в дальнейшем развивать созданную САПР на основе более совершенных технических решений и с меньшими затратами ресурсов.

В целом, для всех этапов проектирования изделий и технологии их изготовления можно выделить следующие основные виды типовых операций обработки информации:

• поиск и выбор из всевозможных источников нужной информации;
• анализ выбранной информации;
• выполнение расчетов;
• принятие проектных решений;
• оформление проектных решений в виде, удобном для дальнейшего использования (на последующих стадиях проектирования, при изготовлении или эксплуатации изделия).

Автоматизация перечисленных операций обработки информации и процессов управления использованием информации на всех стадиях проектирования составляет сущность функционирования современных САПР.

Каковы основные черты систем автоматизированного проектирования и их принципиальные отличия от “позадачных” методов автоматизации?

Первой характерной особенностью является возможность комплексного решения общей задачи проектирования, установления тесной связи между частными задачами, т. е. возможность интенсивного обмена информацией и взаимодействие не только отдельных процедур, но и этапов проектирования. Например, применительно к техническому (конструкторскому) этапу проектирования САПР РЭС позволяет решать задачи компоновки, размещения и трассировки в тесной взаимосвязи, которая должна быть заложена в технических и программных средствах системы.

Применительно к системам более высокого уровня можно говорить об установлении тесной информационной связи между схемотехническим и техническим этапами проектирования. Такие системы позволяют создавать радиоэлектронные средства, более эффективные с точки зрения комплекса функциональных и конструкторско-технологических требований.

Вторым отличием САПР РЭС является интерактивный режим проектирования, при котором осуществляется непрерывный процесс диалога “человек-машина”. Сколь ни сложны и изощренны формальные методы проектирования, сколь ни велика мощность вычислительных средств, невозможно создать сложную аппаратуру без творческого участия человека. Системы автоматизации проектирования по своему замыслу должны не заменять конструктора, а выступать мощным инструментом его творческой деятельности.

Третья особенность САПР РЭС заключается в возможности имитационного моделирования радиоэлектронных систем в условиях работы, близких к реальным. Имитационное моделирование дает возможность предвидеть реакцию проектируемого объекта на самые различные возмущения, позволяет конструктору “видеть” плоды своего труда в действии без макетирования. Ценность этой особенности САПР заключается в том, что в большинстве случаев крайне трудно сформулировать системный критерий эффективности РЭС. Эффективность связана с большим

числом требований различного характера и зависит от большого числа параметров РЭС и внешних факторов. Поэтому в сложных задачах проектирования практически невозможно формализовать процедуру поиска, оптимального по критерию комплексной эффективности решения. Имитационное моделирование позволяет провести испытания различных вариантов решения и выбрать лучший, причем сделать это быстро и учесть всевозможные факторы и возмущения.

Четвертая особенность заключается в значительном усложнении программного и информационного обеспечения проектирования. Речь идет не только о количественном, объемном увеличении, но и об идеологическом усложнении, которое связано с необходимостью создания языков общения проектировщика и ЭВМ, развитых банков данных, программ информационного обмена между составными частями системы, программ проектирования. В результате проектирования создаются новые, более совершенные РЭС, отличающиеся от своих аналогов и прототипов более высокой эффективностью за счет использования новых физических явлений и принципов функционирования, более совершенной элементной базы и структуры, улучшенных конструкций и прогрессивных технологических процессов.

7. 2. Принципы создания САПР конструкции и технологии

При создании САПР руководствуются следующими общесистемными принципами.

1. Принцип включения состоит в том, что требования к созданию, функционированию и развитию САПР определяются со стороны более сложной системы, включающей в себя САПР в качестве подсистемы. Такой сложной системой может быть, например, комплексная система АСНИ – САПР – АСУТП предприятия, САПР отрасли и т. п.
2. Принцип системного единства предусматривает обеспечение целостности САПР за счет связи между ее подсистемами и функционирования подсистемы управления САПР.
3. Принцип комплексности требует связности проектирования отдельных элементов и всего объекта в целом на всех стадиях проектирования.
4. Принцип информационного единства предопределяет информационную согласованность отдельных подсистем и компонентов САПР. Это означает, что в средствах обеспечения компонентов САПР должны использоваться единые термины, символы, условные обозначения, проблемно-ориентированные языки программирования и способы представления информации, которые обычно устанавливаются соответствующими нормативными документами. Принцип информационного единства предусматривает, в частности, размещение всех файлов, используемых многократно при проектировании различных объектов, в банках данных. За счет информационного единства результаты решения одной задачи в САПР без какой-либо перекомпоновки или переработки полученных массивов данных могут быть использованы в качестве исходной информации для других задач проектирования.
5. Принцип совместимости состоит в том, что языки, коды, информационные и технические характеристики структурных связей между подсистемами и компонентами САПР должны быть согласованы так, чтобы обеспечить совместное функционирование всех подсистем и сохранить открытую структуру САПР в целом. Так, введение каких-либо новых технических или программных средств в САПР не должно приводить к каким-либо изменениям уже эксплуатируемых средств.
6. Принцип инвариантности предусматривает, что подсистемы и компоненты САПР должны быть, по возможности, универсальными или типовыми, т. е. инвариантными к проектируемым объектам и отраслевой специфике. Применительно ко всем компонентам САПР это, конечно, невозможно. Однако многие компоненты, например, программы оптимизации, обработки массивов данных и другие, могут быть сделаны одинаковыми для разных технических объектов.
7. Принцип развития требует, чтобы в САПР предусматривалось наращивание и совершенствование компонентов и связей между ними. При модернизации подсистемы САПР допускается частичная замена компонентов, входящих в подсистему, с изданием соответствующей документации.

Приведенные общесистемные принципы являются чрезвычайно важными на этапе разработки САПР. Контроль над их соблюдением обычно осуществляет специальная служба САПР предприятия.

Сущность процесса проектирования РЭС заключается в разработке конструкций и технологических процессов производства новых радиоэлектронных средств, которые должны с минимальными затратами и максимальной эффективностью выполнять предписанные им функции в требуемых условиях.

В результате проектирования создаются новые, более совершенные РЭС, отличающиеся от своих аналогов и прототипов более высокой эффективностью за счет использования новых физических явлений и принципов.

Дальше >>

< Лекция 6 || Лекция 7: 12 || Лекция 8 >

Будущее систем проектирования автоматизировано

Это часть нашей серии статей о будущем систем проектирования. Ранее мы говорили о сложности навигации. Здесь мы беседуем с представителями отрасли о том, как плагины, виджеты и инструменты меняют ландшафт, и о том, что они надеются на будущее.

В 2017 году Бенджамин Уилкинс поделился ранними исследованиями с использованием систем проектирования и машинного обучения для создания кода из каркасов с низкой точностью. Коллективный консенсус? (1.) Ничего себе, это невероятно, (2.) А как насчет нашей работы? «Я действительно думал, что у меня есть больше времени, пока меня не заменит робот», — написал Нир Бенита в Твиттере.

Этот пост снова начал распространяться в Твиттере совсем недавно, когда команда Diagram* представила Genius, управляемый искусственным интеллектом инструмент, который может анализировать ваши файлы Figma и вносить предложения, используя компоненты из вашей системы проектирования, что привело к осуществлению этих ранних исследований. Джем Голд, ученый-исследователь, работавший в то время над ИИ в Airbnb, пояснил в Твиттере, что эти ранние исследования так и не были полностью реализованы, а вместо этого использовались в качестве прототипов. Тем не менее, эта работа продемонстрировала будущее дизайна с помощью ИИ, которое формируется сейчас, когда технология догоняет .

*Figma Ventures, специализированный инвестиционный фонд Figma, является инвестором

«Мы создаем наши инструменты, а затем наши инструменты делают нас», — пишет философ и теоретик Маршалл Маклюэн. От плагинов и виджетов до технологий с искусственным интеллектом — новый класс инструментов меняет правила игры и ставит некоторые экзистенциальные вопросы: какова роль дизайнера в мире, где дизайн можно автоматизировать? Разработчик с автоматически сгенерированным кодом? Когда наши инструменты выходят за рамки расширения наших навыков и заканчивают наши… предложения? Что это означает для будущего нашей практики и отрасли в целом?

Знакомство с плагинами и виджетами

История плагинов и виджетов тесно связана с дизайном. Некоторые из первых подключаемых модулей были созданы в 1970-х годах для текстовых редакторов и программ для публикации, таких как Hypercard и QuarkXPress, на компьютерах Apple Macintosh. Создатели развили целую микроэкономику вокруг создания плагинов, продажи пользовательских эффектов, кистей и стилей, чтобы другие могли их использовать и создавать.

С тех пор многие другие компании-разработчики программного обеспечения с распростертыми объятиями приветствовали созданные пользователями надстройки, способствуя их распространению через форумы сообщества и торговые площадки для приложений. (В конце концов, кто бы не хотел расширить охват своих команд и приложений?) Плагины для систем дизайна обычно ориентированы на функциональность и делятся на две категории: те, которые автоматизировать ряд ​​существующих задач или расширить набор функций, таких как сбор аналитики, тестирование проектов, улучшение специальных возможностей и многое другое.

Лучшие плагины для систем проектирования в сообществе Figma

Плагины для автоматизации повторяющихся задач

В Figma мы видим это на наших собственных страницах сообщества: самые популярные плагины, занимающие половину первых десяти позиций. Другие помогают автоматизировать потоки, преобразовывать проекты в HTML или превращать проекты в наборы слайдов. Общая тема? Снижение сложности и оптимизация рабочих процессов. Все, что мешает дизайнерам отказываться от одного инструмента, чтобы взять что-то из другого, или повторять серию кликов до тошноты, является благодатной почвой для плагина.

Любой, кто когда-либо сталкивался с синдромом запястного канала или просматривал страницу результатов поиска « дизайнов эргономичных клавиатур », вероятно, знаком с острой физической болью, которая может сопровождать многие повторяющиеся дизайнерские задачи. Хотя существует бесчисленное множество причин для карьеры дизайнера, использование пикселей обычно не входит в их число.

Мэтью Стрём, менеджер по дизайну продуктов в Stripe, объясняет, что сложные системы дизайна имеют много путей между любой проблемой и ее решением. По мере роста дизайн-системы изучение каждого из этих путей требует дополнительного времени и усилий, а определение каждой итерации занимает все больше и больше времени. «Инструменты автоматизации и тестирования с небольшим количеством кода или без него могут значительно ускорить его и сэкономить неисчислимое количество часов ручной работы командам разработчиков систем проектирования», — говорит он. В статье на UXdesign.cc Тейсану Тюдор описывает усилия, необходимые для проверки 20 возможных комбинаций шрифтов и размеров текста, и заключает: «Большинство людей никогда не изучат все 20… Очень немногие люди начнут задумываться, сколько существует возможных комбинаций. есть, чтобы потом тут же создавать их одну за другой, не привязываясь к какому-то конкретному». И это всего 9Тип 0003.

«Одна из моих самых больших страстей — поговорить с дизайнерами, чтобы посмотреть, как они строят вещи, а затем представить, как вы могли бы сделать это быстрее или более творчески», — говорит Эндрю Пулиот, инженер по машинному обучению в Diagram. «Тратить меньше времени на механические действия и получать более качественный результат. Я думаю, что это станет огромной частью будущего дизайн-систем». Diagram (команда, стоящая за вышеупомянутым инструментом Genius на основе ИИ) хорошо известна в инструментальном сообществе, создавая плагины для прототипирования, автоматизации и отладки. Automator, один из наиболее часто используемых плагинов Diagram, позволяет командам создавать собственные средства автоматизации с помощью перетаскивания для создания руководств по стилю, пакетного изменения размера значков или получения данных API. (И до октября прошлого года он также предоставлял элегантное решение для долгожданной функции Figma по поиску и замене.)

Плагины для расширения набора функций

Когда инструменты не подходят для определенных случаев использования, плагины и интеграции также могут помочь преодолеть разрыв. Stark помогает командам находить и устранять проблемы с доступностью и в настоящее время поддерживается на девяти различных платформах, включая настольные компьютеры, браузеры и различные приложения. «Это набор инструментов, и когда вы покупаете экосистему Stark, вся философия заключается в том, что мы подключаемся к инструментам, которые уже использует ваша продуктовая команда, будь вы дизайнером, разработчиком, менеджером проекта или экспертом по обеспечению качества. и объедините их вместе в рабочий процесс доступности», — сказал TechCrunch главный дизайнер Stark Бенедикт Ленерт.

Поддерживаемые платформы на веб-сайте Старка (getstark.co)

Виджеты для визуализации и организации

Если плагины ориентированы на функциональность, виджеты — это внешний вид. Инструменты в приложении, как правило, предлагают уровень интерактивности, предлагая пользователям вовлекать и визуализировать контент. Самые популярные виджеты для систем проектирования включают в себя диаграммы для отображения информации, кнопки для быстрого связывания, рамки устройств для демонстрации стилей в действии и множество таблиц для организации свойств компонентов.

Виджеты лучших систем дизайна в сообществе Figma

Виджеты могут расширить возможности навигации по файлам Figma и FigJam, обслуживая файлы в приложении. Виджет рамки устройства позволяет дизайнеру быстро набросать идею интерфейса без необходимости рыскать по всемирной паутине в поисках чистого каркаса телефона. Виджет таблицы свойств компонентов генерирует свойства из компонентов Figma, экономя время дизайнеров при составлении спецификаций и документации для передачи.

В каждом из этих примеров плагины и виджеты встречают пользователей там, где они есть, и предоставляют более быстрые и простые способы добраться туда, куда они хотят. Это может означать большие преимущества для групп проектных систем, пытающихся внедрить или стремящихся оптимизировать обслуживание и распространение. Уменьшая трения или предоставляя своим пользователям дополнительные функции, эти инструменты могут расширять возможности системы, упрощая создание библиотек и компонентов и управление ими. Таким образом, несмотря на то, что дизайн продукта усложняется, требуя от команд перемещаться по лабиринту точек соприкосновения, устройств и платформ, эти интеграции создают новые возможности для оптимизации и масштабирования этих рабочих процессов.

И тем не менее, эти инструменты настолько эффективны, насколько важны их входные данные.

Расширение возможностей инструментов с помощью ИИ

Если плагины улучшают функциональность, а виджеты повышают удобство использования, искусственный интеллект предлагает новую основу для обоих. Хотя у нас нет хрустального шара, просмотр популярных плагинов и виджетов дает нам несколько подсказок о том, какие болевые точки существуют в настоящее время и как ИИ может заполнить эти пробелы.

Быстрое создание значков, изображений, текста и другого контента является очевидной потребностью, и несколько разных компаний решают эту задачу. Shopify недавно анонсировала описания продуктов, сгенерированные искусственным интеллектом, для своих витрин, основанные на том, что они называют «Shopify Magic». Между тем, последний плагин Diagram, Magician, использует глубокие генеративные модели для вставки значков, копий и изображений в файлы дизайна Figma из текстовых подсказок. (Мы говорили с Джорданом Сингером о создании Magician с использованием Figma Plugin API здесь.)

Пулио из Diagram говорит, что GitHub Copilot был одним из инструментов, который изменил его представление о том, каким может быть взаимодействие человека с компьютером. Помощник по машинному обучению существует в редакторе кода, автоматически заполняя строки кода или предлагая решения из текстовых подсказок. «Это что-то вроде увеличения собственного мозга, — объясняет он. «Я только начну писать имя функции, и еще до того, как я доберусь до того, какими должны быть параметры, она уже заполнит оставшуюся часть строки». Он также смотрит на контекст в редакторе — не только на текущий файл, но и на другие аспекты проекта, разумно внося предложения по ходу вашей работы.

Это не идеально. Пользователям по-прежнему может потребоваться настроить базу кода и исправить ошибки по мере необходимости. Тем не менее, GitHub Copilot создает связь между человеком и компьютером. Это не только ускоряет рабочие процессы разработчиков, но и подчеркивает, что ИИ уже становится обычным явлением в дизайне и разработке. Пулио рад продолжать создавать интеллектуальные инструменты, такие как Genius, для более широкого сообщества дизайнерских систем. «Системы дизайна претерпят большие изменения в течение следующих нескольких лет, и я думаю, что лучший способ предсказать будущее — это создать его», — говорит он.

Кэлиг Делоумо-Прижан, основатель группы сообщества Design Tokens W3C Community Group, видит большой потенциал ИИ для улучшения рабочих процессов системы проектирования. «Есть так много исследований, которыми можно управлять с помощью ИИ. AI Copilot от GitHub теперь может помочь нам писать код. Я хочу увидеть такое же сотрудничество с технологиями для систем проектирования», — говорит он. Делоумо-Прижан считает, что в ближайшие несколько лет мы увидим более совершенные системы управления токенами, которые помогут снизить барьер для входа. В настоящее время существует несколько готовых решений, и альтернатива требует значительных знаний в области кодирования, а также понимания GitHub, аудита и автоматизации. «Для некоторых команд это барьер, который они не смогут преодолеть, — говорит он. Он считает проектирование с помощью ИИ областью, в которой токены будут наиболее полезны в будущем.

Догоняя будущее

На панели Figma 2021, посвященной предстоящему году, Солейо поделился: «Мы должны ожидать значительного прогресса в том, как исследование дизайна и обратная связь становятся все более автоматизированными. Во многом так же, как мы сейчас живем в среде совместной работы с другими людьми, я ожидаю, что мы окажемся в будущем, где больше знаний, обратной связи и итераций будет происходить через виртуальных сотрудников: нечеловеческих агентов, которые хорошо приспособлены к типы задач, которые мы сегодня выполняем вручную».

По мере того, как ИИ становится более доступным, мы можем ожидать появления будущих функций, таких как расширение систем проектирования для быстрого объединения новых интерфейсов или выявление потенциальных проблем или конфликтов до их возникновения. Еще одна возможность для технологии находится в области документации и рекомендаций, чтобы помочь не только с соблюдением требований, но и с рекомендациями по использованию.

Спрос на дизайнеров (людей)

ИИ может быть ценным инструментом для дизайнеров, но важно помнить, что это всего лишь инструмент. Подобно виджетам и плагинам, они могут автоматизировать определенные задачи и предоставить новые возможности для дизайна, но не могут заменить креативность и навыки решения проблем, которые люди приносят с собой (а также поднимают несколько новых проблем). По мере появления новых сред, таких как Web3 и Metaverse, будет возрастать потребность в адаптивных дизайнерских решениях, а также в более дифференцированных и интересных взаимодействиях.

Сэм Андерсон, директор по системам проектирования и доступности в Intuit, считает, что в обозримом будущем проектирование останется критически важной деятельностью, управляемой человеком. «Было бы сложно создать ИИ, который бы выяснял проблему клиента, выявлял из каталога то, что могло бы решить эту проблему клиента, и правильно отображал бы ее на экране. Для этого нам по-прежнему нужны люди-дизайнеры», — объясняет он. Он надеется, что автоматизация может ускорить работу по проектированию, позволяя командам быстрее переходить от концепции к прототипу, обеспечивая быстрое экспериментирование и более быстрое экранное тестирование и обратную связь с пользователями.

Будьте уверены, спрос на дизайнеров остается высоким. «По мере того, как дизайн все больше связывается с кодом, а системы проектирования становятся проще в использовании и все более популярными, все больше людей могут создавать удобные интерфейсы», — говорит Эндрю Хоган, руководитель отдела аналитики в Figma. «Однако будет больше спроса на отличные взаимодействия и на новые интересные взаимодействия. Стремление компаний выделиться и создать статус и дифференциацию предполагает, что спрос на дизайнеров будет еще больше». Дизайнерам по-прежнему будет предложено изучить другие направления, рассмотреть новые отзывы и проблемы, а также привнести новые точки зрения на проблемы.

В эту потребность, конечно же, входят дизайнеры и технологи с глубоким пониманием этих технологий, способные создавать этичные и ответственные решения для будущего.

Дайте нам знать, что вы думаете, и ваши прогнозы на будущее дизайн-систем на Twitter! Эта статья была первоначально опубликована на DesignSystems.com.

Автоматизация систем проектирования: Необходимость | Дхананджай Гарг

Опубликовано в

·

Чтение: 5 мин.

·

9 января 2022 г.

Токены Figma и варианты компонентов

Дизайн-системы повсюду. Наконец, компании уделяют первостепенное внимание необходимости иметь систему проектирования, создают специальную команду дизайнеров для масштабирования и управления операциями систем проектирования и нанимают разработчиков внешнего интерфейса, которые могут точно настроить интерфейс системы проектирования. Но, тем не менее, собрать очень сложную и функциональную дизайн-систему непросто. Это довольно сложно; задача требует навыков, изучения новых концепций и методов для масштабирования, а также упрощения работы других дизайнеров продуктов за счет разработки более совершенных систем проектирования.

Прежде чем мы углубимся в эту тему, давайте проясним некоторые основы —

Что такое дизайн-системы?

Система дизайна — это набор стандартов для управления дизайном в масштабе за счет уменьшения избыточности при создании общего языка и визуальной согласованности на разных страницах и каналах.

Узнайте больше об основах Design Systems (от NN Group) ниже 👇 .

Design Systems 101

По мере того, как дизайн пользовательского интерфейса развивался с годами, масштаб и скорость, с которой необходимо создавать экраны пользовательского интерфейса, также увеличивались…

www.nngroup.com.

Что такое компоненты?

Компоненты являются многоразовыми строительными блоками нашей системы проектирования . Каждый компонент соответствует определенному взаимодействию или потребности в пользовательском интерфейсе и был специально создан для совместной работы для создания шаблонов и интуитивно понятного пользовательского интерфейса.

Что такое варианты?

Варианты — это различные состояния определенного компонента системы, предназначенные для того, чтобы каждый мог легко переключаться между другими состояниями. Подробнее о вариантах в Figma читайте ниже 👇 .

Создание и организация вариантов

Варианты открывают ряд новых возможностей для компонентов и масштабируемых систем проектирования. На первый взгляд, они создают и…

www.figma.com.

Варианты

Одним из самых значительных факторов, отнимающих время сегодня для систем проектирования, является проектирование различных вариантов. Это важный шаг в любой дизайн-системе, но это также и самая негламурная часть всего процесса. Кроме того, поскольку процесс очень ручной, он создает ошибки, несоответствия и упущенные моменты.

Вот пример стандартных состояний, которые может иметь кнопка —

1. Включено
2. Нажато
3. Выключено
4. Загрузка
5. Наведение

Добавление сложности, упомянутой выше, каждое из пяти вышеперечисленных состояний может быть воспроизведено в семь различных типов кнопок.

1. Маленькие кнопки
2. Средние кнопки
3. Большие кнопки
4. Круглые кнопки со значком
5. Квадратные кнопки со значком
6. Таблетки — вторичные цвета и состояния
7. Таблетки — третичные цвета и состояния

Небольшой лист кнопок, помещаемый в систему дизайна

Типы компонентов

Следующей проблемой, помимо создания вариантов, является, возможно, количество компонентов, которые дизайнер должен создавать, интегрировать и использовать внутри и вне системы дизайна. Поскольку существует множество нестандартных наборов компонентов, которые существуют помимо обычных кнопок и текстовых полей, вероятность того, что они пропадут в дизайн-системе, высока.

Вот тип стандартного списка компонентов, которые мы видим почти в каждой дизайн-системе —

1. Цветовые палитры
2. Типографика/Шрифт и толщина шрифта
3. Сетки макета
4. Кнопки
5. Закусочная & Баннер для более длинных строк текст
6. Подсказка
7. Текст/Поля ввода
8. Выбор даты и времени
9. Карточки и соответствующие варианты макета
10. Нижний лист

Необходимость автоматизации

Как вы могли догадаться на примере стандартных компонентов, упомянутых выше, необходимо отказаться от ручной работы, которую сегодня выполняет почти каждый дизайнер продукта. Например, кнопка в своей простейшей форме представляет собой просто прямоугольник с текстом в центре, некоторым интервалом вокруг всех четырех углов и закругленными углами по бокам. Хотя кнопки между двумя дизайн-системами могут выглядеть по-разному, в основном они одинаковы с несколькими незначительными отличиями. Мы могли бы добиться этого быстрее, если бы дизайнер мог указать несколько значений переменных в инструменте и нажать кнопку «создать систему», чтобы собрать вместе все варианты и размеры, используя функцию автоматического макета Figma.

Определив API компонента и предоставив набор параметров, которые генерируют все варианты компонентов, мы можем автоматизировать создание вариантов сложных и простых компонентов.

https://automator.design/

Automator — это премиум-плагин Figma за 5 долларов, созданный Diagram, который позволяет создателям создавать набор действий и объединять их вместе для создания потока автоматизации. Затем можно поделиться этим набором «Действий» с сообществом, экспортировав вспомогательный файл JSON. Ранние признаки того, что Automator позволяет автоматизировать тривиальные повторяющиеся задачи, весьма многообещающи, и многие эксперты по дизайн-системам уже поддерживают плагин и то, чего он может достичь.

Вот краткий список того, чего Automator достиг на данный момент —

Автоматизация экспорта значков

Автоматизация спецификаций

Автоматизация руководства по стилю

Но, глядя на автоматизацию системы дизайна, необходимо сделать больше. Необходимо автоматизировать системы проектирования со стороны Figma и кода. Что, если бы программное обеспечение также могло предлагать и создавать стандартный набор значений токенов дизайна вместе с системой проектирования на уровне компонентов? Разве это не изменит правила игры?

Что такое дизайнерские жетоны?

Токены дизайна — это все значения, необходимые для создания и поддержки системы дизайна — интервалы, цвет, типографика, стили объектов, анимация и т. д. Они могут означать все, что определено дизайном: цвет как значение RGB, непрозрачность как число , анимация упрощается как координаты Безье. Они используются вместо жестко закодированных значений, чтобы обеспечить гибкость и единство всех продуктов.

Маркеры дизайна напрямую интегрируются в наши библиотеки компонентов и наборы пользовательского интерфейса. Они охватывают масштабы платформы, цветовые темы, состояния компонентов и другие параметры.

Сегодня понимание токена дизайна все еще находится на ранней стадии. Поскольку необходимость настройки базовой системы проектирования отнимает много времени, дизайнеры склонны в настоящее время полностью отказываться от приоритетов токенов дизайна. Следовательно, дизайнерские токены часто появляются на более позднем этапе.

Сборник рассказов

Наконец, чтобы сделать систему проектирования еще более удобной для использования сообществом разработчиков, необходимо создавать автоматизированные блоки кода для каждого компонента и его вариантов.

Storybook — фантастический инструмент с открытым исходным кодом для изолированного создания компонентов пользовательского интерфейса и страниц. Он упрощает разработку, тестирование и документирование пользовательского интерфейса.

При автоматизации пользовательского интерфейса Figma также необходимо интегрировать проверенные блоки кода для всех систем проектирования с помощью встроенного инструмента, такого как Storybook. Это повысит удобство использования компонентов дизайн-системы и упростит интеграцию и внедрение дизайн-системы.

Я надеюсь, что эта короткая статья об автоматизации систем проектирования оказалась для вас полезной и наводящей на размышления.