Перебудова компресійного PDP без перебудови рушія варіантів Dawn

Компресійний трикотаж складніше купувати, ніж звичайний одяг. Одна сторінка товару має водночас нести два дуже різні типи вибору, і лише один з них повинен змінювати те, що потрапляє в кошик. Ось як сторінка товару Absolute Support зберегла власний інтерфейс, що враховує компресію, поверх власної поведінки Shopify для варіанта, ціни, URL, форми товару та кошика, не будуючи другу комерційну систему, яка боролася б з першою.

Це один із трьох детальних розборів з кейсу Absolute Support. Він доповнює детальний розбір фільтрації та детальний розбір секцій, редагованих продавцем.

Проблема в одному абзаці

Absolute Support продає компресійні шкарпетки, рукави та панчішні вироби. Купити один товар означає ухвалити кілька рішень водночас: рівень компресії (вимірюється в mmHg), розмір, тип виробу, крій за статтю та скільки пар у пакуванні. Рівень компресії, це рішення, яке має клінічну вагу, і його найлегше обрати неправильно. Якщо він стоїть у тому ж випадному списку, що й колір, покупець може обрати «20 до 30 mmHg» так само, як обирає темно-синій колір замість чорного, не усвідомлюючи, що означає це число. Сторінка мала зробити цю різницю зрозумілою, і мала навчати, не вдаючи, що дає медичну пораду.

Обмеження

Кілька меж визначили кожне наступне рішення.

• Shopify володіє станом покупки. Вибір варіанта, ціна, URL товару, форма додавання в кошик та кошик, це поведінка платформи. Їх повторна реалізація тягне за собою непомітні, дорогі помилки саме в тому місці, де магазин заробляє гроші.
• Тема, це Dawn. Dawn уже постачає перевірену систему варіантів. Завдання полягало у власному інтерфейсі з точністю до пікселя, а не в новому комерційному середовищі виконання.
• Компресія тут не є опцією для купівлі. У цьому каталозі кожен товар представляє один клінічний рівень. Рівень, це властивість товару, а не перемикач, який клацає покупець.
• Тексти, дотичні до медицини, потребують обережності. Пояснення можуть описувати та порівнювати. Вони не повинні діагностувати, обіцяти результат чи казати комусь, який рівень лікує його стан.

Рішення: два види даних про товар

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

Compression level        Color · Size · Pack
(product attribute)      (Shopify variants)
      |                        |
      v                        v
  tier display             variant ID
  comparison view          price
  educational context      product URL
      |                        |
      v                        v
 describes the product    changes the cart

Легенда:

1. Рівень компресії, це атрибут товару. Він керує показом ступеня, виглядом порівняння та навчальним контекстом. Він ніколи не змінює кошик.
2. Колір, розмір і пакування, це варіанти Shopify. Кожна комбінація зводиться до варіанта з власним ID, ціною та URL, і саме це отримує кошик.

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

Чому Dawn лишився джерелом істини

Власні елементи керування, це презентація. Щойно покупець змінює один із них, робота передається Dawn.

Custom selectors          (authored presentation)
  color · size · pack
        |
        v
Dawn variant state        (native)
        |
        v
Selected variant          (native)
  price · product URL · product form
        |
        v
Cart                      (native commerce output)

На телефоні це читається згори вниз, і саме так браузер це складає. Тут немає жодного паралельного сховища стану. Власний шар задає значення; Dawn вирішує, що ці значення означають. Збереження єдиного джерела істини, це весь сенс: дві системи, що відстежують «обраний варіант», ось як сторінка врешті показує одну ціну, а стягує іншу.

Покроковий розбір реалізації

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

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

Dawn визначає варіант і повторно рендерить. Власний елемент variant-selects у Dawn читає ці поля, знаходить відповідний варіант і повторно рендерить інформацію про товар із сервера. Оскільки цим кроком володіє Dawn, ціна та текст «ви заощаджуєте» оновлюються самі.

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

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

URL та кошик лишаються нативними. URL товару оновлюється до обраного варіанта, а форма додавання в кошик надсилає цей варіант, і те, й інше, це стандартна поведінка Dawn. Поширене посилання знову відкривається на тому самому варіанті.

Один набір елементів керування. Немає дубльованого блоку вибору для мобільного проти десктопного. Ті самі елементи керування стилізовані адаптивно, тож ніколи не існує другої, застарілої копії вибору покупця.

Інтерфейс порівняння компресії

Рівень компресії обробляється повністю на описовому боці.

• Сторінка зчитує рівень товару з його даних і показує відповідний ступінь.
• Покупець може відкрити вигляд порівняння, який розкладає ступені поруч: Легка (8 до 15 mmHg), Помірна (15 до 20), Сильна (20 до 30) та Дуже сильна (30 до 40), кожен із приміткою простою мовою про типове застосування.
• Вигляд містить нагадування проконсультуватися з медичним фахівцем.

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

Що лишилося нативним

Я змінив стиль buy box. Я не відгалужував його поведінку. Це лишилося за Shopify та Dawn:

• Форма товару та додавання в кошик
• Вибір варіанта та стан
• Ціна та порівняльна ціна (compare-at)
• URL товару
• Кошик та висувна панель кошика (cart drawer)
• Checkout

Перевірка

Те, що я можу перевірити, це реалізація, а не бізнес-результат.

• Рівень компресії змодельований як дані товару, окремо від варіантів.
• Власні елементи керування оновлюють нативний стан варіантів Dawn.
• Ціна, URL товару, форма товару та кошик лишаються узгодженими з обраним варіантом.
• Ціноутворення пакувань виводиться з реальних цін варіантів.
• Джерелом істини для стану покупки лишається Shopify.

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

Компроміси

• Оновлення Dawn потребують узгодження. Власний buy box тримається за контракт варіантів Dawn, тож майбутня зміна Dawn у цій ділянці потребуватиме ручного проходу.
• Частина контенту порівняння зафіксована в коді. Частини тексту про ступені живуть у шаблоні, а не в редагованих налаштуваннях, тож зміна цього формулювання наразі потребує розробника.
• Модель залежить від стабільних домовленостей. Вона покладається на послідовний тег компресії та передбачуваний шаблон пакування. Дані поза шаблоном непомітно відкочуються до запасного варіанта, а не викликають помилку, що безпечно, але легко пропустити.
• Тексти, дотичні до медицини, потребують контролю. Описова мова може зсуватися в бік поради, тож правки цього контенту потребують перевірки.

Що я покращив би далі

• Перенести решту зафіксованого тексту порівняння в редаговані налаштування, щоб команда могла коригувати формулювання без розробника.
• Додати автоматизоване тестування матриці варіантів за кольором, розміром і пакуванням, щоб зміна даних, яка ламає якусь комбінацію, виявлялася рано.
• Задокументувати домовленості щодо тегу компресії та пакування, на які покладається модель.
• Завершити перевірку клавіатурної навігації та фокусу для вигляду порівняння.

Далі: Власний UI фільтрації на Shopify Search & Discovery, який застосовує ту саму ідею до сторінки колекції. Власний інтерфейс згори, нативний рушій знизу.