Как выстроить работу над дизайном цифровых продуктов со сторонним агентством

Всем привет! Меня зовут Саша Юдин, я арт-директор компании MobileUp. В этой статье я поделюсь своим опытом и расскажу, как выстраивать работу над дизайном цифрового продукта со сторонним агентством. А ещё постараюсь ответить на три вопроса: как выбирать исполнителей под задачи, как налаживать процессы взаимодействия и какие артефакты важно получить, чтобы стартовать разработку.

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

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

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

Цифровые продукты, предполагающие активное взаимодействия с пользователем, обычно гораздо сложнее в реализации. Они являются полноценной частью бизнеса, поэтому для их реализации нужно хорошо понимать бизнес-процессы, на которых продукт будет реализован. А ещё, как правило, эти бизнес-процессы нужно сильно дорабатывать или формировать новые. Всё начинается с исследования, когда мы собираем необходимую информацию. Затем наступает этап анализа, когда на основе полученных данных мы формируем концепцию будущего продукта и состав работ. Далее идут работы по проектированию, разработке дизайн-концепции, проработке интерфейса и подготовке документации. И чтобы сделать всё это понадобятся целая команда: проджект-менеджер, дизайнеры и аналитик. И, конечно, сам бизнес — именно на его стороне находится основная экспертиза по продукту.

Обычно выбор исполнителя для создания цифрового продукта выглядит так:

У компании появляется потребность, удовлетворить которую должен цифровой продукт. Компания решает, как именно он должен работать и формирует ТЗ. Дальше она либо проводит тендер, либо начинает искать исполнителей по своим каналам. Затем собирает коммерческие предложения, и на их основании выбирает подрядчика. Основные критерии выбора — наличие релевантных кейсов и стоимость. После этого начинается работа. А теперь давайте разберём, что не так с этим процессом.

Продукты на самом деле всегда разные. Согласно книге «Управление фирмой, оказывающей профессиональные услуги», все проекты делятся на три типа:

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

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

• ТЗ не может появиться в начале сложного проекта. На старте у компании недостаточно экспертизы, чтобы грамотно описать задачу и сформулировать ТЗ.
• Не учитывается экспертиза исполнителя. Когда компания решает самостоятельно подготовить ТЗ, она автоматически лишает проект ценности, которую в него может привнести студия-исполнитель.
• Тендеры лишают гибкости и диалога. В тендерах предусмотрен этап, когда можно задать вопросы, но не на все вопросы можно получить ответы. Компания-заказчик не может полноценно обсуждать проект, и это порождает проблемы.
• Оценка проекта зависит от экспертизы. Экспертизы заказчика часто недостаточно, чтобы предусмотреть все риски. И его оценка проекта может оказаться ниже реальной. Студия-исполнитель с более глубокой экспертизой хорошо понимает, с чем предстоит работать, какие подводные камни могут возникнуть, и отражает это в смете. Но заказчик не выбирает её, потому что стоимость кажется завышенной. В практике MobileUp было несколько кейсов, когда мы проигрывали по цене, но потом клиенты возвращались спустя время. Риски, о которых мы предупреждали сбывались, и они понимали, что наша оценка была верной.
• Нет понимания ценности для бизнеса. В ТЗ редко описывается, как будущий проект будет влиять на бизнес-показатели, что в нём важно, а что — второстепенно. Но понимание целей и миссии продукта очень важно для принятия решений в процессе работы.

Есть несколько принципов, которых стоит придерживаться в поиске и выборе исполнителей:

• Описывать не «как» должен работать продукт, а «что» он должен делать. Можно в свободном формате описать ожидаемые функции, но не готовить строгое ТЗ.
• Искать релевантных исполнителей с подтверждённой экспертизой. Под «релевантными» понимаются те, кто действительно подходит под задачу. Скажем, у вас проект-седина, и вам необходим опыт в конкретном направлении — финтехе. Вы ищите студии, которые работали в нише и могут показать подтверждённые кейсы. Если у вас проект-мозги, релевантный опыт в конкретной нише не так важен. Гораздо важнее то, как в компании выстроены процессы аналитики и есть ли кейсы, когда ребята делали что-то с нуля. Например, запускали стартап или какой-то проект, у которого нет аналогов на рынке.
• Обязательно познакомиться и рассказать про задачу. Знакомство лучше проводить лично, но и Zoom вполне подойдёт. На встрече нужно рассказать про задачу, узнать об опыте студии и запросить кейсы. Желательно пообщаться с командой и заранее узнать, с кем предстоит работать.
• Запросить коммерческие предложения. КП точно должно включать видение процесса работы над проектом — какие этапы планируются, какие артефакты будут на выходе. Также понадобятся декомпозиция проекта и оценка. Поскольку агентство само предлагает решение, декомпозиция будет более точной. Скажем, если вы обращаетесь в пять агентств, вы получаете пять видений развития проекта.

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

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

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

• Синхронизации в понимании целей и задач проекта. Часто бывает, что на пресейле один состав участников, а в проектной команде другой. В этом случае особенно важно добиться полной синхронизации, чтобы и клиент, и исполнитель однозначно понимали все заявленные пункты.
• Понимания доступных ресурсов и ограничений. Разберём важность этого пункта на примере дедлайнов. Иногда дедлайны — это просто дедлайны. Условно, в компании обсудили, что задача должна быть решена за два месяца, но это ни к чему не привязано. А иногда дедлайны связаны с определёнными событиями. Скажем, важно зарелизить приложение к 1 декабря, потому что с 1 декабря стартуют рекламные кампании, по которым сейчас ведутся подготовительные работы. Единое понимание доступных ресурсов и ограничений помогает более эффективно выстроить совместную работу.
• Непрерывный диалог. Нужно постоянно быть на связи, чтобы сохранять нужную динамику работы. Гигиенический минимум управления проектом — это регулярные встречи, фиксация договоренностей после каждого митинга и обновление статуса проекта.

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

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

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

Есть несколько сценариев взаимодействия:

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

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

Какие артефакты важно получить вне зависимости от сценария взаимодействия:

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

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

• Документация. Зависит от договоренности и состава команды, но обычно включает описание поведения интерфейса, скринкаст и техническое задание.

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

Если было полезно, подписывайтесь на мой Telegram-канал «Зависит от контекста». Там ещё больше размышлений о творчестве, технологиях и, конечно, дизайне. Например, о том, как выбирать дизайнеров в команду или как эффективно выстраивать работу.