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

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

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

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

  1. Створюю уявний експеримент, абстрагуюся від того, що знаю і намагаюся діяти, як користувач, для якого відвідування сайту (наприклад) є першим у його житті.
    Уявляю, як він сюди потрапив — що написав у пошуку або на який банер натиснув, чому зробив це і що очікував побачити.
    По ходу справи я проходжу весь процес до кінця — до відправки заявки або купівлі товару, і записую кожен пункт, де мені захотілося закрити сайт, де я не знайшов відповіді на потрібне питання, де мені захотілося зв’язатися з сапортом, де щось вантажилося повільніше чим мені хотілося або зображалося не те, чого я очікував.
    Список правок я передаю розробникам і після впровадження повторюю весь процес ще раз.
  1. Прошу когось зі знайомих, не занурених у процес і, звичайно, не працюючих зі мною в одній компанії, пройти весь такий самий шлях і дати мені свій фідбек. Такий результат, швидше за все, буде «чистішим», але, при цьому, значно довшим.
    Отримавши фідбек, я перевіряю всі пункти на собі, оформлюю трохи більш зрозумілою мовою і, знову ж таки, передаю у відділ розробки.

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

Підписатися у Telegram

Надіслати
 5   1 міс   Sad But True   лайфхаки