Клієнт не думає категоріями «вебверсія», «iOS» чи «Android». Для нього існує ваш магазин. Він хоче вибрати товар за ноутбуком, повернутися до нього в телефоні й бачити те саме замовлення всюди. Сайт і додаток можуть давати саме такий цілісний досвід — якщо проєктувати їх як частини одного продукту.
- Один продукт — це спільні дані, правила та зрозумілий шлях між платформами, а не лише однаковий логотип
- Синхронізацію акаунта, кошика й замовлень потрібно спроєктувати; вона не виникає автоматично
- Інтерфейси можуть відрізнятися під пристрій, зберігаючи характер бренду та логіку дій
Одна покупка, кілька пристроїв
Уявімо магазин товарів для дому. Увечері клієнт знаходить на сайті настільну лампу, переглядає фотографії на великому екрані та додає потрібний колір до кошика. Наступного дня відкриває застосунок, входить у той самий акаунт і продовжує оформлення. Після покупки перевіряє доставку там, де йому зручніше.
Такий сценарій цілком можна побудувати, але він має бути вимогою до продукту. Система повинна впізнати акаунт, знайти відповідний кошик, зберегти варіант товару та перевірити актуальну наявність. Якщо цього не передбачити, зовні схожі сайт і додаток залишаться двома окремими каналами.
Найкращий результат — коли клієнту не потрібно розуміти, як усе пов’язано. Він не створює другий профіль, не шукає покупку в іншій історії та не пояснює підтримці, на якій саме платформі оформив замовлення. Перехід між пристроями не обнуляє вже зроблену роботу.
Однаковий характер, а не однакові пікселі
Зв’язок між платформами люди помічають ще до входу. На нього працюють типографіка, палітра, стиль фотографій, назви розділів, вигляд кнопок і тон повідомлень. Якщо на сайті розділ називається «Обране», а в додатку — «Моя колекція», людині доводиться здогадуватися, чи це одна функція.
Водночас не потрібно стискати десктопний сайт до розміру телефона. На ноутбуці каталог може мати бічні фільтри й багато товарів у ряд, а в застосунку — окрему панель фільтрів та нижню навігацію. Спільними залишаються зміст, акценти та передбачуваний результат дій.
Для цього корисна дизайн-система: узгоджений набір кольорів, шрифтів, компонентів і правил поведінки. У неї входять не тільки красиві екрани, а й помилки, порожні стани, завантаження та підтвердження. Наприклад, повідомлення про відсутній товар має однаково пояснювати проблему на всіх платформах.
Клієнт має впізнавати сервіс, але користуватися звичними можливостями свого пристрою. Узгодженість важливіша за буквальне копіювання екранів.
Акаунт і кошик — місце, де єдність стає відчутною
Спільний акаунт означає, що після підтвердженого входу сайт і застосунок працюють з одним профілем. Це не обов’язково означає автоматичний вхід на всіх пристроях: окремі сесії та перевірки доступу залишаються потрібними. Відновлення доступу теж має вести до того самого профілю, а не створювати новий.
Для кошика необхідні окремі правила. Що робимо з товарами, доданими без входу? Як поєднуємо кошик телефона з кошиком акаунта? Що відбувається, коли на двох пристроях змінюють кількість одного товару? Відповіді варто узгодити до розробки, а не залишати випадковій поведінці системи.
У WooCommerce Store API, наприклад, Cart Token дозволяє звертатися до конкретного кошика без прив’язки лише до браузерних cookies. Але наявність такого механізму сама по собі не створює спільний кошик між пристроями: прив’язку до акаунта, захист доступу й правила об’єднання потрібно реалізувати окремо.
Після переходу на інший пристрій ціна або залишок можуть уже змінитися. Перед оформленням замовлення їх потрібно перевірити, а зміни — пояснити клієнту. Обіцянка «усе збережено» не повинна означати продаж за застарілими даними.
Замовлення має жити довше за відкритий екран
Людина може закрити додаток під час оформлення, втратити мережу або повернутися до покупки з браузера. Статус замовлення не повинен залежати від того, чи залишився відкритим один екран. Сайт і застосунок мають отримувати підтверджений результат із серверної системи.
Припустімо, оплата пройшла, але телефон не отримав відповідь. Замість нової спроби списання інтерфейс має перевірити стан уже створеного замовлення. Для повторних запитів команда повинна передбачити захист від небажаних дублів, а для невизначеного стану — чесне повідомлення й можливість перевірити результат.
Те саме стосується доставки, скасування та повернення. Якщо менеджер оновив замовлення, клієнт має побачити узгоджений статус на обох платформах. Сповіщення допомагає дізнатися про зміну, але не замінює її збереження: історія повинна бути доступною і тим, хто вимкнув повідомлення.
Посилання повинне вести до товару, а не на старт
Коли клієнт отримує посилання на конкретну лампу, він очікує побачити саме її. Якщо замість цього відкривається головна застосунку й потрібно починати пошук заново, відчуття єдиного продукту зникає. Тому переходи між повідомленнями, сайтом і додатком теж є частиною проєктування.
Для пов’язування вебадрес із відповідним вмістом застосунку iOS має Universal Links, а Android — App Links. Вони дозволяють налаштувати відкриття потрібного екрана за звичайним вебпосиланням. Якщо застосунок не встановлений, має залишатися доступний вебмаршрут; конкретна поведінка залежить також від системи та контексту відкриття.
Приватні сторінки потребують перевірки доступу. Посилання на замовлення не повинне розкривати чужі дані лише тому, що хтось його отримав. Якщо потрібен вхід, після нього людину варто повернути до початкової задачі. Сам перехід за посиланням не переносить акаунт або кошик автоматично.
Джерела: Apple: Universal Links · Android: App Links
Для команди магазину це теж має бути одна система
Покупцю важлива зручність, а бізнесу — керованість. У правильно пов’язаному продукті менеджер бачить замовлення з різних каналів у спільному процесі. Йому не потрібно щогодини перевіряти окремий список «із додатка» й вручну переносити покупки в основну систему.
При цьому канал оформлення можна зберігати для аналітики. Він допомагає зрозуміти, як користуються продуктом, але не повинен створювати дві несумісні історії клієнта. Єдині дані спрощують пошук замовлення, підтримку та перевірку бонусів, якщо ці можливості передбачені продуктом.
Умови також мають бути зрозумілими. Якщо бізнес свідомо робить акцію лише для застосунку, це потрібно пояснити. Несподівана різниця в ціні, доставці чи бонусах виглядає як помилка, навіть коли технічно все працює за задумом.
Як зібрати цілісний продукт поетапно
Якщо інтернет-магазин уже працює, не обов’язково починати з його повного переписування. Спочатку перевірте, які дані й правила можна використати, а де потрібні зміни. Особливу увагу приділіть нестандартним знижкам, доставці та іншим розширенням, від яких залежить покупка.
Першим результатом варто зробити один наскрізний сценарій. Наприклад: увійти на сайті, зберегти товар, відкрити його в застосунку й побачити замовлення в обох інтерфейсах. Це корисніша перевірка єдності, ніж окрема демонстрація красивого сайта й окрема демонстрація телефона.
Після запуску розвивайте обидві платформи за спільним планом, але не вимагайте одночасного встановлення кожного оновлення. Частина клієнтів залишатиметься на старішій версії додатка. Нові серверні правила мають враховувати це, щоб покращення вебверсії не ламало мобільний сценарій.
- Визначити спільні дані, відповідальних за них і правила доступу
- Узгодити дизайн, назви та поведінку ключових дій
- Перевірити вхід, кошик і замовлення на двох пристроях
- Перевірити перехід за посиланням, втрату мережі та повторне натискання
- Залишити команді один зрозумілий процес опрацювання замовлень
Цілісний продукт — це коли клієнт обирає зручний пристрій, а не починає взаємодію з вашим бізнесом заново.
Маєте питання про свій продукт? Напишіть нам.