Wi-Fi та eSIM застосунок

Проблема

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

Гіпотеза

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

Рішення

Одна перевірка на старті і два виходи. Є зв'язок: звичайний вхід і маршрутизація. Немає: окремий екран з підказкою і кнопкою «Спробувати ще», без закешованого акаунта чи плану, що вдає актуальність.

Проблема

Один екран мав служити трьом людям: тому, хто ще нічого не купив, тому, хто має Wi-Fi, і тому, хто має Wi-Fi і eSIM. Каталог продає клієнтам те, за що вони вже платять, а дашборд дає новачку порожню кімнату.

Гіпотеза

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

Рішення

Головна будується зі стану. Немає акаунта: двоє дверей, плани або вхід. Є одна послуга: її картка зі швидкістю, пристроями і наступним платежем, а нижче eSIM як єдине, що ще можна додати. Є обидві: купувати нічого, бо двох однакових ні в кого не буває. Купівля eSIM одразу його активує, бо план лише один.

Проблема

У вебпорталі було сім пунктів навігації, і плани просилися восьмими, хоча плани є шляхом, а не місцем.

Гіпотеза

Якщо оболонка тримає три вкладки, навігація відповідає тому, як працює продукт.

Рішення

Сім сторінок стали трьома вкладками: Головна, Підтримка, Акаунт. Вкладки «Плани» немає, бо головна вже показує, що цей акаунт ще може купити.

Проблема

Партнерські заклади й універсальні плани стояли в одному списку, і ніхто не розумів, що з цього справді для нього.

Гіпотеза

Якщо в застосунку лише універсальні плани, каталог перестає плутати.

Рішення

Два універсальні каталоги: базовий Wi-Fi і мобільний eSIM. Реєстрація в закладах свідомо лишилася в captive-порталі.

Проблема

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

Гіпотеза

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

Рішення

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

Проблема

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

Гіпотеза

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

Рішення

Акаунт відкривається на послугах і їхньому стані. Кожна послуга має свій екран: «Активна» або «На паузі» з датою відновлення, а під цим пристрої, апгрейд, скасування. Пристрої мають окремий екран із назвою мережі, паролем і QR-кодом, що підключає телефон без набору.

Проблема

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

Гіпотеза

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

Рішення

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