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

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

UI-кит

Представьте ситуацию.

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

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

Вы бодро забираете тикет и твердо намерены разобраться с ситуацией. Но тут в процесс врывается реальность.

С легкой ноткой недоумения вы обнаруживаете, что вообще-то в проекте есть UI-кит, но дизайнеры (и разработчики, да) используют его скорее как набор рекомендаций, а не жестких правил. Ещё круче — оказывается, что есть пара компонентов, которые решают очень похожую задачу.

Мы же разработчики. Чего мы хотим? Правильно — использовать готовое и не пилить новых компонентов под каждую задачу. Во-первых, это здоровая лень, а во-вторых, мы все-таки молодцы и не хотим раздавать кодовую базу. Ну и, как минимум, неплохо бы следовать паттернам разработки, в нашем случае — DRY.

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

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

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

Что делать?

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

Чекаут

Следующий этап по нашему флоу — это чекаут. Это этап, на котором дизайнер смотрит верстку, щупает ее руками, говорит, что получилось, и пишет нам правки.

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

Что же случилось?

Дизайнер внёс свои правки и не предупредил нас. Почему? Да забыл он.

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

А дальше вот что. За несколько часов до релиза дизайнер с двух ног залетает в нашу задачу и говорит, что надо срочно что-то переделать.

Примерно в этой ситуации мы были где-то три года назад.

Как всё было

Для понимания проблемы расскажу подробнее, над чем именно я работаю.

• личные кабинеты.

• единый личный кабинет (новая версия нашего ЛК).

• сам сайт beeline.ru, наша общая витрина.

• частично — над UI-китом.

Как понимаете, проекты достаточно большие, поэтому без UI-кита тут вообще никак, да и без большой команды — тоже. У нас около 30 фронтендеров и 20 дизайнеров, которые всей толпой разрабывают с десяток проектов. Наша задача — сделать так, чтобы эти люди не переломали всё в попытках разобраться с китом.

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

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

А вот процесса передачи дизайна в разработку не было в принципе. То есть разработчик не мог быстро дать какой-то фидбэк, рассказать про edge-кейсы, рассказать про какие-то сложности, либо наоборот, где что можно упростить.

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

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

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

Что стали делать

У кита было достаточно проблем.

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

Во-вторых, сами компоненты были очень открыты для кастомизации. То есть можно было менять их практически как угодно, вплоть до того, что кнопки у нас были тогда желтые. Можно было сделать их черными, градиентными, какими угодно. Кто во что горазд, в общем.

Терпеть дальше это было совершенно нельзя. 

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

И тут в нашу команду пришли новые дизайнеры со своим взглядом на киты.

Мы встали перед выбором — переписывать все в промежуточную версию или запилить все уже с нуля. Взвесив все «за» и «против», поняли, что с нуля написать будет проще. Да, у нас в какой-то момент было три версии кита на проекте, но от промежуточной мы быстро избавились. И начали делать полноценную новую версию.

Что нам помогло?

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

Во-вторых, написать роадмап и (что важно) придерживаться его. Потому что если на это забить, ничего, собственно, и не выйдет.

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

У нас сейчас всё выглядит примерно вот так.

Мы долго думали, как лучше сделать.

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

Так что мы пришли к ситуации на картинке выше. Мы рассказываем о том, что у нас разработано и какие изменения произошли. То же самое примерно делают и дизайнеры. Любой может зайти и почитать историю, какие-то актуальные изменения и прочие полезности.

Еще одна проблема с прошлым китом была в том, что никто особо не знал, что там вообще дорабатывается. Собственно, это тоже решилось.

Дизайн-ревью

Тут, по большому счету, мы не стали изобретать какой-то космолет. Все достаточно просто. 

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

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

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

Что в итоге

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

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