Вы можете написать, как правильно использовать тостер, рисовать рисунки тостеров и даже придумать более эффективные способы рисования тостеров. Но в конце концов, если у вас нет работающего тостера, все эти усилия напрасны. В своих семинарах по проектированию, на дизайн конференциях я спрашиваю участников об их успехах с дизайн системой. Большинство рук поднимаются, когда я спрашиваю, есть ли у их организаций дизайн системы. Однако, когда я прошу показать их мне, многие участники показывают библиотеку Sketch или веб-сайт руководства по стилю с большим количеством скриншотов. Но не хватает живых компонентов пользовательского интерфейса. Это может показаться очевидным, но важно понимать, что вы не можете создавать рабочее программное обеспечение из скриншотов и файлов Sketch. Дело не в том, что инструменты и документация по статическому дизайну не важны (они важны!), но они не могут создавать функционирующие компоненты интерфейса, которые можно использовать для создания реальных программных приложений. Файлы статического дизайна, документация по исходникам, рекомендации помогают рассказать, как ваша организация проектирует и разрабатывает продукты, но в основе любой системы дизайна лежит набор многократно используемых компонентов интерфейса, которые продуктовые команды могут использовать для создания реального программного обеспечения. Итак, что же делать команде, чтобы удостовериться, что вы занимаетесь разработкой реально функционирующих компонентов интерфейса?
- Удостоверьтесь, что в вашей команде есть фронтенд-дизайнеры. Если у вас их нет или недостаточно, наймите несколько. Есть множество фронтенд-дизайнеров, стремящихся построить чистый, красивый модульный, многоразовый код интерфейса.
- Установите управляемый шаблонами междисциплинарный рабочий процесс, который подчеркивает необходимость раннего перехода в браузер и итерацию фронтенд-кода. Вместо того, чтобы дизайнеры оставались в комфортных стенах своих инструментов статического дизайна, поощряйте совместную работу с разработчиками, чтобы дизайнерское видение пробивалось в фактический код, который будет развернут в реальных продуктах.
- На ранней стадии создания вашей дизайн системы обсудите методы, которые вы будете использовать для развертывания компонентов интерфейса в код продукта, а затем быстро оцените этот рабочий процесс, используя один компонент («ОК, вот компонент кнопки нашей дизайн-системы, как мы используем его на нашей домашней странице?")
- Понять трение между созданием функционирующих компонентов интерфейса, которые используют определенные технологии (такие как React, Angular, Twig и др.) и создать систему дизайна, которая будет больше, чем внедрение любой технологии.
- Убедитесь, что живые компоненты и код отображаются вместе с любой дизайнерской документацией и скриншотами в руководстве по стилю.
Не поймите меня неправильно, я думаю, что такие инструменты, как Sketch, InVision Studio, Adobe XD, Figma и другие, наконец, признали важность создания многократно используемых компонентов интерфейса и обмена ими между членами команды. Еще больше меня радует множество усилий по добавлению живых компонентов в инструменты статического дизайна, поэтому дизайнеры могут создавать экраны, которые точно показывают, как эти экраны будут выглядеть в браузере. Существует реальная ценность использования инструментов статического проектирования для работы с дизайн-системой, но не забудьте обратить внимание на главное преимущество: создание красивой, гибкой, коллекции фронтенд-компонентов, которая может использоваться для создания реального программного обеспечения. Теперь идите и создайте свои тостеры.
Перевод статьи Brad Frost
Топ коментарі (0)