Тестирование прототипов при разработке программного продукта

В рeaльнoсти лучшe пoтрaтить 30 минут нa тeстирoвaниe прoтoтипa нa пoльзoвaтeляx, чeм сдeлaть дизaйн, свeрстaть, зaпрoгрaммирoвaть, a пoтoм oбнaружить, чтo нужнo всe [censored] пeрeдeлывaть! И пoлучaeтся, чтo нужнo всё пeрeкрoить, всё пeрeдeлaть. Пoнимaeтe, o чём я? A eсли вы нe дизaйнeр, тo вaшa зaдaчa — oтпрaвить зaмeчaния дизaйнeру. Eсть нeбoльшoй нюaнс: нaдo пoстoяннo нaпoминaть, чтo этo прoтoтип. В прoцeссe рaзрaбoтки мы чaстo стaлкивaeмся с тaкoй дилeммoй: кaк сдeлaть прoдукт xoрoшo и быстрo, нo при этoм интeрeсным и пoнятным и пoльзoвaтeлям, и зaкaзчикaм. И интeрнeт для этoгo нe нужeн. Нo я зуб дaю, чтo лучшe тaк, чeм вooбщe бeз тeстирoвaния: чaстo всплывaют глупыe интeрфeйсныe oшибки, кoтoрыe сaм ни зa чтo нe увидишь. Всeм, нaпримeр, бeзрaзличнo, чтo у вaс сaйт бирюзoвый, и чтo кнoпoчки нa нeм нe в Material Design, a с грaдиeнтoм 90-x гoдoв. Бумaжный прoтoтип

Нa бумaгe идeaльнo тестировать концепты, когда есть доступ к целевой аудитории и несколько человек для проведения исследования. Но в рамках этой дискуссии не буду об этом говорить, так как не про дизайн-мышление мы тут. Потому что у вас просто нет трех дней на тестирование, зато есть полгода на переписывание того безобразия, которое вышло без тестирования. Разве только вы из компании с большим трафиком и командой из: UI-дизайнера + быстро-верстальщика + быстро-программиста + быстро-BigData-спеца + быстро-продюсера + быстро-сис. Иногда оно так и есть, правда. Хорошая практика, но бывает так, что пользователи не понимают всю основную функциональность, а не просто интерфейсные мелочи. Тестирование цветного прототипа в программах типа Axure

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

для тестирования сложной логики с серьезными скриптами и анимацией;
для оценки визуального дизайна, о котором не выскажется разве что самый ленивый респондент. Можно, конечно, поколдовать с резаком и вырезать различные элементы, но это слишком долго. Но всё работает как нужно. Тестируем на целевой аудитории, можно по Скайпу. Да, прототип будет очень далек до реального результата, но зато у респондентов не будет возникать вопросов: «почему фотка не моя», «почему я нажал на картинку кроссовок, а появился ремень», «почему нет красивой анимации у этого окошка», «почему скролл не двигается», «почему тут кнопки кривые» и т. Тестируем то, что есть, и видим косяки. Метод особенно рекомендуется тем, кто думает что у них плохо работает функциональность, потому что так думает сын директора (который уже через 20 лет станет великим дизайнером). Дизайнер делает красивый интерфейс, в котором вы размечаете области, при взаимодействии с которыми должно что-то происходить. Но! Из опыта

Однажды делали проект единого дизайна сайта муниципальных округов. Если очень нужно проверить сложную дорогую функциональность, которую разрабатывать минимум год, то сделайте быстрое решение и проверяйте его. Обычно это просто «on click» или «on move». Вы хотите сделать мобильное приложение со сложной функциональностью. Кстати, в нем уже не место бессмысленной «рыбе»: нужны нормальные тексты, картинки, иконки. Он в этом время проговаривает действия и мысли, мы записываем косяки, составляем статистику по ошибкам. Бумажные прототипы делал несколько раз на реальных проектах и ещё раза четыре на различных интенсивах и курсах. Первый плюс в том, что нарисовать бумажный прототип можно за 3 часа, а вот спроектировать прототип в программе — это минимум день. И да, и нет. Есть еще один метод

Называется «Прототип из разной дешевой фигни», но подходит больше для промышленного дизайна. Всё должно пройти идеально. Тестирование со скриптами, или MVP-тестирование на alfa-версии продукта

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

сайт или приложение,
целевая аудитория;
юзабилити-исследователь;
личное присутствие в месте обитания ЦА или Skype. Но так не работает. Вряд ли вообще кто-то знает, что можно пойти путем такого тестирования: проверить на пользователях ранние решения и исправить основные косяки, которые будут совершать 9 из 10 пользователей. Можно взять их из интернета, только помните про правообладателей. Нам всегда хочется избежать тестирования прототипов, прикинувшись овощем. Берём, что есть, приглашаем ЦА на тестирование (или на Skype-сессию), смотрим на экране, что делает респондент. Никому не хочется, чтобы сыпались миллионы одинаковых вопросов о том, как это вообще работает. Мелкие баги, которые мешают реальному пользователю прийти к цели быстро и эффективно, записываем, а потом правим. Если, например, предполагается картинная галерея и акцент на картинах, то лучше сразу делать прототип похожим на реальность, а изображения взять из поиска. Ни за что! Кажется, что можно вычеркнуть этот небольшой «эпизод», сберечь ресурсы, и никто не заметит даже. Или не выкладываете — зависит от результата. Учтите, что во время тестирования UI- или графический дизайнер, который это всё делал, должен молчать, а лучше вообще быть далеко от респондентов. Если невозможно найти людей из ЦА, и при этом не требуется проверять слишком сложный прототип, сделайте «коридорное тестирование». Хотите написать колонку для «Нетологии»? админа + быстро-арт-дира. В интерактивных прототипах не должно быть Lorem Ipsum, стандартных картинок с горами Axure и перечеркнутых прямоугольников. Такое наполнение плохо воспринимается респондентом, который часто забывает, что это просто прототип для тестирования логики, и зацикливается на наполнении и визуальном оформлении. Или 7 из 10. Если из такой компании, то собирайте команду, быстро пилите беты, заливайте на продакшен, пускайте трафик через линки и проверяйте гипотезы. Часто это тратит очень много времени. Такое тестирование помогает оценить:

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

Именно вы принимаете это важное решение: снизить риски выпустить на рынок полное «неюзабельное» нечто. Так делать не стоит. Вывод

В работе я постоянно использую интерактивные прототипы, в том числе в цвете. А то и два. У нас получилось выявить немало косяков в навигации и взаимодействии пользователя с сайтом. Можно по скайпу, многие прототипы беспроблемно расшариваются. Если рядом, то только с выражением «poker face». Вы рискуете не только собственным временем, но и деньгами компании. Поэтому нужно тестировать не в конце разработки продукта, а намного раньше, может даже в начале. Всё работает как нужно. Тестирование со скриптами делал разок, но это долгая история создания такого MVP — нужно отрисовывать каждый экранчик и состояние кнопок, все разворачивающие списки и выполнение тех или иных сценариев. Такой подход мало кто использует, но это реально классная штука, особенно перед любым процессом изменения дизайна продукта, если он у вас уже есть. Вывод для себя сделайте сами: стоит ли вам использовать тестирование прототипов или нет. Однако если времени впритык, то лучше бумаги ничего нет. Да, не стоит делать в интерактивном прототипе цветовые акценты на нужных вам элементах, так как это неверно с точки зрения реальности, когда таких акцентов уже не будет. И всё же не всегда можно обойтись черно-белым прототипом. Дмитрий Мелентьев, глава отдела проектирования компании Paneglif, специально для блога Нетологии написал колонку о том, как тестировать прототип при разработке программного продукта. Пользователи кликали прототипные кнопки, скроллили страницу, переходили по вкладкам и искали информацию в поиске. Тестировать надо на ЦА! Респондент может проговаривать действия вслух, а вам нужно просто дождаться, пока он сделает нужное действие. Если респонденты допускают невообразимые логические ошибки, значит, либо дизайнер сделал реально плохое решение, либо вы очень плохо протестировали прототип на предыдущем этапе. Модератор предлагает решить сценарий, ведёт респондента, наблюдатель внимательно следит за респондентом, записывает свои наблюдения и молчит, «робот» подкладывает нужные листочки с интерфейсами, молчит и не проявляет никаких эмоций (работа у робота такая). Решение:

делаете за 500 $ мобильную версию сайта с той же функциональностью;
проверяете, чтобы работало так, как нужно;
тестируете на ЦА;
выкладываете в дорогую разработку. Программа обучения: «Курс Python: программирование на каждый день и сверхбыстрое прототипирование»

Конечно, можно тестировать и прямо перед самым релизом. Теперь берёте пользователя из целевой аудитории (не нужно брать программистов из соседнего помещения), даёте ему цель, и пусть он её выполняет. Если вам страшно и лень, да и это не ваши деньги — можете не делать. Конечно, можно взяться и за сложную навигацию, но придется потрудиться с количеством и качеством экранов. Однако если вы не предложите протестировать продукт на прототипах, вряд ли руководство об этом узнает. Есть несколько проверенных временем и опытом способов тестировать продукт: начиная с этапа, когда он существует только в виде набросков, и заканчивая тестированием прототипа на пользователях, которые будут думать, что это уже готовый сайт в работе, и никакой не прототип. Реальные косяки. Да, не очень похоже на вылизанный конечный продукт, но позволяет выявить громадные косяки в функциональности, взаимодействии с интерактивными элементами, навигации по интерфейсным решениям и экранам, и в понимании значений кнопок. Интерактивные прототипы идеально тестировать на целевой аудитории. Используется, например, IDEO. Сделали прототипы на бумаге: все экраны и окна. Мнение автора и редакции может не совпадать. Если пользователь не замечает нужные элемент или кликает почём зря — значит, нужно править. Вся эта красота делается интерактивной и тестируется на пользователях: насколько быстро расставленные вами цветовые акценты позволяют пользователю найти нужные элементы. Второй плюс: если во время тестирования что-то не так «работает», на бумаге это быстро исправляется карандашом и ластиком — и можно тестировать дальше. д. Интерактивные прототипы в мелкой детализации

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

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

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

один «робот»,
один модератор,
один наблюдатель. И помещение нужно где-то взять тихое, и еще быть добрым со всеми респондентами, даже когда они, мягко говоря, несколько не ориентируются в происходящем. Со стороны это всё похоже на ненужный дорогостоящий ад. Пользователь включит трансляцию экрана, а вы сможете наблюдать за его действиями. Зачем тестировать, если и так «всё понятно»? Если всё ок — делайте полноценные версии на основе этих бет. Главное в такой ситуации — не брать тех, кто идеально знает весь продукт или непосредственно участвует в разработке. Тестирование имеющегося продукта

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

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.