кейси
Portmone. Як оптимізувати
дизайн-систему на
3000 сервісів
дизайн-систему на
3000 сервісів
Студенти професіуму з продуктового дизайну реорганізували профіль користувача на сайті платіжної системи.
Поповнити мобільний чи інтернет, скинути гроші на картку чи оплатити комуналку. Яке бажання зазвичай виникає, коли маєш справу з такими операціями? Зробити все максимально швидко і просто — без зайвих кліків і зайвих нервів, аби скоріше повернутися до звичних справ. Вгадали?
Наблизити це бажання до реальності допомагає ефективна дизайн-система. Будувати такі вчилися студенти річного курсу Product Interface Design Professium під кураторством Дениса Суділковського (нині куратор курсу Product design). Як і водиться в Проджі, практикувалися на кейсі від реального клієнта, в ролі якого виступила міжбанкова електронна платіжна система Portmone.
Над кейсом працювало кілька команд, і одна з них — під назвою Design System — запропонувала рішення, яке можна швидко імплементувати і не злякати постійних користувачів.
Наблизити це бажання до реальності допомагає ефективна дизайн-система. Будувати такі вчилися студенти річного курсу Product Interface Design Professium під кураторством Дениса Суділковського (нині куратор курсу Product design). Як і водиться в Проджі, практикувалися на кейсі від реального клієнта, в ролі якого виступила міжбанкова електронна платіжна система Portmone.
Над кейсом працювало кілька команд, і одна з них — під назвою Design System — запропонувала рішення, яке можна швидко імплементувати і не злякати постійних користувачів.
Команда
Goals
Кожен кейс на цьому курсі — це про подолання: невпевненості в собі, страху перед невідомим, іноді банальної втоми і бажання поспати. У випадку з Portmone нам довелося «подолати» ще й новорічні свята, які випали на період роботи над кейсом. Але про все по порядку.
Спочатку ми провели стейкхолдер інтерв'ю, після якого визначили цілі проєкту. Основне завдання — зробити редизайн профілю користувача на сайті Portmone. Якщо більш конкретно, то все звелося до вирішення кількох проблем.
1. Бізнес розумів, що панель навігації перенасичена і пропонує занадто багато пунктів. Ми мали змінити навігацію в профілі користувача і зменшити показник відмов.
2. Нові користувачі мають «закохатися» у систему і згодом до неї повернутися. Бо зараз частина користувачів не повертається вже після першого платежу. Тому була потреба у зміні не тільки користувацької взаємодії, але і візуальної складової.
3. Portmone — це не лише про комуналку: система пропонує більш ніж 3000 сервісів, але мало хто знає про це. Наше завдання — зробити їх більш помітними для користувачів.
Аби нам було простіше, замовник поділився своїми маркетинговими дослідженнями, презентацією з описом проблеми і базовою сіткою.
Та простіше не стало. Як вже згадувалося, кейс випав на новорічні свята, а коли всі навколо відпочивають, не так вже й просто змусити себе працювати. Потрібно було синхронізуватися, знайти зручний для всіх таймслот. Зустрічатися виходило рідко, але ті зустрічі мали крутий результат. Взагалі командна робота мотивує, змушує тебе докладати зусилля і не філонити. В команді у нас були різні точки зору, і це дозволяло поглянути на здавалося б очевидні речі під іншим кутом.
Кожен кейс на цьому курсі — це про подолання: невпевненості в собі, страху перед невідомим, іноді банальної втоми і бажання поспати. У випадку з Portmone нам довелося «подолати» ще й новорічні свята, які випали на період роботи над кейсом. Але про все по порядку.
Спочатку ми провели стейкхолдер інтерв'ю, після якого визначили цілі проєкту. Основне завдання — зробити редизайн профілю користувача на сайті Portmone. Якщо більш конкретно, то все звелося до вирішення кількох проблем.
1. Бізнес розумів, що панель навігації перенасичена і пропонує занадто багато пунктів. Ми мали змінити навігацію в профілі користувача і зменшити показник відмов.
2. Нові користувачі мають «закохатися» у систему і згодом до неї повернутися. Бо зараз частина користувачів не повертається вже після першого платежу. Тому була потреба у зміні не тільки користувацької взаємодії, але і візуальної складової.
3. Portmone — це не лише про комуналку: система пропонує більш ніж 3000 сервісів, але мало хто знає про це. Наше завдання — зробити їх більш помітними для користувачів.
Аби нам було простіше, замовник поділився своїми маркетинговими дослідженнями, презентацією з описом проблеми і базовою сіткою.
Та простіше не стало. Як вже згадувалося, кейс випав на новорічні свята, а коли всі навколо відпочивають, не так вже й просто змусити себе працювати. Потрібно було синхронізуватися, знайти зручний для всіх таймслот. Зустрічатися виходило рідко, але ті зустрічі мали крутий результат. Взагалі командна робота мотивує, змушує тебе докладати зусилля і не філонити. В команді у нас були різні точки зору, і це дозволяло поглянути на здавалося б очевидні речі під іншим кутом.
Найскладніше на старті
На першому етапі ми взагалі не розуміли, як зможемо допомогти клієнту. Portmone — це вже відлагоджена система з 120-ма тисячами регулярних користувачів. Платформа працює з 2002 року і тричі отримувала нагороду найкращого сервісу онлайн-платежів в Україні. В компанії напевне провели десятки А/Б тестувань різних гіпотез. А ми що?..
А ми тоді тільки оговталися від попереднього кейсу. Одразу зрозуміли, що підходи, які використовували там, цього разу не спрацюють. Завдання здавалося надскладним: як розібратися з продуктом, з усією його навігацією, як це все структурувати? Та Денис нас трохи заспокоїв, сказав, що все буде добре, і провів лекцію з об'єктно-орієнтованого прототипування (ООП — не плутати з програмуванням).
Опанування ООП стало, мабуть, найскладнішою частиною кейсу. Потрібно було розібрати кабінет користувача Portmone на об'єкти і визначити компоненти, які стануть будівельним матеріалом для всієї системи. Ми помітили багато проблем. Наприклад, три різних варіанти навігації або дублювання однакової інформації під різними назвами в різних розділах.
На першому етапі ми взагалі не розуміли, як зможемо допомогти клієнту. Portmone — це вже відлагоджена система з 120-ма тисячами регулярних користувачів. Платформа працює з 2002 року і тричі отримувала нагороду найкращого сервісу онлайн-платежів в Україні. В компанії напевне провели десятки А/Б тестувань різних гіпотез. А ми що?..
А ми тоді тільки оговталися від попереднього кейсу. Одразу зрозуміли, що підходи, які використовували там, цього разу не спрацюють. Завдання здавалося надскладним: як розібратися з продуктом, з усією його навігацією, як це все структурувати? Та Денис нас трохи заспокоїв, сказав, що все буде добре, і провів лекцію з об'єктно-орієнтованого прототипування (ООП — не плутати з програмуванням).
Опанування ООП стало, мабуть, найскладнішою частиною кейсу. Потрібно було розібрати кабінет користувача Portmone на об'єкти і визначити компоненти, які стануть будівельним матеріалом для всієї системи. Ми помітили багато проблем. Наприклад, три різних варіанти навігації або дублювання однакової інформації під різними назвами в різних розділах.
Об'єктна модель Portmone
Нам треба було уніфікувати продукт, щоб не плодити десятки зайвих елементів. Це має заощадити час команді розробки і забезпечити консистентність продукту.
Але тут є одна заповідь: «не нашкодь!» Бо зламати те, що будувалося 17 років, погано для карми. Виникав постійний розрив шаблону: здається, ти все розбив по класах, описав властивості, все ніби зрозуміло і правильно. Але ж ні — кілька разів доводилося все перероблювати і переосмислювати. Врешті ми розібрали кабінет користувача на 15 унікальних об'єктів, які потім візуалізували в блоках інтерфейсу за методологією БЕМ (блок-елемент-модифікатор).
Але тут є одна заповідь: «не нашкодь!» Бо зламати те, що будувалося 17 років, погано для карми. Виникав постійний розрив шаблону: здається, ти все розбив по класах, описав властивості, все ніби зрозуміло і правильно. Але ж ні — кілька разів доводилося все перероблювати і переосмислювати. Врешті ми розібрали кабінет користувача на 15 унікальних об'єктів, які потім візуалізували в блоках інтерфейсу за методологією БЕМ (блок-елемент-модифікатор).
Компоненти кабінету користувача
З шести тижнів, відведених на кейс, три ми мучилися з ООП. Здавалося, що всі інші команди давно пройшли цей етап, а ми якісь «особливі». Бувало й таке, що губилася мотивація, бо коли ти не можеш щось зрозуміти, це боляче б'є по самооцінці. Нам допомогло те, що в команді були люди з аналітичним складом розуму і досвідом створення дизайн-систем.
Навігація
Далі ми проаналізували навігаційну систему. Побачили, що деякі пункти меню втратили релевантність, деякі дублюють функціонал сторінки. Наприклад, у пункті «Підписатися на періодику» можна оформити підписку на друковані газети, журнали тощо. Нібито і корисно, але камон — в нашу диджитал-епоху ця послуга втратила популярність. Прийняли рішення перемістити цей пункт з основної панелі навігації у список сервісів. А залишити тільки ті елементи, які, згідно з дослідженнями бізнесу, використовуються найчастіше: комунальні платежі, поповнення мобільного, доставка квитанцій.
Далі ми декомпозували і перегрупували структуру усього кабінету користувача. На нинішній версії сайту було чотири типи навігації: хедер, сайдбар, випадне меню і футер. Така структура є перевантаженою для користувача і заважає йому зробити цільову дію — оплатити послуги. Ми вирішили сфокусувати увагу на основних сервісах продукту, які приносять бізнесу найбільше грошей та профіту.
Далі ми проаналізували навігаційну систему. Побачили, що деякі пункти меню втратили релевантність, деякі дублюють функціонал сторінки. Наприклад, у пункті «Підписатися на періодику» можна оформити підписку на друковані газети, журнали тощо. Нібито і корисно, але камон — в нашу диджитал-епоху ця послуга втратила популярність. Прийняли рішення перемістити цей пункт з основної панелі навігації у список сервісів. А залишити тільки ті елементи, які, згідно з дослідженнями бізнесу, використовуються найчастіше: комунальні платежі, поповнення мобільного, доставка квитанцій.
Далі ми декомпозували і перегрупували структуру усього кабінету користувача. На нинішній версії сайту було чотири типи навігації: хедер, сайдбар, випадне меню і футер. Така структура є перевантаженою для користувача і заважає йому зробити цільову дію — оплатити послуги. Ми вирішили сфокусувати увагу на основних сервісах продукту, які приносять бізнесу найбільше грошей та профіту.
До — Після
Прототип і тестування
На першому кроці прототипування ми не вносили великих змін до поточної структури сторінок, аби не відлякати постійних користувачів. Вирішили зробити дизайн легшим, зрозумілішим і з виділеним Call to Action.
На першому кроці прототипування ми не вносили великих змін до поточної структури сторінок, аби не відлякати постійних користувачів. Вирішили зробити дизайн легшим, зрозумілішим і з виділеним Call to Action.
Перший прототип
Під час тестування ми запропонували користувачам найпоширеніший флоу у Portmone — сплатити комунальні платежі. Всього тестували три різні сценарії. Результати показали, що 30% респондентів не знайшли потрібний CTA, тому не змогли довести завдання до завершення.
Результати тестування
Які висновки ми зробили після тестування: блок з пропозиціями «Що ви хочете сплатити?» є неінформативним та займає багато місця. Через це кнопку «Знайти рахунки», за допомогою якої розпочинається основний флоу взаємодії користувача, ми сховали за межами першого екрану.
Рішення
Всі попередні кроки наштовхнули нас на думку застосувати підхід SPA (Single Page App — односторінковий застосунок). Він дозволив помістити на головну сторінку найбільш популярний функціонал платіжної системи і пришвидшити процес оплати.
Попередньо бізнес виділив три важливі функції при оплаті комуналки: автоплатежі, шаблони та архів платежів. Ми розмістили їх на головному екрані і цим позбавили користувача можливості заблукати у пунктах меню. Так вдалося вирішити поставлені перед нами проблеми.
Ось основні переваги нашого дизайн-рішення.
1. Швидка імплементація: front-end і back-end розробники можуть швидко і легко провести редизайн Portmone.
2. Легкість у використанні: спрощений і зрозумілий юзерфлоу допоможе не відлякати постійних користувачів і привернути нових.
3. Сучасний UI: новітній дизайн дозволить конкурувати з іншими платіжними системами на ринку і залучити нову аудиторію.
Всі попередні кроки наштовхнули нас на думку застосувати підхід SPA (Single Page App — односторінковий застосунок). Він дозволив помістити на головну сторінку найбільш популярний функціонал платіжної системи і пришвидшити процес оплати.
Попередньо бізнес виділив три важливі функції при оплаті комуналки: автоплатежі, шаблони та архів платежів. Ми розмістили їх на головному екрані і цим позбавили користувача можливості заблукати у пунктах меню. Так вдалося вирішити поставлені перед нами проблеми.
Ось основні переваги нашого дизайн-рішення.
1. Швидка імплементація: front-end і back-end розробники можуть швидко і легко провести редизайн Portmone.
2. Легкість у використанні: спрощений і зрозумілий юзерфлоу допоможе не відлякати постійних користувачів і привернути нових.
3. Сучасний UI: новітній дизайн дозволить конкурувати з іншими платіжними системами на ринку і залучити нову аудиторію.
Фінальне дизайн-рішення
Дизайн-система
Одне з наших рішень має допомогти бізнесу заощадити багато часу і ресурсів на етапі розробки. Це рішення — створення дизайн-системи. Завдяки набору елементів можна створювати нові блоки сторінки, ніби з деталей конструктора. Так виходить швидше, а UI системи стає більш консистентним.
Одне з наших рішень має допомогти бізнесу заощадити багато часу і ресурсів на етапі розробки. Це рішення — створення дизайн-системи. Завдяки набору елементів можна створювати нові блоки сторінки, ніби з деталей конструктора. Так виходить швидше, а UI системи стає більш консистентним.
Елементи дизайн-системи
Час швидко збігав, днів до захисту лишалося все менше, але ми все ж встигли зробити мобільну версію кабінету користувача.
Прототип мобільної версії сайту
Підсумки
Чи не головний урок кейсу — готуйте презентацію свого рішення заздалегідь. Можна починати, навіть коли ще не всі скріни домальовані. Бо слабенька презентація здатна потопити найсильніші рішення. Нам не вистачило буквально двох-трьох днів, щоб відшліфувати гіпотези та аргументи.
Може, через це, а може з інших причин клієнт не обрав наше рішення. Але йому однозначно сподобався підхід — те, що дизайн можна легко і безболісно імплементувати, не злякавши постійних користувачів.
Та хоч там як, кейс залишив позитивні враження. Круто, коли на практиці застосовуєш методи та інструменти, про які дізнався на курсі.
Ми отримали можливість подивитися на продукт системно, з архітектурної сторони. Розкласти дизайн на об'єкти та класи, створити компоненти, зрозуміти усю логіку складної системи та зробити її легкою. Коли виконаєш все це, вкотре розумієш, що дизайнер — це не тільки про пікселі та красу.
І ще одна порада — думайте глибше! Ставте запитання: як буде працювати фіча у корнер кейсах, що буде зі сторінкою, коли на неї потрапить новий юзер? Про такі речі варто думати одразу, бо вони можуть зруйнувати усі ваші повітряні замки.
Чи не головний урок кейсу — готуйте презентацію свого рішення заздалегідь. Можна починати, навіть коли ще не всі скріни домальовані. Бо слабенька презентація здатна потопити найсильніші рішення. Нам не вистачило буквально двох-трьох днів, щоб відшліфувати гіпотези та аргументи.
Може, через це, а може з інших причин клієнт не обрав наше рішення. Але йому однозначно сподобався підхід — те, що дизайн можна легко і безболісно імплементувати, не злякавши постійних користувачів.
Та хоч там як, кейс залишив позитивні враження. Круто, коли на практиці застосовуєш методи та інструменти, про які дізнався на курсі.
Ми отримали можливість подивитися на продукт системно, з архітектурної сторони. Розкласти дизайн на об'єкти та класи, створити компоненти, зрозуміти усю логіку складної системи та зробити її легкою. Коли виконаєш все це, вкотре розумієш, що дизайнер — це не тільки про пікселі та красу.
І ще одна порада — думайте глибше! Ставте запитання: як буде працювати фіча у корнер кейсах, що буде зі сторінкою, коли на неї потрапить новий юзер? Про такі речі варто думати одразу, бо вони можуть зруйнувати усі ваші повітряні замки.
Автор: Арсеній Овсянніков
Courses
Сподобалась стаття?
