В команде Adobe Design Brand мы создаем брендинг для всех наших настольных, мобильных и веб-продуктов. Фирменный элемент может быть любым от двухбуквенных логотипов продукта до заставки и иконок в интерфейсе самого продукта.
Часто не замечаемый, но весьма наглядный элемент — это иконка типа файла. Тип файла — это имя, заданное конкретному виду файла, который может создавать приложение, например, .DOC для файла Word. Иконка типа файла — это значок, присвоенный типу файла, который отображается на экране при сохранении или открытии фактического файла.
С новейшей версией Creative Cloud этой осенью пользователи увидят, что все наши иконки типа файла имеют новый, свежий вид! В этой статье я углублюсь в размышления и процесс, связанный с нашим последним редизайном системы иконок типа файла Adobe, и расскажу о проблемах, с которыми мы сталкиваемся, в связи с развитием системы брендов в огромном семействе продуктов.
Определение проблемы
Многие клиенты могут не понимать, что Adobe имеет более 100 продуктов и сервисов в трех облаках: Creative Cloud, Document Cloud и Experience Cloud
Это означает, что одно небольшое изменение в системе дизайна может создать сотни изменений по всем направлениям.
Когда дело доходит до иконок типа файла, люди часто рассматривают только основные типы файлов приложения, например:
- .PSD для Photoshop,
- .AI для Illustrator,
- .INDD для InDesign
Однако большинство наших продуктов могут импортировать и экспортировать различные типы дополнительных файлов (например, только Photoshop имеет более 120 различных иконок типов файлов, отображаемых в его реестре).
Чтобы оптимизировать требования различных операционных систем, наши иконки типов файлов должны быть вручную попиксельно подогнаны под 10 различных размеров, а затем выпущены как набор растрированных .PNG-файлов, которые упаковываются в .ICNS (Mac) и .ICO (Windows) файлы.
Когда мы учитываем количество размеров и форматов для каждой иконки типа файла, мы рассматриваем более 7000 ресурсов для изменения и управления с каждым циклом релиза.
Со скоростью, с которой продуктовая линейка Creative Cloud росла за последние четыре года, стало ясно, что объем усилий, необходимых для создания и поддержки этих иконок типов файлов в существующем рабочем потоке, больше не является масштабируемым.
Шаг 1: Аудит и исследование
Прежде чем мы смогли начать редизайн системы, нам пришлось исследовать, что мы сейчас используем в наших продуктах. Мы обратились к команде каждого продукта, чтобы помочь нам провести аудит всех их иконок типа файла.
Отсутствие системности были повсюду, и они, вероятно, были результатом двух факторов:
- Различные команды, владеющие семейством продуктов, и больше не согласовывающие дизайн
- При появлении онлайн новых продуктов и типов файлов отдельные иконки создаются как единоразовые.
С информацией, собранной в ходе нашего аудита, мы, с высоты птичьего полета, создали представление о существующей архитектуре типа файла.
Во-первых, мы организовали иконки типа файла по семейству продуктов и перекрестно привязали их, чтобы посмотреть, какие дополнительные типы файлов были разделены между несколькими приложениями, чтобы мы могли устранить повторяющиеся иконки. Сделав это, мы смогли сократить количество дополнительных типов файлов до 65%.
Затем мы классифицировали типы файлов по функциям, таким как «Изображение», «Аудио», «Код» и «3D». Обычно иконка типа файла будет содержать метафору, которая говорит о ее основной функциональности (например, иконка файла HTML будет использовать метафору скобок </>, чтобы сообщить, что ее функциональность связана с кодом или кодировкой).
Мы заметили, что некоторые типы файлов использовали несколько версий одной и той же метафоры, в то время, как другие имели индивидуальные метафоры, которые могли быть заменены более общим значком. Мы начали создавать широкие группы типов файлов, чтобы назначить единую метафору для всей семьи. При этом нам удалось сократить число метафор типа файла в нашей библиотеке более чем наполовину.
Шаг 2: Эскиз и дизайн
После того, как мы получили полное представление о старой системе, мы начали устанавливать основные принципы организации для новой:
- Только основные типы файлов получат ассоциацию цветов логотипа продукта. Например, .PSD будет синим и .AI будет оранжевым.
- Создаем нейтральную палитру для дополнительных типов файлов, которые поддерживаются несколькими приложениями. Например, Photoshop и Illustrator будут использовать одну и ту же иконку типа файла .PNG, вместо того, чтобы каждый из них имел свою собственную уникальную версию иконки посредством ассоциации цветов бренда.
- Создаем основную библиотеку метафор типов файлов, чтобы иконки были согласованными и не пришлось настраивать ресурсы для отдельных случаев.
Мы начали делать эскизы с учетом этой новой структуры.
Одним из основных факторов, лежащих в основе редизайна, было упрощение и удаление как можно большего количества элементов на иконке типа файла без потери ее смысла. Мы опустили тег и переместили тип файла в нижнюю часть иконки. Мы также убрали загиб страницы, чтобы сгладить дизайн и создать более современный визуальный язык.
Еще одним важным фактором было соответствие по спектру — новый язык дизайна интерфейса Adobe — который в настоящее время распространяется во всех наших продуктах. К тому же мы закруглили углы наших иконок типа файла и начали создавать библиотеку, которая либо использовала существующие метафоры из базы данных Spectrum, либо создавала новые, которые соответствовали бы их стилю иллюстрации.
Наконец, мы добавили яркую цветовую схему в иконку типа файла, чтобы связать существующий брендинг логотипов наших продуктов. Это изменение не только создало более сплоченную визуальную систему, но также новые иконки стали отображаться лучше в темных интерфейсах, тогда как наши старые иконки исчезли на темном фоне.
Шаг 3: Итерация и утверждение
После того, как мы определились с направлением проектирования, мы протестировали новые иконки типа файла в контексте. Во время первоначальной проверки мы исследовали все области, где иконки типа файла отображаются в разных операционных системах и в наших собственных продуктах. Мы также рассмотрели каждый контекст, в котором иконки отображались в разных размерах и разрешениях.
На экранах рабочего стола Mac и Windows нам приходилось учитывать иконки, отображаемые в разных представлениях (список и сетка) с различными коэффициентами масштаба (от минимального размера 16 пикселей до 512 пикселей). Также была проблема со светлым и темным интерфейсами, например, в разделах «Недавние элементы» или «Поиск в Spotlight» на рабочем столе Mac. Затем мы рассмотрели, где представлены наши иконки типов файлов в наших собственных продуктах, например, в панели «Активы», «Диалог медиа-браузера» и «Экран приветствия» при первом запуске приложения.
Как можно себе представить, мы быстро углублялись в неясные и забытые уголки нашей системы, где живут иконки типа файла. Тем не менее, это было ценное упражнение. Нам нужно осознать масштаб задачи.
Последний шаг состоял в том, чтобы посмотреть иконки типа файла, добавленные в пользовательском интерфейсе наших веб- и мобильных сервисов, таких как Adobe Acrobat и Creative Cloud Libraries. Поскольку эти службы также управлялись разными дизайн командами, нам приходилось координировать работу множества людей в соответствии с нашими планами по модернизации системы дизайна типов файлов.
Мы гордимся конечным результатом, потому что новый язык дизайна более ясен, более последователен и представляет собой следующую эволюцию системы визуального бренда Adobe.
Шаг 4: Создание нового рабочего процесса
Мы создали новый рабочий процесс для производства, который использовал скриптовые функции в Illustrator для компиляции и экспорта .PNG-файлов одним нажатием кнопки. Этот новый шаблон сэкономил нам десятки часов мучительно медленной, ручной работы.
Нам также нужен был лучший способ компиляции этих растрированных PNG-файлов в .ICNS (Mac) и .ICO (Windows). Раньше мы использовали плагин IconBuilder от IconFactory с нашими шаблонами Fireworks. Однако с новым рабочим процессом нам требовалось более гибкое решение, которое отвечало бы нашим потребностям: в первую очередь способность перетаскивать любой набор .PNG-файлов и наличие приложения автоматически сохраняющего файлы в форматах .ICO и .ICNS в правильных размерах.
После поиска стороннего компилятора мы решили, что лучше работать с нашими инженерами, чтобы создать внутреннее приложение, настроенное под наши нужды. Они создали удивительный инструмент, который мы с любовью называем Captain Icon — компилятор, который мы использовали для группирования всех наших новых иконок типа файла. (Хотя Captain Icon по-прежнему программа на стадии внутреннего бета-тестирования, наши инженеры надеются в ближайшем будущем поделиться им в GitHub, чтобы он стал доступен для нашего сообщества разработчиков!)
Шаг 5: Внедрение изменений
Мы все еще находимся на этом этапе и, вероятно, задержимся на нем надолго. Каждый раз, когда мы выпускаем новую версию Creative Cloud, мы привлекаем менеджеров продуктов и инженеров из многих команд, следя за тем, чтобы дизайн был согласован повсюду.
Внедрение изменений часто представляет собой утомительный процесс общения с командами по электронной почте (сотни писем), установка нескольких версий тестовых сборок для проверки ресурсов, ведение журнала и устранение неизбежных багов, управления несколькими дедлайнами релиза.
Наши продукты также построены на базе разных кодов, это означает, что команды могут реализовывать одни и те же ресурсы по-разному и находить проблемы, уникальные для каждой платформы. Обеспечение качества и соблюдение руководящих принципов бренда, вероятно, является одной из наименее интересных задач для нашей команды, но это важная часть поддержания развитой системы дизайна.
Небольшие изменения могут сделать большие отличия
В нашей команде, мы часто используем метафору дерева Бонсай, чтобы описать работу, которую мы делаем.
Разработка системы дизайна бренда, которая содержит сотни продуктов, опирается на миллион небольших поэтапных изменений на этом пути — мы обрезаем ветку тут и там и направляем рост дерева в желаемом направлении.
Хотя в деталях легко заблудиться, все, что мы узнаем в процессе, переносит нас на следующую итерацию, а затем на следующую.
Нет комментариев