Там де я мешкаю, зазвичай приходить два щорічні рахунки на оплату води. Перший за постачання води, другий за водовідведення. Рахунок за водовідведення за стандартним тарифом, і здається більшість людей налаштували щомісячний автоматичний платіж. Це з розряду «встановив і забув». Бути занадто захопленим тут важко чи не так?
Нещодавно я отримав листа з водоканала, що переконував мене підписатись на їхній онлайн портал, щоб я міг отримувати рахунки в електронному вигляді. Я навіть можу собі уявити історію користувача в якій описувалось наступне: «Як користувач, я хочу отримати доступ до своєї річної виписки онлайн, щоб знати, скільки з мене стягнуть».
Отже, для мене це щось типу ілюзії. Я точно не потребую ще одного додатку, я точно не потребую ще одного рахунку і пароля. Для рахунків, що потребують моніторінгу раз на рік, є велика ймовірність того, що я забуду пароль коли його буде потрібно вводити, якщо бути до кінця чесним, я все одно переглядаю близько 10% виписки (я дивлюся на суму щомісячного платежу, а потім заповнюю виписку).
Оцифрування з метою
Я не стверджую, що додатки не мають користі, вони беззаперечно корисні при правильному контексті. Я використовую онлайн банкінг постійно, що економить мій час. Однак, мені цікаво скільки користувачів водоканал опитав перед тим як створив додаток. А також цікаво чи визначали вони, чи справді клієнти хотіли цього чи ні?
З іншого боку, ця ініціатива могла йти не від кінцевого користувача. Можливо, директору відділу обслуговування клієнтів поставлена задача зменшити витрати. Одним з можливих шляхів було б зменшити кількість листів і звітів, які друкуються. Кожна заява коштує грошей: папір, друк, конверт, поштові витрати плюс витрати на обслуговування цього процесу.
Та коли зміни продиктовані виключно внутрішніми міркуваннями економії, з незначною або нульовою взаємодією з клієнтом, чи буде коректно писати користувацьку історію з точки зору клієнта? Клієнта, з яким не консультувалися? Існує небезпека, що ми переходимо одразу до рішення, а без взаємодії з клієнтом це рішення може мати дуже низький рівень прийняття.
Розуміти реальні рушійні сили
Отже, якщо рушійною силою є скорочення витрат, так і скажіть. Замість того, щоб одразу переходити до історії користувача або набору вимог, більш корисною відправною точкою буде розуміння конкретних результатів, яких ви прагнете досягти. У цьому випадку це може бути
«Зменшення витрат на відправлення та обробку вихідної кореспонденції на X%».
Потім корисно зрозуміти будь-які обмеження. Ймовірно, існує нормативна вимога щодо щорічного «звіту» (хоча, що таке «звіт», може бути прописано в нормативних документах, а може і не бути). Маючи це на увазі, можна поставити під сумнів існуючу практику.
Потім, зрозумівши, чому зміни необхідні в першу чергу, ми можемо почати працювати з командою зацікавлених сторін (включаючи клієнтів або представників клієнтів), щоб з’ясувати, як цього можна досягти, що в ідеалі також принесе їм користь. Або, принаймні, способи, з якими вони зможуть змиритися.
Це може створити дуже різний набір рішень. Наприклад, можна запропонувати рішення, коли клієнт отримує невелику знижку на перший рік, коли він обирає електронні виписки. Вони отримуватимуть SMS-повідомлення з ключовими деталями (суми платежів, дати) та електронного листа з нагадуванням про те, що інформація про виписки доступна, якщо вони хочуть її отримати. Це лише один з варіантів, який би спрацював би для мене, але я є лише прикладом. Важливо отримати думки від різних груп зацікавлених сторін.
Розуміти розмаїття
Коли ми думаємо про такі зміни, важливо також враховувати тих, хто не може взаємодіяти з організаціями в цифровому форматі. На це може бути багато причин, тому важливо думати про доступність не лише з точки зору «як ми можемо зробити цифрове рішення доступним», а й «які у нас є варіанти нецифрової взаємодії». Важливо розуміти різноманітність людей, їхні потреби та вподобання.
Насамкінець, яке б остаточне рішення не було узгоджене, якщо почати з розуміння бажаних результатів (і бути прозорим, якщо основною метою є економія коштів), це призведе до ширшої розмови. Важливо уникати поспішних рішень за відсутності такого розуміння!
Оригінальна стаття – User Stories Without Users: The Pitfalls of Assumption-Driven Design від Adrian Reed, переклад – Клавдія Хадухіна, ревью – Іван Вільчавський. Зображення згенероване DALL-E у ChatGPT.