// //
Мнения

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

4 июня, 2018
avatar
Денис Судилковский
Head of Products Design в ЛУН.ua
Мы любим тексты без ошибок. Если вы все же их обнаружили, выделите фрагмент и нажмите Ctrl+Enter.

Денис Судилковский, Head of Products Design в ЛУН, рассказывает о бессмысленности хайпа дизайн-систем, ошибочном принятии их за панацею для ускорения работы команды и успеха продукта. Примеры показательны в B2C продуктах с возможностью применения Continuous Integration и здравого смысла.

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

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

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

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

1. Становление. Разработка дизайн-системы противопоказана

Вы ищите бизнес-модель. У вас нет продукта, это еще пробы конкретизировать потребность с достаточным спросом и оптимальный (с точки зрения рынка!) способ ее решения и дистрибуции.

Этап требует концентрации, скорости и гибкости. У вас не может быть стандарта, вы еще не знаете своих ограничений в рамках которых будете действовать.

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

2. Рост. Дизайн-система не нужна

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

Этап роста — это вырвать из рта соседа напротив уже дожеванный им кусок пирога.

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

Продукт (вместе с компанией) растет в численности привлеченных к его созданию участников. И здесь вопрос к новой структуре организации. Вас уже не 10 в коворкинге, теперь 100 коллег на двух этажах.

Вариант А. Отделы и департаменты.

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

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

Но здесь дизайн-система — костыль, который решает проблемы возникшие из-за природы структуры «отделов». Возможно выгоднее изменить причину, а не «лечить симптомы»?

Вариант Б. Кросс-функциональные команды.

6–8 человек в одной комнате. Каждый закрывает определенную экспертизу, которая идет «в нахлёст» с соседом. Грубый пример: дизайнер достаточно компетентен в разработке, чтобы говорить на языке разработчика о задачах разработчика и сидит с ним за соседними столами работая над одной общей задачей.

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

Делить Большой Продукт на части для отдельных команд:

  •  По фичам. У продукта есть core-предложение к которому «прилипают» дополнительные. Каждая команда занимается своей фичей.
  • По этапам воронки. Когда есть более-менее линейный flow пользователей, удобно делить отдавая ответственность за каждый этап конкретной команде. Огромный плюс — у каждой группы есть свой главный KPI, над ростом которого они и работают.
  • По сегментам ЦА. Особо сложная форма разбития, но есть ситуации, когда один продукт работает с разными сегментами с большим пересечением их потребностей.
  • Дробить на отдельные продукты. Когда продукт дорастает до размера, что детали его работы не укладываются в голове одного человека, самое время разделить его на части дав каждой большую автономию.
  •  Еще как-то.

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

Кросс-функциональная структура дает значимо большую скорость при отсутствии внутренней бюрократии по сравнению с другими формами организации. На этом этапе вы не создаете дизайн-систему, потому что она (sic!) затормозит и так высокую скорость принятия решений!

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

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

Исправляют ошибки проводя рефакторинг и заданием идеологических ограничений для команды. Пример таких в ЛУН:

«Не плоди новые сущности»
«Baby Steps»
«Проще»

*да, они не всем понятны. Про них расскажу отдельно.

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

3. Зрелость. Дизайн-систему надо было начать год назад.

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

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

Подобрать идеальный момент для старта работы над дизайн-системой невозможно.

Есть несколько сигналов, что пора подумать о дизайн-системе:

  • Продукт в своем росте MAU вот-вот приближается к плато. Дальше только качать эффективность (DAU/MAU+LTV). (Ваш рост замедлится)
  • Ближайший сильный конкурент по доле рынка отстает на треть вашей доли. (Ваша позиция стабильна)
  • Тренд по рынку положительный и скорость роста продукта приближается к отраслевому индексу. (Вы можете инвестировать в длинную)

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

4. Упадок. Дизайн-система вам не поможет

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

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

 

Статья впервые опубликована в блоге Дениса Судилковского.

avatar
Денис Судилковский
Head of Products Design в ЛУН.ua
Колонка

У нас есть еще кое-что для вас

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: