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

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

Більшість оглядів сторінок товарів закінчуються списком думок. Хтось каже, що галерея здається тісною, хтось інший захищає вкладки, нічого не вирішено. Це радше рубрика: дванадцять перевірок, кожна з письмовим порогом проходження, отримали оцінку від 0 до 2, що завершується числом з 24, щодо якого два аудитори, що працюють окремо, повинні узгодити це з точністю до одного-двох пунктів. Це для команд UX та CRO, які працюють над сторінками деталей продукту електронної комерції. За даними Інституту Баймарда, він містить понад 155 провідних сайтів США та Європи. 62% мобільних сайтів показують «посередній або гірший» результат на сторінці продукту UX, і жоден з них не отримав ідеальної оцінки. Припустимо, що у вас є висновки. Питання в тому, які саме і наскільки погані.

Як працює підрахунок очок

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

Аудит шаблон, а не один продукт: виберіть три артикули, які по-різному його підкреслюють – простий товар, товар із великою кількістю варіантів, товар, який частково відсутній на складі – і беріть найнижчий бал за кожну перевірку. PDP, яка працює лише для простого SKU, не є робочою PDP.

Смуги: 20-24, шаблон надійний, а проблема з конвертацією в іншому місці. 14-19, виправте нулі, перш ніж запускати тут ще один тест. 0-13, шаблон є вузьким місцем, і тестування елементів поверх нього дасть нечіткі результати.

Ворота 1: чи можуть вони зрозуміти, що це за продукт?

Перевірка 1 – Набір зображень та масштабування. Поріг: щонайменше п'ять зображень, що охоплюють кожну сторону, одне детальне зображення на рівні матеріалу, одне, що встановлює масштаб, і масштабування, яке дозволяє розрізняти реальні деталі. Baymard виявив, що 25% сайтів не мають достатньої роздільної здатності або масштабування, а 37% не надають зображень у масштабі. Масштаб – це те, що команди пропускають, і саме це генерує прибутки.

Перевірка 2 – Видимість зображення на мобільних пристроях. Поріг: додаткові зображення відображаються як мініатюри або індикатори положення, і користувачеві не потрібно проводити пальцем, щоб дізнатися про їх наявність. 76% мобільних сайтів не надають мініатюр, тому галерея невидима для тих, хто не здогадується.

Перевірка 3 – Опис та можливість сканування специфікацій. Поріг: опис відповідає на п’ять запитань, які найчастіше надходять у вашу поштову скриньку підтримки для цієї категорії, а специфікації відображаються як список атрибутів для сканування, а не проза. Baymard оцінює 50% сайтів як такі, що неправильно враховують можливість сканування специфікацій. Візьміть п’ять запитань із заявок або пошуку на сайті, а не з семінару.

Ворота 2: чи можуть вони вибрати правильний варіант?

Перевірка 4 – Відображаються елементи керування варіантами. Поріг: розмір, колір та інші параметри відображаються як видимі кнопки або зразки, а не як випадаючий список, який користувач має відкрити. 57% сайтів не використовують кнопки для вибору розміру. Закритий випадаючий список приховує параметри та недоступні з них.

Перевірка 5 – Синхронізація даних варіантів. Поріг: вибір варіанта оновлює ціну, зображення, стан запасів та оцінку доставки разом, без відображення застарілих значень на екрані. 28% сайтів не синхронізують дані між варіантами. Зазвичай це виявляє проблему архітектури інтерфейсу, а не проблему дизайну.

Перевірка 6 – Обробка недоступного варіанту. Поріг: варіанти, яких немає в наявності, залишаються видимими та вимкненими з зазначеної причини, а на сторінці пропонується одна наступна дія – сповіщення про поповнення запасів, найближча альтернатива або відкладене замовлення. 68% сайтів не дозволяють користувачам купувати товари, яких тимчасово немає в наявності. Найгірше – це непомітне видалення опції: користувач не може визначити, чи існує потрібний розмір.

Ворота 3: чи можуть вони розрахувати реальну суму?

Цей пункт призначення несе найбільший дохід і найбільший регуляторний вплив. Згідно з 50 агрегованими дослідженнями, Baymard оцінює середній показник відмови від кошика на рівні 70.22%Серед зазначених причин, занадто високі додаткові витрати становлять 40% від загальної кількості витрат. Більшість із цих витрат можна дізнатися на PDP, і вони розкриваються під час оформлення замовлення.

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

Перевірка 8 – Представлення ціни та посилання на знижку. Поріг: відображена загальна сума включає всі податки; будь-яке порівняння «було/зараз» використовує обґрунтовану довідкову ціну; а там, де відображаються платежі в розстрочку, загальна ціна, кількість платежів та сума кожного платежу відображаються разом у зручному для читання розмірі.

Тут сходяться два правила. У ЄС стаття 6a Директиви 98/6/ЄС вимагає, щоб у оголошеному зниженні ціни вказувалася попередня ціна, яка визначається як найнижча ціна, що застосовувалася принаймні за попередні 30 днів. У рекламному регулюванні Туреччини застосовується та сама логіка найнижчої ціни за останні 30 днів і додатково регулюється відображення розстрочки. Це положення не є формальністю: регулятор виділяє розстрочку саме тому, що вона є помітною в турецькій електронній комерції, тому PDP, що приховує цифру за розстрочку за модальним вікном, приховує кількість, яку обирають покупці.

Перевірка 9 – Політика повернення протягом однієї взаємодії. Поріг: вікно повернення та інформація про те, хто сплачує зворотну доставку, доступні одним дотиком, а не через футер. 44% сайтів не відображають або не посилаються на політику повернення на сторінці товару, а незадовільна політика є зазначеною причиною відмови для 13% користувачів.

Ворота 4: чи кожен може ними керувати?

Перевірка 10 – Цільовий розмір. Поріг: кожен інтерактивний елемент керування — зразки, крокові шкали кількості, стрілки галереї, фільтри огляду — має розмір щонайменше 24 на 24 пікселі CSS або розташований таким чином, щоб 24-піксельне коло з центром на ньому не перетинало сусіднє. Це відповідає WCAG 2.2 SC 2.5.8, рівень AA. Зразки та крокові шкали найчастіше не відповідають цьому критерію.

Перевірка 11 – Реагування на взаємодію. Поріг: Взаємодія з наступним малюванням на 75-му процентилі польових даних для шаблону PDP становить 200 мс або менше; вище 500 мс – погано. Використовуйте польові дані, а не лабораторний пробіг: перемикання варіантів та взаємодія з галереєю – це ті моменти, де PDP INP погіршується, а синтетичні тести їх не використовують.

Перевірка 12 – Перевірте якість доказів. Поріг: присутній зведений розподіл оцінок, зображення відгуків можна переглядати для різних відгуків, а на сторінці зазначено, як збираються відгуки та чи перевіряються вони. 65% сайтів неправильно розподіляють оцінки. 4.4, побудований з 5 та 1, – це інший продукт, ніж 4.4, побудований з 4 та 5.

Лист оцінювання

#перевіритиПрохідний поріг (бал 2)ворота
1Набір зображень та масштабування5+ зображень, одне з яких масштабоване, масштабування додає деталейЗрозуміти
2Видимість зображень на мобільних пристрояхВидимі мініатюри або індикатор положенняЗрозуміти
3Опис та характеристикиВідповіді на 5 найпопулярніших запитань служби підтримки; характеристики можна скануватиЗрозуміти
4Варіантні елементи керуванняПараметри, видимі як кнопки або зразкиВиберіть
5Синхронізація варіантівЦіна, зображення, наявність, оновлення доставки одночасноВиберіть
6Недоступні варіантиВидимий, вимкнено, причина вказана, наступна діяВиберіть
7Вартість та дата доставкиОбидва оцінюються на PDP без взаємодіїЗагальна вартість
8Довідка про ціну та знижкуВключно з податком; найнижчий 30-денний довідковий тариф; оплата трьома частинами разомЗагальна вартість
9Політика поверненняВікно та хто платить, одна взаємодіяЗагальна вартість
10Цільовий розмір24x24 CSS пікселів або еквівалентний інтервал (WCAG 2.2 AA)Робота
11ЧуйністьПольовий INP p75 на рівні або нижче 200 мсРобота
12Огляд доказівПоказано розповсюдження, зображення доступні для перегляду, колекція розкритаРобота

Працюючий приклад

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

Зрозумійте: 2 + 0 (сліпе свайпування) + 1 (специфікації прозою) = 3/6. Виберіть: 2 + 1 (орієнтовна вартість доставки застаріла) + 0 (розміри зникають) = 3/6. Загальна вартість: 0 + 1 (загальна сума платежу лише в модальному вікні) + 1 (повернення у футері) = 2/6. Оперуйте: 0 (зразки з розміром 20 пікселів) + 1 (INP p75 340 мс) + 1 (без розподілу) = 2/6.

Всього: 10/24. Це не «провести тест заголовка». Це виправлення шаблону, охоплене чотирма нулями, у такому порядку: оцінка доставки, розміри, що зникають, цільовий розмір зразка, мобільна галерея. Три з чотирьох – це інженерні квитки, а не проектні роботи, які зазвичай є фактичним результатом. [ПОТРІБНІ ВНУТРІШНІ ДАНІ: Медіанні показники Switas Gate у всіх перевірених PDP та рух конверсій після виправлень Gate 3.]

Що робити з балом

Виправте кожен нуль, перш ніж тестувати щось на сторінці: експеримент, що виконується над несправним кроком, вимірює саме поломку, а не вашу гіпотезу. Одиниці – це ваш беклог тестів – реальний, але з спірним виправленням. Переоцінку проведіть після того, як виправлення будуть відправлені, для тих самих трьох SKU.

Де ця рубрика розпадається

Він створений для роздрібної торгівлі фізичними товарами. Цифрові товари, підписки, туристичний інвентар та налаштовувані B2B-продукти мають різні вирішальні атрибути, і Gate 3 не переноситься: сторінка готелю чи авіаквитка має ціни, що залежать від дати, які ця рубрика не моделює. Він також ігнорує залучення клієнтів – тут ніщо не оцінює повноту структурованих даних, яка визначає відповідність списку продавців. І він повідомляє вам, що не відповідає письмовому порогу, а не чому певний користувач вагався: він замінює раунд думок, а не тестування зручності використання.

FAQ

Скільки часу триває цей аудит?

Близько 40 хвилин на один SKU після узгодження порогових значень, тобто приблизно дві години на шаблон. Більша частина цього часу йде на етап 3, оскільки логіка доставки та встановлення залежить від типу продукту.

Хто має це керувати?

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

Чи низький бал доводить, що PDP коштує нам грошей?

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

Чим це відрізняється від аудиту доступності?

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

Наш PDP відображається на торговельному майданчику або SaaS-платформі. Чи це все ще корисно?

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

Чи застосовуються турецькі правила відображення цін, якщо ми продаємо лише на внутрішньому ринку?

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

Запустіть це у власному каталозі

Отримайте цього тижня три SKU з вашого власного шаблону PDP та перевірте, чи результат потрапив туди, де ви очікували. Якщо ви бажаєте, щоб це було зроблено правильно, зіставивши результати з інженерними заявками та додавши дані вашої воронки продажів, Зверніться до нас щодо UX-аудиту.

Джерела


Статті по темі

Світас, як видно на

Magnify: Масштабування інфлюенсер-маркетингу з Енгіном Юртдакулом

Перегляньте наш тематичний аналіз Microsoft Clarity

Ми відзначили Microsoft Clarity як продукт, створений з урахуванням практичних випадків використання в реальних умовах реальними розробниками, які розуміють проблеми, з якими стикаються такі компанії, як Switas. Такі функції, як кліки, що викликають гнів, та відстеження помилок JavaScript, виявилися безцінними для виявлення невдоволення користувачів та технічних проблем, що дозволило цілеспрямовано покращити роботу, що безпосередньо вплинуло на взаємодію з користувачем та коефіцієнти конверсії.