Всем доброго времени суток. Давно я что-то ничего не писал, и вот созрел. Предлагаю сегодня поговорить о ui-системе. Зачем она нужна, когда она нужна, что дает, какие минусы имеет и вообще стоит ли ввязываться в это блуд. Я часто слышу на разных конференциях, что панацея от всех болезней в бизнесе — это наличие дизайн-системы (ui-системы). Что, как только вы достигаете ее, то сроки сокращаются в 100500 раз. Что разработчики не хотят открутить голову дизайнерам, и, наоборот, что качество продукта возноситься до небес, и еще много всего восхитительного об этой сущности. Но так ли все это ? Или это просто розовые очки, которые застилают глаза всех причастных к созданию ui-системы в компании и побочка от постоянных нервных срывов, скандалов, поиска компромиссов и просто выгорания? В этой статье я постарался разобраться, а стоит ли игра свеч или как в анекдоте про нюансы.
Для начала, чтобы рассуждать, что чем является, нам потребуется разобраться в понятиях и терминах предметной области.
UI - kit — это полный набор элементов и компонентов, необходимый для сборки большого однородного продукта. Он включает различные кнопки, иконки, поля для ввода данных и т. д. и позволяет сохранять узнаваемость продукта и доверие пользователей. Так мне сказал поисковик, я спорить не стал.
UI component являются основными блоками и элементами для дизайна пользовательского интерфейса. Они предоставляют пользователям способ взаимодействия с вашим веб-сайтом или приложением. Этими компонентами могут являться интерактивный текст и графика, которые сообщат пользователю, что делать дальше.
Гайдлайны — набор шаблонов и правил использования элементов, которые упорядочивают процесс работы. Благодаря гайдлайнам к простым задачам не привлекают дизайнера, а сразу подключают разработчика.
UI - система — это совокупность всего вышеперечисленного. Вся информация в UI - системе структурирована и разложена по полочкам, а на любой чих там найдутся ответы.
Звучит очень заманчиво, не правда ли? Давайте теперь поподробнее разберемся, что дает UI-система в абсолюте. То есть пока, для первого приближения, берем верхи.
Плюсы.
Аккумуляция знаний — все что может потребоваться при разработке или погружении нового дизайнера или разработчика заключена в одном месте. И, по сути, весь процесс обучения и погружения в продукт сводится к одному действию - к изучению UI - системы.
Консистентность — все интерфейсы выглядят одинаково, имеют одинаковую сетку, одинаково себя ведут.
Простота работы — так как все описано, отрисовано, протестировано и весь процесс создания сводится к тому, что ты берешь готовые кирпичики и разбрасываешь согласно гайдлайнам по экрану. Не пинайте, да, пример утрированный.
Скорость работы — как бы банально не звучало, но, как мне кажется, когда UI-система готова, то она не кисло сокращает время разработки в целом, включая создание новых экранов (дизайн). Как было замечено выше — просто двигай кирпичики.
Продуманность — так как UI- система никогда не делается впопыхах, а требует скрупулезной проработки, то, как правило, вся логика проработана до мельчайших деталей. Как пример: какое сообщение и когда выводить, состояния кнопок, или как выводятся ошибки.
Вот я пишу плюсы, и восторг меня захлестывает, я начинаю переобуваться в воздухе. НО…. К сожалению, я писал вначале черновик и поэтому знаю что будет дальше… Эх! Теперь давайте будем взрослыми людьми и поговорим о минусах.
Минусы.
Стоимость — создание простой дизайн системы обходится в стоимость космического шаттла, так как над дизайн-системой работает целая команда дизайнеров, аналитиков, разработчиков и проджектов. Все высказывают свои хотелки и стараются свести все воедино. Помимо прочего, вам потребуется внедрить созданную систему и поддерживать её в актуальном состоянии.
Многие скажут, что на создание всего уходят ресурсы. Да, но тут затраты в разы выше, чем просто разработка и поддержка продукта. UI-система это игра в долгую, и не всегда оправданная.
Гибкость — так как это большой пласт работы, то при каких-то изменениях надо задействовать множество ресурсов, а, значит, делается это не быстро. Давайте представим что у нас ребрендинг, который по статистике происходит раз в 3-5 лет. Получение результата займет 2 человека/года, если утрировано. Так же надо понимать, что помимо изменений потребуется еще и применить их к проектам.
Шаблонность -— шаг в сторону расценивается, как попытка побега, а прыжок приравнивается к попытке улететь. А, значит, если у вас передовой или креативный продукт — это будет очень больно. Вы либо получите очень неповоротливую систему, либо очень обширную, которая будет в себе содержать любой чих.
Добавление ресурсов -— если к вашему основному костяку потребуется добавить любое звено, будь то дизайнер, разраб или еще кто-то, то быстро это сделать просто физически не получится. Это связано с тем что, разрабу придется прочитать 2 “Войны и мира” для того чтобы вникнуть в подход, а дизайнеру прочитать 5 таких книг, так как придется ознакомиться со всеми стайл-гайдами и требованиями.
Стекозависимость -— разработанная дизайн система на ангуляре не будет работать на вью или реакте, так как созданные части не будут подходить. Как следствие, вы становитесь заложниками того, на чем у вас создана система. Высока вероятность того, что вам рано или поздно придется переписывать все, даже если будут просто серьезные изменения между версиями того стека, который вы выбрали. Как пример, vue 2 и 3. Или, например, произойдет обновление версий зависимых пакетов, которые будут содержать в себе синтаксические изменения, конфигурационные или обновления собственные.
Сложность интеграции с другими системами -— в некоторых случаях UI-системы могут быть сложно интегрированы с существующими системами или сторонними сервисами. Это может потребовать дополнительных усилий и времени.
Как вы могли заметить, минусов не так уж и много, но каждый из них может похоронить вашу идею о дизайн-системе на корню. Плюсы и минусы — это, конечно, аргументы, но, как мы все знаем, есть и другие переменные, которые вносят поправки на ветер.
Для каких проектов подходят UI системы?
По опыту могу сказать следующее: UI системы подходят только для кровавого энтерпрайза и точка. Для всех остальных — это неподъемный инструмент. Возьмем пример проекта: у вас есть один продукт, над которым работают несколько команд разработки, дизайнеров, но продукт один. Тогда создание системы оправдано. При игре “в долгую” дизайн-система себя окупит и сделает вашу жизнь проще.
Но если в компании несколько продуктов и, более того, если они несут разную смысловую нагрузку, тогда создание ui-системы бессмысленно. Причиной этому то, что, скорее всего, продукты имеют разный внешний вид, функциональность, паттерны и много чего другого. Сведение их в единую ui-систему приведет к замедлению скорости разработки, а продукты будут мешать друг другу развиваться.
Так же нельзя скидывать со счетов стоимость обслуживания и развития ui-системы. Да, кто-то скажет, что все стоит денег, и с этим я соглашусь. Но далеко не всем нужна дизайн-система. Большинству достаточно иметь полноценный гайдлайн, который создается в разы быстрее и поддерживается проще.
Комментарии (7)
OlegZH
27.09.2024 07:12Почему авторы подобных статей (с хорошим внутренним посылом) не любят разбирать конкретные примеры? Статья завершается там, где должен возникнуть рабочий пример.
Лично для меня важная "зацепка" для понимания истинного положения вещей находится вот здесь:
Стекозависимость -— разработанная дизайн система на ангуляре не будет работать на вью или реакте, так как созданные части не будут подходить. Как следствие, вы становитесь заложниками того, на чем у вас создана система. Высока вероятность того, что вам рано или поздно придется переписывать все, даже если будут просто серьезные изменения между версиями того стека, который вы выбрали
Сказанное Вами совершенно справедливо. Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Строго говоря, здесь нужно три языка:
Язык, на котором создаётся сама дизайн-система.
Язык, на котором описываются пользовательские интерфейсы. Дизайн-система имеет дело с проектами на таком языке.
-
Язык конечной реализации, на который транслируются описания на языке №2.
Паразительно то, что всё это давно и хорошо известно в Computer Science. Существует понятие T-диаграммы, имеется метод раскрутки компиляторов и т.д. и т.п.
Evil_Evis Автор
27.09.2024 07:12Проблема в том что не существует универсального способа. Так как постройка такого монстра очень трудозатратное мероприятие и оно зависит от множества фактов:
Какой калификации сотрудники
На сколько их знания в этой области глубоки и есть ли опыт
Есть ли финансирование данной активности и одобрение руководства так как я знаю случаи когда такое старались провернуть в тихоря.
На сколько большая компания
Как быстро нужен результат
На сколько большое легаси в которое надо будет вживлять данную систему
И это далеко не весь список вопросов, ответы на которые повлияют на выбор сценария реализации проекта или же вообще прекращения активности в этом направлении
Сказанное Вами совершенно справедливо. Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Вывод немного другой. Я сообщил о риске который надо учитывать и построении планов на будущее. Просто если компания не определилась со стеком, то строить систему до решения этого вопроса просто глупо. А что касается чего-то нативного или абстрактного, то нативное будет работать медленнее компонента который сделан на конкретном стеке, а абстрактного то тут вляпываешься в поддержку, читабельность и прочее.
Строго говоря, здесь нужно три языка:
Язык, на котором создаётся сама дизайн-система.
Язык, на котором описываются пользовательские интерфейсы. Дизайн-система имеет дело с проектами на таком языке.
-
Язык конечной реализации, на который транслируются описания на языке №2.
Паразительно то, что всё это давно и хорошо известно в Computer Science. Существует понятие T-диаграммы, имеется метод раскрутки компиляторов и т.д. и т.п.
Мне кажется отчасти вы правы, но я не встречал ни одного годного решения которое просто в обращении или хотя бы понятно в использовании. Самое главное я не встречал готовых решение который выдавали бы хоть какой-то приемлемый результат пусть и с плясками. Если знаете с радостью готов выслушать.
OlegZH
27.09.2024 07:12Проблема в том что не существует универсального способа.
Универсальный способ существует и он коротко обрисован здесь мною. Решение известно. Но никто не торопится это решение воплощать.
. Так как постройка такого монстра очень трудозатратное мероприятие и оно зависит от множества фактов:
Наверное, то, что Вы сказали, суть одна из причин того, что описанное мною до сих пор не сделано. Я подчеркнул в Вашем высказывании ключевое слово "монстр". В действительности, декомпозиция задачи построения сложной системы посредством использования различных языков, суть разделение на относительно простые подзадачи и должно приводить к ускорению разработки.
Самое главное я не встречал готовых решение который выдавали бы хоть какой-то приемлемый результат пусть и с плясками.
Боюсь, таких решений нет. Хотя, я подозреваю, что в отдельных компаниях имеются внутренние системы, которые в чём-то близки к задуманному.
Evil_Evis Автор
27.09.2024 07:12Наверное, то, что Вы сказали, суть одна из причин того, что описанное мною до сих пор не сделано. Я подчеркнул в Вашем высказывании ключевое слово "монстр". В действительности, декомпозиция задачи построения сложной системы посредством использования различных языков, суть разделение на относительно простые подзадачи и должно приводить к ускорению разработки.
В данном случаи я думаю проблема не в столько в декомпазиции, сколько в том что постоянно меняется задача и оценки. А это значит что не возможно спрогнозировать когда это действительно будет приносить прибыль. Тут же все-таки про бизнес. А в бизнесе если нет сроков то нельзя этим управлять.
OlegZH
27.09.2024 07:12... меняется задача и оценки.
Давайте, тогда, рассмотрим какие-нибудь конкретные задачи. Вот была одна задача, а возникла другая... Чтобы оценить сложность.
ncix
Тема абсолютно верная, несмотря на "внушительные" названия типа "ядро", бигдата, сервисы, бизнес-логика, кластеры и прочий бэкенд, именно UI по прежнему съедает бОльшую часть дорогих ресурсов вашей команды
Но agile никто не отменял, не обязательно сразу пилить всю СИСТЕМУ, сделайте хотя бы сборник дизайна типовых элементов UI, без привязки к стеку. Это уже сразу сэкономит десятки дорогих человеко-часов.
Далее, придумайте правила, регламенты, как наращивать эту систему маленькими шажками, экологично, командами действующих проектов, без привлечения выделенных ресурсов. Через год-два глядишь и будет уже что-то серьезное.
Evil_Evis Автор
проблема размеренного подхода в том что как правила у каждой команды свои релизные циклы и как правило жёсткие. И очень трудно будет заставить команду у которой в KPI стоит вовремя сдать очередной релиз. Так как на это просто может не хватать времени да и думать о том что и как будут использовать другие просто не смогут так как не вкурсе деталей. Предположим начали делать шажками, но систему не только надо создать но и поддерживать, через 2 года вы попадете в точку в которой надо будет ее переписывать.