Глава #5.3: Поддержка системы дизайна (часть 3)

40

← Предыдущая часть | Следующая часть →

Перед вами перевод книги Atomic Design Брэда Фроста, разработчика интерфейсов, поклонника мобильного интернета и создателя методики «Атомарный дизайн».

Если вы здесь впервые, то лучше начните сначала.


Сделайте систему гибкой

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

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

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

  • Что происходит, когда существующий паттерн не подходит для конкретного случая? Меняем паттерн? Рекомендуем использовать другой паттерн? Создаем новый?
  • Как обрабатываются запросы на создание новых паттернов?
  • Как списываются устаревшие паттерны?
  • Что происходит при обнаружении багов?
  • Кто утверждает изменения в системе дизайна?
  • Кто несет ответственность за обновление документации?
  • Кто непосредственно вносит изменения в паттерны?
  • Как изменения системы дизайна отражаются в продуктах?
  • Как люди узнают о внесенных изменениях?

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

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

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

# Внесение изменений в систему дизайна

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

Для этой цели разработка стратегии по обновлению паттернов имеет решающее значение. Инайяли де Леон Перссон (Inayaili de León Persson), веб-разработчик из студии Canonical, выделила время на проработку такой стратегии при создании фронтенд-фреймворка Vanilla:

Мы подумали, что хорошо бы задокументировать критерии, которым должен соответствовать паттерн, чтобы стать паттерном Vanilla. В результате мозгового штурма мы создали диаграмму. Она показывает, какие шаги нужно предпринять, чтобы превратить обычный паттерн в паттерн Vanilla. ~ Инайяли де Леон Перссон, Canonical

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

Веб-разработчики из Canonical задокументировали процесс принятия решений для управления обновлениями и дополнениями паттернов в фронтенд-фреймворке Vanilla.

С паттернами, входящими в систему дизайна, может произойти три события: обновление, добавление и удаление.

Обновление

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

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

Чтобы система дизайна прослужила много лет, крайне важно поддерживать актуальность паттернов. Никто не хочет использовать и поддерживать систему дизайна, ориентированную на Web 2.0, полную ошибок и плохого кода!

Добавление

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

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

Возможно, вы предполагаете, что какой-то паттерн одноразовый. Однако, если другая команда, работающая над другим продуктом, увидит ваш и скажет: «Нам это тоже нужно!» — это сигнал, что паттерн стоит добавить в библиотеку.

Удаление

Паттерны устаревают по многим причинам. Возможно, какой-то паттерн оказался ужасно неудобным в использовании (как говорится, хорошая мысля приходит опосля). Возможно, паттерн устарел из-за обновлений в UX или по техническим причинам. Или уже долгое время нигде не использовался. Может быть вы получили от пользователей большое количество негативных отзывов о работе с определенным паттерном.

Отличная идея — составить схему работы с устаревшими паттернами. Ведь просто взять и удалить паттерн из системы — это как выдернуть коврик из-под ног людей, использующих его в своей работе. Для решения этой проблемы Salesforce создала умную утилиту Sass Deprecate, которая помечает шаблоны-претенденты на удаление в ближайшем будущем. Благодаря использованию флажков и стилей разработчики предупреждают пользователей, что определенный шаблон не рекомендуется использовать и лучше подыскать альтернативу.


Над переводом работают Ольга Кокоулина и Ринат Шайхутдинов.

Если вам понравился перевод, нажмите кнопку Clap в левой части экрана. Вам нетрудно, нам приятно 🙂

← Предыдущая часть | Следующая часть →


Мобильное приложение «Заметки о психике» | Mental Notes

Подкидывает идеи, как привлечь, удержать и направить внимание пользователя.

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

Скачать приложение в Appstore →
Курс «Атомарный дизайн»

Посты в категории UI-дизайн

5 техник, которые помогут сделать call to action интуитивно понятным

Ринат Шайхутдинов

7 мая 2019

Посты в категории UI-дизайн

Оптические иллюзии в дизайне интерфейсов (для фанатиков дизайна)

Ольга Жолудова

3 марта 2019

Посты в категории UI-дизайн

Руководство по веб-дизайну для разработчиков

Ринат Шайхутдинов

15 октября 2018