Глава 5: Поддержка системы дизайна (часть 3)
← Предыдущая часть | Следующая часть →
Перед вами перевод книги Atomic Design Брэда Фроста, разработчика интерфейсов, поклонника мобильного интернета и создателя методики «Атомарный дизайн».
Если вы здесь впервые, то лучше начните сначала.
Сделайте систему гибкой
Бытует выражение: «Единственное, что постоянно — это перемены». Система дизайна считается жизнеспособной, только когда является достаточно гибкой, реагирует на обратную связь, проходит итерации и развивается вместе с продуктами, которые обслуживает.
Ошибочно полагать, что как только вы создадите систему дизайна, она станет единственным и незаменимым источником истины. Ограничить мышление таким образом — верный способ получить обратный результат. Если пользователи почувствуют себя загнанными в рамки паттернов, которые не решают их проблемы, они будут воспринимать систему дизайна как бесполезный инструмент и начнут искать более удобные решения.
Чтобы ваша система могла развиваться и приносить пользу в долгосрочной перспективе, необходимы четкие принципы управления ею. Продуманная стратегия управления начинается с ответов на важные вопросы о внесении изменений. А именно:
- Что происходит, когда существующий паттерн не подходит для конкретного случая? Меняем паттерн? Рекомендуем использовать другой паттерн? Создаем новый?
- Как обрабатываются запросы на создание новых паттернов?
- Как списываются устаревшие паттерны?
- Что происходит при обнаружении багов?
- Кто утверждает изменения в системе дизайна?
- Кто несет ответственность за обновление документации?
- Кто непосредственно вносит изменения в паттерны?
- Как изменения системы дизайна отражаются в продуктах?
- Как люди узнают о внесенных изменениях?
Наверняка, есть еще много вопросов, на которые нужно ответить. Смысл в том, что ваша команда должна понимать, что делать в случае внесения изменений в систему. А изменения неизбежны.
Не устаю повторять: отлаженные коммуникации и сотрудничество между разработчиками и пользователями — ключ к успешному управлению системой дизайна. Сделайте это взаимодействие как можно проще. Настройте канал системы в Slack или Yammer, установите фиксированные рабочие часы, убедитесь, что ваше программное обеспечение для техподдержки помогает в коммуникации и позволяет при необходимости связаться с вами в чате и по телефону. Если у пользователей возникла проблема, они должны точно знать, куда обращаться за помощью.
Помимо повседневного неофициального общения между разработчиками и пользователями, запланируйте регулярные встречи для обсуждения «положения в стране» с ключевыми заинтересованными сторонами. На этих встречах обсуждайте, что работает, а что нужно улучшить, пересматривайте приоритеты и дорожную карту, чтобы система точно удовлетворяла потребности бизнеса. Такие встречи особенно полезны для того, чтобы держать заказчиков в курсе всех событий, поскольку они в основном не участвуют в повседневной задачах, связанных с системой дизайна.
# Внесение изменений в систему дизайна
Важнейшей частью обслуживания системы дизайна является поддержание ее актуальности. Паттерны интерфейса должны быть релевантными, отражать лучшие практики разработки и дизайна, эффективно решать задачи компании.
Для этой цели разработка стратегии по обновлению паттернов имеет решающее значение. Инайяли де Леон Перссон (Inayaili de León Persson), веб-разработчик из студии Canonical, выделила время на проработку такой стратегии при создании фронтенд-фреймворка Vanilla:
Мы подумали, что хорошо бы задокументировать критерии, которым должен соответствовать паттерн, чтобы стать паттерном Vanilla. В результате мозгового штурма мы создали диаграмму. Она показывает, какие шаги нужно предпринять, чтобы превратить обычный паттерн в паттерн Vanilla. ~ Инайяли де Леон Перссон, Canonical
Диаграмма, о которой идет речь, — дерево решений, которое точно определяет, что нужно сделать, чтобы добавить новый паттерн в систему дизайна.
С паттернами, входящими в систему дизайна, может произойти три события: обновление, добавление и удаление.
Обновление
В паттерны интерфейса можно и нужно вносить изменения по многим причинам: добавлены новые функции, исправлены баги, подтянута графика, улучшена производительность или доступность, произошел рефакторинг кода, обновление в UX и т. д.
Разработчики системы дизайна должны понимать, когда и зачем нужно править паттерны, как это делать, и как распространить обновления на каждый продукт.
Чтобы система дизайна прослужила много лет, крайне важно поддерживать актуальность паттернов. Никто не хочет использовать и поддерживать систему дизайна, ориентированную на Web 2.0, полную ошибок и плохого кода!
Добавление
Будучи командой профессионалов, наверняка вы не планируете включать в систему дизайна все мыслимые и немыслимые паттерны. По крайней мере в самом начале. Поскольку система используется в большом числе продуктов, неизбежно возникнут ситуации, когда существующие паттерны не смогут покрыть какой-либо конкретный запрос. В этой связи вам понадобятся новые.
При добавлении паттернов в библиотеку следует соблюдать осторожность. Если каждая «хотелка» будет приводить к созданию нового паттерна, система дизайна раздуется до космических размеров. Нужно понять, является ли тот или иной запрос разовой ситуацией или пригодится и в других случаях.
Возможно, вы предполагаете, что какой-то паттерн одноразовый. Однако, если другая команда, работающая над другим продуктом, увидит ваш и скажет: «Нам это тоже нужно!» — это сигнал, что паттерн стоит добавить в библиотеку.
Удаление
Паттерны устаревают по многим причинам. Возможно, какой-то паттерн оказался ужасно неудобным в использовании (как говорится, хорошая мысля приходит опосля). Возможно, паттерн устарел из-за обновлений в UX или по техническим причинам. Или уже долгое время нигде не использовался. Может быть вы получили от пользователей большое количество негативных отзывов о работе с определенным паттерном.
Отличная идея — составить схему работы с устаревшими паттернами. Ведь просто взять и удалить паттерн из системы — это как выдернуть коврик из-под ног людей, использующих его в своей работе. Для решения этой проблемы Salesforce создала умную утилиту Sass Deprecate, которая помечает шаблоны-претенденты на удаление в ближайшем будущем. Благодаря использованию флажков и стилей разработчики предупреждают пользователей, что определенный шаблон не рекомендуется использовать и лучше подыскать альтернативу.
Над переводом работают Ольга Кокоулина и Ринат Шайхутдинов.
Если вам понравился перевод, нажмите кнопку Clap в левой части экрана. Вам нетрудно, нам приятно :)
Видеокурсы и практика по дизайну интерактивных систем: ux/ui, веб-дизайн и бренд-дизайн
Вас ждет плотная проектная практика по анимации интерфейсов, дизайну сайтов, а также мобильных и веб-приложений. Под руководством наставников в стиле «смотри и повторяй»!
Breezzly — это среда для тренировки digital-навыков. Здесь вы встретите комплекты видеокурсов в актуальных инструментах интерактивного дизайна, среди них Figma, Principle и Invision Studio. А каждый проект — это живой кейс с историей, собранной по горячим следам!
