Дмитрий Мелентьев, глава отдела проектирования компании Paneglif, специально для блога Нетологии написал колонку о том, как тестировать прототип при разработке программного продукта.

В процессе разработки мы часто сталкиваемся с такой дилеммой: как сделать продукт хорошо и быстро, но при этом интересным и понятным и пользователям, и заказчикам. Никому не хочется, чтобы сыпались миллионы одинаковых вопросов о том, как это вообще работает.

Рецепт есть: тестировать продукт перед выходом на рынок.

Программа обучения: «Курс Python: программирование на каждый день и сверхбыстрое прототипирование»

Конечно, можно тестировать и прямо перед самым релизом. Так делают многие компании: выпускают «бету», смотрят на реакцию, собирают фидбэк, потом правят баги. Хорошая практика, но бывает так, что пользователи не понимают всю основную функциональность, а не просто интерфейсные мелочи. И получается, что нужно всё перекроить, всё переделать. Или написать огромный мануал для пользователей, который никто, кроме конкурирующих разработчиков, читать не будет.

Поэтому нужно тестировать не в конце разработки продукта, а намного раньше, может даже в начале.

Тестирование прототипа поможет обмануть время и устранить глобальные проблемы в самом начале разработки.

Нам всегда хочется избежать тестирования прототипов, прикинувшись овощем. Зачем тестировать, если и так «всё понятно»? Это ведь займёт время разработки продукта и ещё добавит организационных проблем — тот же подбор людей на тестирование чего стоит. И помещение нужно где-то взять тихое, и еще быть добрым со всеми респондентами, даже когда они, мягко говоря, несколько не ориентируются в происходящем. Кажется, что можно вычеркнуть этот небольшой «эпизод», сберечь ресурсы, и никто не заметит даже. И всё будет хорошо!

Но так не работает.

В реальности лучше потратить 30 минут на тестирование прототипа на пользователях, чем сделать дизайн, сверстать, запрограммировать, а потом обнаружить, что нужно все [censored] переделывать!

Пусть даже респондентами будут сотрудники компании, главное, не те, что отвечают за дизайн продукта.

Есть несколько проверенных временем и опытом способов тестировать продукт: начиная с этапа, когда он существует только в виде набросков, и заканчивая тестированием прототипа на пользователях, которые будут думать, что это уже готовый сайт в работе, и никакой не прототип. Иногда оно так и есть, правда.

Бумажный прототип

На бумаге идеально тестировать концепты, когда есть доступ к целевой аудитории и несколько человек для проведения исследования. Лучше всего тестировать сложные сценарии с множеством экранов, миллионом кнопок — в общем, что-то такое, что можно аналогично протестировать только на готовом продукте.

Да, прототип будет очень далек до реального результата, но зато у респондентов не будет возникать вопросов: «почему фотка не моя», «почему я нажал на картинку кроссовок, а появился ремень», «почему нет красивой анимации у этого окошка», «почему скролл не двигается», «почему тут кнопки кривые» и т. д.

Все понимают, что это бумага, и не возникает странных вопросов по поводу её интерактивности. Да, не очень похоже на вылизанный конечный продукт, но позволяет выявить громадные косяки в функциональности, взаимодействии с интерактивными элементами, навигации по интерфейсным решениям и экранам, и в понимании значений кнопок.

Из опыта

Однажды делали проект единого дизайна сайта муниципальных округов. Сначала провели исследования, чтобы понять, что можно размещать на сайте, что нельзя. Затем определили, что будет важно посетителям, а что нет, но по закону обязательно должно быть на сайте.

Сделали прототипы на бумаге: все экраны и окна. И провели тестирование на бумаге, с тремя участниками тестирования с нашей стороны:

один «робот»,
один модератор,
один наблюдатель.

Модератор предлагает решить сценарий, ведёт респондента, наблюдатель внимательно следит за респондентом, записывает свои наблюдения и молчит, «робот» подкладывает нужные листочки с интерфейсами, молчит и не проявляет никаких эмоций (работа у робота такая).

Вначале нам казалось, что респонденты не поймут этот вид прототипа. Сложно представить депутата, «кликающего» на бумажные кнопки, листающего бумажные списки и карты.

Но внезапно всё пошло хорошо. Пользователи кликали прототипные кнопки, скроллили страницу, переходили по вкладкам и искали информацию в поиске. То есть действительно «работали» с бумажным прототипом. Да, немного непривычный, но вполне рабочий процесс.

Первый плюс в том, что нарисовать бумажный прототип можно за 3 часа, а вот спроектировать прототип в программе — это минимум день. А то и два. Потом понадобится вставлять контент, выравнивать всё, готовить под тестирование.

Второй плюс: если во время тестирования что-то не так «работает», на бумаге это быстро исправляется карандашом и ластиком — и можно тестировать дальше. И интернет для этого не нужен.

Кроме того, у людей не возникало отторжения, непонимания или негатива на такое тестирование. Всё было чётко и по делу. У нас получилось выявить немало косяков в навигации и взаимодействии пользователя с сайтом.

Интерактивные прототипы в мелкой детализации

С помощью интерактивных прототипов хорошо тестировать логику, особенно простую, а также ожидания пользователей. Конечно, можно взяться и за сложную навигацию, но придется потрудиться с количеством и качеством экранов. Респондент зачастую не воспринимает интерактивный прототип как прототип, поэтому ему приходится постоянно об этом напоминать.

Для чего плохо подходят такие прототипы:

для тестирования сложной логики с серьезными скриптами и анимацией;
для оценки визуального дизайна, о котором не выскажется разве что самый ленивый респондент.

Контент в таких прототипах должен быть максимально приближен к реальному.

В интерактивных прототипах не должно быть Lorem Ipsum, стандартных картинок с горами Axure и перечеркнутых прямоугольников.

Такое наполнение плохо воспринимается респондентом, который часто забывает, что это просто прототип для тестирования логики, и зацикливается на наполнении и визуальном оформлении.

Так делать не стоит. Да и зачем, если очень просто найти «рыбу» по теме:

взять текст на fishtext.ru;
скачать картинки с Яндекс.Картинки;
поставить стандартные иконки Bootstrap;
разместить фотографии пользователей из поиска по людям ВКонтакте;
написать максимально реальные заголовки, чтобы потом не оказалось, что они не входят в ширину экрана.

Есть мнение, что такие прототипы стоит делать черно-белыми. И да, и нет. Да, не стоит делать в интерактивном прототипе цветовые акценты на нужных вам элементах, так как это неверно с точки зрения реальности, когда таких акцентов уже не будет. И всё же не всегда можно обойтись черно-белым прототипом. Если, например, предполагается картинная галерея и акцент на картинах, то лучше сразу делать прототип похожим на реальность, а изображения взять из поиска. Так сразу будет понятно, что это за прототип и зачем он нужен.

Интерактивные прототипы идеально тестировать на целевой аудитории. Можно по скайпу, многие прототипы беспроблемно расшариваются. Пользователь включит трансляцию экрана, а вы сможете наблюдать за его действиями.

Если невозможно найти людей из ЦА, и при этом не требуется проверять слишком сложный прототип, сделайте «коридорное тестирование». Возьмите простых сотрудников компании, которые похожи на ЦА. Главное в такой ситуации — не брать тех, кто идеально знает весь продукт или непосредственно участвует в разработке.

Не все специалисты согласны с «коридорным» подходом, аргументируя это тем, что выборка не представляет целевую аудиторию. Но я зуб даю, что лучше так, чем вообще без тестирования: часто всплывают глупые интерфейсные ошибки, которые сам ни за что не увидишь. Ни за что!

Тестирование цветного прототипа в программах типа Axure

Тут всё достаточно просто. Дизайнер делает красивый интерфейс, в котором вы размечаете области, при взаимодействии с которыми должно что-то происходить. Обычно это просто «on click» или «on move». Можно, конечно, поколдовать с резаком и вырезать различные элементы, но это слишком долго. Хотя есть и такие перфекционисты.

Вся эта красота делается интерактивной и тестируется на пользователях: насколько быстро расставленные вами цветовые акценты позволяют пользователю найти нужные элементы. Респондент может проговаривать действия вслух, а вам нужно просто дождаться, пока он сделает нужное действие. Или не дождаться и уйти плакать — если вы дизайнер. А если вы не дизайнер, то ваша задача — отправить замечания дизайнеру.

Тестируем на целевой аудитории, можно по Скайпу. Есть небольшой нюанс: надо постоянно напоминать, что это прототип. Постоянно! Потому что такой прототип уж слишком похож на реальность. Кстати, в нем уже не место бессмысленной «рыбе»: нужны нормальные тексты, картинки, иконки. Можно взять их из интернета, только помните про правообладателей.

Если респонденты допускают невообразимые логические ошибки, значит, либо дизайнер сделал реально плохое решение, либо вы очень плохо протестировали прототип на предыдущем этапе.

Такое тестирование помогает оценить:

насколько конкретный элемент, который ранее был, например, большой кнопкой, а сейчас стал красивеньким тонким баром, понятен пользователю;
акценты и видимость всех важных элементов дизайна.

Если пользователь не замечает нужные элемент или кликает почём зря — значит, нужно править.

Учтите, что во время тестирования UI- или графический дизайнер, который это всё делал, должен молчать, а лучше вообще быть далеко от респондентов. Если рядом, то только с выражением «poker face». Ему будет сложно, он периодически будет хвататься то за топор, то за верёвку с мылом, так что лучше всего его держать чуть в стороне от самого процесса тестирования дизайна на пользователе.

Тестирование со скриптами, или MVP-тестирование на alfa-версии продукта

Всё работает как нужно, но пока вместо 1 млрд пользователей у вас 5 человек — друзей проекта, вместо базы в 5 млн SKU у вас пока 1 база на 100 товаров, а вместо выделенных серверов на Амазоне, виртуальный хостинг на 1gb.ru. Но всё работает как нужно.

Всё работает как нужно. Это главное условие!

Теперь берёте пользователя из целевой аудитории (не нужно брать программистов из соседнего помещения), даёте ему цель, и пусть он её выполняет. Всё должно пройти идеально. Мелкие баги, которые мешают реальному пользователю прийти к цели быстро и эффективно, записываем, а потом правим.

Ещё раз для тех, кто хитрый. Тестировать надо на ЦА! Не тестируйте свой продукт на работниках столовой у вас в офисе, если ЦА — это девушки с «Барвиха Лухари Вилаж».

Если очень нужно проверить сложную дорогую функциональность, которую разрабатывать минимум год, то сделайте быстрое решение и проверяйте его.

Главное, чтобы всё работало так же, как и в вашем будущем суперкалькуляторе плотности пыли 1 грамма песка Сахары. Можно также заменить готовыми решениями, которые есть на рынке.

Со стороны это всё похоже на ненужный дорогостоящий ад. Но! Вы хотите сделать мобильное приложение со сложной функциональностью. Это минимум 5000 $ на создание, а для некоторых нетривиальных решений это число может быть умножено на 100.

Решение:

делаете за 500 $ мобильную версию сайта с той же функциональностью;
проверяете, чтобы работало так, как нужно;
тестируете на ЦА;
выкладываете в дорогую разработку. Или не выкладываете — зависит от результата.

Тестирование на Big Data

Это путь Яндекса и больших компаний: придумать быстрое решение, выпустить бета-версию, сделать пререлиз, пустить миллионный суточный трафик и смотреть, как всё работает.

Здесь я не буду останавливаться, потому как это вариант вам вряд ли подойдёт. Разве только вы из компании с большим трафиком и командой из: UI-дизайнера + быстро-верстальщика + быстро-программиста + быстро-BigData-спеца + быстро-продюсера + быстро-сис. админа + быстро-арт-дира.

Если из такой компании, то собирайте команду, быстро пилите беты, заливайте на продакшен, пускайте трафик через линки и проверяйте гипотезы. Если всё ок — делайте полноценные версии на основе этих бет.

Тестирование имеющегося продукта

Тестирование схожего продукта, что уже у вас есть, или есть у ваших конкурентов отлично подходит тем, кто хочет сделать «идеально, как у конкурента».

Такой подход мало кто использует, но это реально классная штука, особенно перед любым процессом изменения дизайна продукта, если он у вас уже есть. Или у вас нет, но у вашего главного врага по рынку — есть.

Для этого требуется:

сайт или приложение,
целевая аудитория;
юзабилити-исследователь;
личное присутствие в месте обитания ЦА или Skype.

Берём, что есть, приглашаем ЦА на тестирование (или на Skype-сессию), смотрим на экране, что делает респондент. Он в этом время проговаривает действия и мысли, мы записываем косяки, составляем статистику по ошибкам.

Метод особенно рекомендуется тем, кто думает что у них плохо работает функциональность, потому что так думает сын директора (который уже через 20 лет станет великим дизайнером). Тестируем то, что есть, и видим косяки. Реальные косяки. Всем, например, безразлично, что у вас сайт бирюзовый, и что кнопочки на нем не в Material Design, а с градиентом 90-х годов. А вот баги всем заметны. Кстати, это очень хороший способ отсеивать визуальных перфекционистов, которым не нравится цвет менюшки, а также компании, которые проводят «usability-аудиты» силами аккаунт-менеджера, который вышел на работу неделю назад.

Есть еще один метод

Называется «Прототип из разной дешевой фигни», но подходит больше для промышленного дизайна. Используется, например, IDEO. Но в рамках этой дискуссии не буду об этом говорить, так как не про дизайн-мышление мы тут.

Вывод

В работе я постоянно использую интерактивные прототипы, в том числе в цвете.

Бумажные прототипы делал несколько раз на реальных проектах и ещё раза четыре на различных интенсивах и курсах. Скорее проектирую на бумаге сложные элементы, но не тестирую на ней, так как это не особо часто требуется. Однако если времени впритык, то лучше бумаги ничего нет. Тестирование со скриптами делал разок, но это долгая история создания такого MVP — нужно отрисовывать каждый экранчик и состояние кнопок, все разворачивающие списки и выполнение тех или иных сценариев. Часто это тратит очень много времени.

Вывод для себя сделайте сами: стоит ли вам использовать тестирование прототипов или нет. В любом случае это ваше решение. Вы рискуете не только собственным временем, но и деньгами компании.

Однако если вы не предложите протестировать продукт на прототипах, вряд ли руководство об этом узнает. Вряд ли вообще кто-то знает, что можно пойти путем такого тестирования: проверить на пользователях ранние решения и исправить основные косяки, которые будут совершать 9 из 10 пользователей. Или 7 из 10. Или всего лишь 1 из 10 — всего-то каких-то 10% рынка.

Читать еще «Что такое аффордансы и как они улучшают юзабилити»

Именно вы принимаете это важное решение: снизить риски выпустить на рынок полное «неюзабельное» нечто. Понимаете, о чём я? Если вам страшно и лень, да и это не ваши деньги — можете не делать. Можете смело не делать. Потому что у вас просто нет трех дней на тестирование, зато есть полгода на переписывание того безобразия, которое вышло без тестирования. А три дня тестирования при участии трех человек — это ведь то же самое, что и полгода работы команды программистов, правда?

Так что всё зависит от вас.

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.