Как заказать дизайн цифрового продукта и не выкинуть его потом в мусорное ведро
За последний год у нас в MobileUp было несколько кейсов, когда клиент приходил с набором артефактов от предыдущего исполнителя и просил помочь, искренне не понимая, как так вышло, что ничего не вышло, а полгода прошли. Решил рассказать, как выстроить работу над дизайном сложного цифрового продукта со сторонним подрядчиком. Да, и не только над дизайном. И не только со сторонним подрядчиком.
Немного вводных
MobileUp — команда специалистов по дизайну и разработке цифровых продуктов. Именно тут я работаю последние три года диджитал-арт-директором. Чтобы пойти дальше — быстрый синк, чтобы мы понимали, что говорим об одном и том же. Наш глоссарий.
Цифровые продукты — это приложения и веб-сервисы, которые вплетены в бизнес-процессы компании, а иногда являются их основой. Лендинги и сайты-визитки — тоже цифровые продукты, но с ними проблем как раз нет, и, с точки зрения дизайна, они ближе к графическому дизайну.
Продакшн — аутсорс-компания, обладающая экспертизой в области дизайна и разработки цифровых продуктов. Большая часть моего опыта связана с дизайном мобильных приложений, но основные тезисы справедливы и для веба.
Клиент — носитель экспертизы по своему бизнес-продукту или носитель идеи этого бизнес-продукта. И, конечно, носитель денег.
Всё относительно
Дисклеймер: всё, что будет дальше, не является абсолютной истиной. Это усредненный опыт на основе сотни разных проектов. Он может оказаться полезным, если вы сталкивались со схожими проблемами или только готовитесь к запуску собственного продукта.
Я решил не писать пошаговую инструкцию, да, это и невозможно. Каждый проект — уникален, а дьявол кроется в деталях. Это и есть первое, что нужно учитывать. У каждого бизнеса будут уникальные бизнес-процессы, технические ограничения, цели, аудитория и внутренняя экспертиза. И запрос на внешнюю экспертизу тоже будет разный.
Все сценарии развития событий описать невозможно. Зато можно продумать такие процессы работы над проектом, которые будут держать хаос под контролем и с каждой итерацией уменьшать степень неопределённости.
ТЗ — фикция
Как правило, проект начинается в недрах компании и к моменту, когда клиент начинает искать исполнителя, у него уже готово «техническое задание». Но чаще всего это всё-таки не ТЗ, а БФТ — бизнес-функциональные требования. Или даже их гибрид. Если ТЗ отвечает на вопрос «КАК система должна работать», то БФТ — на вопрос «ЧТО система должна делать без учёта технической реализации».
Но путаница в формулировках не столь критична. Критично то, что документы эти слишком абстрактны, чтобы по ним можно было однозначно понять, что же именно система должна делать. Не говоря уже о том, как она это должна делать.
За всё время мне попадалось буквально пару документаций, которые можно было взять в работу, и они действительно давали ответы на вопросы и были хорошо продуманы. Это не упрёк, а просто факт, который нужно учитывать. Если ТЗ или БФТ есть, скорее всего, их нет.
Если слышите: «Без ТЗ результат — ХЗ», то бегите быстрее ветра от такого подрядчика
Если вы клиент, и слышите что-то вроде: «Без ТЗ результат — ХЗ», бегите быстрее ветра от такого подрядчика. Он будет постоянно требовать ответов, которых у вас нет и быть не может, и перекладывать ответственность за результат. Помочь клиенту сформулировать грамотные бизнес-функциональные требования к системе — одна из задач продакшена. Именно он является экспертом в возможностях и ограничениях системы и без этого понимания требования будут слишком общими и абстрактными.
А непосредственно ТЗ уже появится после этапа дизайна и будет во всех подробностях описывать, как продукт будет работать на техническом уровне с учётом дизайн-макетов.
Что делать? Нужно просто принять этот факт и быть готовым к тому, что по мере погружения в проект, требования к нему будут меняться. Главное — чтобы все были в курсе причин этих изменений.
Бэкэнд важен
Стоп, мы же вроде про дизайн начинали, причём тут бэкэнд?
Всё верно. Мы начинали про дизайн. Но если вы хотите, чтобы он не улетел в мусорное ведро, важно учитывать бэкенд. В противном случае вы создадите дизайн в вакууме, точнее в параллельной вселенной.
Какие могут быть варианты развития событий.
- Бэкэнд есть — это хорошо. Но нужно учитывать, что для мобильного приложения, бэк нужно дорабатывать. Важно на берегу договориться, кто и в какие сроки это будет делать. Напомню, мы говорим про сложные цифровые продукты, а это подразумевает, что большая часть данных и логики хранится на бэкэнде. Это накладывает много ограничений, без учёта которых сделать качественный дизайн невозможно.
- Бэкэнда нет — тоже хорошо, если делает его та же команда. Если команда клиента или другого подрядчика, готовьтесь дорабатывать дизайн, когда бэк появится.
- Интеграции со сторонними сервисами — если они есть, перед дизайном нужен технический ресерч: какую информацию мы можем получить из этих сервисов и в каком виде. Иногда оказывается, что никакую и нужно вставлять виджеты «как есть».
Мобильные приложения и веб-сервисы, как правило, тонкие клиенты — вся бизнес-логика крутится на стороне бэка, а на фронте просто отображается. Они напрямую зависят от того, как работает бэкэнд и какую информацию из него можно получить. Что в свою очередь сильно влияет на проработку сценариев и конечный дизайн.
Что делать? На старте проекта у команды обязательно должен быть аналитик. При этом именно на стороне продакшена, который хорошо понимает специфику производства. Клиентский аналитик тоже не помешает, но это опционально.
Как узнать стоимость
Очень правильный вопрос. На этот случай у нас есть штатный таролог и астролог! Ладно, насчёт таролога — шутка, а вот астролог действительно есть, но к оценкам проектов мы его не подключаем.
Вне зависимости от того, есть у клиента ТЗ или нет, для первичной оценки мы собираем следующую информацию:
Фичерлист. Это список ожидаемой функциональности приложения. Иногда для этого достаточно внимательно изучить ТЗ и вытащить из него всё необходимое. Иногда — устроить брифинг с клиентом и за час добыть нужную информацию. Каждую функцию оценивают технические команды. Команда дизайна оценивает сценарии:
- процесс регистрации;
- выбор товаров из каталога;
- оформление заказа.
Технические риски также добавляют при оценке: некоторые функции могут сильно отличаться по трудозатратам в зависимости от реализации.
Интеграции. Это сторонние сервисы, с которыми нужно взаимодействовать. Их тоже важно учитывать. В случае оценки только дизайна, этот пункт не принципиален.
Нефункциональные требования — ожидания по дизайну, реализации, срокам, процессу работы и вот это всё.
Эти данные дают понимание общего объёма работ и примерную стоимость. Такая оценка обычно делается на самом старте, чтобы понимать, попадаем мы в ожидания клиента или нет. Для более детальной оценки нужно глубоко копнуть и провести анализ, а на это не всегда есть время. Да, и не всегда нужна точная оценка. На старте обычно достаточно средней вилки для сравнения общего порядка цен у разных подрядчиков.
Важно понимать, что это оценка, основанная на списке фичей. А этот список может сильно измениться, например, после этапа исследования. Поэтому вписываться в фикс никто и не любит: оценили одно — а делаем по факту другое.
Что делать? Стремиться к открытости и командной работе. Если есть жесткие ограничения по бюджету, их важно обозначить. Тогда продакшн сможет лучше распределить ресурсы. Со стороны производства важно отслеживать изменения и заранее предупреждать, если что-то идёт не по плану. Обычно всегда есть возможность упростить в одном месте и инвестировать в более детальную проработку в другом.
Клиент — не эксперт
Клиент не является экспертом в области дизайна и производства и не должен им быть. На самом деле он, может, и эксперт, но при разработке продукта с помощью подрядчика это точно не его головная боль. Он эксперт в своём бизнесе и за экспертизой пришёл к продакшену. Важно на старте разграничить зоны ответственности.
Условно можно выделить следующие зоны ответственности:
- Продукт — создание продукта, который будет востребован целевой аудиторией.
- Бизнес — разработка стратегии, как продукт удовлетворяет потребности бизнеса.
- Техническая реализация — как именно он будет реализован с технической точки зрения.
- Маркетинг — реклама и всё прочее.
Продакшн обычно берёт на себя техническую реализацию — это его основная зона ответственности. Он проводит исследования и помогает с формированием продукта, но ответственность за конечный результат на клиенте. Продакшн должен быть погружен в бизнес и маркетинг. Но, как правило, на эти пункты он влияет только на уровне вброса идеи.
Что делать? Убедиться, что все всё понимают. Бывает, что клиент просто не готов на уровне своих процессов к появлению нового бизнес-продукта. Или думает, что после того, как приложение попадает в стор, его сразу начинают неистово скачивать.
Давайте запустим MVP
Термин MVP плотно закрепился в наших сердцах. Многие клиенты используют его для обозначения первой версии продукта, которую можно запустить быстрее и дешевле, чем весь остальной заявленный скоуп. И совершают ошибку, теряя время и деньги. Важно разделять два понятия: MVP и первая версия продукта.
MVP — термин, который пришёл к нам из стартапов. Кроме него ещё есть BVP, MLP и другие разновидности. Это не способ выпустить первую версию продукта. Это способ найти востребованный продукт и бизнес-модель. Тут важны быстрые итерации и тесты. Качество в топку, фокус на скорости.
Первая версия продукта — это когда есть бэклог на пару тысяч строк, бюджет, нужно решить, с чего начать. Тут важно грамотно продумать масштабирование и заложить фундамент, чтобы при накатывании новых фичей не приходилось заново переписывать уже готовое.
Обе стратегии имеют право на жизнь. Главное — точно понимать, какой из вариантов нужен сейчас и почему именно он. Если, например, заходит речь о том, чтобы быстро запустить из «говна и палок», чтобы хоть что-то было, это в лучшем случае — выброшенные деньги, в худшем — репутационные риски и для клиента, и для подрядчика.
Что делать? Добиться синхронизации между бизнесом и производством в понимании целей продукта и стратегии развития.
Прозрачность и гибкость
Заказчик, который заказывает продукт, и исполнитель, который его делает, — одна команда. Важно сразу выстроить прозрачные отношения, где все понимают свои роли, ответственность и доступные ресурсы. В противном случае будет сложно принимать оптимальные решения при появлении новых вводных. А они обязательно появятся. И чем больше проект, тем больше нюансов будет всплывать. Базовая конструкция продукта может и останется изначальной, но вот всё, что глубже, претерпит массу метаморфоз. К этому нужно быть готовым.
На этапе исследования и формировании концепции продукта будет один скоуп. На этапе проектирования — уже другой: какие-то фичи родятся в ходе обсуждение, а какие-то, наоборот, уйдут в закат. После согласования концепции и проработки дизайна всё опять может немного измениться, но уже на уровне интерфейсных решений. Например, на проектировании сценарий казался логичным, а после того, как натянули дизайн, он стал слишком громоздким, и нужно его разбить на шаги.
С каждым новым этапом происходит взаимный обмен экспертизой и приходит более глубокое понимание продукта. И это отлично. При условии, что у проекта есть толковый менеджер, который этим процессом может управлять и вовремя перераспределять ресурсы.
Что делать? Обеспечить регулярную сверку часов — отчёты, статусы, риски. Радикальная прозрачность всего, что происходит на проекте. Только так можно добиться действительно эффективной командной работы.
Лебедь, рак и щука
Цифровой продукт — это живой организм. Он рождается из идеи или потребности и дальше развивается под влиянием людей, которые его делают. Идеальный сценарий, когда весь продукт делает одна постоянная команда: бизнес и производство.
У этого подхода есть несколько неоспоримых преимуществ.
Накопление знаний. Как бы вы не стремились задокументировать всё происходящее, покрыть документами всё невозможно. Команда в процессе работы принимает огромное количество микрорешений, которые в итоге влияют на состав и общий вид продукта. Большая часть таких решений распределена в головах участников проекта, особенно в активной фазе работы над проектом. Поэтому в ситуации, когда проектирование делает одна команда, за дизайн берётся вторая, а разрабатывает третья — биполярки не избежать. Каждая новая команда будет подстраивать продукт под себя.
Эффективность. Если за всё производство отвечает одна команда, процесс кросс-функционального взаимодействия будет бесшовным с наименьшим количеством рисков и высоким КПД. Конечно, если продакшн зрелый с отлаженными процессами.
Командность. Бизнес и производство — одна команда. Но на построение этой команды тоже нужно время: понять принципы работы друг друга, особенности взаимодействия, да, и просто наладить личный контакт и выстроить доверительные отношения. В случае нескольких подрядчиков это время неизбежно умножается на количество этих подрядчиков.
Что делать? Минимизировать количество действующих сторон. А оставшихся свести друг с другом и совместно работать над продуктом. Ситуация, когда, например, команда дизайна общается с командой бэкэнда через прокси-менеджера ни к чему хорошему не приведёт.
Работа над цифровым продуктом — это всегда вызов
Причем это вызов как для клиента, так и для продакшена. Важно сохранять хладнокровие и действовать одной командой. Большая часть проблем, которые возникают на проектах, связана именно с рассинхроном ожиданий.
Углубляясь в проработку нового продукта, вы можете зарыться в мелочи и в итоге потерять основную цель. На проекте обязательно должен быть человек со стороны продакшена, который будет видеть картину в целом и направлять творчество в нужное русло. И человек со стороны бизнеса, который будет отвечать за соответствие проекта потребностям бизнеса. Эти персонажи отчасти дублируют функции друг друга, но при этом не дают проекту завалиться в одну из крайностей и позволяют сохранить баланс.
У нас в MobileUp эту роль закрывает менеджер проекта. А на стороне клиента это обычно продакт оунер или аналогичная роль. Иногда это не один человек. Главное, чтобы у этого человека или группы лиц было достаточно полномочий для принятия решений.
У нас ушло много времени на то, чтобы отстроить эффективные внутренние процессы. За каждым нашим гайдом стоит ошибка, которая стоила времени, денег, а иногда и клиента. Но другого способа расти, к сожалению, пока не изобрели.
Если вы сталкивались со сложностями в работе над дизайном или разработкой цифровых продуктов, опишите свои кейсы в комментариях, и я постараюсь разобрать их в следующих статьях.