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

Олеся Каіта, студентка курсу продакт-дизайну у школі Projector, показала своє бачення редизайну мобільної версії сайту. Зокрема, процесу купівлі квитків. У прототипі Олесі час від початку до завершення придбання квитків за патерном – квитки на двох в обидва кінця – скоротився втричі.

Альтернатива «і так норм»

Усе почалось із того, що я захотіла глибше розібратись у об’єктно-орієнтованому прототипуванні. І зробити все сама. А ідея редизайну флоу купівлі квитків з мобільної версії Укрзалізниці підходила якнайкраще – сайт не надто складний у плані об’єктів, але досить погано продуманий, тобто є у чому розбиратися.

Я сіла за ноутбук і купила квиток. За 53 гривні 25 копійок. Так перейшла до визначення об’єктів класів, їх властивостей, обмежень та функцій.

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

Почала з класу Користувач (User), це з простого. Те, що ми знаємо про кожного користувача – це його властивості. У класу “User” є властивості: ID (тип даних: ID), Прізвище (string), Ім’я (string), Еmail (string), Телефон (string), Тип користувача (string), Реєстрація (timestamp), Пароль (string), Fb(number), G+ (number). Тип користувача – це студентський/пільговий, наприклад. Дещо з нього не обов’язкове до заповнення – Телефон, Тип користувача, Fb (number), G+ (number) – значить, може мати значення “null”. Те, що ми можемо робити з об’єктом класу – це методи. Тут це Create User, Read User, Update User, Delete User. Ніби не складно.

Також є класи Поїзд (Train), Оплата (Card), та Документ (Doc). З них цікавий Поїзд (Train). Давайте подивимося.

У класу “Train” є властивості: ID (тип даних: ID), Номер поїзда (string), Маршрут (Array [Time_come:timastamp, Time_go:timastamp, Station:string]), Дата відправлення (date), Дата прибуття (date) та Вагони (Array [Number:num, Class:string, All_places:num, Free_places:num]).

Маршрут (Array [Time_come:timastamp, Time_go:timastamp, Station:string]) – означає, що у кожного поїзда є таблиця зі стовпчиками «Прибуття», «Відбуття» та «Станція».

Вагони (Array [Number:num, Class:string, All_places:num, Free_places:num]) – означає, що кожен поїзд складається з вагонів, а у кожного вагону є номер, клас, загальна кількість місць та кількість вільних місць. Звісно, все дещо складніше і є ще продані місця та заброньовані, їх номери, але в нашому контексті ми можемо цим знехтувати.

Тут я зрозуміла, що кейс на цьому не залишу. Хочу його повністю, з дослідженням, проєктуванням, тестуванням та UI.

Similarweb web показав 2,87 млн візитів на сайт. З них 59,16% заходять прямо на сайт: або вводять інтернет-адресу, або переходять із закладок. Найпопулярніші запити Google, що приводили на сайт – «укрзалізниця», «жд білети», “booking uz” і т.д. Значить, 80% від органічного пошуку можна прирівняти до тих, що вводив інтернет-адресу, а це ще 29,76%.

Тобто,Укрзалізниця вже виховала 2,55 млн людей, котрим «і так норм». Але ж можна краще!

Як не налякати людей своїм «краще»?

Для початку, залишити лейаут і навігацію без змін. З лейаутом на цій сторінці все нормально, з меню не дуже (але це не сьогодні). Ідентифікація через шрифт, лого, кольори – тут усе логічно.

Плюси. Мені у мобільній адаптації сайту сподобався логотип. Його розробляла агенція Galagan у 2018.

Мінуси. На основному екрані (якщо брати до уваги лише UX) мені не подобається згорнуте поле «Дата відправлення». Для вибору дати треба викликати попап. Так, автоматично стоїть сьогоднішня дата, але, якщо мені потрібен квиток на завтра — я втрачу тап на вибір нової дати. А якщо на завтра квитки закінчилися — то й не один тап.

Тому є гіпотеза: якщо календарик показувати розгорнутим, з обраною сьогоднішньою датою, а також дозволити обирати не одну, а кілька дат виїзду, це зекономить клієнтам час і гроші. А значить — додасть нам лояльності. А лояльність не купиш!

Якщо потрібно купувати квитки туди й назад для двох осіб (тобто 4 квитки), то ми у теперішній версії мобільного сайту пройдемо шлях у 66 кроки. 66 кроків, Карл!

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

Вибір часу відправлення для інтернет-замовлення – надлишковий. Бо найчастіший патерн вибору квитка безпосередньо на вокзалі – це найближчий до потрібної станції. Але ж це на вокзалі, там це логічно. Хоча навіть там, є й інший патерн – це «байдуже коли, аби дешевше». Люди часто купували квитки:

• на найближчий потяг до потрібної їм станції (часто знали уже номер поїзда);
• в обидва кінці;
• два квитки поруч;
• найдешевший з усіх варіантів.

Типовий діалог на касі:

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

Отже. Найважливіші зміни на сторінці з модулем вибору квитків:

• Станцію «Звідки» визначаємо по геолокації.
• Вводим функціонал «Квитки в обидві сторони».
• Позбуваємось кнопки «Перемикання» між станціями.
• Додаємо «2 квитки поряд».
• Показуємо календар повністю, не використовуючи поп-апи.
• Позбуваємось вибору часу відправлення.

На сторінці з результатом пошуку:

• Вводимо сортування квитків за ціною – від найдешевшого.
• Показуємо доступні квитки та їх ціни у кожному з поїздів, виділяючи найдешевші.

На сторінці поїзда:

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

На сторінці замовлення квитків:

• Вводимо чек баттон «використати ті самі дані для зворотнього квитка».

І отримуємо новий флоу замовлення квитків в обидва кінця для двох у 21 крок. Не у 66, а у 21!

Взагалі дуже хотілося зробити не правки до існуючого флоу, а змінити його на глибшому рівні. Наприклад, був варіант сайту без корзини. Тобто, всі обрані квитки після заповнення просто б висіли зверху екрана – до них можна було у будь-який час повернутися та перевірити чи змінити дані. «Варіація на тему акордеона». Але ні. Адже є більше двох мільйонів людей, котрі приходять на сайт і очікують пройти весь шлях по- старому. Бо сортування за ціною, зміна ієрархії в картці поїзду чи вивід цін одразу на картці (без необхідності заходити на сторінку поїзда) – це одне, а відсутність корзини – це те, що точно налякає.

Прототип, який можна тестити

Після двох тижнів роботи я зібрала прототип і показала першій живій людині. Виявилося, що тоді сортування «від дешевших» (зліва) було геть неочевидним. У наступних ітераціях виправилась.

Далі, використовуючи прототип, тестувала флоу купівлі найдешевших квитків Київ-Львів в обидва кінця, на 2 персони і за тиждень до потрібної дати.

У постійного користувача купівля квитків за вищезгаданими умовами зайняла 3 хвилини 1 секунду. Перше проходження шляху купівлі на новому прототипі зайняло 1 хвилину 49 секунд, а повторне використання прототипу – 53 секунди! Для чистоти експерименту додамо ще 8 секунд за рекапчу, котрої у тому варіанті не було. Тобто флоу в новій версії можна пройти у 3 рази швидше оригіналу!

У наступній ітерації дизайн ще трохи удосконалився: збільшила контраст та зробила виразнішими кнопки. Сам же флоу залишився без змін.

Робила проєкт два місяці, а відчуття закінченості немає. Мабуть, так і повинно бути з продуктовим дизайном.