⌘57. Дивитись на проблему з боку

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

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

Як же бути? Я завжди використовую один із двох варіантів:

1. Створюю уявний експеримент, абстрагуюся від того, що знаю і намагаюся діяти, як користувач, для якого відвідування сайту (наприклад) є першим у його житті.

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

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

Список правок я передаю розробникам і після впровадження повторюю весь процес ще раз.

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

Отримавши фідбек, я перевіряю всі пункти на собі, оформлюю трохи більш зрозумілою мовою і, знову ж таки, передаю у відділ розробки.

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