Бэк, фронт и аналитика, или «почему мои макеты не выйдут в прод»
Разогрев и аналитика
Продуктовый дизайнер – неотъемлемая часть продуктовой команды, поэтому для эффективного взаимодействия он должен быть интегрирован в работу команды на полных правах. Быть в курсе процесса разработки и аналитики, понимать цели и задачи бизнеса, смотреть на продукт в том числе за рамками своего процесса/экрана и понимать как работает тестирование и почему нельзя просто поскорее выпустить уже мою красивую фичу!
В ОТП Банке у нас была небольшая и дружная команда, поэтому мне удалось глубоко погрузиться во все этапы продуктового процесса и ненароком спросить у разных ролей «а что это вы тут делаете и почему»
И так как финтех, а особенно такая сложная многоуровневая машина как Сбер, оперируют огромным количеством данных с кучей нюансов безопасности, то очень важно понимать технические ограничения, задавать вопросы и общаться с коллегами на кривом, но разработческом языке
Аналитики – это в том числе переводчики между бизнесом/дизайном и разработкой. И многие дизайнеры рассчитывают, что в макеты придет аналитик, ткнет тут и там своими техническими ограничениями, а далее найдет решение или попросит переделать. Но мы же хотим уважать время аналитиков, и уж тем более свое, поэтому в наших силах хотя бы поверхностно разобраться, что же они все хотят от наших пикселей
Фронтенд
По сути это все то, что видит пользователь и с чем непосредственно взаимодействует. Разработчик смотрит в макеты, сверяется с аналитикой и делает магию, чтобы поле было именно таким и именно тут
На примере картинки ниже: фронт расположит иконку, заголовок и подзаголовок на определенном расстоянии друг от друга, задаст шрифт, так как это компонент из дизайн-системы с определенными требованиями, проставит скругления, возможно, обозначит цвет шрифта и фона, если в команде было решено зашить это на фронте. Еще много другой работы, но это самое важное, что нужно понимать дизайнеру
При этом если говорить о веб-разработке, то со стороны фронта закладывается намного больше информации, так как нет версионности для пользователя – он всегда увидит самую последнюю версию, ведь в моменте зашел на актуальный сайт
В Сбере я впервые столкнулась с приложениями, и тут-то все оказалось сложнее, так как у приложений есть версии, поэтому если пользователь не обновляет приложение, то он может никогда не увидеть, что оказывается иконки стали другого цвета, если этот цвет был зашит на фронте
И вот тут как раз в игру вступает
Бэкенд
Это все, что находится под капотом: базы данных, интеграции со смежными системами, запросы, ответы, ошибки и тэдэ и тэпэ. Фактически все элементы, которые фронт пропишет так, что их отображение зависит от бэка – не будут зависеть от версии
На примере картинки ниже: при отрисовке экрана фронт спрашивает у бэка «какую иконку и какого цвета отобразить в этом контейнере с этими отступами?» и получает в ответ код иконки и цвета, которые фронт посмотрит в дизайн-системе и покажет пользователю – и вот мы уже можем без привязки к версии управлять этими элементами в приложении
Другая ситуация с данными. 4 помидора и 60% – это цифры, которые бэкенд берет из определенных таблиц (баз данных). Допустим количество помидоров – это информация со стороны нашей команды, взять ее и передать фронту не так сложно. А вот 60% требуют интеграции с соседней командой, так как эта цифра высчитывается на основе данных, которые хранятся у них. Из-за этого всего лишь подзаголовок повлияет на длительность аналитики и разработки, а ведь я как дизайнер просто взяла и напечатала эти цифры в макетах за две секунды
Знаю, ваша голова скорее всего уже пухнет, но вот еще: в маленьких продуктах нет ресурса делать отдельный сервис под названием админка, с помощью которого тексты/коды иконок/цвет шрифта будут контролироваться аналитиками в отдельном интерфейсе, поэтому все подобные изменения будут занимать время бэкенд-разработчика, который руками полезет в код и поправит то, что «мы поисследовали, и эта иконка воспринимается пользователями лучше, и вообще я дизайнер, я так вижу»
В масштабных продуктах такие админки есть, поэтому на подобные изменения тратит время аналитик, но меньше и дешевле для компании. Связи между админкой и интерфейсом, конечно же прописывает бэк с помощью аналитики, но это уже совсем другая *далекая от дизайнера* история
Ну так и почему мои макеты не выйдут в прод?
Потому что макеты, оторванные технических возможностей, целей и специфики вашей компании – это, к сожалению, просто картинка
Например, Додо и Дринкит выбирают визуальный восторг пользователя, потому они могут себе это позволить в силу ЦА, приоритетов и требуемых в приложении фич
Банковские приложения тоже думают о клиентском опыте, но по-другому, так как есть свои нюансы во взаимодействии подразделений, в юридических вопросах и другие тонкости, которые касаются и дизайнера
Поэтому хотя бы поверхностное понимание технических тонкостей вашей компании может облегчить работу и улучшить взаимодействие в команде. Так что общайтесь с аналитиками, не бойтесь расспрашивать разработчиков и вникайте в специфику реализации, как минимум это будет полезно для кругозора)
Спасибо за внимание! О своих наблюдениях в мире UX пишу в тг-канале – подписывайтесь)
Всем привет! В этой статье поговорим о процессе найма UX/UI дизайнера со стороны нанимающей стороны, на что обращаем внимание, как смотрим и каких ошибок лучше избежать. Статья будет в формате вопрос-ответ, просто потому что мне так легче думается и пишется и, надеюсь, так будет меньше воды. Поехали.
Зубная паста — это не просто средство для чистки зубов, но и важный элемент ухода за полостью рта. В ней содержатся различные ингредиенты, которые помогают поддерживать здоровье зубов и десен. В этой статье мы рассмотрим полезные компоненты, которые могут значительно улучшить состояние вашей улыбки.
Дизайн отличается от реализации на проде? Файлы перегружены и на 30% состоят из нереализованных сценариев? Команда не понимает что из макетов должно быть реализовано в рамках задачи, а что нет? В статье расскажу как решить эти проблемы и поддерживать файлы в актуальном виде
UX/UI-дизайн — это поле битвы между художниками с кистью и учеными с калькуляторами. Каждый из них считает себя главным героем, а пользователей — своими подопытными кроликами. Но что же это на самом деле: искусство, которое требует вдохновения, или наука, которая основывается на данных? Давайте разберемся!
ИИ тоже может принять участие в фестивале искусств на Луне, но проблематично, в его нынешнем состоянии, "создать" произведение искусства в том же смысле, что и человек. ИИ не обладает эмоциями, интуицией или личным опытом, которые являются ключевыми компонентами художественного творчества. ИИ пока только может генерировать изображения, музыку, текс…
Статья для тех, кто думал, что дизайн — это просто рисовать картинки за деньги :)
Очень полезно!
Спасибо!
О чём статья?
Вижу только упоминание крупных компаний для придания важности статье и поисковой оптимизации. Хотя это по большому счёту не влияет ни на что.
Вижу сумбурное изложение того, чем занимаются аналитики, фронтендеры и бэкэндеры.
А почему макеты не дошли до продакшена? Какая ваша роль в этом?
"Банковские приложения тоже думают о клиентском опыте, но по-другому, так как есть свои нюансы во взаимодействии подразделений, в юридических вопросах и другие тонкости, которые касаются и дизайнера"
Так много слов ни о чём. Везде есть свои нюансы, но без примеров это выглядит словоблудием и генеренкой.
"Потому что макеты, оторванные технических возможностей, целей и специфики вашей компании – это, к сожалению, просто картинка"
С какими техническими ограничениями вы столкнулись?