Подход, который помог нам точно оценить трудозатраты на разработку дизайн-системы
При планировании проекта команде дизайна приходится отвечать на много вопросов. Главные — что делать, как долго и сколько это будет стоить. Ответы есть не всегда и точно не у дизайнеров, которые занимаются отдельными задачами и не видят картину в целом.
Меня зовут Александр Самсонов, я руководитель отдела UX в СберТехе. Вместе с командой работаю над продуктом Platform V UK Kit — дизайн-системой React-компонентов корпоративного масштаба. Расскажу, как мы начали оценивать затраты ресурсов при разработке дизайн-системы, и как метод помог нам лучше планировать работу, точно отвечать на вопросы и не выглядеть в глазах бизнеса нервными белыми воронами в чёрных толстовках.
Зачем вообще оценивать время на разработку
Вернёмся ненадолго к вопросам заинтересованных лиц. Чаще всего вопросы можно разбить на три группы:
Про время:
— Сколько времени нужно на создание дизайн-системы?
— Когда будет готово?
— Почему так долго?
Про объём:
— Что уже сделано?
— Что ещё надо сделать?
— Что можно не делать?
— Почему этого нельзя не делать?
Про стоимость:
— Сколько стоит?
— Сколько-сколько? Почему?!
На первые две группы вопросов почти всегда может ответить проектировщик, так как он владеет практически всей информацией. А вот третья группа обычно вызывает затруднения и у проектировщика, и у дизайнера. Как вообще рассчитать, во сколько обойдётся разработка радиокнопки с точки зрения ресурсов и денег?
Наша команда столкнулась с этими вопросами, когда приступила к разработке дизайн-системы. В СберТехе десятки продуктов: одни разрабатываются и развиваются не один год, другие находятся поддержке с перспективой замены на новые продукты. Нужно было привести пользовательские интерфейсы продуктов к единому внешнему виду и поведению, то есть перевести на общую дизайн систему. Для компании это означало не только наведение порядка во внешнем виде, но и экономию ресурсов за счёт того, что команды перестанут раз за разом создавать одни и те же компоненты для продуктов.
При этом и бизнесу, и разработчикам нужна была точная оценка времени и стоимости, чтобы правильно планировать последовательность работы над продуктами и вовремя реализовывать важные фичи. Никакой системы оценки не было — и мы начали создавать её для себя с нуля.
Немного теории про дизайн-систему
Поскольку все дальнейшие расчёты ведутся в рамках проекта дизайн-системы, в этой главе я дам немного теории про дизайн-системы вообще. Если вы и так знаете, зачем нужны ДС, как они разрабатываются, и кем поддерживаются — листайте сразу к расчётам.
Дизайн-системы сейчас в моде: о них много пишут, многие их внедряют и разрабатывают. При этом мало кто задумывается, сколько ресурсов нужно на внедрение, развитие и поддержку собственной дизайн-системы. Вопрос не праздный. Дизайн-система — очень крутая и очень ресурсозатратная вещь. С одной стороны, дизайнер получает не просто компоненты для составления макетов, а целый набор сущностей:
Базовые примитивы:
Айдентику:
Элементы взаимодействия:
компоненты;
шаблоны;
сценарии.
Документацию:
Ресурсы для разработчиков:
С другой стороны, для поддержки и развития в идеале нужна отдельная команда, которая будет ставить цели, проводить исследования, своевременно исправлять выявленные недостатки и обновлять дизайн-систему. Если делать это в свободное от основных задач время, результат будет так себе.
Делать с нуля или взять готовое решение
При планировании состава компонентов новой дизайн-системы можно ориентироваться на уже существующие ДС. Например, на Ant, в которую сейчас входит около 70 типовых компонентов взаимодействия.
Взяв за основу устоявшееся решение с открытым кодом, разработчики сразу же смогут использовать его компоненты для реализации фронтэнда, проектировщики могут сосредоточиться на создании и тестировании библиотеки компонентов и шаблонов для используемого редактора, а дизайнеры — на стилях оформления и подготовке материалов айдентики и брендинга. В этом случае можно быстрее получить результат с меньшими затратами и внедрять изменения поэтапно, обновляя части компонентов или разделов.
Делать с нуля дольше и сложнее: разработчикам придётся ждать, когда в библиотеке соберётся необходимый минимум компонентов, а пользователям может показаться, что продукт остановился в развитии. Зато своя разработка снимает правовые риски и убирает вероятность того, что изменения в корневой дизайн-системе повлекут за собой проблемы в вашем продукте.
Мы решили писать свою дизайн-систему после того, как провели внутреннее исследование и посмотрели, как и с чем работают другие команды в СберТехе. С прицелом на долгосрочную перспективу победила разработка с нуля, так как нам важно было обеспечить независимость от чужой системы.
Как считать время и что такое дизайн-час
Чтобы рассчитать время, нужна понятная единица измерения. Для оценки работы проектировщиков и дизайнеров мы решили использовать условную единицу под названием дизайн-час. Он не равен астрономическому часу, но переводится в него. Преобразование дизайн-часа в астрономические часы и плановые даты завершения работы выполняется через коэффициенты:
загруженности;
эффективности используемого инструмента;
продуктивности сотрудника или его группы.
Например, опытный дизайнер Петя может проанализировать потребность, сделать черновой вариант, протестировать, скорректировать и выпустить компонент за один рабочий день = 15 дизайн-часов. А джун Вася только погружается в процессы, и ему на эту же работу и те же 15 дизайн-часов потребуется 5 рабочих дней. То есть один дизайн-час для Пети и для Васи в реальности будет занимать разное количество времени из-за разницы опыта.
Важно, что дизайн-час может быть только целым, не делится на более мелкие части. То есть на любую работу уйдёт минимум 1 дизайн-час, даже если опытный Петя сделает это за 10 минут. А так как в продуктовом проектировании и дизайне практически не бывает типовых задач, привести эту единицу измерения к нормативу не получится.
Оценка времени на разработку базовых примитивов
Теперь, имея среднюю временную единицу с учётом коэффициента опыта дизайнера, мы можем перевести её в количество часов. А количество часов — в стоимость разработки, исходя из зарплаты этого сотрудника.
Например, базовые примитивы — палитры, шрифты, плашки и тени — мы считали так. Сначала прикинули все компоненты работы:
Количество и наименования (семейства) гарнитур (обычно одна‑две, редко три и больше).
Количество стилей текста (для европейских языков может хватить 5–10 стилей, для поддержки азиатских потребуется ещё 5–7).
Количество цветов и оттенков каждого цвета (единицы или максимум два десятка цветов, единицы или десятки оттенков каждого).
Число плашек, степени прозрачности фона и радиусы скругления их углов (если это требуется).
Количество уровней теней (3–7 уровней).
Направление и скорость анимации (вывод форм, проявление теней).
Сначала создали пробную страницу с черновыми компонентами, иллюстрациями и текстами. Затем провели несколько итераций для оценки и корректировки, затратив около недели на каждую. Итого на разработку базовых примитивов ушёл примерно месяц работы старшего дизайнера, а стоимость подготовки базовых примитивов оказалась эквивалентной его месячной оплате.
В результате мы получили небольшую обособленную часть библиотеки с именованными цветами, стилями и прочими составляющими. Это важная для начала часть — базовые примитивы позволяют потом перейти к работе над составными компонентами. Например, над пунктом навигационного меню или шапкой формы, которые состоят из отдельных примитивов.
Айдентика
Работу над пиктограммами оценивали так: за один дизайн-час можно подготовить 5–10 пиктограмм, если постановка задачи понятна и образ утвержден. А вот с иллюстрациями и фонами ситуация иная, здесь детализация выше и масштаб работы гораздо больше. В нашем случае одна иллюстрация занимает не меньше двух дизайн-часов.
Вариант выбрать и купить готовый набор допустим только на первом этапе, потом всё равно придётся доделывать и дорисовывать. Мы, например, просто не нашли настолько полного набора пиктограмм, фонов и иллюстраций, который сразу устроил бы все продуктовые команды, поэтому, опять же, делали с нуля.
Компоненты взаимодействия
Компоненты также делятся на базовые и составные: флаг (чек-бокс) — базовый компонент, а радиокнопка — составной. Чек-бокс без сопровождающей подписи может быть использован в интерфейсе, например, в первой колонке записи для её выбора, а радиокнопка без подписи смысла не имеет и применяться не может. Соответственно, времени на разработку компонента чек-бокса без сопровождающей подписи понадобится меньше, чем на радиокнопку с подписью.
Примеры оценки простого компонента
Строго говоря, все базовые компоненты содержат в себе как минимум два примитива: цвет и плашку, цвет и шрифт или цвет и пиктограмму. Оценка сложности компонента равна произведению удвоенного количества входящих в него примитивов и других компонентов (без учёта вариантов) на количество возможных состояний и размеров создаваемого компонента (вариантов). При этом повторные вхождения компонентов или примитивов не считаем. Например, если в компоненте две пиктограммы, считаем её за одну единицу и т. п.
Формула подсчёта простых компонентов выглядит так:
Простой компонент = количество примитивов × 2 × (количество состояний × количество размеров и тем / 2)
Для примера давайте оценим сложность для базовых компонентов в случае, когда у нас нет готовых примитивов и всё надо делать «с нуля».
Флаг (чек-бокс)
Составляющие:
плашка (активна, неактивна);
цвет (при наведении, при выборе);
пиктограммы рамки, галочки и неполного выбора (есть, нет);
подпись.
Итого три элемента для варианта без подписи или четыре с подписью.
Состояния:
неактивен (сброшен);
неактивен (выбран);
активен (сброшен);
активен (выбран).
Всего четыре штуки.
Для создания и описания компонента «с нуля» потребуется:
Радиокнопка
Составляющие:
плашка (активна, неактивна);
цвет (при наведении, при выборе);
пиктограммы рамки и точки (есть, нет);
подпись.
Всего четыре элемента.
Состояния:
активна (не выбрана);
активна (выбрана);
неактивна (не выбрана);
неактивна (вся).
Всего четыре штуки.
Итого, для создания и описания компонента «с нуля» потребуется: 4×2×2 = 16 дизайн-часов.
Оценка сложности составных компонентов
Сложность составного компонента оценивается похоже: мы комбинируем готовые компоненты, поэтому заменяем умножение на возведение в квадрат и учитываем возможные варианты. Получается формула:
Сложный компонент = количество компонентов × 2 × (количество состояний × количество вариантов × количество размеров и тем / 2)
На простейший компонент нужно отводить не менее двух дизайн-часов, потому что при подготовке каждого компонента придётся явно или неявно пройти следующие этапы:
Анализ потребности.
Анализ состава (это сложность компонента, ее минимум мы уже умеем считать).
Составление списка свойств (название и тип).
Подготовка рабочего варианта.
Коммуникации с коллегами.
Тестирование (самостоятельное или с помощью коллеги).
Создание дополнительных вариантов (например, размеров или цветовых тем).
Подготовка или обновление сопроводительной документации.
Подготовка рабочего варианта, коммуникации и тестирование фактически представляют собой запас времени для исправления ошибок. Если вы умеете делать всё сразу «набело» — повезло, справитесь ещё быстрее!
Примеры расчёта оценки составного компонента
Здесь мы считаем, что все входящие базовые компоненты уже сделаны. Используем вторую формулу расчёта.
График
Составляющие:
плашка (базовый, при наведении);
цвет (при наведении, при выборе, цвета сегмента для обозначения параметра);
изображения (заглушка при отсутствии данных и окружность, разделённая на сегменты);
пиктограммы;
флаги (чек‑боксы);
текст (заголовок, подписи и примечания).
Всего шесть элементов.
Состояния:
Всего три штуки.
Итого, для создания компонента нам потребуется: 6^2×(3/2) = 54 дизайн-часа.
Карточка
Составляющие:
плашка (активна, неактивна);
цвет (при наведении, при выборе);
пиктограммы;
Флаги (чек‑боксы);
метки (теги, чипсы);
раскрываемое меню действий;
текст (заголовок, подзаголовок, основное содержание, примечание или дата);
график (считаем готовым, на составляющие не делим);
кнопка.
Всего девять элементов.
Состояния:
активна (выбрана);
при наведении;
перемещение (перетаскивание на другое место);
неактивна.
Всего четыре штуки.
Следовательно, для создания компонента нам потребуется: 9^2×(4/2) = 162 дизайн-часа.
Пример расчёта оценки сложности таблицы
Таблица — самый насыщенный и сложный по составу компонент дизайн-системы, поэтому пример его расчёта приведу отдельно.
Отдельные компоненты таблицы — это:
плашка;
цвета (фоны для заголовка, записей, разделительных линий, панели информирования, выделенных ячеек и колонок);
кнопки;
раскрываемые меню;
группирующий элемент (аккордеон);
поля ввода;
флаги (чек‑боксы);
радио‑кнопки;
пиктограммы;
ссылка;
метка (теги, чипсы);
текст;
разбиение на страницы.
Всего 13 элементов
Состояния:
ячейка активна;
ячейка неактивна;
ячейка подсвечена;
при наведении;
перемещение (изменение порядка записей вручную);
при выборе.
Всего шесть штук.
Варианты верстки:
строками;
колонками.
Всего две штуки.
Размеры:
малый;
средний;
крупный.
Всего три штуки.
Количество тем:
светлая;
тёмная.
Всего две штуки.
Следовательно, для создания компонента нам потребуется: 13 × 2 × (6 × 3 × (2 + 2) / 2) = 2448 дизайн-часов.
Если какого-то компонента не хватает, к этому числу придётся добавить ещё время на его изготовление.
Результаты в нашей команде
На этапе планирования дизайн-системы нам удалось уйти от приблизительных оценок, которых было достаточно для выполнения работы, к конкретным числам. Такой метод расчёта помогает с точностью до 90% спрогнозировать стоимость и время на разработку каждого элемента дизайн-системы.
Дополнительно к этому:
Работа стала более предсказуемой и комфортной благодаря более точным оценкам времени.
Экономим ресурсы команд благодаря учёту работы в целом и переиспользованию отдельных компонентов.
Оптимизируем трудозатраты, снижаем стресс и неприятные сюрпризы, потому что всегда точно знаем, сколько сил и времени нужно на каждую задачу.
Наработки, которые мы получили в результате работы над дизайн-системой, перенесли в продукт Platform V UI Kit. Сейчас он представляет собой развитую дизайн-систему корпоративного масштаба с возможностью быстрой и гибкой настройки внешнего вида. По сути, это готовое решение для проектов любого масштаба, позволяющее создавать пользовательские интерфейсы и не тратить на это огромное количество ресурсов проектировщиков, дизайнеров или разработчиков. Инструмент подходит командам и приложениям, для которых важны скорость разработки, быстро и качественное прототипирование и создание UI-макетов.
На этом у меня всё. Буду рад ответить на вопросы и комментарии!
