Product Design против UX/UI: где реально начинается цифровой продукт?

Цифровой продукт не начинается с экрана. Он начинается с проблемы, достойной решения.

Есть момент почти в каждом цифровом проекте, когда кто-то открывает Figma. Появляется пустой фрейм. Кто-то создаёт кнопку, потом навигацию, потом дашборд, потом мобильную версию. Ощущается как прогресс, и технически так и есть. Но есть вопрос, на который стоило ответить до того, как спроектировали первый экран: что именно мы проектируем? Не как должна выглядеть главная страница, не какого цвета должна быть кнопка. Что является продуктом, какую проблему он решает, для кого, что бизнес должен от этого получить?

Именно здесь начинается Product Design. UX/UI, это часть этой работы, но не вся работа, и понимание разницы важит всё больше, когда цифровые продукты становятся сложнее, более связанными и всё чаще строятся с помощью ИИ.

Можно улучшить UX неправильного продукта. Нельзя улучшениями исправить фундаментально неправильное продуктовое решение.

ЭКРАН НЕ ПРОДУКТ

Экран не является продуктом

Экран, это то, что ты видишь. Продукт, это то, что происходит. Возьми e-commerce сайт: дизайнер может создать красивую страницу товара, отличная типографика, идеальные отступы, красивые фото. Но реальный продукт включает значительно больше. Товару нужна модель данных, должны существовать варианты, цена должна быть определена, инвентарь должен быть известен, клиента нужно распознать, корзина должна сохраняться, платежи должны работать, заказы должны создаваться, CRM должна получить клиента.

Интерфейс, это только видимый слой. Продукт, это весь опыт и система, что делает этот опыт возможным. Поэтому красивый интерфейс всё ещё может принадлежать плохо спроектированному продукту, а продукт с относительно простым интерфейсом может быть чрезвычайно хорошо спроектирован. Качество продукта не пропорционально визуальной сложности.

ОТКУДА НАЧИНАЕТСЯ

Где реально начинается Product Design

Он начинается до интерфейса, с понимания проблемы. Иногда проблема очевидна, компании нужен способ для клиентов делать заказы онлайн. Иногда нет. Компания может сказать «нам нужен новый сайт», но после взгляда на бизнес реальная проблема может быть в том, что лиды продаж теряются между отделами, информация о товаре существует в четырёх системах, или существующая CRM не отражает, как компания реально продаёт. В таких ситуациях редизайн может быть частью ответа, или может быть наименее важной частью.

Я работал с производственным клиентом в прошлом году, что пришёл с просьбой о редизайне портала дилеров. После двух недель исследования реальная проблема оказалась в том, что дилеры вручную вносили те же данные заказа в три отдельные системы, потому что никто никогда не проектировал, как эти системы должны относиться друг к другу. Редизайнированный портал сделал бы повторный ввод красивее. Он бы его не убрал. Product Design задаёт менее удобный вопрос: что мы должны реально построить, чтобы решить базовую проблему, не запрос на функцию перед нами.

UX/UI сильно фокусируется на том, как люди взаимодействуют с продуктом. Product Design имеет более широкую зону ответственности, охватывая бизнес-цели, потребности пользователей, продуктовую стратегию, информационную архитектуру, воркфлоу, данные, технические ограничения и метрики успеха, наряду с реальным опытом использования продукта. UX/UI часто одна из самых видимых частей Product Design, но Product Design также спрашивает, является ли то, что проектируется, вообще правильной вещью, а это существенная разница.

ЧЕТЫРЕ ВОПРОСА

Четыре вопроса перед первым экраном

Прежде чем проектировать интерфейс, стоит ответить на четыре вопроса. Какую проблему мы решаем, не запрос на функцию, а проблему за ним. Кто имеет эту проблему, поскольку клиент, торговый представитель, администратор и дилер могут взаимодействовать с той же системой, не нуждаясь в одинаковом опыте продукта. Что должно измениться, когда продукт успешен, больше лидов, меньше ручных операций, более быстрый онбординг, лучшее удержание. И что должно существовать, чтобы сделать это изменение возможным, именно здесь product design начинает двигаться в сторону архитектуры и разработки.

Традиционный UX часто начинается с пользовательского пути: главная страница, страница товара, корзина, чекаут, подтверждение. Это полезно, но для реального бизнеса продукт не заканчивается на странице подтверждения. Под ней есть ещё один поток: клиент, заказ, платёж, инвентарь, выполнение, CRM, бухгалтерия, поддержка. Теперь есть два пути, путь пользователя и путь бизнеса, и хорошо спроектированный продукт должен учитывать оба. Пользователь видит один клик. Этот клик может запускать шесть систем за кулисами.

МЕЖДУ МИРАМИ

Работа между мирами

Хороший Product Design сложен именно потому, что продуктовый дизайнер работает между дисциплинами: бизнес и технологии, стратегия и исполнение, потребности пользователя и операционные ограничения, бренд и функциональность. Чисто визуальный дизайнер может создать красивые экраны. Чисто техническая команда может построить чрезвычайно эффективную систему. Ни одно не гарантирует хороший продукт. Интересная работа происходит в пространстве между ними, переводя «клиенты покидают этот процесс» в «на этом этапе слишком много неопределённости в воркфлоу», потом в «нам нужна другая информационная архитектура», потом в конкретное изменение бэкенд-логики и конкретную цель KPI. Эта цепочка перевода и есть продуктовое мышление.

Документ требований может говорить «пользователи должны иметь возможность сравнивать товары». Product Design спрашивает, сколько товаров, какие атрибуты важны, какое решение пользователь реально пытается принять, и какое действие следует за сравнением, добавить в корзину, запросить расчёт, связаться со специалистом. В этой точке ты уже проектируешь не таблицу сравнения, а механизм принятия решений, и эта разница фундаментальна.

Отполированный прототип может скрывать огромное количество неотвеченных вопросов. Прототип показывает счастливый путь. Продукт живёт во всём, что происходит вокруг него.

FIGMA ВВОДИТ В ЗАБЛУЖДЕНИЕ

Почему Figma может вводить в заблуждение

Figma мощная, но может создавать опасную иллюзию: если экраны готовы, продукт определён. Это не так. Отполированный прототип может скрывать вопросы вроде откуда берутся данные, кто ими владеет, что случится, когда их нет, что случится, когда записей десять тысяч вместо десяти, что случится, когда платёж не проходит или CRM отклоняет запрос. Это не крайние случаи, это часть продукта, и они редко появляются в файле Figma.

Именно здесь Product Design напрямую соприкасается с цифровой архитектурой. Архитектура определяет, что система может надёжно делать. Product Design определяет, что система должна позволять людям делать. Представь, дизайнер создаёт путь, что требует настроить товар, сохранить конфигурацию, запросить цену, назначенного торгового представителя, follow-up в CRM. Звучит как UX-поток, но технически требует данных конфигурации товара, персистентности, логики ценообразования, создания лида, правил назначения и интеграции CRM. Дизайнер не может ответственно завершить поток, не понимая хотя бы часть этих ограничений, а команда разработки не может хорошо это построить, не понимая, почему этот поток вообще существует. Product Design, это сотрудничество, не передача: проблема, продукт, опыт, архитектура, разработка.

НЕ ОДНО И ТО ЖЕ

Product Design, UX/UI и Product Management, не одно и то же

Есть реальное пересечение, и сильный продуктовый дизайнер может глубоко работать во всех четырёх зонах. Но сферы не идентичны. UX/UI может существовать без значительного продуктового мышления. Product Design не может, потому что сам продукт должен быть определён сначала. Роадмап говорит, что запланировано. Product Design помогает определить, чем запланированное должно реально стать, и в меньших командах один человек может выполнять части всех этих ролей, но они всё равно не взаимозаменяемы.

ИДЕАЛЬНЫЙ UX ПРОВАЛ

Продукт может иметь идеальный UX и всё равно провалиться

Это случается чаще, чем люди думают. Продукт интуитивен, интерфейс чистый, онбординг плавный, юзабилити-тестирование выглядит хорошо, и никто им не пользуется. Это случается, потому что команда оптимизировала опыт проблемы, что не была достаточно важной, или продукт не создаёт достаточно ценности, или бизнес-модель не работает, или у клиентов уже есть лучшая альтернатива. Юзабилити не полезность, а полезность не автоматически бизнес-ценность, поэтому Product Design должен сидеть ближе к стратегии, чем традиционный интерфейсный дизайн.

Это касается того, что может быть самым ценным вопросом во всей дисциплине: нам это реально нужно? Приходит запрос на функцию, «добавим дашборд», и честные следующие вопросы: какие клиенты, какое решение они примут с этой аналитикой, как часто, и что случится, если бизнес вообще это не построит. Иногда лучшее продуктовое решение, не строить запрошенную функцию. Это не провал, это дизайн.

Мы видели именно этот паттерн с платформой медицинского образования, что строили несколько лет. Профессиональный форум для обсуждений никогда не был частью изначального ТЗ, ни один клиент его не просил, его не было в роадмапе. Он появился только через годы наблюдения за тем, как врачи реально взаимодействуют с материалом, они не останавливаются, когда лекция заканчивается, они спорят о ней, делятся сложными случаями, бросают вызов мышлению друг друга. Образование оказалось разговором, не событием, и построение именно под это осознание важило больше, чем следование изначальному ТЗ. Форум в итоге усилил и видимость в поиске, но это было следствие, никогда причина, почему его построили.

ИИ ДЕЛАЕТ ВАЖНЕЕ

Product Design становится важнее с ИИ, не менее важным

ИИ делает реализацию значительно легче. Команда может прототипировать функциональность быстрее, строить интерфейсы быстрее, генерировать код быстрее, тестировать концепции быстрее. Это реально ценно, но создаёт реальную проблему: стоимость постройки идеи падает, а значит строится больше идей, тестируется больше функций, существует больше софта. Дефицитный ресурс становится очевидным, знание того, что вообще заслуживает существования.

Мы видим это напрямую в текущем проекте перестройки цифрового фундамента столетнего люксового ювелирного дома. Самым лёгким и наименее интересным шагом было бы прикрутить ИИ-чатбот к сайту и назвать это инновацией. Реальный вопрос был в том, как ИИ может помочь продукту понять отношение между человеком и объектом, как открытие может стать более личным, как система может объяснить изделие, не превращая опыт в технический каталог. ИИ в итоге стал ещё одним слоем системы, не самой стратегией, и эта разница держится, только когда кто-то относится к этому как к продуктовому решению, не запросу на функцию.

Мы видели это напрямую с клиентом, что оценивал инструмент разработки на базе ИИ, что мог сгенерировать пять рабочих концепций интерфейса за послеобеденное время. Узкое место не исчезло, оно переместилось. Оно перестало быть «можем ли мы это построить» и стало «какая версия реально имеет смысл», а это продуктовое суждение, не технический вопрос. Когда исполнение дорогое, команды естественно избирательны. Когда исполнение становится дешёвым, количество возможных решений взрывается в настоящую перегрузку опциями, и Product Design становится дисциплиной, что превращает возможность в направление, не генерируя больше экранов, а решая, какой из них важен.

ИИ-продукты обостряют это ещё больше. Традиционный софт следует вход, логика, выход. ИИ-системы ведут себя вероятностнее, пользователь может спрашивать что-то по-разному каждый раз, системе может понадобиться контекст, ответ может требовать проверки. Ты уже не проектируешь кнопки вокруг детерминированной функциональности, ты проектируешь, как люди взаимодействуют с системой, что может рассуждать, генерировать и иногда ошибаться.

ПРОЕКТИРУЙ СИСТЕМУ

Проектируй систему, не только интерфейс

Возьми CRM. Традиционное UI-упражнение может включать дашборд, контакты, возможности, задачи, отчёты. Но реальный продукт, это сама операция продаж: где входит лид, как он квалифицируется, кто им владеет, когда он становится возможностью, какие действия требуют человеческого согласования. Теперь ты проектируешь продукт, а экраны, лишь видимое выражение этих решений, точно та же разница, что мы разбираем со стороны CRM в кастомная CRM против ERP.

Та же логика касается e-commerce. Витрина, не продукт, продукт, это опыт покупки и каждая система, что его поддерживает: каталог, инвентарь, CRM, ERP, платежи, поиск, контент, интеграции. Именно поэтому некоторые e-commerce проекты становятся неожиданно сложными, ты проектируешь не онлайн-каталог, ты проектируешь коммерческую систему, что переживается через интерфейс.

ПРОВАЛ + ОГРАНИЧЕНИЯ

Product Design должен учитывать провал и ограничения

Одна из самых чётких разниц между прототипом и реальным продуктом, это то, что происходит, когда что-то идёт не так. Что если нет данных, что если платёж не проходит, что если CRM недоступна, что если ИИ не знает, что если сеть медленная. Это не крайние случаи, это часть продукта, и хороший продуктовый дизайнер планирует для них с самого начала, вместо того чтобы латать потом.

Каждый реальный продукт также имеет ограничения: бюджет, время, технология, регуляция, существующая инфраструктура. Ошибка, это относиться к ограничениям как к тому, что происходит после дизайна. Они должны формировать его. Если существующая ERP не может обновлять инвентарь в реальном времени, продуктовый опыт должен это учитывать. Если CRM имеет строгую модель данных, воркфлоу должен её уважать. Ограничения не враг творчества, они определяют пространство, в котором могут существовать хорошие решения.

НЕ ЭСТАФЕТА

Не эстафета, и спроектирован для второй версии

Слабый процесс выглядит как бизнес, что передаёт требования дизайнеру, что передаёт экраны разработчику, что возвращает финальный продукт бизнесу. Проблемы возникают на каждой передаче. Более сильный процесс выглядит как исследование, определение продукта, UX/UI, архитектура, разработка, тестирование, обратная связь и итерация, с дисциплинами, что реально пересекаются: разработчики бросают вызов предположениям, дизайнеры открывают технические возможности, клиент добавляет операционное знание.

Версия первая редко финальный продукт. Клиенты ведут себя иначе, чем ожидалось, воркфлоу оказывается ненужным, рынок меняется, нужна новая интеграция. Хороший Product Design не пытается предсказать каждую будущую функцию, он создаёт структуру, внутри которой продукт может учиться, чёткие границы, понятную информационную архитектуру, и архитектуру, что не делает каждое будущее изменение дорогим.

Та же платформа медицинского образования никогда не относилась к своему MVP как к «наименьшей возможной вещи». Её строили как наименьшую вещь, способную пережить то, чем продукт может стать: безопасность, масштабируемая архитектура, мультистрановая сертификация, и модель данных, построенная под рост, что никто ещё не мог предсказать, всё это вложено до того, как большинство пользователей вообще это заметили бы. Годами позже, когда платформе понадобились новые страны, новые языки и функции, что никто изначально не планировал, ничего из той ранней архитектуры не пришлось разрушать.

Самая дорогая ошибка, это красиво спроектировать неправильный продукт. Плохой UI можно перепроектировать. Продукт, что решает неправильную проблему, нельзя исправить лучшей кнопкой.

ЧТО ПРЕДОСТАВЛЯЕТСЯ

Что реально предоставляет продуктовый дизайнер

Не только файлы Figma. Серьёзный процесс Product Design производит определение продукта (что это есть и чем не является), потоки пользователя и бизнеса, информационную архитектуру, функциональную модель, архитектуру взаимодействия, вайрфреймы и прототипы, визуальный дизайн, дизайн-систему, требования к продукту, метрики успеха, и, важнее всего, общее понимание того, зачем продукт вообще существует.

Передача также не является концом. Как только начинается разработка, реализация меняет реальность, компонент ведёт себя иначе, чем ожидалось, API имеет ограничения, что никто не предвидел, лучшее решение становится возможным посреди постройки. Продуктовый дизайнер должен оставаться частью этого разговора, потому что цель никогда не была «построить точно то, что было в Figma», она в том, чтобы «построить продукт, который мы задумали, и улучшить его, когда реальность научит нас чему-то лучшему».

Где UX/UI всё ещё важит чрезвычайно

Ничто из этого не умаляет UX/UI, наоборот. Как только продукт правильно определён, UX/UI становится невероятно мощным. Хороший UX делает сложность понятной, хорошая информационная архитектура делает большие системы навигируемыми, хороший UI устанавливает иерархию, доверие и ясность. Но интерфейс сильнее всего, когда выражает хорошо определённый продукт. Хороший UX не может спасти неясное продуктовое мышление, он может лишь сделать ясное мышление легче переживаемым.

Именно поэтому Product Design не является ещё одной услугой рядом с UX/UI, это дисциплина, что соединяет стратегию, брендинг, UI и разработку в одно согласованное продуктовое решение. В Peretz мы всё больше думаем о цифровых продуктах как о системах, не отдельных интерфейсах, сайт, мобильное приложение, e-commerce магазин или CRM, всё это лишь интерфейсы к чему-то большему, и прежде чем что-либо из этого проектировать, более важный вопрос, что система должна реально позволять делать бизнесу и его клиентам. Кнопка, это решение. Воркфлоу, это решение. Даже выбор не строить что-то, это решение. Product Design сводит эти решения вместе, и когда они согласованы, результат ощущается простым, не потому что система простая, а потому что кто-то сделал сложное мышление до того, как пришёл пользователь.

Нужен ли нам продуктовый дизайнер, если уже есть UX/UI дизайнер?

Зависит от того, насколько сложна базовая система. Для простого маркетингового сайта UX/UI может быть достаточно. Для чего угодно, что включает CRM, логику e-commerce, несколько ролей пользователей, или системы, что должны разговаривать друг с другом, сам продукт нуждается в определении, прежде чем работа над интерфейсом может быть надёжной.

Разве это не то, что уже делает хороший Product Manager?

Есть пересечение, но Product Management обычно владеет стратегией, приоритетами и роадмапом. Product Design переводит эти решения в реальный продуктовый опыт и операционную модель, информационную архитектуру, воркфлоу, и то, как должна вести себя система, не только что строится и когда.

Как ИИ меняет то, что продуктовый дизайнер реально делает каждый день?

Он убирает очень мало из работы суждения и ускоряет почти всё остальное. ИИ может быстро генерировать варианты интерфейса и даже рабочий код, а значит реальное узкое место смещается на решение, какая версия достойна запуска, решение, что ИИ за тебя не принимает.

Какой самый большой признак, что проект пропустил Product Design?

Интерфейс выглядит завершённым, но никто не может чётко ответить, что случится, когда что-то пойдёт не так, платёж не пройдёт, данные отсутствуют, система недоступна. Тот разрыв между «счастливый путь спроектирован» и «продукт реально работает» почти всегда означает пропущенный шаг Product Design.