День 22 февраля 2014 года запомнится мне надолго. И не только потому, что это канун Дня защитника Отечества: 22 февраля я впервые протестировала мобильное приложение в роли респондента.
В бизнес-школе RMA завершается курс по разработке мобильных приложений. Одно из заключительных занятий мы провели в офисе USABILITYLAB, где тестировали прототипы, нарисованные студентом нашей группы. Напомню предысторию: заказчик хочет создать приложение, которое я опишу ниже, слушатели Британской высшей школы дизайна разрабатывают брендинг продукта, а мы, студенты И-14, продумываем архитектуру приложения и рисуем прототипы. Одним словом, тренируемся применять в работе то, чему нас научили.
Теперь вкратце расскажу о приложении под тестовым названием «Кибермозг». Целевая аудитория — руководители бизнеса; задача продукта — получив от бизнесмена описание текущей проблемы, предложить наиболее подходящее решение. Например, у директора строительной фирмы есть несколько грузовиков, а с ними связана определенная проблема: неоправданно быстро расходуется топливо. Какие причины могут вызывать подобную проблему? Отсутствие крышек на бензобаках? Отверстия, через которые происходит утечка? Низкая зарплата водителей, которые сливают и перепродают топливо? По замыслу заказчика, руководитель должен отметить одну или несколько потенциальных причин, а в ответ система, обработав данные, вычислит оптимальное решение. Сценарий с повышенным расходом топлива мы проработали в ходе тестирования. Не вдаваясь в тонкости, отмечу, что лично мне концепция приложения показалась странной. Но скажите, кто из нас не работал с удивительными заказчиками? Уверена, что каждому есть что вспомнить. :-)
Так сложилось, что до занятия я не располагала информацией о приложении и не видела прототипов, а потому не принимала участие в разработке. Впрочем, это оказалось даже кстати, и меня выбрали респондентом — то есть потенциальным пользователем. Приняв участие в настоящем тестировании, я хочу поделиться наблюдениями. К слову, я уже описывала процедуру тестирования вебсайтов в компании USABILITYLAB и в этот раз принципиальных отличий не обнаружила. Если вы не знакомы с темой, рекомендую для начала прочитать небольшую, но интересную статью с картинками. :-)
На занятии я убедилась, что тестировать продукты на этапе разработки просто необходимо. Восприятие разработчика не совпадает с тем, что думает о приложении конечный пользователь. Разработчики принадлежат к продвинутым пользователям компьютера или телефона; им изначально известна и понятна идея продукта — как он должен выглядеть, какие функции выполнять. Они точно знают последовательность действий в открытом приложении и помнят, какие кнопки в данный момент нажимать не следует. Пользователи ничего этого не знают — тем они и ценны. У них совершенно другое восприятие, другая логика, а значит, они могут кликать по ссылкам и кнопкам в произвольном порядке. Выбранная разработчиком приложения последовательность отображения окон может даже оказаться для пользователя неприемлемой. Понять это и исправить ошибки без тестирования невозможно. Предлагая потребителю продукт, не прошедший должную проверку, разработчик уже не сумеет вернуть тех, кто останется недоволен приложением во время пробного запуска. Понимать, почему пользователь может уйти, очень важно.
Не секрет, что после долгой работы над проектом глаз «замыливается», и половину недочетов уже не замечаешь. Тестирование помогает обнаружить все скрытые или «забытые» дефекты, потому что респондент пользуется незнакомым продуктом впервые.
Хорошо, что тестирование можно проводить и с настоящими прототипами, и с рисунками от руки на бумаге. Важная деталь: на прототипах необходимо размещать финальные версии текстов. Несмотря на предостережения, многие разработчики забывают об этом правиле. Респондент должен видеть то, что ожидает его в готовом продукте, иначе возникнут лишние вопросы и пояснения, которые во время тестирования крайне нежелательны.
Важно, чтобы респондент тестировал продукт по заранее заданному сценарию. К примеру, мне предстояло решить проблему с топливом: внести ключевые данные в систему, получить от нее решение и делегировать задачу подчиненным. Если нет заранее проработанного сценария, тестирования получится скомканным.
Побывав в роли респондента я поняла, как важно комментировать каждую мелочь, каждое несоответствие. Пусть разработчики не обижаются — ведь критика дает им возможность улучшить продукт.
В ходе тестирования многое зависит от модератора, который общается с респондентом. Мне повезло — моим модератором оказалась Юля Суворова, которая ранее читала у нас лекции. Юля работает в USABILITYLAB и умеет получить нужную информацию от респондента с помощью нейтральных вопросов: «Что было сложно/легко на этом этапе?», «Что ты ожидаешь увидеть дальше?», «Что особенно понравилось?», «Что вызвало непонимание?», «Что могло бы облегчить задачу?» и т.д. Эти общие вопросы не содержат отвлекающей конкретики или вариантов ответа; я не чувствовала рамок и говорила только то, что думаю и чувствую на самом деле.
Таким я увидела тестирование продукта, побывав в роли респондента. Если вы все еще сомневаетесь в том, что тестирование — это важнейший инструмент разработчика, примите участие в тестировании как заказчик или респондент. Я уверена, что от ваших сомнений не останется и следа. Удачи в работе!
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.