Этот пост является первым в серии из трех статей о том, как наша команда в YNAB думает о цвете в нашей системе дизайна. Мы рассмотрим принципы работы нашей системы, что вдохновило нас на ее создание и почему мы рады этому.
Другие посты посвящены тому, как система работает для дизайнеров и разработчиков.
Содержание статьи
Вступление
За последние несколько месяцев команда «Вам нужен бюджет» (YNAB) обновила подход к цветам в нашей системе проектирования.
Цвета обманчиво просты. Они являются основополагающим элементом интерфейсов, но слишком часто в конечном итоге становятся неразберихой путаницы встроенных определений, различных соглашений об именах на разных платформах, путаницы, когда использовать какой цвет, и проблем с обновлениями, когда что-то меняется. А поддержка темных режимов, которая становится нормой, вносит в цвета еще одно измерение сложности.
Наша новая система решает эти проблемы, используя комбинацию семантического именования и дополнительного «уровня абстракции» (подробнее о том, что именно это означает позже) как в наших проектах, так и в коде.
Эта серия статей посвящена тому, что мы можем назвать «формой» цветов в нашей системе проектирования: как мы структурируем систему и как она работает для дизайнеров и разработчиков.
Эта серия не будет охватывать «содержание» цветов в нашей системе дизайна: такие вещи, как то, как мы выбрали фактические значения цвета, которые мы используем, как мы обеспечиваем адекватный контраст, наши цветовые решения при проектировании для темного режима и т. Д.
Хорошо, давай займемся этим!
Что в имени?
Если вы дизайнер или разработчик, скорее всего, вы уже видели слова «семантический» и «цветной» в одном предложении ранее. Обычно это относится к способу именования цветов в зависимости от того, как они используются, а не от их оттенка. Это одна из многих теорий о том, как лучше назвать цвет.
С помощью семантического имени вы можете назвать цвет «деструктивным» или «негативным» — то, что означает, что цвет означает в вашем интерфейсе, в отличие от чего-то вроде «красный» (или даже что-то более забавное, например «помидор»). «).
Цветовая палитра, безусловно, является неотъемлемой частью любой системы дизайна. Палитра представляет вселенную возможностей для цвета в интерфейсе.
Палитра — отличное начало для создания визуально непротиворечивых приложений — определенный набор цветов уменьшает вероятность проникновения мошеннического шестнадцатеричного значения.
Вот как выглядит наша палитра в YNAB:
Наши семантические цвета идут дальше, чем просто именование цветов в зависимости от общей области их использования. Это второй уровень абстракции, который располагается поверх базовой палитры.
Наша цветовая система состоит из двух слоев:
- Базовая палитра, которая определяет каждое возможное значение цвета в нашем приложении.
Семантическая палитра, которая определяет цвета в зависимости от того, как они используются. Каждый семантический цвет указывает на цвет из базовой палитры. - Например, у нас есть семантический цвет для нашего основного цвета действия и еще один для фона заголовков. Каждый из этих семантических цветов ссылается на цвет из базовой палитры.
YNAB — это программное обеспечение для составления бюджета, что означает, что мы часто используем цвет в качестве визуального сигнала для положительного и отрицательного сальдо счета (мы никогда не полагаемся только на цвет, но цвет и доступность были бы отдельным постом).
Например, представление бюджета содержит «таблетки», которые отображают сумму, оставшуюся в данной категории бюджета пользователя. В верхней части экрана также есть панель, отображающая общий бюджетный статус.
Помимо визуальной согласованности, основным преимуществом этой системы является то, насколько легко она поддерживает темный режим. Фактически, адаптация наших приложений к темному режиму — это то, что вдохновило этот подход к цвету в первую очередь.
Давайте рассмотрим цвет, который мы используем для первичных элементов — primaryAction
. Этот цвет ссылается на primary600
из базовой палитры.
Великий. Но как насчет темного режима?
Ну, все, что нам нужно сделать, это создать дополнительное отображение для primaryAction
.
Для темного режима мы сопоставляем его с primary500
более светлым синим цветом, потому что мы хотим, чтобы первичные элементы «выскакивали» больше на темном фоне (например, доступность, выбор цвета для темного режима может быть совершенно отдельным статья. Мы не будем вдаваться в подробности здесь, но прочитайте эту статью команды в Superhuman для отличного учебника).
Двухслойный семантический подход к цветам позволяет нам гибко обновлять цвета, сохранять наше приложение визуально согласованным и эффективно проектировать для темного режима.
В следующих двух статьях этой серии будут рассказываться о том, как эта система работает на самом деле — для дизайнеров и разработчиков.
Спасибо Алану Деннису (который придумал структуру этого подхода) и остальным командам разработчиков и разработчиков YNAB за помощь в реализации этой системы.
Дополнительная благодарность Алану Деннису, Дилану Мэйсону и Тристану Гарварду за отзыв о первом черновике этого поста.