Як ми проєктуємо e-commerce: від об'єктів до досвіду

Цифровий продукт може містити відмінний дизайн, сучасну технологію і десятки ретельно задокументованих функцій, і все одно не вирішувати проблему, заради якої його будували.

Причина часто на диво проста: проєкт почався з сайту, а не з бізнесу.

У Peretz ми підходимо до e-commerce інакше. Перш ніж обговорювати Shopify чи Laravel, React чи Vue, вайрфрейми чи дизайн-системи, ми намагаємось зрозуміти систему за інтерфейсом: бізнес-модель, шлях клієнта, процес продажу, контент, логістику і рішення, що рухають клієнта до купівлі.

Лише тоді ми вирішуємо, чим цифровий продукт має реально бути.

Цей підхід тісно пов'язаний з кількома усталеними методологіями продуктового дизайну, включно з Jobs to Be Done, Double Diamond, Object-Oriented UX (OOUX) і Atomic Design. Ми не ставимось до них як до ізольованих фреймворків. Разом вони дають корисні способи формалізувати процес, що ми застосовували до цифрових продуктів роками.

Відправна точка завжди одна:

Що цьому бізнесу реально потрібно від цифрового досвіду?

НЕ З ТЕХНОЛОГІЇ

Ми не починаємо з технології

Технологія важлива. Просто це не перше рішення.

Чи варто проєкту використовувати Shopify, WordPress, Laravel, headless-архітектуру, React, Vue чи інший стек, залежить від того, чого продукту потрібно досягти, як він зростатиме і як підтримуватиметься.

Ці рішення стають набагато простішими, коли зрозумілі вимоги, що лежать в основі.

Наш процес тому починається з питань на кшталт:

• Хто клієнт?

• Чого він намагається досягти?

• Як бізнес реально продає?

• Скільки займає рішення про купівлю?

• Яку роль сайт відіграє в процесі продажу?

• Які частини шляху відбуваються онлайн, а які через людей?

• Як маркетинг, продажі, логістика і клієнтська підтримка взаємодіють?

• Що відбувається після запуску?

Ці питання визначають архітектуру набагато надійніше, ніж вподобаний технологічний стек.

Перш ніж пропонувати рішення, ми також вивчаємо ринок і прямих конкурентів. Це включає видиму структуру конкуруючих сайтів, патерни навігації, контент, шляхи клієнтів і повторювані моделі взаємодії.

Мета не скопіювати те, що роблять конкуренти.

Мета, відрізнити справжній патерн категорії від довільного рішення одного конкретного бренду.

Ця відмінність важлива.

У конкурента може бути конкретна сторінка, взаємодія чи потік купівлі через впізнаваність бренду, операційну структуру, аудиторію чи модель продажів. Відтворити інтерфейс, не відтворивши умови, що зробили його ефективним, не відтворює результат.

Ми писали більше про проєктування навколо реальних бізнес-умов, а не передбачуваних, у статті We Design for Reality, Not for Ideal Scenarios.

СПЕЦИФІКАЦІЯ

Специфікація корисна, лише коли ми розуміємо, що за нею стоїть

Клієнти часто приходять з готовою специфікацією.

Тридцять сторінок. Іноді більше.

Карта сайту, список функцій, референси, технічні вимоги і детальний опис того, що має містити новий сайт.

Ми не відхиляємо цю роботу автоматично. Насправді сильна специфікація може значно прискорити проєкт.

Є клієнти, особливо великі компанії і зрілі продуктові організації, що вже інвестували в дослідження ринку, аналіз конкурентів, карту шляху клієнта, продуктову стратегію і бізнес-аналіз. Їхня специфікація, результат цієї роботи.

Це чудова відправна точка.

У таких випадках наша роль не повторювати вже зроблене дослідження. Ми можемо використати наявну роботу і рухатись ефективніше до продуктової архітектури, UX, дизайну і розробки.

Проблема не в тому, що є специфікація.

Проблема в тому, що список припущень видають за дослідження.

Документ, що каже "нам потрібно 30 сторінок", не пояснює, чому ці сторінки потрібні.

Вимога, що каже "користувачам потрібні персоналізовані рекомендації", не пояснює, що саме має персоналізуватись, на основі яких даних, чи яку бізнес-проблему персоналізація має вирішити.

А сайт конкурента автоматично не дає креслення для іншого бізнесу.

Саме тому ми розробляємо власну початкову структуру після розуміння бізнесу і шляху клієнта. Результат може підтвердити оригінальну специфікацію клієнта, або показати, що продукт потрібно організувати інакше.

Це не додатковий шар бюрократії.

Це частина продуктового дизайну.

ВІД ДОСЛІДЖЕННЯ ДО ШЛЯХУ

Від конкурентного дослідження до шляху клієнта

У успішного e-commerce сайту рідко є один універсальний шлях клієнта.

Уяви двох відвідувачів того самого преміального продуктового сайту.

Один приходить через пошуковик, вже точно знаючи, чого хоче.

Інший відкриває бренд вперше і проводить кілька тижнів, вивчаючи компанію, її продукти, матеріали, людей і філософію, перш ніж ухвалити рішення.

Врешті вони можуть купити той самий товар.

Їхні шляхи геть різні.

Це стає особливо важливим для обдуманих покупок: luxury-товарів, ювелірки, елітних меблів, нерухомості, B2B-продуктів, професійних послуг та інших покупок, де важливі довіра і оцінка.

Для цих категорій звичне:

каталог → сторінка товару → кошик → чекаут

може описувати лише частину досвіду.

Клієнт може натомість рухатись так:

бренд → колекція → історія → товар → експерт → консультація → купівля

або:

пошук → товар → порівняння → дослідження → повторний візит → купівля

Інтерфейс має вміщувати ці шляхи, а не змушувати кожного відвідувача в одну задану послідовність.

Саме тому карта шляху клієнта для нас не просто UX-документ. Це один із вхідних даних, що визначає архітектуру самого продукту.

Індустрія теж важлива.

Деяким бізнесам корисно прибирати тертя і скорочувати шлях до купівлі. Іншим потрібно створювати простір для відкриття, довіри, навчання чи емоційної залученості.

Іноді кращий досвід швидший.

Іноді сам досвід частина того, що купує клієнт.

САЙТ НЕ ПРОДУКТ

Сайт не продукт

Ця відмінність веде до ширшого питання:

Що саме ми проєктуємо?

Якщо думати лише категоріями сторінок, відповідь очевидна:

Головна.
Сторінка категорії.
Сторінка товару.
Про нас.
Блог.
Контакти.
Чекаут.

Але бізнеси насправді не складаються зі сторінок.

Вони складаються з об'єктів і відносин.

Товар належить колекції.

У колекції може бути історія.

У товару можуть бути матеріал, дизайнер, походження, сертифікація, експерт, послуга чи консультація, з ним пов'язані.

Магазин може бути пов'язаний з локацією.

Експерт може бути пов'язаний з послугою.

Клієнт може взаємодіяти з кількома цими об'єктами, перш ніж ухвалити рішення.

Щойно ми починаємо думати так, архітектура цифрового продукту змінюється.

Замість питання:

"Скільки сторінок нам потрібно?"

ми можемо запитати:

"Які фундаментальні сутності цього бізнесу, і як вони мають взаємодіяти?"

Саме тут Object-Oriented UX (OOUX) стає особливо актуальним для e-commerce.

OOUX пропонує проєктувати навколо реальних об'єктів системи, а не починати з екранів чи дій користувача. Для e-commerce продукту такими об'єктами можуть бути товари, колекції, матеріали, дизайнери, історії, експерти, локації чи послуги.

Цінність не у використанні абревіатури.

Цінність у створенні системи, що може точно представити бізнес, а потім перевикористовувати ці об'єкти в різних досвідах.

Товару не потрібно існувати лише на сторінці товару.

Він може з'являтись всередині колекції, історії, порівняння, рекомендації, кампанії чи персоналізованого досвіду, лишаючись тим самим об'єктом, що лежить в основі.

Це фундаментально інший спосіб думати про архітектуру e-commerce.

OOUX І ATOMIC

OOUX і Atomic Design: два шари однієї системи

OOUX допомагає визначити об'єкти і відносини, що складають цифровий продукт. Atomic Design працює з іншим шаром: як сам інтерфейс побудований з перевикористовуваних компонентів.

Atomic Design, представлений Бредом Фростом, описує інтерфейс як ієрархію атомів, молекул, організмів, шаблонів і сторінок. Кнопка, поле форми чи типографічний елемент може стати частиною більшого перевикористовуваного компонента, що потім збирається у дедалі складніші структури інтерфейсу.

Важлива ідея для e-commerce не в самій термінології.

Вона в тому, що сторінка не первинна одиниця інтерфейсу.

Нова кампанія, товарна категорія, ринок чи шлях клієнта не мають автоматично вимагати проєктування геть нового інтерфейсу з нуля. Добре структурована система може перезбирати наявні компоненти навколо різного контенту і бізнес-об'єктів.

Саме тут OOUX і Atomic Design доповнюють одне одного.

OOUX описує, з чого складається бізнес.

Atomic Design описує, як інтерфейс це представляє.

Один працює переважно на рівні концептуальної моделі продукту, інший на рівні його візуальної та інтерактивної системи.

Разом вони дають корисний фундамент для модульної e-commerce архітектури.

ОРГАНІЗМ НЕ АТОМИ

Ми починаємо з організму, не з атомів

Є важливий нюанс у тому, як ми застосовуємо ці ідеї.

Нам подобається Atomic Design, але ми не починаємо з малювання атомів.

Ми починаємо з живого організму.

Ми вивчаємо реальні бізнеси, реальні сайти, реальні шляхи клієнтів і повторювані патерни по всій категорії. Дивимось, як різні частини досвіду взаємодіють, і як система змінюється залежно від наміру користувача.

Лише тоді ми розбиваємо цю систему на перевикористовувані компоненти.

Це важливо, бо проєктування від найдрібніших елементів вгору не гарантує правильний продукт.

Можна створити чудово побудовану дизайн-систему і все одно побудувати неправильний досвід.

Ідеально консистентна кнопка не каже, чи має клієнт бачити кнопку саме в цей момент.

Технічно вишуканий компонент не каже, чи потрібне клієнту порівняння товарів, розмова з експертом, історія матеріалу, чи просто швидший шлях до чекауту.

Консистентність цінна. Контекст визначає, чи належить компонент тут взагалі.

Саме тому наш процес рухається між різними рівнями абстракції, а не слідує чисто лінійній послідовності дизайну.

Ми дивимось на бізнес цілком, визначаємо його об'єкти і шляхи, а потім вирішуємо, які компоненти інтерфейсу можуть консистентно виразити ці відносини.

ОБДУМАНА ПОКУПКА

Чому це важливо для обдуманої покупки

Ця відмінність стає особливо важливою при проєктуванні e-commerce для обдуманої покупки, тієї самої території, яку ми розбираємо у статті Why Luxury E-commerce Breaks Every Rule of Conversion Optimization.

Клієнт, що купує недорогий, знайомий товар, може прийти з високим наміром і дуже невеликою потребою в дослідженні.

Клієнт, що розглядає прикрасу, luxury-товар, нерухомість, дорогі меблі чи складне B2B-рішення, може мати геть інший процес ухвалення рішення.

Йому може знадобитись:

• інформація про товар;

• порівняння;

• походження;

• експертне керівництво;

• соціальний доказ;

• технічна документація;

• історія за товаром;

• консультація;

• час повернутись і переосмислити.

Це не обов'язково кроки в фіксованій воронці.

Це незалежні частини досвіду, що можуть стати актуальними в різні моменти.

Ця відмінність важлива.

Якщо всі ці елементи жорстко закодовані в один лінійний шлях, інтерфейс стає негнучким. Він може добре працювати для одного типу клієнта, створюючи водночас непотрібне тертя для іншого.

Модульна архітектура дозволяє тим самим об'єктам, що лежать в основі, з'являтись у різних контекстах.

Товар може бути представлений разом зі своєю історією.

Колекція може бути пов'язана зі своїм дизайнером.

Матеріал може стати точкою входу в групу товарів.

Експерт може стати частиною шляху купівлі, а не ізольованою сторінкою "Зв'язатись з нами".

Система стає здатною відображати, як люди реально ухвалюють рішення.

СТОРІНКИ ДО МОДУЛІВ

Від сторінок до модульного досвіду

Саме тому ми не бачимо майбутнє e-commerce обов'язково "безсторінковим".

Сторінка все ще корисна.

Людям потрібні URL. Пошуковикам потрібні індексовані документи. Контенту потрібен контекст. Користувачі все ще навігують між значущими пунктами призначення.

Важливий зсув у тому, що сторінки більше не зобов'язані бути фундаментальними будівельними блоками продукту.

Сторінка може бути композицією перевикористовуваних бізнес-об'єктів і модулів інтерфейсу.

Той самий товар може з'являтись на сторінці категорії, колекції, кампанії, в модулі рекомендацій, досвіді порівняння чи персоналізованій посадковій сторінці, не стаючи окремою версією товару щоразу.

Це створює гнучкішу інформаційну архітектуру e-commerce.

Це також полегшує еволюцію продукту.

Новому ринку може знадобитись інша комбінація наявних компонентів.

Новій кампанії може знадобитись інша композиція.

Новий шлях клієнта може оголити відсутній зв'язок між двома об'єктами.

Замість перезбирання всього сайту система може еволюціонувати, перезбираючи і розширюючи те, що вже існує.

У цьому практична цінність модульності.

Справа не в тому, щоб зробити архітектуру модною.

Справа у збереженні можливості передумати.

І це стає дедалі важливішим у міру того, як цифрові продукти стають розумнішими.

ШІ І СТРУКТУРА

ШІ потребує структурованого продукту, щоб працювати

ШІ змінює, як цифрові досвіди можуть персоналізуватись, але персоналізація не починається з AI-моделі.

Вона починається зі структури продукту.

Якщо e-commerce сайт по суті колекція ізольованих сторінок, у інтелектуальної системи відносно мало що перезбирати, крім тексту, зображень чи наперед заданих рекомендацій.

Але якщо у продукту є структуровані відносини між:

товари → колекції → матеріали → історії → експерти → послуги → намір клієнта

тоді ці відносини стають придатними для шару персоналізації.

ШІ може допомогти визначити, які об'єкти, інформація чи дії найбільш релевантні конкретному відвідувачу, і зібрати досвід навколо них.

Це одна з причин, чому архітектурні рішення, що ми ухвалюємо сьогодні, можуть вплинути на те, що стане можливим за кілька років.

Ми не вважаємо, що кожному e-commerce бізнесу потрібна AI-оркестрація сьогодні.

Не потрібна.

Але бізнесу варто уникати того, щоб робити майбутню персоналізацію невиправдано дорогою, жорстко закодувавши кожен досвід в ізольовані сторінки.

Чим більш модульна система, що лежить в основі, тим більше опцій лишається доступним.

Саме тут наше мислення пов'язується з ідеями, що ми розбирали у статті Що буде з e-commerce, коли сайт перестане бути сайтом?, нашому матеріалі про Callimacus і AI-ведену оркестрацію інтерфейсу. Ідея не в тому, що ШІ має замінити архітектуру продукту. Радше, ШІ може врешті працювати поверх структурованої системи перевикористовуваних об'єктів і модулів, динамічно збираючи досвід залежно від контексту.

Іншими словами:

OOUX визначає об'єкти. Atomic Design визначає перевикористовувані компоненти інтерфейсу. ШІ може врешті вирішувати, як ці компоненти і об'єкти мають комбінуватись для конкретного контексту.

Це набагато цікавіше майбутнє, ніж просто поставити чат-бота на сторінку товару.

ШІ, дзеркало людей, що його використовують

Є ще одна AI-пов'язана зміна, що ми бачимо набагато раніше в процесі.

Дедалі частіше клієнти приходять зі специфікаціями, створеними з ChatGPT, Claude, Perplexity, Copilot чи іншими AI-інструментами.

Ми самі використовуємо ці інструменти, широко.

У розробці, дослідженні, написанні, аналізі, документації і багатьох рутинних частинах нашого робочого процесу ШІ може заощадити величезну кількість часу.

Немає нічого спочатку неправильного у специфікації, створеній за допомогою ШІ.

У багатьох випадках це може значно прискорити процес.

Важливе питання, яке мислення стоїть за документом.

ШІ може видати винятково відполіровану специфікацію з поверхневого дослідницького процесу так само легко, як допомогти досвідченій команді видати дуже сильну. Різниця не обов'язково в моделі.

Вона в експертизі, що веде роботу.

Засновник розуміє речі про бізнес, які зовнішній консультант може ніколи не побачити.

Маркетолог розуміє залучення і позиціонування.

Бізнес-аналітик бачить процеси, залежності і вимоги.

UX-спеціаліст вивчає поведінку і взаємодію.

Проєктний менеджер розуміє ресурси, обмеження постачання і реалізацію.

Команда продажів бачить заперечення і ухвалення рішень, що можуть ніколи не з'явитись в аналітиці.

Жодна з цих перспектив не повна сама по собі.

ШІ, дзеркало людини, що його використовує.

Коли кілька взаємодоповнюючих спеціалістів об'єднують свою експертизу і використовують ШІ, щоб прискорити свою відповідну роботу, результат може бути значно сильнішим, і набагато швидшим, ніж традиційне дослідження і документація наодинці.

Мета не уникати ШІ.

Мета переконатись, що ШІ прискорює хороше мислення, а не просто прискорює припущення.

ТЕХ СЛІДУЄ ЗА ПРОДУКТОМ

Технологія має слідувати за продуктом

Щойно бізнес-модель, шлях клієнта, об'єкти і досвід зрозумілі, рішення про технологію стає набагато прямолінійнішим.

Саме тут ми часто бачимо ще одну поширену помилку: вибір технології спочатку, а потім спробу підлаштувати під неї продукт.

Команда особливо добре знає Laravel, тому проєкт стає Laravel.

Інша команда спеціалізується на Shopify, тому все стає Shopify.

Хтось воліє React.

Хтось інший стверджує, що Symfony краща для великих команд.

Все це можуть бути технічно розумні рішення.

Вони також можуть бути геть нерелевантними реальній бізнес-проблемі.

Не існує універсально правильної e-commerce платформи чи фреймворку.

Для одного бізнесу WordPress може бути більш ніж достатнім. Іншому може бути чудово достатньо Shopify. Іншому продукту може реально знадобитись кастомний застосунок, headless-архітектура на Laravel, чи більш витончений бекенд. Помилитись у цьому рішенні дорого виправляти потім, ми розбираємо цей ризик напряму у статті The Hidden Cost of Choosing the Wrong Architecture.

Рішення залежить від таких факторів, як:

• складність товару;

• кількість і тип товарів;

• інтеграції;

• внутрішні процеси;

• очікуване зростання;

• вимоги до персоналізації;

• контентна архітектура;

• можливості команди;

• вимоги безпеки і відповідності;

• модель підтримки;

• і очікуване життя продукту.

Технологія, це рішення про реалізацію.

Вона має бути наслідком розуміння продукту, не відправною точкою для його визначення.

Це також змінює, як ми думаємо про вартість.

Технічно вражаюча архітектура автоматично не краща інвестиція. Правильне питання, чи створює додаткова складність вимірювану цінність для бізнесу.

Іноді найвитонченіше рішення це рівно те, що потрібно проєкту.

Іноді це дорогий спосіб вирішити проблему, якої у бізнесу насправді немає.

РОБОТА ПІСЛЯ ЗАПУСКУ

Цифровий продукт має працювати після запуску

Сайт не завершений, коли команда розробки його розгортає.

Це особливо правда для e-commerce.

Щойно реальні клієнти починають використовувати продукт, у нас нарешті є те, що жодне теоретичне дослідження не може повністю відтворити: реальна поведінка.

Аналітика показує, звідки люди приходять.

Дані пошуку показують, що вони шукають.

Поведінка користувачів показує, де вони вагаються.

A/B-тестування може оскаржити припущення.

Команда продажів чує заперечення, що ніколи не з'являються в аналітиці.

Клієнтська підтримка виявляє питання, що оригінальна інформаційна архітектура ніколи не передбачала.

І раптом продукт починає нас чогось вчити.

Саме тому ми часто ставимось до запуску як до початку ітеративного процесу, а не кінця розробки.

Перша версія дає нам докази.

Ці докази інформують наступну версію.

Наступна версія виробляє більше доказів.

З часом продукт стає дедалі більше узгодженим з бізнесом і його клієнтами.

Саме тут може бути корисна логіка MVP, тема, яку ми розібрали глибше у статті MVP, це не мінімальний продукт. Це вартість входу., але MVP не повинен означати незавершений чи недбало спроєктований.

Добре спроєктований MVP може бути візуально відполірованим, технічно надійним і повністю професійним.

Що робить його MVP, не погана якість.

Це обсяг того, що ми обираємо валідувати, перш ніж взяти на себе наступний рівень інвестицій.

Ця відмінність може заощадити бізнесам величезні суми грошей.

Компанія може витратити великий бюджет, будуючи витончену платформу, і лише потім виявити, що клієнти поводяться не так, як очікувалось.

Або вона може запустити менший, але ретельно спроєктований продукт, протестувати припущення, навчитись на реальних користувачах, а потім інвестувати в те, що підтвердили докази.

Другий підхід не усуває ризик.

Він робить ризик видимим раніше, поки змінювати напрямок ще доступно за ціною.

ДОСЛІДЖЕННЯ НЕ РАЗОВЕ

Дослідження, не одноразова фаза

Це ще одна причина, чому ми не думаємо про дослідження як про щось, що відбувається лише на початку проєкту.

Початкове дослідження встановлює гіпотези.

Ринок їх тестує.

Продукт генерує нову інформацію.

Ця інформація змінює наше розуміння.

Процес стає ітеративним:

Дослідження → Гіпотеза → Дизайн → Запуск → Вимірювання → Навчання → Доопрацювання

Іноді результат підтверджує оригінальну архітектуру.

Іноді ні.

Обидва результати корисні.

На практиці це одна з головних переваг ставлення до цифрового продукту як до системи, а не як до завершеної колекції сторінок.

Модульна система може еволюціонувати.

Жорстка зазвичай накопичує латки.

БІЗНЕС ПЕРЕД ІНТЕРФЕЙСОМ

Бізнес приходить перед інтерфейсом

Після роботи в різних індустріях і з різними цифровими продуктами це стало одним з наших найсильніших принципів:

Ми не проєктуємо сайти окремо від бізнесів, що вони представляють.

Ми проєктуємо цифрові продукти як частину більшої бізнес-системи.

Це означає розуміти, як маркетинг створює попит, як продажі його конвертують, як операції його виконують, як контент це підтримує, і як клієнти рухаються через весь досвід.

Лише тоді UX стає значущим.

Лише тоді інформаційна архітектура стає значущою.

Лише тоді ми можемо ухвалити розумне рішення про технологію.

І лише тоді дизайн-система стає чимось більшим за колекцію красивих компонентів.

Саме тому ми не просто виконуємо кожну вимогу рівно так, як вона приходить.

Іноді найкраще, що ми можемо зробити для клієнта, побудувати рівно те, що він попросив.

Іноді найкраще, що ми можемо зробити, оскаржити вимогу, перш ніж хтось напише рядок коду.

Ця відмінність не про те, щоб бути складним.

Це про розуміння, за що ми відповідаємо.

Якщо ми знаємо, що запропоноване рішення навряд чи спрацює, просто реалізувати його, бо воно є в специфікації, не експертиза.

Це виконання.

І є різниця.

ВІД ОБ'ЄКТІВ ДО ДОСВІДУ

Від об'єктів до досвіду

Найкорисніший спосіб думати про e-commerce, що ми знайшли, тому не як про набір сторінок, і навіть не як про колекцію екранів.

Це система об'єктів, відносин, шляхів і рішень.

Об'єкти дають бізнесу структуру.

Шляхи клієнтів дають цій структурі контекст.

UX визначає, як люди з нею взаємодіють.

Atomic Design дає інтерфейсу перевикористовувану візуальну мову.

Технологія дає інфраструктуру, що потрібна системі для роботи.

Аналітика і тестування показують нам, як вона поводиться в реальності.

А ШІ дедалі більше дає нам можливість адаптувати частини цього досвіду під конкретних користувачів.

У кожного шару своя робота.

Плутати їх, ось що створює багато проблем, що ми бачимо в цифрових проєктах.

Почати з технології може призвести до непотрібної складності.

Почати зі сторінок може створити жорстку інформаційну архітектуру.

Почати з UI може виробити красиві інтерфейси, що не вирішують правильну проблему.

Почати зі ШІ може виробити вражаючі функції без значущої ролі у шляху клієнта.

Почати з бізнесу дає нам інший шлях.

Перше питання не "Що нам будувати?"

Коли починається новий e-commerce проєкт, є сотні питань, що ми могли б поставити про дизайн, технологію, функціональність, контент і продуктивність.

Але є одне питання, що йде першим:

З чого реально складається цей бізнес, і який досвід потрібен клієнту, щоб через нього пройти?

Щойно ми можемо на це відповісти, решта стає дизайн-завданням.

Ми можемо визначити об'єкти.

Картувати шляхи.

Вивчити ринок.

Визначити архітектуру.

Обрати підходящу технологію.

Побудувати дизайн-систему.

Запустити першу версію.

Виміряти, що відбувається.

І продовжувати розвивати продукт.

Ось чому ми не бачимо e-commerce UX дизайн просто як проєктування інтернет-магазину.

Ми бачимо це як проєктування цифрового шару бізнесу.

І цей шар має бути достатньо гнучким, щоб працювати сьогодні, лишаючись здатним змінюватись завтра.

Бо найсильніші e-commerce продукти, не ті, що спроєктовані лишатись рівно такими, які є.

Це ті, що спроєктовані еволюціонувати.

Далі по темі

Ідеї цієї статті напряму пов'язані з кількома сферами нашої роботи, включно з обдуманою покупкою і luxury e-commerce, модульними цифровими досвідами, OOUX і Atomic Design, і AI-веденою оркестрацією інтерфейсу. Модульний підхід, що ми описали тут, також архітектурний фундамент того, що ми розбирали у статті Що буде з e-commerce, коли сайт перестане бути сайтом?: AI-система може динамічно збирати досвід лише тоді, коли продукт, що лежить в основі, вже структурований у значущі, перевикористовувані об'єкти і модулі.

Сторінка не продукт. Інтерфейс не бізнес. І технологія не стратегія.

Стратегія починається з розуміння того, з чого бізнес, і досвід навколо нього, реально складається.

Автор: Євген Боровий, засновник Peretz Agency.