Как понимать контекст проекта Этот материал объясняет: разницу типов проектов, что такое mission critical / non-mission-critical, когда дизайнер должен общаться с заказчиком, а когда избыток коммуникаций — во вред, как отличается клиентский опыт в продуктах и в мини-апах, как всё это классифицировать, как команда может ориентироваться в этих режимах и не путать одно с другим. 🟧 Два мира разработки: продукты vs мини-аппы. Как отличать, как работать и какие процессы нужны Мы сталкиваемся с разными типами проектов. Где-то мы делаем полноценный продукт, который живёт годами, влияет на бизнес-процессы и проходит десятки согласований. А где-то — небольшой мини-апп, простой инструмент или небольшую коммуникационную вставку внутри чат-бота. Чтобы команда работала эффективно и не пыталась применить “тяжёлые” процессы там, где они только мешают, важно понимать фундаментальную разницу между двумя классами проектов: Полноценные продукты / Mission Critical Мини-аппы и поддерживающие интерфейсы / Non-Mission-Critical Это два разных мира, требующих двух разных подходов — в дизайне, разработке, коммуникациях и управлении ожиданиями. 🟧 1. Что такое Mission Critical, и почему эти проекты другие Mission Critical — это продукты, без которых бизнес не сможет выполнять свою основную функцию. Примеры: Яндекс.Такси — приложение не работает → такси не существует Интернет-банк — ошибка → бизнес клиента остановился Личный кабинет госуслуг → критичен для доступа к услугам Управляющая панель в промышленности (логистика, производство, расчёты) У промышленной компании, например фармацевтической, mission critical — это производство таблеток, логистика, ERP, склад, документоборот. Чат-боты, мини-формы, калькуляторы, маркетинговые инструменты — не mission critical.Их можно улучшать, допиливать, полировать, но они не остановят бизнес. Отличительные признаки Mission Critical: UI = бизнес-операция, ошибка стоит дорого требуется глубокая выверенная архитектура десятки согласований UX-исследования строгая типографика, модульные сетки, дизайн-системы дизайнер обязан общаться напрямую с заказчиком множество рабочих встреч нужно понимать роли, сценарии, ограничения всё должно быть документировано много уровней ответственности Там нет “примерно нормально” — там только идеально и надёжно. 🟧 2. Что такое Non-Mission-Critical (наши текущие мини-аппы) Мини-аппы, калькуляторы, формы, промо-страницы, быстрые B2B-калькуляторы в мессенджерах — это дополняющие интерфейсы. Они помогают: сократить путь пользователя, поддержать маркетинг, объяснить продукт, загрузить данные, собрать обратную связь. Но не являются ядром бизнеса. Отличительные признаки таких проектов: одна или две встречи достаточно можно опираться на вкус и здравый смысл нет 50 согласований нет десятков UX-сценариев проще требования к цветам, сетке, блокам допускаются разумные компромиссы UI — не синоним бизнес-операции, а инструмент коммуникации Это не значит “делать плохо”, это значит не переусложнять там, где это не нужно. 🟧 3. Почему процессы должны быть разными Если на non-mission-critical проекты натянуть процессы от больших продуктовых студий, произойдёт следующее: сроки вырастут x3–5 стоимость выйдет за рамки бюджета ценность UI станет ниже цены его производства клиент удивится, почему такие простые задачи делаются так дорого команда будет перегружена ненужными встречами дизайнеры будут ловить лишние правки и вкусовщину фронтендеры погрязнут в овердизайне Но если на mission critical проект натянуть подход “как для мини-аппа” — бизнес словит катастрофу. Поэтому нужен двухрежимный подход. 🟧 4. Должен ли дизайнер встречаться с заказчиком? Да — но не всегда. Два типа проектов = два типа участия дизайнера. 🟩 Тип 1. Полноценные продукты — дизайнер участвует активно Тут дизайнер — не художник и не исполнитель.Он — аналитик, переговорщик, продуктовый партнёр. Его обязанности: собирать требования уточнять задачи выяснять сценарии согласовывать логику прототипировать решать UX-проблемы участвовать в созвонах защищать решения с цифрами и логикой Без прямой коммуникации тут работать невозможно. 🟦 Тип 2. Мини-аппы — дизайнеру достаточно 1-2 встречи В этих проектах: нет сложной логики, нет рискованных пользовательских сценариев, нет десятков ролей и use-case'ов, нет mission critical-функций, интерфейс не решает судьбу компании. Поэтому дизайнеру достаточно: 1 вводной встречи, 1 обсуждения прототипа, остальная коммуникация — через менеджера. Прямой контакт с клиентом после этого ничего не улучшит, а часто только ухудшит: начинается вкусовщина, “попробуйте зелёный”, “давайте кнопку побольше”, “а сделайте фон потемнее”, дизайнер теряет фокус, дизайн разваливается, сроки растут. Дизайнер защищает эстетику и логику →Менеджер фильтрует запросы →Команда работает спокойно. Это правильный процесс. 🟧 5. Разные типы клиентского опыта (CX): “деловой” vs “приятный” Чтобы правильно строить интерфейсы, важно понимать разницу между двумя видами клиентского опыта. 🟩 Тип 1. “Деловой” клиентский опыт (B2B, сервисный, утилитарный) Цель: дать результат быстро, чётко и без лишних действий. Примеры: B2B калькуляторы формы заказа заявки рабочие панели кабинки операторов функциональные мини-аппы Тут интерфейс должен быть: быстрым простым прямым без флейвора без украшательств минимум шагов минимум когнитивной нагрузки Это “инструмент”, а не “впечатление”. 🟦 Тип 2. “Приятный” клиентский опыт (развлечения / эмоции / smacking experience) Цель: вовлечь, развлечь, удержать внимание. Примеры: рестораны, еда, сервис, доставка игры развлекательные проекты брендинг storytelling-интерфейсы Здесь можно: растягивать путь, играть с эмоцией, добавлять анимации, давать “вкус” и “медленность”, делать journey красивым. 🟧 6. Как классифицировать проект за 1 минуту Задаём два вопроса: ❓ Если интерфейс сломается — пострадает ли основная миссия бизнеса? Если да → это mission critical → полноценный продуктовый процесс.Если нет → это мини-апп → упрощённый процесс. 🟧 7. Что важно Не надо натягивать продуктовые процессы на мини-аппы.Это убивает скорость и ценность проекта. Не надо упрощать миссион-критичные проекты.Там нужна глубина. Дизайнер не должен общаться с заказчиком там, где это во вред.Коммуникация — ресурс, его надо дозировать. Нужно уметь классифицировать тип задачи с первых минут проекта. Наша цель — гибкость.Мы должны одинаково уверенно вести оба типа проектов. 🟧 8. Тонкое различие, которое важно осознать Мы не “студия, которая делает всё одинаково”.Мы команда, которая умеет менять подход под контекст. Где-то нужен продуктовый UX, десятки встреч и прототипы.Где-то достаточно одного звонка, одного прототипа и менеджерского фильтра. Зрелость = умение различать.