Почему страдает продукт, если его раздельно делают айтишники и дизайнеры

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

Допустим, клиент находит IT-компанию, которая берется не только за разработку бэка, но и за отрисовку дизайна. Программисты прекрасно понимают, как работает внутренняя архитектура, из чего строится пользовательский путь, но не могут его красиво визуализировать. Например, для них нет принципиальной разницы, как расположить меню: списком, кнопкой или на весь экран. В результате получается технически продуманный, рабочий продукт, но его эстетическая сторона остается под большим вопросом. Теперь ситуация наоборот –– представим, что агентство дизайнеров пытается развить у себя  годную back-end архитектуру и берет на себя разработку IT. Одно дело, если это простые проекты, без связи с CRM и интеграций внешних сервисов. Как только задачи усложняются, у дизайнеров получается продукт, который буквально рассыпается на глазах. Он может быть красиво сделан, но абсолютно не функционален.

Самый распространенный подход –– нанять команду дизайнеров, затем найти IT-разработчиков и разделить работу на два этапа. Исполнители между собой незнакомы, каждый несет ответственность только за свою часть. Дизайнеры делают работу и кидают в общий котел, программисты принимают. Потом выясняется, что она на какую-то часть нереализуема. Начинается бесконечное перетягивание одеяла, после чего первичная идея видоизменяется, портится и в итоге получается «недопродукт». Все, наверное, уже видели мем с рисунком лошади –– проект на этапе идеи (идеальный скакун) и конечная реализация... Проблема кривой лошади в том, что клиент не связал две команды одной общей целью на начальном этапе. 

Что, если back и front будут работать вместе

Главный довод на этом уровне заключается в том, что аудитория не доверяет продукту, который по всем параметрам отстает от общих тенденций. То, что хорошо работает, должно выглядеть соответствующим образом. Например, Notion, Figma — новейшие сервисы и стартапы, которые смотрятся отлично, работают как часы и объединяют в себе несколько сложных интеграций. Дело в том, что у продуктов последнего поколения экспертиза на всех уровнях находится условно под одной «крышей», т.е. они собирают сервис целиком, от IT до дизайна. 

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

Для IT-разработчиков нелишним будет включиться на начальном этапе и контролировать работу дизайнеров, чтобы те не углублялись в свои красивые фантазии и понимали, что делать можно, а чего категорически нельзя. Например, в одном крупном проекте при разработке сервиса для банка к команде дизайнеров был прикреплен внутренний back-end разработчик, который следил за работой и направлял в нужную сторону при необходимости. А необходимости разного рода случались часто  –– сложная банковская система с большим количеством нюансов и ограничений по безопасности. Без помощи IT-разработчика у дизайнеров не получилось бы безошибочно разработать интерфейс. Благодаря продуктивной коллаборации сервис был успешно реализован в общей схеме банка и работает на радость всем.
 
Дизайнерам важно понимать свою ответственность не только при отрисовке интерфейса, но и в дальнейшем вести авторский надзор. Стройно протянуть идею от начала до конца и объяснить все детали разработчикам, если это необходимо.

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

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

Партнеры, а не подрядчики

Вырастить дизайнеров внутри IT-компании такой же мертвый номер, как и наработать back-end экспертизу внутри обычного digital-агентства. В моем нынешнем агентстве есть опыт начинаний подобного рода, который не привел ни к чему хорошему. Единственный вариант — искать партнеров. Именно партнеров, а не подрядчиков. 

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

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