# Как понимать контекст проекта Этот материал объясняет: - разницу типов проектов, - что такое 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. Что важно 1. **Не надо натягивать продуктовые процессы на мини-аппы.** Это убивает скорость и ценность проекта. 2. **Не надо упрощать миссион-критичные проекты.** Там нужна глубина. 3. **Дизайнер не должен общаться с заказчиком там, где это во вред.** Коммуникация — ресурс, его надо дозировать. 4. **Нужно уметь классифицировать тип задачи с первых минут проекта.** 5. **Наша цель — гибкость.** Мы должны одинаково уверенно вести оба типа проектов. --- ### 🟧 8. Тонкое различие, которое важно осознать **Мы не “студия, которая делает всё одинаково”.** Мы команда, которая умеет **менять подход под контекст**. Где-то нужен продуктовый UX, десятки встреч и прототипы. Где-то достаточно одного звонка, одного прототипа и менеджерского фильтра. Зрелость = умение различать.