🚀 Стартуем с темы, которую почему-то не форсят на профильных конференциях для дизайнеров. Причем эта дыра в скиллсете вырастает как у дизайнеров, вскормленных на ютуб курсах по Figma, так и у матерых выпускников профильных ВУЗов.
Нас учат: ⁃ Формулировать и проверять гипотезы ⁃ Рисовать идеальные user flow ⁃ Создавать pixel-perfect макеты ⁃ Применять консистентные компоненты дизайн-системы ⁃ Анализировать метрики и возвращаться к первому пункту.
Очко начинается, когда мы не знаем: ❓ Как и когда данные попадают в интерфейс ❓ Почему "простое поле" может стоить 2 недели работы ❓ Что будет, если бэк вернёт ошибку вместо красивой карточки
⛔️ Типичные отмазки: ⁃ «Мне так написали в ТЗ» ⁃ «Это же работа аналитика» ⁃ «UX-редактор потом поправит».
По факту это значит: «Я в душе не ебу, Даша» 🏳️ Моргни, если узнаешь себя. Это булщит и давай что-нибудь с этим делать!
Вот 5 реальных кейсов, когда игнор бэкенда мог привести к катастрофе 1. Сразу или по частям? Пример: Проектируем дашборды статусов документов. ⁃ В дизайне: вся страница красиво грузится разом ⁃ В реальности: данные для страницы придут 3 разными запросами, на любом из запросов может быть ошибка. Сам запрос может долго обрабатываться. Итог: Пол-экрана пустое, юзеры в панике. Итог, если ты думаешь про бэк: состояние загрузки конкретных блоков, ошибка получения данных для блока и для всей страницы.
2. «Автообновление», которое сожрет бюджет Пример: Бизнес и пользователь хотят live-обновление данных в дашбордах, ведь это удобно. ⁃ В дизайне: счетчики в дашбордах обновляются без перезагрузки страницы ⁃ В реальности: нужно потратить 3 месяца на доработки бэка, в том числе отрефакторить статусную модель Итог: без рефакторинга страница грузится 30 секунд, пользователь раздражен скоростью продукта и уходит к конкурентам Итог, если ты думаешь про бэк: сделай блин кнопку «Обновить» для блока и выведи информацию, на какую дату/время показываем данные.
3. Валидация, которая не работает Пример: Нужно сделать форму заявления на выпуск ключа электронной подписи, чтобы пользователь не допустил ошибок. ⁃ В дизайне: Сделали разные типы инпутов, счетчики для ввода символов, маски ввода, валидацию при расфокусе поля. Ни один косяк не пройдет. ⁃ В реальности: API пропускает ввод любых символов, проверка на длину поля на фронте и бэке разная. Итог: Данные записывались криво, клиенты получают отказ в выпуске КЭП. Итог, если ты думаешь про бэк: Требования к полям, форматам, валидации на фронте и бэке совпадают, в заявлении нет ошибок, пользователь легко заполняет сложную форму и получает нужный ему продукт — КЭП.
4. Фильтр-убийца Пример: После глубинного интервью сформировали гипотезу, что пользователям внутреннего продукта по созданию и управлению единой системы тарифов нужен фильтр из 10 параметров. ⁃ В дизайне: красивый фильтр с конструктором значений + возможность добавить новые значения в справочники + по каждому фильтру можно отправить отдельный запрос для фильтрации + сохранение наборов фильтров для конкретного пользователя ⁃ В реальности: разработка всех этих хотелок займет год Итог: Продукт заморожен, так как нет ресурса на такую доработку Итог, если ты думаешь про бэк: простой сайдбар со всеми параметрами фильтрации, значения фильтров пополнять нельзя, список параметров заранее определен, фильтрация происходит не по каждому параметру, а по единому сабмиту. Да, не наворочено, зато реализовано за месяц и приносит пользу.
