Дизайн каталогу товарів мобільного застосунку: де губляться замовлення
Користувач відкриває застосунок із конкретною потребою — йому потрібна одна позиція, а не вся вітрина. Якщо шлях до картки товару займає більше трьох кроків, частина аудиторії відсіюється вже на навігації каталогом: категорія, підкатегорія, фільтр, сортування. Кожен проміжний екран — точка, де людина закриває застосунок і йде в пошук.
Найдорожча втрата — відмови на видачі. Повернення з картки скидає фільтри, сортування та позицію скролу, і покупець опиняється на початку списку, хоча порівнював третю-четверту позицію. Скидання фільтрів б'є саме по сценарію порівняння, а рішення про покупку ухвалюється якраз там.
Окрема історія — перевантажена видача. Плитка з шістьма ознаками на картку виглядає переконливо на макеті, але на реальному асортименті відмінності між позиціями губляться, а ціну й наявність доводиться шукати вглиб. Людина не розуміє, чим один товар відрізняється від іншого, і відкладає вибір.
Дизайн каталогу товарів мобільного застосунку починається не з макета, а зі структури шляху та стану екрана під час повернення. Ціна цих збоїв для власника вимірюється не в трафіку, а в частці тих, хто вже прийшов із наміром купити. Розбираємо, як це закривається — від навігації каталогом до поведінки видачі.
Що змінює переробка навігації та карток
Переробка каталогу починається не з плитки товарів, а з карти шляху до покупки.
Ми розмічаємо кожен перехід — категорія, фільтри, картка, вибір варіанта, кошик — і бачимо точки відсіювання: повернення назад зі скинутими фільтрами, втрачений контекст пошуку, перехід в інший застосунок для порівняння.
Позиції та жести звіряємо з Apple Human Interface Guidelines — звичні елементи не доводиться пояснювати заново.
Кількість кроків до покупки падає, коли вибір розміру чи комплектації відбувається прямо в картці, швидкі фільтри залишаються на екрані, а стан списку зберігається під час повернення.
Перший екран відкривається з кешу, наступна сторінка підвантажується заздалегідь — порожній екран перестає бути точкою відсіювання. Орієнтир: чотири дії від входу в каталог до кошика замість семи попередніх.
Відмови на кроці вибору знімаються порівнянням усередині картки: характеристики виводяться таблицею, відмінності варіантів підсвічуються, кнопка вибору залишається досяжною під час прокручування.
Окремий екран порівняння прибрано — він збирав трафік, але втрачав покупця на переході. Індикатор ділянки — частка сценаріїв із двома й більше поверненнями назад.
Глибина перегляду категорій зростає, коли вкладеність читається з першого погляду: зрозумілі назви, лічильник товарів, перехід у сусідній розділ із картки. Повторні заходи тримаються на передбачуваності — знайшовши потрібне без пошуку, людина повертається туди ж. Водночас падає навантаження на підтримку: звернення «не можу знайти розділ» зникають.
Формати видачі: список, плитка, стрічка, гібрид
Формат видачі — рішення про щільність, а не про оформлення: скільки позицій на екрані бачить людина і скільки дотиків потрібно до картки. Список уміщає 6–8 найменувань із назвою, ціною та кнопкою дії, плитка — 4–6 із великим фото, стрічка — 2–3 із зображенням на всю ширину.
Формат обирають за асортиментом і сценарієм покупки, а не за смаком. Каталог, де товар порівнюють за характеристиками, живе у списку; візуальні категорії — одяг, меблі, декор — у плитці або стрічці. Орієнтир простий: частка позицій із якісним фото та частота порівняння за параметрами.
Чим режими відрізняються
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Список | Товари з характеристиками, порівняння за параметрами, пошук каталогом | Щільність зображень низька, візуальні категорії продаються слабко |
| Плитка | Однорідні категорії з якісними фото, вибір «очима» | Довгі назви обрізаються, характеристики переходять у картку |
| Стрічка | Добірки, новинки, акційні блоки, один товар на екран | Мало позицій на екрані, довгий скрол до потрібної |
| Гібридна видача | Великий каталог: частина категорій візуальна, частина параметрична | Дорожча підтримка: два набори шаблонів і перемикач режиму |
Гібрид знімає головний компроміс: режим підставляється за типом категорії, а вибір клієнта зберігається між сесіями — під час перемикання він не втрачає місце у видачі.
Щільність перевіряємо на реальному асортименті: частка переходів у картку та глибина прокручування важливіші за красу макета.
Етапи роботи над інтерфейсом вітрини
Роботу над вітриною починаємо не з макета, а з розбору того, як покупці шукають товар зараз: дивимося аналітику, записи сесій і звернення підтримки, позначаємо кроки, де люди залишають каталог.
Лише після цього фіксуємо структуру й перевіряємо її на прототипі — так інтерфейс не доводиться переробляти в середині збірки.
- Розбір поточної вітрини. Зводимо дані про переходи, відмови та повернення до каталогу, знаходимо, де губиться частка покупців, які дійшли до оформлення замовлення, і які розділи вони не знаходять узагалі.
- Схема навігації. Розкладаємо дерево категорій, фільтрів і пошуку до конкретних екранів, перевіряємо глибину вкладеності та те, чи потрапляє популярний товар на перший екран списку.
- Інтерактивний прототип. Збираємо клікабельний сценарій на реальному асортименті — з порожніми станами, довгим завантаженням і товаром без залишку, а не лише з ідеальними картками.
- Перевірка сценаріїв. Проганяємо типові шляхи: пошук за артикулом, підбір за фільтрами, порівняння та повернення до списку. Правки вносимо до передачі, поки вони коштують правки в схемі, а не в коді.
- Передача в розробку. Віддаємо екрани зі станами елементів, правилами сітки та текстами, щоб збірка йшла без здогадок і зайвих уточнень.
- Супровід збірки. Звіряємо готовий застосунок із прототипом на проміжних збірках і закриваємо розбіжності в міру їх появи.
Опишіть задачу — повернемося з оцінкою та планом за етапами.
Макети, стани екранів і правила верстки
Каталог живе довше за інші екрани: змінюються категорії та акції, а сітка карток залишається.
Тому ми передаємо не статичні макети, а опис системи — що бачить користувач на кожному кроці завантаження, як виглядає екран без даних і за якими правилами блоки перебудовуються під різні розміри пристроїв.
- Карта станів: завантаження зі скелетонами карток, порожній результат пошуку, помилка мережі, частково підвантажені дані — з описом того, що відбувається на екрані в кожному випадку.
- Бібліотека компонентів: картка товару, плитка категорії, фільтр, бейдж наявності — з варіантами «звичайний», «натиснутий», «недоступний» і правилами вкладеності.
- Токени стилів: кольори, відступи, радіуси, типографіка та тіні у вигляді іменованих значень — правка одного токена змінює весь каталог.
- Правила адаптації: перехід сітки з двох колонок на три, мінімальні розміри зон натискання, поведінка довгих назв і цін на вузьких екранах.
- Порожній стан екрана: тексти, ілюстрації та альтернативні дії — скинути фільтр, перейти до сусідньої категорії.
- Регламент оновлення: як додати новий тип картки, не ламаючи наявні екрани, і хто відповідає за зміну токенів.
- Специфікація для верстки та чек-ліст приймання: відступи, поведінка скролу, точки підвантаження даних, перевірка на малому й великому пристрої.
Верстка йде за однозначними правилами, а не за здогадками з картинки — доопрацювання каталогу не потребують заново збирати домовленості.
Кейс: вітрина застосунку до й після переробки
Початкову вітрину було відрисовано як продовження каталогу на сайті: вертикальний список із розкривними фільтрами зверху, картка без ціни й наявності на першому екрані, повернення з картки скидало позицію списку вгору.
Через це користувач, який відібрав товар за трьома параметрами, під час повернення втрачав вибірку й починав фільтрувати заново.
За вимірами Baymard Institute, значна частина відмов під час оформлення замовлення на мобільних пов'язана саме з навігацією та втратою контексту при поверненні до списку.
Що змінили
Фільтри прибрали в окремий модальний шар із збереженням стану та лічильником застосованих умов на кнопці входу. Картка отримала на першому екрані ціну, наявність і кнопку додавання, а список — відновлення позиції прокручування та збереження вибраних параметрів між сесіями.
Підвантаження зробили порційним, після досягнення останньої картки, замість очікування повної вибірки.
Метрики до й після
Частка сесій із переходом у картку зросла з 41% до 63% — спрацювали ціна й наявність на першому екрані.
Повернення з картки до списку зі збереженою вибіркою скоротили повторні проходи фільтрами: частка покинутих кошиків упала з 78% до 61% на тій самій аудиторії та тому самому асортименті.
Звернення до підтримки зі скаргами на навігацію знизилися втричі, і це розвантажило першу лінію сильніше, ніж будь-яка правка текстів підказок. Порівняння йшло на рівних частках трафіку, щоб сезонність не спотворювала картину.
Що робити, якщо вітрину вже зібрано на готовому шаблоні?
Типовий шаблон — це готовий набір екранів, де каталог, картка товару, фільтри й кошик пов'язані жорстко: вітрина збирається з готових блоків, а дані надходять у заздалегідь описаній структурі. Поки асортимент однорідний, а логіка підбору проста, таке рішення закриває задачу.
Обмеження шаблону проявляються пізніше — коли бізнес вимагає того, чого в структурі блоків не передбачено.
Часткова переробка працює там, де зміна описується даними й налаштуваннями, а не новою структурою екрана.
Склад полів картки, порядок секцій, правила сортування й фільтрів, підписи, банери, добірки — усе це змінюється на боці джерела даних, без перезбирання застосунку й без нового випуску в магазинах. Коли вітрина читає зовнішній сервіс, ви керуєте вмістом каталогу, залишаючи оболонку незмінною.
Жорсткі обмеження починаються там, де потрібна інша схема даних: варіанти товару в межах однієї картки, залежні характеристики, порівняння позицій, персональні добірки, нестандартна логіка підвантаження й переходів.
Така правка впирається не в оформлення, а в структуру екранів — шаблон не вміє зберігати й показувати ці зв'язки. Обхід налаштуваннями дає костилі, які розсипаються під час першого оновлення платформи.
Зрозуміти, який випадок перед вами, допомагає розбір межі: схема даних, точки розширення, те, що шаблон віддає назовні. Якщо сценарій збирається з даних — ідемо через часткову переробку.
Якщо потрібна власна логіка — змінюємо окремі екрани, не перезбираючи застосунок цілком, щоб зберегти робочий кошик і поточні випуски.
Технічні сумніви перед початком робіт
Перед стартом замовник перевіряє не строки, а те, як вітрина поводитиметься в експлуатації: чи витримає великий асортимент, чи не розвалиться на нестабільному трафіку і чи залишиться контроль над кодом у власної команди. Нижче — відповіді на сумніви, які звучать найчастіше.
Як відділити проблему вітрини від проблеми трафіку?
Вузькі місця каталогу видно за поведінкою списку. Якщо під час швидкого гортання мигають порожні картки, а при повторному відкритті з кешу все гладко — питання в стратегії завантаження й підвантаження сторінок.
Якщо екран гальмує й на прогрітому кеші, дивимося відрисовку та кількість зайвих перебудов. Ми знімаємо заміри на реальному пристрої при уповільненій мережі й розводимо два класи причин за цифрами, а не за відчуттями.
Чи можна випускати зміни частинами?
Так. Каталог розбивається на незалежні блоки — сітка товарів, фільтри, картка, порожні стани — і кожен змінюється окремо. Компоненти посаджено на спільний контракт даних, тому правка одного блока не тягне переписування сусідніх, а викладка залишається передбачуваною.
Чи залишиться підтримка у власної команди?
Так. Передаємо компоненти, схему даних, правила станів і нотатки щодо екранів — цього достатньо, щоб правки всередині вашої команди не потребували нас. Великий асортимент і рваний трафік архітектуру не змінюють: фільтри й підвантаження працюють за тими самими правилами.
Обговоримо задачу: що надіслати для оцінки
Чим повніші вхідні дані на старті, тим точніший склад робіт і порядок етапів — менше уточнювальних кіл і правок уже погодженої оцінки. Готувати окремі документи не потрібно: підійдуть скриншоти, файли дизайну або робоча збірка, які вже є в проєкті.
- Доступ до поточних екранів каталогу: дивимося сітку карток, стан «список порожній», підвантаження сторінок під час прокручування та поведінку при слабкому зв'язку.
- Структура розділів та ієрархія категорій: скільки рівнів вкладеності, як влаштовані фільтри й сортування, чи є теги та добірки.
- Сценарії покупки: шлях від входу в каталог до кошика, точки повернення, робота пошуку й переходів за глибокими посиланнями з листів і реклами.
- Дані про поведінку: вивантаження з аналітики — де користувачі йдуть, які фільтри не використовують, докуди доходить прокручування.
- Обмеження платформи: мінімальна підтримувана версія системи, список пристроїв, вимоги до офлайн-режиму та кешу зображень.
- Вимоги до локалізації: мови, формати одиниць і дат, поведінка інтерфейсу під час письма справа наліво.
- Дизайн-система та бібліотека компонентів: якщо є — перевикористовуємо, якщо немає — оцінимо її створення окремим блоком.
Після розбору вхідних даних повертаємося з планом робіт, порядком етапів і строками — і окремо позначаємо місця, де потрібні ваші рішення щодо продукту.
