Дмитрий Мелентьев, руководитель конструкторского отдела компании Панеглиф , специально для блога Нетологии рассказал о своем опыте тестирования прототипов при разработке программного продукта.
В процессе разработки мы часто сталкиваемся со следующей дилеммой: как сделать продукт качественно и быстро, но при этом интересным и понятным как пользователям, так и клиентам.
Никто не хочет, чтобы его засыпали миллионами одинаковых вопросов о том, как это вообще работает. 
Рецепт есть: тестируйте продукт перед выходом на рынок.
Конечно, вы можете протестировать его прямо перед релизом.
Многие компании так и делают: выпускают бета-версию, смотрят на реакцию, собирают отзывы, а затем исправляют ошибки.
Хорошая практика, но бывает, что пользователи не понимают весь основной функционал, а не только детали интерфейса.
И оказывается, что все нужно перекраивать, все нужно переделывать.
Или напишите огромное руководство пользователя, которое никто, кроме конкурирующих разработчиков, не будет читать.
Поэтому тестировать нужно не в конце разработки продукта, а гораздо раньше, может быть, даже в начале.
Тестирование прототипа поможет сэкономить время и исключить глобальные проблемы в самом начале разработки.Мы всегда хотим избежать тестирования прототипов, притворяясь овощем.
Зачем проверять, если «все ясно»? Это потребует времени на разработку продукта, а также добавит организационных проблем — тот же подбор людей для тестирования того стоит. И нужно найти где-нибудь тихую комнату, а также быть добрым ко всем респондентам, даже когда они, мягко говоря, несколько не в курсе происходящего.
Кажется, можно вычеркнуть этот маленький «эпизод», сэкономить ресурсы, и никто этого даже не заметит. И все будет хорошо! Но это не работает таким образом.
В реальности лучше потратить 30 минут на тестирование прототипа с пользователями, чем проектировать, верстать, программировать, а потом обнаружить, что нужно [цензура] всё переделывать! Даже если респондентами являются сотрудники компании, главное, а не те, кто отвечает за дизайн продукта.
Существует несколько проверенных временем и опытом способов протестировать продукт: начиная с этапа, когда он существует только в виде эскизов, и заканчивая тестированием прототипа на пользователях, которые подумают, что это готовый сайт в эксплуатация, а вовсе не прототип.
Иногда это действительно так.
Бумажный прототип
На бумаге идеально тестировать концепции, когда у вас есть доступ к целевой аудитории и нескольким людям для проведения исследования.Лучше всего тестировать сложные сценарии с множеством экранов, миллионом кнопок — в общем, то, что аналогичным образом можно протестировать только на готовом продукте.
Да, прототип будет очень далек от реального результата, но у респондентов не возникнет вопросов: «почему фото не мое», «почему я кликнул на картинку кроссовок и появился ремень», «почему нет красивая анимация для этого окна», «почему скролл не двигается», «почему кнопки кривые» и т.д. Все понимают, что это бумага, и никаких странных вопросов по поводу ее интерактивности не возникает. Да, он не слишком похож на отшлифованный конечный продукт, но позволяет выявить огромные пробелы в функциональности, взаимодействии с интерактивными элементами, навигации по интерфейсным решениям и экранам, а также в понимании значения кнопок.
Из опыта
Однажды мы делали проект единого дизайна сайта муниципальных районов.Сначала мы провели исследование, чтобы понять, что можно размещать на сайте, а что нельзя.
Затем мы определили, что будет важно для посетителей, а что нет, но по закону должно быть на сайте.
Мы сделали прототипы на бумаге: все экраны и окна.
И мы тестировали на бумаге, с тремя участниками тестирования на нашей стороне: один «робот» один модератор, один наблюдатель.
Модератор предлагает решить сценарий, направляет респондента, наблюдатель внимательно наблюдает за респондентом, записывает его наблюдения и молчит, "робот" вкладывает нужные бумажки с интерфейсами, молчит и не проявляет никаких эмоций( вот как работает робот).
Сначала мы думали, что респонденты не поймут этот тип прототипа.
Трудно представить депутата, «нажимающего» на бумажные кнопки, листающего бумажные списки и карты.
Но внезапно все пошло хорошо.
Пользователи нажимали кнопки-прототипы, прокручивали страницу, перемещались по вкладкам и искали информацию.
То есть действительно «работали» с бумажным прототипом.
Да, немного необычный, но вполне работоспособный процесс.
Первое преимущество — нарисовать прототип на бумаге можно за 3 часа, а вот проектирование прототипа в программе занимает минимум день.
Или даже два.
Дальше вам нужно будет вставить контент, все выровнять и подготовить к тестированию.
Второе преимущество: если во время тестирования что-то «работает» не так, это можно быстро исправить на бумаге карандашом и ластиком — и тестировать дальше.
И для этого вам не нужен Интернет. Кроме того, люди не испытывали какого-либо неприятия, непонимания или негатива по отношению к такому тестированию.
Все было четко и по делу.
Нам удалось выявить множество проблем в навигации и взаимодействии пользователя с сайтом.
Интерактивные прототипы в мельчайших деталях
Интерактивные прототипы — хороший способ проверить логику, особенно простую, а также ожидания пользователей.Конечно, можно заняться сложной навигацией, но с количеством и качеством экранов придется потрудиться.
Респондент зачастую не воспринимает интерактивный прототип как прототип, поэтому ему приходится постоянно об этом напоминать.
Почему такие прототипы не подходят для: для тестирования сложной логики с серьёзными скриптами и анимацией; оценить визуальное оформление, которое не прокомментирует только самый ленивый респондент. Содержание таких прототипов должно быть максимально приближено к реальному.
Интерактивные прототипы не должны содержать Lorem Ipsum, стандартные изображения гор Axure или перечеркнутые прямоугольники.Подобный контент плохо воспринимается респондентом, который часто забывает, что это всего лишь прототип для проверки логики, и зацикливается на контенте и визуальном оформлении.
Тебе не следует этого делать.
Да и зачем, если по теме найти «рыбку» очень легко: текст взять с сайта fishtext.ru; скачать картинки с Яндекс.
Картинок; установить стандартные иконки Bootstrap; размещать фотографии пользователей из поиска людей ВКонтакте; пишите максимально реалистичные заголовки, чтобы потом не оказалось, что они не соответствуют ширине экрана.
Бытует мнение, что подобные прототипы должны быть выполнены в черно-белом цвете.
Да и нет. Да, не стоит расставлять цветовые акценты на нужных вам элементах в интерактивном прототипе, так как это неверно с точки зрения реальности, когда таких акцентов уже не будет. Тем не менее, не всегда можно обойтись черно-белым прототипом.
Если, например, планируется картинная галерея и упор сделан на картины, то лучше сразу сделать прототип похожим на реальность, а изображения взять из поиска.
Таким образом, сразу будет понятно, что это за прототип и зачем он нужен.
Идеально тестировать интерактивные прототипы на целевой аудитории.
Вы можете использовать Skype; многими прототипами можно легко поделиться.
Пользователь включит трансляцию экрана, и вы сможете наблюдать за его действиями.
Если невозможно найти людей из целевой аудитории, и при этом вам не нужно тестировать слишком сложный прототип, проводите «коридорное тестирование».
Возьмите обычных сотрудников компании, похожих на вашу целевую аудиторию.
Главное в такой ситуации — не брать на работу тех, кто прекрасно знает весь продукт или принимает непосредственное участие в разработке.
Не все эксперты согласны с «коридорным» подходом, утверждая, что выборка не представляет целевую аудиторию.
Но я обещаю, что это лучше, чем вообще отсутствие тестирования: часто всплывают дурацкие ошибки интерфейса, которые вы никогда не увидите сами.
Никогда!
Тестирование цветного прототипа в программах типа Axure
Здесь все довольно просто.Дизайнер делает красивый интерфейс, в котором вы размечаете области, где что-то должно происходить при взаимодействии с ними.
Обычно это просто «по клику» или «по ходу».
Можно, конечно, поколдовать резаком и вырезать различные элементы, но это будет слишком долго.
Хотя есть и такие перфекционисты.
Вся эта красота сделана интерактивной и тестируется на пользователях: насколько быстро расставленные вами цветовые акценты позволяют пользователю находить нужные элементы.
Респондент может проговаривать действия вслух, а вам просто нужно подождать, пока он выполнит желаемое действие.
Или не ждите и уходите в слезах — если вы дизайнер.
А если вы не дизайнер, то ваша задача отправить дизайнеру комментарии.
Тестируем на целевой аудитории, через Skype. Есть небольшой нюанс: нужно постоянно напоминать, что это прототип.
Постоянно! Потому что такой прототип слишком похож на реальность.
Кстати, бессмысленным «рыбам» в нем нет места: нужны нормальные тексты, картинки и иконки.
Их можно взять из Интернета, только помните о правообладателях.
Если респонденты допускают невообразимые логические ошибки, то либо дизайнер принял очень плохое решение, либо вы очень плохо протестировали прототип на предыдущем этапе.
Это тестирование помогает оценить: насколько понятен конкретный элемент, который раньше был, например, большой кнопкой, а теперь превратился в красивую тонкую полоску, понятную пользователю; акценты и видимость всех важных элементов дизайна.
Если пользователь не замечает нужные элементы или нажимает зря, то это нужно исправить.
Обратите внимание, что во время тестирования UI или графический дизайнер, который все это делал, должен молчать, а еще лучше находиться подальше от респондентов.
Если рядом, то только с выражением «покерфейс».
Ему будет сложно, он периодически будет хвататься то за топор, то за веревку с мылом, поэтому лучше всего держать его немного в стороне от процесса тестирования конструкции на пользователе.
Тестирование скриптами или MVP-тестирование на альфа-версии продукта.
Все работает как надо, но пока вместо 1 миллиарда пользователей у вас 5 человек - друзей проекта, вместо базы в 5 миллионов SKU у вас остается 1 база на 100 товаров, а вместо выделенных серверов на Amazon, виртуальный хостинг на 1gb.ru. Но все работает как надо.
Все работает так, как должно.
Это главное условие! Теперь вы берете пользователя из целевой аудитории (не нужно брать программистов из соседней комнаты), даете ему цель и даете ему ее выполнить.
Все должно пройти идеально.
Мелкие ошибки, которые мешают реальному пользователю быстро и эффективно достичь своей цели, фиксируются, а затем исправляются.
Еще раз для тех, кто хитрит. Вам нужно протестировать это на своей целевой аудитории! Не тестируйте свой продукт на работниках столовой в вашем офисе, если ваша целевая аудитория — девушки из села Барвиха Лухари.
Если вам действительно нужно протестировать сложный, дорогой функционал, на разработку которого уходит минимум год, то сделайте быстрое решение и протестируйте его.Главное, что все работает так же, как и в вашем будущем суперкалькуляторе плотности пыли 1 грамма песка Сахары.
Также вы можете заменить его готовыми решениями, доступными на рынке.
Со стороны все это выглядит ненужным, дорогим адом.
Но! Вы хотите сделать мобильное приложение со сложным функционалом.
Это минимум $5000 на создание, а для некоторых нетривиальных решений это число можно умножить на 100. Решение: сделать мобильную версию сайта с тем же функционалом за 500$; проверьте, работает ли он как надо; тестирование на целевую аудиторию; вы вкладываете его в дорогостоящую разработку.
Или не выкладываешь - от этого зависит результат.
Тестирование больших данных
Это путь Яндекса и крупных компаний: придумать быстрое решение, выпустить бета-версию, сделать пререлиз, отправить миллионы ежедневного трафика и посмотреть, как все работает. На этом я не буду останавливаться, потому что этот вариант вряд ли вам подойдет. Если только вы не из компании с большим трафиком и командой: UI-дизайнер + быстрый верстальщик + быстрый программист + быстрый специалист по BigData + быстрый продюсер + быстрый сис.админ + быстрый арт-директор.
Если вы из такой компании, то собирайте команду, быстро нарезайте бета-версии, загружайте их в продакшен, отправляйте трафик по ссылкам и тестируйте гипотезы.
Если все ок, делайте полноценные версии на основе этих бета-версий.
Тестирование существующего продукта
Тестирование аналогичного продукта, который уже есть у вас или у ваших конкурентов, отлично подходит для тех, кто хочет работать «идеально, как конкурент».Таким подходом мало кто пользуется, но это действительно классная штука, особенно перед любым процессом изменения дизайна продукта, если он у вас уже есть.
Или нет у вас, а у вашего главного врага на рынке есть.
Это требует: веб-сайт или приложение, целевая аудитория; исследователь юзабилити; личное присутствие по месту жительства целевой аудитории или Skype. Берем то, что есть, приглашаем целевую аудиторию на тестирование (или скайп-сессию) и наблюдаем на экране, что делает респондент. В это время он произносит действия и мысли, мы записываем ошибки, составляем статистику ошибок.
Способ особенно рекомендуется тем, кто считает, что у них плохо работает функционал, потому что так думает сын директора (который через 20 лет станет великим дизайнером).
Мы тестируем то, что имеем, и видим ошибки.
Настоящие косяки.
Например, никого не волнует, что ваш сайт бирюзового цвета и что кнопки на нем не в Material Design, а с градиентом 90-х.
Но баги заметны всем.
Кстати, это очень хороший способ отсеять визуальных перфекционистов, которым не нравится цвет меню, а также компании, которые проводят «юзабилити-аудиты» с помощью аккаунт-менеджера, который начал работать неделю назад.
Есть еще один метод.
Называется "Прототип из разной дешёвой хрени", но он больше подходит для промышленного дизайна.Например, используется IDEO. Но в рамках данной дискуссии я не буду об этом говорить, поскольку речь здесь не идет о дизайн-мышлении.
Заключение
В своей работе я постоянно использую интерактивные прототипы, в том числе в цвете.Бумажные прототипы я делал несколько раз на реальных проектах и еще четыре раза на различных интенсивах и курсах.
Вернее, я проектирую сложные элементы на бумаге, но не тестирую на ней, так как это требуется не особо часто.
Однако если времени мало, то нет ничего лучше бумаги.
Тестирование со скриптами я когда-то делал, но это долгая история создания такого MVP — нужно отрисовывать каждое состояние экрана и кнопки, все раскрывающиеся списки и выполнение тех или иных скриптов.
Часто на это уходит много времени.
Сделайте вывод сами: стоит ли вам использовать тестирование прототипов или нет. В любом случае это ваше решение.
Вы рискуете не только своим временем, но и деньгами компании.
Однако если вы не предложите протестировать продукт на прототипах, руководство вряд ли об этом узнает. Вряд ли кто-то вообще знает, что можно пройти такое тестирование: протестировать ранние решения на пользователях и исправить основные ошибки, которые допустят 9 из 10 пользователей.
Или 7 из 10. Или просто 1 из 10 – всего каких-то 10% рынка.
Именно вы принимаете это важное решение: снизить риски выпуска на рынок чего-то совершенно «негодного».
Ты знаешь, что я имею в виду? Если вы напуганы и ленивы, и это не ваши деньги, не обязательно это делать.
Вы можете смело этого не делать.
Потому что у тебя просто нет трех дней на тестирование, а есть полгода, чтобы переписать то безобразие, которое вышло без тестирования.
А три дня тестирования с участием трех человек — это то же самое, что шесть месяцев работы команды программистов, верно? Так что все зависит от вас.
Нетология ведет набор на курсы:
Дизайн интерфейсов: UI-UX дизайн от стратегии до тестирования ; UX-аналитика: исследование пользователей и здравый смысл ; Дизайн мобильных приложений: интерфейсы, архитектура, визуальная концепция ; Adobe XD: основы дизайнера интерфейсов (произвольная программа); Курс Python: повседневное программирование и сверхбыстрое прототипирование .Теги: #Прототипирование #тестирование #Тестирование веб-сервисов #Тестирование мобильных приложений #Тестирование ИТ-систем #разработка программного обеспечения #нетология #прототипы #тестирование прототипов
-
Планшет Htc Flyer Официально Представлен
19 Oct, 24 -
Возмущены: Сайт Microsoft Не Работает В Ie
19 Oct, 24 -
Просто Добавь Воды: Touchnote.com
19 Oct, 24 -
Пятница: Сообществу
19 Oct, 24 -
Хотите Р2Д2? - Выбирать!
19 Oct, 24 -
Будет Ли Веб 3.0?
19 Oct, 24
