Code Pilots 
Тендеры и лиды
Информация
У меня есть личная история на эту тему, и она не в пользу систем. Когда я делал свой первый продукт, мы решили сразу собрать универсальную основу — такую, из которой потом соберётся что угодно. Основу собрали. Первую версию продукта она задержала настолько, что проверку гипотезы мы получили на несколько месяцев позже, чем могли бы.
При этом сегодня у нас в Code Pilots есть продукт, который без такой основы просто не существовал бы. Ниже — разбор развилки: когда дизайн-система и UI Kit возвращают вложенное, а когда превращаются в дорогую мебель, которую никто не двигает.
Коротко: UI Kit — библиотека готовых элементов интерфейса под один продукт. Дизайн-система — это UI Kit плюс токены, правила применения, компоненты в коде, документация и люди, которые всё это поддерживают.
Разница здесь бюджетная, а спор о терминах — следствие. Набор компонентов рисуется один раз и дальше лежит. Система живёт: у неё есть версии, изменения, обратная совместимость и тот, кто отвечает за её развитие. Поэтому вопрос «нам нужна дизайн-система или UI Kit» на практике звучит иначе: готовы ли вы содержать отдельную сущность, у которой есть собственный жизненный цикл.
Рядом встречаются ещё два слова. Стайлгайд задаёт визуальные правила бренда — палитру, типографику, отступы. Гайдлайн объясняет, как и когда применять компоненты. Оба входят в систему, но по отдельности ничего не решают.
Если проговорить это на первой встрече, половина споров исчезает: стороны обычно называют одним словом разные объёмы работ.
Три условия, и работает она, когда совпадают хотя бы два.
Продуктов больше одного. Сайт и приложение, приложение под две платформы, несколько продуктов одной компании. Пока продукт один, выгода от переиспользования почти не видна: компоненты и так лежат в макетах этого продукта.
Релизы идут потоком. Если интерфейс меняется каждые две недели и над ним работают несколько человек, система экономит на согласованиях: спор о том, как выглядит кнопка, случается один раз и закрывается навсегда.
Продукт нужно тиражировать. Это самый честный случай, и у нас он есть. Hubstr — наш собственный продукт, приложение для закрытых сообществ и бизнес-клубов. Каждое сообщество получает своё приложение со своим названием и логотипом, собранное из общей основы с индивидуальными настройками. Внутри одного Hubstr новое сообщество поднимается за четверть часа. Без общей базы компонентов такой продукт не имел бы экономического смысла — он и строился вокруг неё.
Второй наш пример спокойнее: у музея Эрарта есть сайт и мобильные приложения, которые повторяют его функциональность. Мы ведём этот продукт с 2018 года, и общий визуальный язык здесь экономит не столько на разработке, сколько на каждом следующем изменении — выставка, акция и новый раздел выходят одинаково во всех каналах, потому что собираются из одних и тех же элементов. Как это устроено, видно по составу проекта: сайт, интернет-магазин, билеты и приложения живут как одна система.
Обратный случай встречается чаще, и выглядит он одинаково.
Продукт из десяти-пятнадцати экранов, одна команда, гипотеза ещё не проверена. В этой точке системная работа даёт отложенную выгоду, а платить за неё приходится сразу — сроком первой версии. Через полгода половина компонентов окажется ненужной, потому что продукт поедет в другую сторону, и это нормальный ход событий, который планированием не лечится.
Моя история выше — ровно про это. Универсальная основа выглядела разумно: мы строили фундамент на годы вперёд. Проблема в том, что фундамент строился под здание, проекта которого ещё не существовало.
Работающее правило простое: на старте достаточно короткого набора — палитра, типографика, сетка, пять-шесть базовых компонентов. Этого хватает, чтобы продукт выглядел цельным. Всё остальное добавляется тогда, когда компонент понадобился во второй раз. Не раньше — предположения о будущих потребностях здесь ошибаются чаще всего.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Главная статья расходов здесь — сопровождение, и её обычно в смете нет.
Систему нужно версионировать, документировать и обновлять во всех продуктах, которые её используют. Нужен человек, который принимает решения по спорным компонентам. Нужен процесс, по которому изменение доезжает из макета в код и дальше в релиз. Если этого нет, система расходится с продуктом за несколько месяцев: в макетах одна кнопка, в приложении три разные.
Разошедшаяся система хуже отсутствующей. К ней перестают обращаться, но продолжают поддерживать, и она превращается в статью расходов без отдачи.
Поэтому в оценке мы всегда отделяем создание от жизни. Создание — это недели, и его легко посчитать. Жизнь — это доля времени команды на постоянной основе, и решение о системе принимают именно по этой второй цифре.
Самая частая причина провала: систему собрали в макетах и не довели до кода.
Дизайнер обновляет компонент в общей библиотеке, разработчик верстает по скриншоту руками. Формально система есть, фактически интерфейс собирается заново на каждом экране. Проверяется это одним вопросом: что происходит, когда меняется скругление кнопки? Если ответ «дизайнер поменяет в библиотеке, разработчик пройдёт по всем экранам», системы нет — есть библиотека макетов.
Рабочий вариант выглядит иначе. Значения цветов, отступов и размеров живут переменными, которые разбираются и макетами, и кодом. Компоненты существуют в кодовой базе и переиспользуются как есть. Изменение делается в одном месте и приезжает во все продукты с ближайшим релизом. Именно поэтому мы держим дизайн-систему рядом с интерфейсной разработкой, а не в отдельной папке у дизайнера — это единственная её форма, которая доживает до второго года.
Порядок, который занимает час и экономит месяцы.
Посчитайте продукты и платформы, в которых живёт ваш интерфейс. Посчитайте, сколько человек меняет его одновременно. Прикиньте, как часто выходят релизы. Дальше честно ответьте, кто будет вести систему после запуска и сколько его времени вы готовы на это выделить.
Один продукт, одна команда, редкие изменения — берите набор базовых компонентов и живите спокойно. Несколько платформ, поток задач, планы тиражировать продукт — считайте полноценную систему, в бюджете которой отдельной строкой стоит её сопровождение. Промежуточный случай решается компромиссом: начинаете с набора и достраиваете его до системы тогда, когда появится второй продукт. Чем UI Kit отличается от системы по составу, мы разобрали в отдельном материале — там же про токены и уровни компонентов.
Чем UI Kit отличается от дизайн-системы? UI Kit — библиотека компонентов под один продукт. Дизайн-система включает в себя UI Kit и добавляет токены, правила применения, компоненты в коде, документацию и процесс поддержки. Первое можно сделать и забыть, второе нужно вести.
Когда нужна дизайн-система? Когда интерфейс живёт в нескольких продуктах или на нескольких платформах, над ним работают несколько человек и релизы идут потоком. Для одного продукта с редкими изменениями достаточно UI Kit.
Сколько стоит дизайн-система? Считать нужно две суммы: создание и сопровождение. Первая конечна, вторая идёт постоянно и в итоге весит больше. Решение о системе принимают по второй цифре.
Можно ли взять готовую дизайн-систему? Да, готовые библиотеки экономят старт и хорошо работают во внутренних инструментах, где важнее скорость. Для продукта с собственным брендом их обычно берут как основу и настраивают под себя через токены.
Как понять, что дизайн-система не работает? По одному признаку: разработчики собирают экраны мимо неё. Если изменение компонента не доезжает до продукта автоматически, система превратилась в библиотеку макетов, и её нужно либо доводить до кода, либо прекращать поддерживать.
