[Веб-дизайн, Интерфейсы, Дизайн] Свободы и ограничения дизайн-систем
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет! Мы команда дизайнеров и разработчиков, создающих цифровую дизайн-систему Ростелекома. Зачем? В большом энтерпрайзе множество продуктов и проектов, и у каждого из них есть потребности, которые может закрыть дизайн-система.Когда вы начинаете строить такую систему, вам кажется, что первое, что стоит сделать — это спроектировать все нужные компоненты. Вы проводите исследование, аудит текущих проектов и понимаете, что вот этот список компонентов вам и нужен, то есть решаете текущие задачи и немного смотрите в будущее, оценивая, что ещё может понадобиться. И в процессе возникает вопрос — а как дизайн-систему будут применять пользователи? Станут ли следовать всем правилам и гайдам, если мы их заложим в систему? Если напишем подробные мануалы, будут ли их читать? А если не напишем — не появится ли масса вопросов о границах и правильности применения компонентов? Что лучше: жестко зафиксированная инструкция или, наоборот, никаких правил?Чтобы ответить на эти вопросы и упростить себе жизнь, нужно понять, ваша дизайн-система — это, в первую очередь, инструмент или продукт? Поначалу мы считали, что все-таки инструмент и доносили эту идею во всех презентациях и демонстрациях. Говорили, что система предназначена для дизайнеров и разработчиков, и именно им нужна в ежедневной работе. Это работало, систему действительно так и применяли для решения продуктовых и проектных задач (на тот момент систему использовало 26 проектов!).Позже мы пришли к пониманию, что дизайн-система — это и продукт тоже. Она создаётся и развивается как полноценный продукт, более того, её можно упаковывать для разных сегментов по-разному. Нас осенило, что пользовательских ролей не две (дизайнер и разработчик), а гораздо больше, и мы можем адаптировать дизайн-систему под их задачи, тем самым формируя некую культуру дизайна и корпоративную систему стандартов.При этом нас по-прежнему волновал вопрос:А нужны ли вообще стандарты?Если правила можно нарушить без последствий — их нарушат. У нашей команды был опыт создания дизайн-системы и понимание того, что какие бы эталонные гайдлайны не создавались, их все равно не будут достаточно внимательно читать абсолютно все дизайнеры и, тем более, пунктуально им следовать. Когда мы раскатывали дизайн-систему по внутренним проектам Ростелекома, замечали, что дизайнеры используют её по-разному. Мы писали подробнейшие инструкции ко всем компонентам, а то и целым UX-паттернам, но дизайнеры либо соблюдали их выборочно, либо просто игнорировали. Когда вы кропотливо что-то создаете и видите потом, что вашим так заботливо выращенным детищем пользуются по-варварски и абсолютно не так, как вы себе это представляли, — это вводит в отчаяние. Иногда нас накрывала тоска от того, как дизайн-система применялась. Но дизайнеров можно понять. Им не хочется лишний раз думать о том, как правильно использовать дизайн-систему, у них другие задачи — думать о своих проектах, пользовательских сценариях и хорошем UX. У них часто нет ни желания, ни времени на скрупулёзное изучение гайдов дизайн-системы. Поэтому мы решили, что у нас будут правила использования компонентов, но требование следовать им не будет жестким. Иначе нарвемся на неприятие системы, а то и вовсе саботаж. Нужно подходить конструктивно — как помочь дизайнеру? 
Соотношение элементов в макетеРешением стало введение собственной интерпретации всем известного закона Парето, мы его назвали принципом 20/80 — 20% в макетах составляют элементы из дизайн-системы, а 80% — уникальные продуктовые или проектные элементы. Причем мы не стали указывать дизайнеру, что именно в макете должно быть взято из дизайн-системы.
Доля компонентов дизайн-системы в макете
Собственные компоненты в макетеВ итоге дизайнер не страдает, так как нет жёсткого требования применять что-то конкретное, он просто берёт то, что ему нужно для решения задачи, и счастлив. Мы тоже счастливы, потому что ему это помогло. С одной стороны у нас есть подробные гайдлайны, с другой — мы не бьём по рукам за их несоблюдение. Возможно, такой подход покажется странным, но, как показала практика, он работает. Причем само соотношение 20/80 тоже оказалось не строгим — есть проекты, где доля дизайн-системы составила лишь 5%, а есть и такие, где 80%. ОбучениеЕщё один инструмент, который позволяет повышать следование гайдлайнам — обучение. Мы проводим регулярные ревью макетов в командах и подсказываем, где дизайнер мог бы упростить себе жизнь, если бы пользовался дизайн-системой по правилам. И частый кейс, который мы встречаем на ревью — дизайнеры не нашли в библиотеке нужный компонент и рисуют его заново:
Тут дизайнер не нашёл селект и сделал его из инпута ввода номера.
А здесь мы посоветовали дизайнеру в карточке лицевого счёта использовать нотификацию из дизайн-системы, чтобы не кастомить лишний разЕщё распространённый кейс — разная стилистика компонентов:
Тут дизайнер смешал кнопку и инпут разных стилей и накостомил иконку с лейблом. Подсказали, что всё можно взять из дизайн-системы, да ещё и одного стиляИстория выровнялась: эталонные гайдлайны и правила использования дизайн-системы есть, следовать им рекомендуется, но не обязательно, неиспользование не наказывается, но дизайнеры в итоге следуют. При этом все довольны. Озвучивание простого принципа решило кучу проблем, облегчило дизайнерам жизнь и избавило команду дизайн-системы от нервных срывов.
Автор текста — Денис Пушкарь
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка под e-commerce, Разработка мобильных приложений, Flutter, Дизайн мобильных приложений, Монетизация мобильных приложений] How Is Flutter Helping Businesses In Getting Feature-Packed App At Affordable Prices
- [Проектирование и рефакторинг, Управление разработкой, Управление продуктом, Дизайн] Баланс между общим и частным в большой компании: консистентность, переиспользование кода и поиск чётких метрик
- [Искусственный интеллект, Голосовые интерфейсы] Исследовательский практикум. Голосовой UX – как сделать голосового виртуального ассистента лучшей версией человека
- [Фриланс, Развитие стартапа, Управление продуктом, Дизайн] История стартапа по разработке и изготовлению детских конструкторов из фанеры от первого лица
- [Accessibility, Дизайн, Здоровье] Доброшрифт: так пишутся добрые дела
- [Веб-дизайн, Разработка веб-сайтов, Повышение конверсии] Услышал интересное мнение по поводу лэндингов. Согласны или нет?
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android, Монетизация мобильных приложений] На Apps Live 2020 вас ждет не только классика — будем завоёвывать Поднебесную
- [Графический дизайн, Дизайн] Почему не стоит экономить на дизайне?
- [ООП] Чиним наследование?
- [Веб-дизайн, Разработка веб-сайтов, Google Web Toolkit, Поисковая оптимизация, Голосовые интерфейсы] Современное SEO: качество страниц
Теги для поиска: #_vebdizajn (Веб-дизайн), #_interfejsy (Интерфейсы), #_dizajn (Дизайн), #_dizajn (дизайн), #_dizajnsistemy (дизайн-системы), #_rostelekom (ростелеком), #_gajdlajny (гайдлайны), #_interfejsy (интерфейсы), #_blog_kompanii_rostelekom (
Блог компании Ростелеком
), #_vebdizajn (
Веб-дизайн
), #_interfejsy (
Интерфейсы
), #_dizajn (
Дизайн
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:56
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Привет! Мы команда дизайнеров и разработчиков, создающих цифровую дизайн-систему Ростелекома. Зачем? В большом энтерпрайзе множество продуктов и проектов, и у каждого из них есть потребности, которые может закрыть дизайн-система.Когда вы начинаете строить такую систему, вам кажется, что первое, что стоит сделать — это спроектировать все нужные компоненты. Вы проводите исследование, аудит текущих проектов и понимаете, что вот этот список компонентов вам и нужен, то есть решаете текущие задачи и немного смотрите в будущее, оценивая, что ещё может понадобиться. И в процессе возникает вопрос — а как дизайн-систему будут применять пользователи? Станут ли следовать всем правилам и гайдам, если мы их заложим в систему? Если напишем подробные мануалы, будут ли их читать? А если не напишем — не появится ли масса вопросов о границах и правильности применения компонентов? Что лучше: жестко зафиксированная инструкция или, наоборот, никаких правил?Чтобы ответить на эти вопросы и упростить себе жизнь, нужно понять, ваша дизайн-система — это, в первую очередь, инструмент или продукт? Поначалу мы считали, что все-таки инструмент и доносили эту идею во всех презентациях и демонстрациях. Говорили, что система предназначена для дизайнеров и разработчиков, и именно им нужна в ежедневной работе. Это работало, систему действительно так и применяли для решения продуктовых и проектных задач (на тот момент систему использовало 26 проектов!).Позже мы пришли к пониманию, что дизайн-система — это и продукт тоже. Она создаётся и развивается как полноценный продукт, более того, её можно упаковывать для разных сегментов по-разному. Нас осенило, что пользовательских ролей не две (дизайнер и разработчик), а гораздо больше, и мы можем адаптировать дизайн-систему под их задачи, тем самым формируя некую культуру дизайна и корпоративную систему стандартов.При этом нас по-прежнему волновал вопрос:А нужны ли вообще стандарты?Если правила можно нарушить без последствий — их нарушат. У нашей команды был опыт создания дизайн-системы и понимание того, что какие бы эталонные гайдлайны не создавались, их все равно не будут достаточно внимательно читать абсолютно все дизайнеры и, тем более, пунктуально им следовать. Когда мы раскатывали дизайн-систему по внутренним проектам Ростелекома, замечали, что дизайнеры используют её по-разному. Мы писали подробнейшие инструкции ко всем компонентам, а то и целым UX-паттернам, но дизайнеры либо соблюдали их выборочно, либо просто игнорировали. Когда вы кропотливо что-то создаете и видите потом, что вашим так заботливо выращенным детищем пользуются по-варварски и абсолютно не так, как вы себе это представляли, — это вводит в отчаяние. Иногда нас накрывала тоска от того, как дизайн-система применялась. Но дизайнеров можно понять. Им не хочется лишний раз думать о том, как правильно использовать дизайн-систему, у них другие задачи — думать о своих проектах, пользовательских сценариях и хорошем UX. У них часто нет ни желания, ни времени на скрупулёзное изучение гайдов дизайн-системы. Поэтому мы решили, что у нас будут правила использования компонентов, но требование следовать им не будет жестким. Иначе нарвемся на неприятие системы, а то и вовсе саботаж. Нужно подходить конструктивно — как помочь дизайнеру?  Соотношение элементов в макетеРешением стало введение собственной интерпретации всем известного закона Парето, мы его назвали принципом 20/80 — 20% в макетах составляют элементы из дизайн-системы, а 80% — уникальные продуктовые или проектные элементы. Причем мы не стали указывать дизайнеру, что именно в макете должно быть взято из дизайн-системы.  Доля компонентов дизайн-системы в макете  Собственные компоненты в макетеВ итоге дизайнер не страдает, так как нет жёсткого требования применять что-то конкретное, он просто берёт то, что ему нужно для решения задачи, и счастлив. Мы тоже счастливы, потому что ему это помогло. С одной стороны у нас есть подробные гайдлайны, с другой — мы не бьём по рукам за их несоблюдение. Возможно, такой подход покажется странным, но, как показала практика, он работает. Причем само соотношение 20/80 тоже оказалось не строгим — есть проекты, где доля дизайн-системы составила лишь 5%, а есть и такие, где 80%. ОбучениеЕщё один инструмент, который позволяет повышать следование гайдлайнам — обучение. Мы проводим регулярные ревью макетов в командах и подсказываем, где дизайнер мог бы упростить себе жизнь, если бы пользовался дизайн-системой по правилам. И частый кейс, который мы встречаем на ревью — дизайнеры не нашли в библиотеке нужный компонент и рисуют его заново:  Тут дизайнер не нашёл селект и сделал его из инпута ввода номера.  А здесь мы посоветовали дизайнеру в карточке лицевого счёта использовать нотификацию из дизайн-системы, чтобы не кастомить лишний разЕщё распространённый кейс — разная стилистика компонентов:  Тут дизайнер смешал кнопку и инпут разных стилей и накостомил иконку с лейблом. Подсказали, что всё можно взять из дизайн-системы, да ещё и одного стиляИстория выровнялась: эталонные гайдлайны и правила использования дизайн-системы есть, следовать им рекомендуется, но не обязательно, неиспользование не наказывается, но дизайнеры в итоге следуют. При этом все довольны. Озвучивание простого принципа решило кучу проблем, облегчило дизайнерам жизнь и избавило команду дизайн-системы от нервных срывов. Автор текста — Денис Пушкарь =========== Источник: habr.com =========== Похожие новости:
Блог компании Ростелеком ), #_vebdizajn ( Веб-дизайн ), #_interfejsy ( Интерфейсы ), #_dizajn ( Дизайн ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:56
Часовой пояс: UTC + 5