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.