кейси
Інтерфейс для ЛУН Місто: де в Києві справді комфортно жити?
Пола Жмур, студентка курсу Product Interface Design Professium, розповіла про пригоди під час кейсу для ЛУН Місто. Читайте про те, як команда навчилася знаходити користувачів та інтерв'ювати їх, складати джоби, прототипувати, тестувати, і, звісно ж, помилятися.
Яку задачу вирішували для проєкту

Завдання, яке ЛУН Місто вирішує особисто для кожного користувача — розповісти, де в Києві справді жити добре.

В основі сайту — карта Києва і передмістя з показниками, які так чи інакше впливають на комфорт: рівень озеленення, шуму, результати ЗНО, черга в дитячі садочки. В активі проєкту вже понад двадцять проведених досліджень, але всі вони презентовані статичними картинками й чекають свого місця на карті.

Lead Product Designer у Portmone.com
Ось так виглядає карта, коли вмикаєш усі фільтри. Нашарування даних не допомагає з оцінкою комфорту, а тільки ускладнює її.
Аня Денисенко, кураторка проєкту зі сторони ЛУН, прийшла до нас із таким завданням: спростити презентацію даних в інтерфейсі. Щоб зручно було користуватися картою і фільтрами, щоб це могло бути масштабованим (адже кількість даних постійно зростає). Від неї ми дізналися, що на старті проєкту ніяких користувальницьких досліджень чи тестувань не проводилося, даних аналітики немає, весь проєкт рухається внаслідок можливості дістати ті чи інші дані, а також на основі реакцій і запитів користувачів під постами в Facebook.

«Покращити інтерфейс» — таке собі завдання для продуктових дизайнерів. Тому ми вирішили подивитися на проблему ширше:

  • Дослідити, що для людей означає «комфорт в місті».
  • Дізнатися, як люди оцінюють комфорт зараз.
  • Протестувати поточний інструмент, знайти проблеми в інтерфейсі та запропонувати краще рішення.
Плануємо роботу

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

На початку курсу ми познайомилися з Double Diamond — методологією, за якою нам потрібно спочатку знайти всі складові проблеми, а потім визначити ключові. Далі — наштормити всі можливі варіанти вирішення і вибрати ті, які найбільш оптимальні за термінами й можливостям впровадження.
Наш блискучий план по Double Diamond
План дій:

  • Якісне дослідження (пошук респондентів для глибинних інтерв'ю, інтерв'ювання, аналіз даних).
  • Визначення основних проблем, з якими працюємо (пошук спільних для респондентів болей, радощів і завдань, відсіювання їх через двофакторний аналіз).
  • Шторминг ідей щодо зміни інтерфейсу.
  • Прототипування, тестування ідей, ітеративні покращення.
  • Підготовка до презентації.
Блискучий план, вогонь в очах, очікування геніальних ідей, але ... все як у житті.
Де взяти людей для інтерв'ю?

Для якісного дослідження нам потрібні респонденти. На брифі з клієнтом ми почули, що ЦА проєкту — всі жителі Києва. Але це занадто широка характеристика для виявлення схожих болей і потреб. Так можна орієнтуватися і на бабусю, яка 20 років продає жетони в метро, і на студента-першокурсника, який щотижня возить консерви з дому в гуртожиток. Їх розуміння міського комфорту може бути кардинально різним. Не звівши ЦА до однорідної характеристики, ми отримаємо купу даних, які не знатимемо як пріоритезувати.

Нам було важливо знайти тих, кому гостро стояло питання пошуку комфортного місця. У цьому нам допомогли Google-анкета, Facebook і робочі чати.

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

Ми отримали понад 150 відповідей і три десятки респондентів, які недавно переїжджали (знімали або купували житло) в Києві й були готові поговорити.

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

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

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

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

Отримавши на руки понад десяток інтерв'ю, ми зрозуміли, що починається найцікавіше — пошук потреб, які потрібно опрацювати в першу чергу. До цього моменту на курсі ми встигли помацати три методології й перед нами стояв вибір: Customer Journey Map, Value Proposition Canvas або Jobs To Be Done. CJM відкинули відразу, тому що шляхи користувачів в пошуку комфорту були занадто різними та неоднорідними. Вибираючи між VPC і JTBD зупинилися на другий методології.

Ми пішли складним шляхом і вибрали Jobs To Be Done. Нам хотілося командою попрактикуватися в розборі даних на болі, радості й завдання. Та повчитися формувати джоби.

Щоб уникнути суб'єктивного трактування даних, ми розділилися на групи по 2 — 3 людини й методично розбирали кожне інтерв'ю.
Стікери в Miro з болями, радостями й задачами кожного респондента.
Перефразовуючи Толстого буде доречно сказати, що всі щасливі користувачі щасливі однаково, а нещасні по-своєму.
Попри те, болі або потреби користувачів досить специфічні, їх все одно можна було згрупувати за певними категоріями, які й формують той самий запит на комфорт. У нас вийшли такі категорії: Переміщення, Інфраструктура, Злочинність, Громадський транспорт, Контингент, Забудова, Озеленення і т.і.

Далі ми всі разом почали опрацьовувати джоби (задачі) користувачів по JTBD і складати їх у виділені категорії.

Хотіли складніше — отримайте-розпишіться. Етап опрацювання джобів став найбільш неоднозначним. Через те, що конкретне інтерв'ю знав і пам'ятав лише один учасник команди, було багато труднощів з «правильним» формулюванням задачі. З одного болю ми могли сформувати по три-чотири трактування джоба і довго обговорювали кожний, щоб обрати найбільш вірогідний варіант.
Джоби, згруповані по категоріях: Переміщення, Інфраструктура, Злочинність, Громадський транспорт, Контингент, Забудова, Озеленення та інші.
Наступним етапом був вибір джобів для опрацювання в продукті. Ми застосували метод двофакторного аналізу: відсортували джоби за важливістю для користувача і рівнем їх вирішення іншими інструментами.
Фокусуємося на джобах, які важливі, але середньо або слабо закриті.
Ідеї

У нас були виділені групи потреб (джоби), дані юзабіліті-тестування, сильно гарячі дедлайни й фокус на двох завданнях:

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

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

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

Ми швидко зробили два прототипи й протестували з людьми, які раніше відгукнулися на нашу форму в Фейсбуці.
Один з перших варіантів інтерфейсу.
Обидва рішення мали недоліки:

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

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

Людина визначає, які критерії важливі саме йому, а система формує оцінку і висновок — круто тут чи ні. Рішення для ледачих. А хіба бувають інші користувачі?

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

Для того, щоб презентація була більш емоційною, а сам продукт живим, ми придумали історію, в якій наш бізнес став супергероєм, який рятує жителів міста від незнання і некомфортного життя. Глядачам зайшло, і подача кейса отримала окремий відгук від команди ЛУН Місто.
Слайд з презентації клієнту.
Сам інтерфейс ми презентували через деталізований клікабельний прототип, рухаючись макетами, як живим продуктом.

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

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

  1. Створення дворівневої навігації й перенесення вже проведених досліджень на карту.
  2. Розрахунок скоринговою системою рейтингу районів за наявними показниками й створення 2-го рівня карти.
  3. Наповнення ресурсу новими дослідженнями й додавання їх в систему прорахунку комфорту
    Очікувані результати:

    • Зростання користувачів шляхом «сарафанного радіо»: обговорення інформації за кавою на роботі, фейсбучні шери й коментарі, сімейні вивчення локацій для переїзду. Якщо продукт здатний дати мені унікальні дані за моїми особистими уподобаннями, погані чи хороші — я точно захочу поділитися цим.

    • Збільшення кількості часу, що користувач проводить на сайті. Більше досліджень, більше динаміки в показниках — більше залучення.
    Чого навчилися?

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

    1. Потрібно штормити. Ми пропустили цей етап і сконцентрувалися на рішеннях, які лежали на поверхні. Це не означає, що вони погані, але це означає, що ми не спробували копати глибше.

    2. Тестувати. Навіть коли горять дедлайни, не забивати на зайву ітерацію тестування і не покладатися на власний досвід: «Це буде зручно». У мене особисто залишилося відчуття, що наше рішення не до кінця перевірено на користувачах.

    3. Пропонувати ітерації. Розуміючи, що наше рішення не маленьке і не швидке, ми відразу ж продумали етапи його імплементації. Адже так живе продукт — декомпозицією великих завдань й ітераційними покращеннями.

    4. Пам'ятати про UI. Якими б ресьорчем і тестуваннями не був підкріплений дизайн, його зовнішній вигляд грає не останню роль. Клієнт бачить картинку вперше і її краса і рівень опрацювання можуть стати вагомим аргументом в «купівлі» рішення.

      І, здається, найважливіше.

    5. Давати більше свободи й довіряти іншим. Після кейсу я зробила форму, в якій попросила хлопців та дівчат дати невеликий фідбек про роботу зі мною. Так, я дізналася, що я хороша, ідейна й ініціативна лідерка, але часом моя активність «забивала» інших і не давала їм повною мірою проявляти себе. Ок, взяла в роботу.
    Courses
    Сподобалась стаття?