5. Счётчик, который нельзя посчитать Пример: Пользователю будет здорово видеть остатки по своему тарифу. А бизнесу польза в том, что мы подстегнем к продлению, если счетчик будет алармить о скором окончании. ⁃ В дизайне: Счетчик с цветокодировкой в зависимости от остатков по тарифу. ⁃ В реальности: Данные нужно вычислять из нескольких микросервисов в зависимости от тарифа, статуса документов, наличия доп. условий по переносу остатков и т.п. Итог: В счетчике недостоверные данные → сервер падает при 100+ пользователях. Итог, если ты думаешь про бэк: упрощаешь визуальную логику, которая сможет универсально работать с учетом разных условий и показывать корректное число.

Как же перестать быть тем, кто проектирует ракету, когда надо колесо, чтобы уже завтра ехало?

1️⃣ Перед дизайном задай 3 вопроса:

• Какие данные УЖЕ есть?
• Какой запрос самый "дорогой" по времени?
• Где происходит валидация (фронт/бэк)?

2️⃣ Обязательные состояния:

• Пустое (что видит пользователь при первом заходе)
• Загрузка (сколько реально ждать? 0.5 сек или 5 сек?)
• Ошибка (что покажем, если бэк не ответит?)

3️⃣ Оценка сроков: Красивый комплексный фильтр = 3-6 месяцев Упрощённое решение = 2-4 недели

Почему это важно: Хороший дизайн — это не только про красоту. Это про: ▸ Реальные данные ▸ Технические ограничения ▸ Сроки, которые можно выполнить

🔥 Главный лайфхак: пригласи бэкендера на кофе и спроси: «Что из моего дизайна тебя бесит больше всего?» Инсайты гарантированы!

P.S. Если после этого поста ты сходишь с вопросами к своему бэкендеру — кинь в комменты 🍕 символ перемирия. Если нет — разработчик пожелает, чтобы у тебя случился понос, когда будешь стоять в пробке 🫶🏻

P.P.S. В комментах пиши: — Было ли полезно? — Твой худший косяк из-за незнания бэка? — Какие ещё темы хочешь, чтобы я разобрала?

Всех обняла, ваш дизайнер-реалист 💛🫡