Основы DesignOps: как работают современные дизайнеры

Development | Amber | Комментировать запись

Если вы читаете эту заметку, вы, вероятнее всего, знакомы с термином DevOps. А вот термин, о котором сегодня пойдет речь – DesignOps – гораздо менее популярен. Его значение понять несложно, он образован по аналогии с DevOps, но это лишь вершина айсберга.

Итак, DesignOps, или Design operations – это новая, еще до конца не сформированная проблема, с которой уже сталкиваются группы дизайнеров, стремящиеся повысить свою ценность в проектах, которые они создают для своих заказчиков и их клиентов. Поскольку эта область еще только формируется, пока что в терминологии DesignOps встречаются несоответствия.

В этой статье мы немного поговорим о DesignOps (учитывая опыт дизайнеров из Autodesk, Uber, Airbnb, Pinterest, Expedia и других организаций).

Инструментарий разработчика и дизайнера

Как мы знаем, разработчики кодят. Код можно писать в TextEdit или Notepad и использовать FTP, а можно в редакторах типа Emacs или vi. Позже можно добавить такие инструменты, как IDE, систему контроля версий, репозитории данных и т.п. В завершение можно настроить уровень непрерывной интеграции, который будет отслеживать изменения в коде и автоматически тестировать их. Каждый из этих уровней инструментов должен как-то повышать качество вашего кода и вашу ценность в проекте. То есть выбор используемых инструментов является тактическим решением.

Операционные системы, которые состоят из процессов, практик и инструментов (например, Agile, программное обеспечение для управления проектами (JIRA и т. д.)), а также правильная организация рабочего пространства (которое может быть личным и общим) позволяют сделать вас как разработчика более продуктивным, тем самым улучшая ваши результаты. Все эти моменты направлены на то, чтобы вы стали лучше в своем деле – кодировании.

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

Чаще всего организации используют одни и те же инструменты и для разработчиков, и для дизайнеров– например, JIRA, GitHub или Confluence. Но эти инструменты не учитывают всех потребностей рабочего процесса дизайнера. По мере масштабирования проектных групп игнорирование инструментов и процессов разработки для проектирования приводит к неизбежному снижению ценности дизайнеров. Дизайнеры не используют IDE; они используют набор графических инструментов. Дизайнеры не работают над кодом через текстовые файлы в средах с открытым исходным кодом; они используют комбинацию векторных и растровых графических форматов, которые часто создаются в закрытых, частных системах. Дизайнеры не делают то же самое, что разработчики (они и не должны). Они изучают несколько вариантов практически на каждом этапе проектирования. Концепция «разветвления» не масштабируется при рассмотрении 10-20 вариантов одного микровзаимодействия в одном и том же файле, где находится 5-10 вариантов макета.

В то же время растет тенденция создания систем проектирования, что иногда заставляет дизайнеров взаимодействовать с кодом. Обычно это и есть точки взаимодействия между дизайнерами и разработчиками. Поскольку системы проектирования состоят из компонентов, написанных с помощью комбинации CSS, HTML и JavaScript, использование стандартного контроля версий, управления ошибками и даже инструментов типа Agile начинает приобретать все больший смысл.

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

Организация команды дизайнеров

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

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

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