Как оптимизировать трудозатраты на разработку дизайн-системы с Platform V UI Kit

Источник: Хабр "Подход, который помог нам точно оценить трудозатраты на разработку дизайн-системы"

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

Меня зовут Александр Самсонов, я руководитель отдела UX в СберТехе. Вместе с командой работаю над продуктом Platform V UK Kit — дизайн-системой React-компонентов корпоративного масштаба. Расскажу, как мы начали оценивать затраты ресурсов при разработке дизайн-системы, и как метод помог нам лучше планировать работу, точно отвечать на вопросы и не выглядеть в глазах бизнеса нервными белыми воронами в чёрных толстовках.

Зачем вообще оценивать время на разработку

Вернёмся ненадолго к вопросам заинтересованных лиц. Чаще всего вопросы можно разбить на три группы:

Про время:

— Сколько времени нужно на создание дизайн‑системы?

— Когда будет готово?

— Почему так долго?

Про объём:

— Что уже сделано?

— Что ещё надо сделать?

— Что можно не делать?

— Почему этого нельзя не делать?

Про стоимость:

— Сколько стоит?

— Сколько‑сколько? Почему?!

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

Наша команда столкнулась с этими вопросами, когда приступила к разработке дизайн-системы. В СберТехе десятки продуктов: одни разрабатываются и развиваются не один год, другие находятся поддержке с перспективой замены на новые продукты. Нужно было привести пользовательские интерфейсы продуктов к единому внешнему виду и поведению, то есть перевести на общую дизайн систему. Для компании это означало не только наведение порядка во внешнем виде, но и экономию ресурсов за счёт того, что команды перестанут раз за разом создавать одни и те же компоненты для продуктов.

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

Немного теории про дизайн-систему

Поскольку все дальнейшие расчёты ведутся в рамках проекта дизайн-системы, в этой главе я дам немного теории про дизайн-системы вообще. Если вы и так знаете, зачем нужны ДС, как они разрабатываются, и кем поддерживаются — листайте сразу к расчётам.

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

Базовые примитивы:

• палитру;
• шрифты;
• плашки и тени;
• анимацию.

Айдентику:

• логотипы;
• пиктограммы;
• изображения (фоны, иллюстрации);
• звуки.

Элементы взаимодействия:

• компоненты;
• шаблоны;
• сценарии.

Документацию:

• руководство по стилю;
• руководство по взаимодействию.

Ресурсы для разработчиков:

• код;
• компоновка страницы, разделов и форм.

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

Делать с нуля или взять готовое решение

При планировании состава компонентов новой дизайн-системы можно ориентироваться на уже существующие ДС. Например, на Ant, в которую сейчас входит около 70 типовых компонентов взаимодействия.

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

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

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

Как считать время и что такое дизайн-час

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

• загруженности;
• эффективности используемого инструмента;
• продуктивности сотрудника или его группы. 

Например, опытный дизайнер Петя может проанализировать потребность, сделать черновой вариант, протестировать, скорректировать и выпустить компонент за один рабочий день = 15 дизайн-часов. А джун Вася только погружается в процессы, и ему на эту же работу и те же 15 дизайн-часов потребуется 5 рабочих дней. То есть один дизайн-час для Пети и для Васи в реальности будет занимать разное количество времени из-за разницы опыта.

Важно, что дизайн-час может быть только целым, не делится на более мелкие части. То есть на любую работу уйдёт минимум 1 дизайн-час, даже если опытный Петя сделает это за 10 минут. А так как в продуктовом проектировании и дизайне практически не бывает типовых задач, привести эту единицу измерения к нормативу не получится.

Оценка времени на разработку базовых примитивов

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

Например, базовые примитивы — палитры, шрифты, плашки и тени — мы считали так. Сначала прикинули все компоненты работы:

• Количество и наименования (семейства) гарнитур (обычно одна‑две, редко три и больше).
• Количество стилей текста (для европейских языков может хватить 5–10 стилей, для поддержки азиатских потребуется ещё 5–7).
• Количество цветов и оттенков каждого цвета (единицы или максимум два десятка цветов, единицы или десятки оттенков каждого).
• Число плашек, степени прозрачности фона и радиусы скругления их углов (если это требуется).
• Количество уровней теней (3–7 уровней).
• Направление и скорость анимации (вывод форм, проявление теней).

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

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

Айдентика

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

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

Компоненты взаимодействия

Компоненты также делятся на базовые и составные: флаг (чек-бокс) — базовый компонент, а радиокнопка — составной. Чек-бокс без сопровождающей подписи может быть использован в интерфейсе, например, в первой колонке записи для её выбора, а радиокнопка без подписи смысла не имеет и применяться не может. Соответственно, времени на разработку компонента чек-бокса без сопровождающей подписи понадобится меньше, чем на радиокнопку с подписью.

Примеры оценки простого компонента

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

Формула подсчёта простых компонентов выглядит так:

Простой компонент = количество примитивов × 2 × (количество состояний × количество размеров и тем / 2)

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

1. Флаг (чек-бокс)

Составляющие: 

• плашка (активна, неактивна);
• цвет (при наведении, при выборе);
• пиктограммы рамки, галочки и неполного выбора (есть, нет);
• подпись.

Итого три элемента для варианта без подписи или четыре с подписью.

Состояния:

• неактивен (сброшен);
• неактивен (выбран);
• активен (сброшен);
• активен (выбран).

Всего четыре штуки.

Для создания и описания компонента «с нуля» потребуется:

• 3×2×2 = 12 дизайн‑часов для варианта без подписи;
• 4×2×2 = 16 дизайн‑часов для варианта с подписью.

2. Радиокнопка

Составляющие:

• плашка (активна, неактивна);
• цвет (при наведении, при выборе);
• пиктограммы рамки и точки (есть, нет);
• подпись.

Всего четыре элемента.

Состояния:

• активна (не выбрана);
• активна (выбрана);
• неактивна (не выбрана);
• неактивна (вся).

Всего четыре штуки.

Итого, для создания и описания компонента «с нуля» потребуется: 4×2×2 = 16 дизайн-часов.

Оценка сложности составных компонентов

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

Сложный компонент = количество компонентов × 2 × (количество состояний × количество вариантов × количество размеров и тем / 2)

На простейший компонент нужно отводить не менее двух дизайн-часов, потому что при подготовке каждого компонента придётся явно или неявно пройти следующие этапы:

• Анализ потребности.
• Анализ состава (это сложность компонента, ее минимум мы уже умеем считать).
• Составление списка свойств (название и тип).
• Подготовка рабочего варианта.
• Коммуникации с коллегами.
• Тестирование (самостоятельное или с помощью коллеги).
• Создание дополнительных вариантов (например, размеров или цветовых тем).
• Подготовка или обновление сопроводительной документации.

Подготовка рабочего варианта, коммуникации и тестирование фактически представляют собой запас времени для исправления ошибок. Если вы умеете делать всё сразу «набело» — повезло, справитесь ещё быстрее!

Примеры расчёта оценки составного компонента

Здесь мы считаем, что все входящие базовые компоненты уже сделаны. Используем вторую формулу расчёта.

3. График

Составляющие:

• плашка (базовый, при наведении);
• цвет (при наведении, при выборе, цвета сегмента для обозначения параметра);
• изображения (заглушка при отсутствии данных и окружность, разделённая на сегменты);
• пиктограммы;
• флаги (чек‑боксы);
• текст (заголовок, подписи и примечания).

Всего шесть элементов.

Состояния:

• данных нет;
• данные отображены;
• данные устарели (нет связи).

Всего три штуки.

Итого, для создания компонента нам потребуется: 6^2×(3/2) = 54 дизайн-часа.

4. Карточка

Составляющие:

• плашка (активна, неактивна);
• цвет (при наведении, при выборе);
• пиктограммы;
• Флаги (чек‑боксы);
• метки (теги, чипсы);
• раскрываемое меню действий;
• текст (заголовок, подзаголовок, основное содержание, примечание или дата);
• график (считаем готовым, на составляющие не делим);
• кнопка.

Всего девять элементов.

Состояния:

• активна (выбрана);
• при наведении;
• перемещение (перетаскивание на другое место);
• неактивна.

Всего четыре штуки.

Следовательно, для создания компонента нам потребуется: 9^2×(4/2) = 162 дизайн-часа.

Пример расчёта оценки сложности таблицы

Таблица — самый насыщенный и сложный по составу компонент дизайн-системы, поэтому пример его расчёта приведу отдельно.

Отдельные компоненты таблицы — это:

• плашка;
• цвета (фоны для заголовка, записей, разделительных линий, панели информирования, выделенных ячеек и колонок);
• кнопки;
• раскрываемые меню;
• группирующий элемент (аккордеон);
• поля ввода;
• флаги (чек‑боксы);
• радио‑кнопки;
• пиктограммы;
• ссылка;
• метка (теги, чипсы);
• текст;
• разбиение на страницы.

Всего 13 элементов

Состояния:

• ячейка активна;
• ячейка неактивна;
• ячейка подсвечена;
• при наведении;
• перемещение (изменение порядка записей вручную);
• при выборе.

Всего шесть штук.

Варианты верстки:

• строками;
• колонками.

Всего две штуки.

Размеры:

• малый;
• средний;
• крупный.

Всего три штуки.

Количество тем:

• светлая;
• тёмная.

Всего две штуки.

Следовательно, для создания компонента нам потребуется: 13 × 2 × (6 × 3 × (2 + 2) / 2) = 2448 дизайн-часов.

Если какого-то компонента не хватает, к этому числу придётся добавить ещё время на его изготовление.

Результаты в нашей команде

На этапе планирования дизайн-системы нам удалось уйти от приблизительных оценок, которых было достаточно для выполнения работы, к конкретным числам. Такой метод расчёта помогает с точностью до 90 % спрогнозировать стоимость и время на разработку каждого элемента дизайн-системы.

Дополнительно к этому:

• Работа стала более предсказуемой и комфортной благодаря более точным оценкам времени.
• Экономим ресурсы команд благодаря учёту работы в целом и переиспользованию отдельных компонентов.
• Оптимизируем трудозатраты, снижаем стресс и неприятные сюрпризы, потому что всегда точно знаем, сколько сил и времени нужно на каждую задачу.

Наработки, которые мы получили в результате работы над дизайн-системой, перенесли в продукт Platform V UI Kit. Сейчас он представляет собой развитую дизайн-систему корпоративного масштаба с возможностью быстрой и гибкой настройки внешнего вида. По сути, это готовое решение для проектов любого масштаба, позволяющее создавать пользовательские интерфейсы и не тратить на это огромное количество ресурсов проектировщиков, дизайнеров или разработчиков. Инструмент подходит командам и приложениям, для которых важны скорость разработки, быстро и качественное прототипирование и создание UI-макетов.