Перейти к основному контенту

Как понимать контекст проекта

Этот материал объясняет:

  • разницу типов проектов,

  • что такое 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, десятки встреч и прототипы.
Где-то достаточно одного звонка, одного прототипа и менеджерского фильтра.

Зрелость = умение различать.

Нет комментариев
Наверх