Разработчик, подумай о туристах, которые тоже люди! Со всей любовью и уважением к городу и его жителям.
Делимся очередным кейсом из жизни. Наш сотрудник, часто бывающий в Москве, впервые за долгое время попал в Санкт-Петербург. В основной столице для проезда на транспорте есть карта Тройка, с которой все удобно и понятно. А в северной столице существует аналог под названием Подорожник. Знакомая схема, аналогичные услуги, что же могло пойти не так?
В метро стоят терминалы по продаже Подорожников. Устройства медленные и очень своеобразные. Представьте, что вы турист, который приехал в город на пару-тройку дней и вам нужно купить карту на несколько поездок. Аппарат без вопросов ее продает. Но ведь нужно как-то пополнить? Если сначала вставить карту, то терминал предложит купить месячный абонемент, не дав других вариантов. Но нам же нужно всего несколько поездок! В итоге нужная опция находится только методом перебора. Кроме того, аппарат тормозит, а кнопки «Далее» и «Отмена» на разных экранах расположены в одном и том же месте, поэтому, пока терминал «думает», пользователь успевает случайно отменить операцию, потому что не подгрузилась кнопка.
Кроме того, туристу сложно понять, что же именно предлагает аппарат. «Пополнить карту ПБ метрополитена». Но что такое «ПБ»? «Пополнить единый электронный билет». Но мы же купили карту «Подорожник»? В итоге какая-то по счету итерация общения с автоматом все-таки дает возможность купить нужные нам поездки. Но вот потраченных на эту покупку нервов, он уже не вернет.
Всем разработчикам систем хочется напомнить, что, зачастую, недостаточно сделать просто корректно работающее приложение. Важно подумать о тех пользователях, для которых это приложение делалось, и как именно сервис ими будет использоваться, в том числе, обращая внимание на все сценарии работы с устройством или программой.
Сергей Москвин
Директор QA Service Lab