Бэк, фронт и аналитика, или три причины «почему мои макеты не выйдут в прод»

Продуктовый дизайнер – неотъемлемая часть продуктовой команды, поэтому для эффективного взаимодействия он должен быть интегрирован в работу команды на полных правах. Быть в курсе процесса разработки и аналитики, понимать цели и задачи бизнеса, смотреть на продукт в том числе за рамками своего процесса/экрана и понимать как работает тестирование и почему нельзя просто поскорее выпустить уже мою красивую фичу!

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

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

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

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

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

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

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

И вот тут как раз в игру вступает

Это все, что находится под капотом: базы данных, интеграции со смежными системами, запросы, ответы, ошибки и тэдэ и тэпэ. Фактически все элементы, которые фронт пропишет так, что их отображение зависит от бэка – не будут зависеть от версии

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

Другая ситуация с данными. 4 помидора и 60% – это цифры, которые бэкенд берет из определенных таблиц (баз данных). Допустим количество помидоров – это информация со стороны нашей команды, взять ее и передать фронту не так сложно. А вот 60% требуют интеграции с соседней командой, так как эта цифра высчитывается на основе данных, которые хранятся у них. Из-за этого всего лишь подзаголовок повлияет на длительность аналитики и разработки, а ведь я как дизайнер просто взяла и напечатала эти цифры в макетах за две секунды

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

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

Потому что макеты, оторванные технических возможностей, целей и специфики вашей компании – это, к сожалению, просто картинка

Например, Додо и Дринкит выбирают визуальный восторг пользователя, потому они могут себе это позволить в силу ЦА, приоритетов и требуемых в приложении фич

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

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

Спасибо за внимание! О своих наблюдениях в мире UX пишу в тг-канале – подписывайтесь)