Это был год системы проектирования. Компании запускают новые системы проектирования почти каждую неделю, и большинство руководителей теперь понимают их ценность. Системы проектирования включают в себя руководства по стилю, библиотеки шаблонов, фреймворки CSS и операции проектирования. Дизайнеры и разработчики чувствуют себя уполномоченными благодаря огромному количеству ресурсов, и есть конференции, полностью посвященные системам проектирования (в основном это Clarity в США и Design Systems London в Европе).
Барьер для входа теперь ниже, но с таким большим количеством информации, это может быть подавляющим и трудно точно знать, какие советы применимы к вашей собственной работе — особенно если вы пытаетесь создать систему проектирования в небольшой организации.
Мы попросили инсайдеров, которые строили системы проектирования в Slack, HubSpot, GoDaddy, IBM и Lloyds Banking Group, за советы о том, как создавать более совершенные системы проектирования. Вот что они рекомендуют:
Содержание статьи
1. Понять контекст, в котором ваша система проектирования должна работать в
«Каждая новая система дизайна начинается с мечтательного стремления стать следующим Airbnb DLS или Google Material Design [1945900] ”Находит Лили Дарт Ведущий специалист по поставке языков дизайна в банковской группе Lloyds . «Но для тех из нас, кто не работает в действительно гибких, ориентированных на пользователя организациях, таких как AirBnb или Google, попытка воспроизвести эти примеры может быть ошибкой».
По словам Лили, реальная хитрость в создании системы проектирования, которая работает, заключается в понимании контекста и культуры, в которых она должна работать. Гибкая организация не будет ценить «идеальные» выпуски раз в шесть месяцев, в то время как организация водопада будет хотеть медленные выпуски, но они также ожидают, что вы будете поддерживать старые версии, если они находятся в производстве.
«Как только вы поймете свой контекст и культуру, вы сможете подумать о том, как ваша система дизайна может улучшить ее», — объясняет Лили. «Хотите повысить эффективность? Определите как можно больше готовых шаблонов чтобы ускорить команду. Хотите повысить креативность? Идите противоположным путем — держите шаблоны минимальными, вместо этого предоставляя атомов чтобы предоставить дизайнерам гибкость ».
В конце концов, система проектирования — это как раз то, на что указывает Лили, — система . «И системы не существуют в изоляции. Если вы не работаете в Airbnb, не создавайте продукты, предназначенные для их команды и пользователей. Сосредоточьтесь на решении проблем, с которыми вы сталкиваетесь каждый день, и вы создадите прекрасную систему проектирования ».
2. Оставайтесь уникальными и сохраняйте накладные расходы
Также вопрос, действительно ли ваша компания нуждается в совершенно новой системе проектирования, предлагает Джеймс Й Раухут разработчик внешнего интерфейса и дизайнер UX в Pingboard.
«Самые мощные системы проектирования основаны на уникальной философии компании», — объясняет он. «Компания Material Design от Google считает, что опыт работы выходит за рамки стеклянного экрана, с которым вы взаимодействуете. Microsoft Fluent Design считает, что опыт адаптируется к окну, которое он занимает. Будет ли ваша система дизайна иметь уникальную точку зрения? Если нет, вы можете принять существующую систему проектирования, чтобы сэкономить техническую задолженность ».
Даже если у вас есть уникальная перспектива, которая отделяет вашу систему от остальных, вам не нужно изобретать меньшие колеса. Вот некоторые инструменты, которые Джеймс рекомендует упростить для выпуска системы проектирования и обеспечения единства компании:
- Framer X Team Store для дизайна
- Reach UI базовые компоненты для доступности
- Grid Wiz Генератор фреймворков CSS Grid для макета
До прихода Джеймса в Pingboard он работал в IBM Design. В этом выступлении он объясняет, как такие усилия, как CSS Grid, позволяют вам продвигать то, что делает система проектирования, и как IBM строит систему проектирования для своих 350 000 сотрудников:
3. Определите процесс, а не проект
«Может быть заманчиво подумать о редизайне или создании системы дизайна как проекта», — признает Лара Тацито старший менеджер (дизайн продукта) в HubSpot , «На самом деле, может потребоваться начать таким образом, чтобы получить бай-ин или импульс. Но единственный способ увидеть реальный успех и не нуждаться в перепроектировании каждый год — это определить процесс и трактовать процесс как продукт ».
Лара предлагает, чтобы первым шагом, как и в любом стандартном процессе проектирования, было выяснение текущих рабочих процессов людей, которые будут использовать систему проектирования.
«Несколько простых интервью пройдут долгий путь», объясняет она. «Тогда найдите способы упростить этот процесс, по-прежнему удовлетворяя потребности пользователей, и, несомненно, упростите правильные действия».
Лара также рекомендует объединить вашу документацию по проектированию и реализации. «В этом есть компромисс сложности, но в итоге мы обнаружили, что чем больше дизайнеров знают о реализации, тем лучше они — и инженеры, которые знают больше о руководящих принципах проектирования принимает лучшие решения для пользователя. ”
Наконец, Лара предлагает привлечь команду, которая будет использовать систему проектирования в процессе, потому что это помогает им понять, как работает процесс, позволяет расширить набор навыков и вкладов, а также помогает подотчетности и автономии.
Посмотрите презентацию Lara Talk UX о создании вечнозеленой системы проектирования, которая облегчит жизнь как вашим клиентам, так и вашей команде:
4. Фокус на общении
«Системы проектирования — это 80% коммуникации и 20% выполняют работу», — отмечает Гаррет Миллер штатный инженер в Slack.
Хотя создание основополагающей архитектуры компонентов является абсолютной необходимостью, Гаррет обнаружил, что гораздо больше работы требуется для обоснования выделения ресурсов и определения приоритетов в рамках более широкой организации.
«Это требует огромного внимания к сотрудничеству», — советует он. «Требуются переговоры с заинтересованными сторонами, чтобы расчистить путь для таких крупных инвестиций в вашу проектную инфраструктуру. Успех системы проектирования является результатом того, насколько хорошо ее адвокат способен справляться с напряжением между всеми сторонами, вовлеченными в эти разговоры ».
Гарретт рекомендует сосредоточиться на экономическом обосновании инвестиций в ваше общение.
«Системы проектирования позволяют нам ускорять рост с меньшим риском регрессий. Сюрпризы стоят денег и времени, обе вещи, которые ваша компания, вероятно, пытается сэкономить ».
5. Увеличение взносов за счет модульности
По своей природе системы проектирования имеют тенденцию быть монолитными, а не модульными. Чарли Роббинс старший директор по инженерным разработкам (платформа UX) в GoDaddy, рекомендует сосредоточиться на модульности, поскольку у него есть два основных преимущества для сообщества, которое вы хотите развивать в любой системе проектирования. ,
«Во-первых, модульная и разобщенная система проектирования побуждает пользователей брать отдельные компоненты и комбинировать их с другими системами проектирования для удовлетворения своих конкретных потребностей», — объясняет он. «Это увеличивает пул возможных участников».
Для новичка, хотя, даже небольшая система проектирования может быть огромной, чтобы внести свой вклад, хотя. «Модульный подход может сделать обновление или добавление новых компонентов или документации в вашу систему проектирования более доступным, поскольку новый участник должен понимать только этот компонент», — отмечает Чарли. «Принимая модульность и« пустоту », когда это возможно, у вашего сообщества будет меньше барьеров для роста».
6. Помните о долге решения
«Одна из самых больших ошибок при работе с системами проектирования в масштабе — это идея, что не принятие решения — это, по сути, решение», — предупреждает Сара Федерман инженер-конструктор в Adobe .
«Каждый раз, когда вы делаете выбор отложить установление стандарта или создание процесса, вы накапливаете долг решения, который может быть таким же, как — если не больше — вредны как долговые обязательства или технические долги », — объясняет она. «Когда вы откладываете решение, принимаемое в вашей системе, вы возлагаете на своих пользователей ответственность за принятие решения. Результатом может быть не тот, который вам нравится, и, конечно, он не будет таким, который одинаков для всех продуктов ».
По опыту Сары долг за решения особенно важен, когда вам нужно принимать далеко идущие дизайнерские решения, касающиеся типографики и расстояния, а также когда вам нужно принимать решения по процессам, например, по версии вашей системы. «У пользователей будут возникать ожидания относительно поддержки, которую они получат, или от стабильности вашей системы, — советует она, — и вы будете бороться с этими ожиданиями в будущем».
Также важно решение — или, в более идеальном случае, требование — о создании инклюзивной системы. «Обеспечение доступности после факта намного сложнее и влияет на самые основные части вашей системы, такие как цвета и размеры».
В конце концов, системы проектирования должны быть адаптируемыми, но начинать с прочной и гибкой основы — это самый простой способ внести изменения в дальнейшее развитие.
«Долг по принятию решений не всегда плох, но это то, о чем нужно помнить и принимать стратегическое решение», — заключает Сара.
Нажмите здесь, чтобы создать свой следующий замечательный проект в Media Temple.