Момент, когда прототип наконец выглядит законченным, часто воспринимается командой как естественная точка перехода к разработке. Экраны собраны, переходы настроены, основные действия пользователя можно прокликать от начала до конца. Кажется, что следующий логичный шаг — передать макеты разработчикам и начинать реализацию.
Тестирование прототипа позволяет проверить продуктовые решения до того, как команда вложит время и бюджет в полноценную разработку. На этом этапе еще относительно легко изменить структуру экрана, перестроить навигацию, переименовать непонятный элемент или полностью пересмотреть пользовательский сценарий. После разработки те же изменения обычно обходятся дороже: затрагивают дизайн, код, аналитику, документацию и повторное тестирование.
Когда на тестировании пользователь останавливается перед экраном, долго ищет нужную кнопку или прямо говорит: «Я не понимаю, что здесь нужно делать», первая реакция команды часто предсказуема: с прототипом что-то не так. Хочется сразу изменить подпись, переставить элементы или сделать нужную кнопку заметнее. Но в своей работе с исследованиями я советую не торопиться с такими выводами.
Мобильный прототип легко открыть на ноутбуке, кликать по нему мышкой и считать, что сценарий уже проверен. Но такое тестирование показывает только часть картины. На смартфоне пользователь взаимодействует с интерфейсом иначе: держит устройство одной рукой, промахивается по небольшим элементам, использует жесты, прокручивает экран большим пальцем и часто действует в условиях, далеких от спокойной работы за столом.
Когда у команды есть два варианта прототипа, выбор часто происходит быстрее, чем его успевают проверить. Дизайнер аргументирует решение привычными паттернами, продакт смотрит на бизнес-логику, разработчики оценивают сложность реализации, а руководитель может предпочесть вариант, который кажется ему понятнее. В итоге обсуждение постепенно сводится к вопросу: «Какой вариант нам нравится больше?»
Одна из дорогих ошибок в работе над интерфейсом — принять логичное для команды решение за очевидное для пользователя. Дизайнер видит знакомую структуру экрана, продакт понимает назначение каждой кнопки, разработчик знает, что произойдет после клика. Пользователь приходит без этого контекста. Он может не заметить нужное действие, иначе интерпретировать название раздела или выбрать маршрут, который команда вообще не рассматривала.