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

Проще говоря: хорошая система дизайна может сэкономить деньги и заработать деньги. Беспроигрышный.

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

Почему многие дизайн-системы терпят неудачу?

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

Однако внедрение систем проектирования с этим шаблоном вызывает несколько проблем и узких мест:

  1. Поскольку ваша дизайн-система находится под контролем, необходимые компоненты могут быть недоступны. Более того, к тому времени, когда вы решите включить его, продуктовые команды уже могут внедрить его самостоятельно.
  2. Ваша дизайн-система получает требования от продуктовых команд. Однако при монолитном подходе требования ставятся в очередь по разным причинам, таким как приоритет, стоимость и совместимость — «связывая» дорожные карты продуктовых команд с дорожными картами команды дизайн-системы.
  3. Принятие дизайн-системы ограничивает гибкость команды, поскольку они не могут внести свой вклад и должны ждать, пока команда дизайн-системы представит новые компоненты. Кроме того, этот процесс может занять несколько итераций и может не полностью соответствовать уникальным потребностям нескольких команд.
  4. Ваша дизайн-система принадлежит одной команде. Таким образом, ускорение доставки и масштабирование системы проектирования означает увеличение численности команды дизайнеров.
  5. Вам необходимо постоянно вкладывать усилия и большие суммы денег в дизайн-систему, чтобы обеспечить ее рост. В ту минуту, когда вы останавливаетесь, он начинает ржаветь и быстро считается «устаревшим кодом».

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

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

  1. Компании приходится вкладывать деньги в проектирование и создание дизайн-системы.
  2. Компания должна нести расходы, связанные с продуктовыми командами, разрабатывающими свою дизайн-систему.
  3. Компания должна нести расходы на непоследовательный пользовательский опыт.

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

Следовательно, крайне важно определить способы снижения затрат при разработке и внедрении систем проектирования.

Ну, как мы можем сэкономить деньги?

Одним из таких методов, который могут использовать компании, является распространение своей дизайн-системы.

Что такое распределенная система проектирования?

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

Однако для обеспечения согласованности и предотвращения путаницы крайне важно установить четко определенный процесс управления и проверки, который будет более подробно описан в следующей главе.

Но подождите, как это экономит расходы?

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

1. Повторное использование компонентов дизайна

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

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

2. Уменьшите нагрузку на развитие

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

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

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

3. Добавление ценности продукта

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

4. Большая отдача от инвестиций

Компании, использующие распределенные системы проектирования, переключают свои инвестиции на фактические группы разработчиков, а не на одну централизованную группу дизайнеров. Чаще всего это обеспечивает более значительную отдачу от инвестиций, чем централизованные системы проектирования, по двум основным причинам.

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

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

Внедрение распределенных систем проектирования

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

Решение проблем с одной попытки означает разработку повторно используемого кода, который могут использовать команды разработчиков, а не увеличение стоимости за счет изобретения велосипеда.

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

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

И организациям не нужно торопиться с процессом внедрения. Вместо этого они могут реализовать его постепенно.

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

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



Заключение

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

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

Я надеюсь, что эта статья была информативной и полезной для вас.

Спасибо за чтение.