Знакомство с css испытание макет прототип. Тестирование UX-прототипов как необходимое звено разработки продукта

Здравствуйте!

CSS кажется простым и понятным, пока вам не приходится делать что-то нестандартное. Вот еще один взгляд на проблемы CSS. Это перевод статьи «5 Most Annoying Things with CSS ».

В 1996 основные браузеры поддерживали CSS лишь частично, и из-за этого веб-дизайнеры были вынуждены придумывать кучу хаков и обходных путей, чтобы их стили работали так, как они хотели. Фактически только с 1999 года каждый браузер наконец стал поддерживать CSS1 полностью. IE 5.0 для Макинтош, выпущенный в марте 2000 года, стал первым браузером, достигшим полной поддержки спецификации CSS1. CSS2 был выпущен в 1999 году, но дизайнеры не решались использовать его повсеместно из-за неполной поддержки стандарта браузерами.

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

К счастью, кроме усилий W3C по улучшению спецификации в соответствии с требованиями разработчиков, сообщество само разработало множество решений для улучшения и упрощения работы с CSS в сложной среде. SASS, Stylus, LESS ввели в обиход циклы, примеси и функции. Внедрение переменных CSS упростило написание сложных стилей, улучшило читаемость и упростило поддержку.

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

Даже сегодня, называя себя «fullstack разработчиком» или «front-end разработчиком», с опытом работы в год или восемь лет, вы все равно столкнетесь с ситуацией, когда CSS заставит вас попотеть.

Я перечислю некоторые крупные проблемы CSS:

CSS ориентирован на разметку, не на дизайн

Дизайнеры должны тратить больше времени на создание отличного дизайна и меньше времени на возню с разметкой и проблемами совместимости браузеров. Когда я говорю «ориентирован на разметку», я имею в виду, что каждый инструмент дизайна CSS заставляет лезть в исходный код, чтобы создавать хороший дизайн. Инструменты для дизайнеров должны быть ориентированы на дизайн. CSS плох, потому что он заставляет дизайнеров думать о том, как реализовать их дизайн технически, а не с позиций дизайна.

Браузерные войны

Вы нарисовали изумительный макет вашего нового сайта. Но преобразование этого прекрасного макета из Фотошопа в точную до последнего пикселя разметку - целое испытание. Проблема не в том, что вы не понимаете, как это закодить. Проблема по большей части в том, что разные браузеры по-своему интерпретируют вашу разметку, даже если вы используете полностью валидный CSS. Это сильно демотивирует, когда вы правите баг в одном браузере, и тем самым добавляете новый баг в другом.

• Всегда используйте Normalize.css . Он заставляет браузеры отрисовывать все элементы более предсказуемо и в соответствии с современными стандартами. Он точно затрагивает только элементы, которые нуждаются в нормализации.
• Вы можете использовать фреймворки типа Bootstrap , Bulma и Materialize . По большей части они хорошо совместимы с большинством браузеров.
• Используйте генераторы кода CSS3. Они помогают разработчикам писать кроссбраузерные участки кода для разных свойств CSS3. Они дают разработчикам широкие возможности кастомизации, включая border-radius, text-shadow, RGBa, box sizing. Один из сервисов - CSS3 Generator .
• Валидация: сервис валидации W3C валидирует разные версии XHTML и HTML, выводя кучу важных ошибок и сообщений, чтобы помочь разработчикам создавать отличные сайты. W3C Validator: http://validator.w3.org
• W3C Css Validator: http://jigsaw.w3.org/css-validator
• Тестирование: поскольку практически невозможно руками протестировать сайт во всех возможных браузерах и операционных системах, на помощь приходят инструменты кроссбраузерного тестирования! Вы можете использовать Browsershots , BrowserStack , Cross Browser Testing и подобные сервисы для тестирования.

Отзывчивый макет

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

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

• Отдавайте приоритет важному контенту и скрывайте маловажные детали на малых экранах. Я считаю, что важнее всего показывать самое важное на небольших экранах. Иногда удалить часть контента на мобильных невозможно, тогда стоит предусмотреть возможность его скрытия.
• Используйте SVG. В отличие от традиционных изображений, вроде PNG или JPEG, SVG легко масштабируется без потери качества. Кроме того, часто они меньше размером, так что вы немного повысите скорость загрузки сайта.
• Когда дело доходит до взаимодействия с пользователем, фокусируйтесь на том, чтобы предоставлять достаточно большие контролы (поля вводы, кнопки, переключатели).
• Для смартфонов по возможности делайте кнопки не меньше 44px, как это рекомендуется в iOS Human Guidelines
• Протестируйте дизайн на минимум пяти пользователях, используя их привычные устройства.
• Используйте фреймворки типа Bootstrap. С ними создание пригодного для мобильных устройств сайта становится намного проще. Использование готовых классов из Bootstrap поможет вам определиться с сеткой и размещением контента.

Сделайте красный более синим

Многие клиенты приходят со странными требованиями, завышенными ожиданиями, желаемым функционалом, который никогда не обсуждается. В результате мы приходим к бесконечным правкам и бесчисленным итерациям. Клиенты меняют свои желания каждую секунду, особенно когда дело касается дизайна. Будучи вынужденными поддаваться каждой прихоти клиента, дизайнеры воспринимают это как плохое обращение или оскорбление. Вот почему популярны сайты вроде Clients From Hell .

• Создание анимированных прототипов - хороший вариант показать ваши идеи. Используйте программы вроде Adobe XD, Sketch , InVision и так далее. Начинайте разработку только после согласования дизайна.
• Будет разумно с самого начала спланировать весь процесс разработки. Вероятнее всего, в процессе придется добавить время на разные неожиданности. Помните закон Мерфи: «Что может пойти не так - пойдет не так».
• Сохраняйте спокойствие. Не позволяйте эмоциям взять над собой верх. Просто помните, что клиент не заканчивал художественную школу, и может не понимать, что красный текст на зеленом фоне не улучшает читаемость. Объясняйте свои решения касательно визуальной иерархии, типографики и всего, что могут затронуть изменения.
• Помните, что сайт - для вашего клиента, а ваша цель - сделать клиента довольным сайтом. Лучшее, что вы можете сделать - дать свои рекомендации касательно изменений. Если вы не согласны, просто сделайте все, что можно, чтобы сайт выглядел максимально хорошо.

CSS недооценен

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

Я работала с несколькими изумительными бэкенд-инженерами, которые знали каждый паттерн ООП в книге, но намертво застревали с позиционированием и float, и считали отзывчивый CSS чем-то вроде черной магии. Так что я нахожу этот комикс очень точным.

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

Как я говорила в своей предыдущей статье «Troubleshooting CSS », работа с CSS и получение хороших результатов от работы с CSS - две большие разницы. С CSS легко начать, но мастерство потребует усилий. Это то, что требует минуту на знакомство и всю жизнь (с преувеличением) на мастерство.

Взяв в качестве критерия работающую систему (поскольку она - конечный результат всех предыдущих процессов разработки), можно поставить макет, прототип и имитатор в разные рабочие условия. Если оценивать сходство с работающей системой, то макет похож на нее меньше, чем имитатор. Прототип гораздо ближе к имитатору, чем к макету. Если говорить о количестве блоков в этих системах, то обычно макет состоит только из одного устройства, хотя он может соответствовать всей системе; прототип изображает всю систему точно так же, как и имитатор (что касается имитатора, то именно это устройство предоставляется человеку-оператору в качестве интерфейса машины). Если же говорить о количестве действий с оборудованием или аспектов обслуживания системы персоналом, то меньше проверок можно проводить с макетом, больше- с имитатором системы и ее прототипом (однако, разумеется, не так много, как с реальной системой).

В отношении электронного оборудования макеты гораздо проще, чем имитаторы, однако если к макету добавить дополнительное оборудование (микроЭВМ, программное обеспечение, блоки управления и отображения и т.д.), то макет в конечном счете превратится в имитатор.

Тестирование макета производится в том случае, когда ИЧФ решит, что оно необходимо, поскольку обычно проверки иа этой стадии разработки не предусмотрены. РИ прототипов регламентируются инструкциями Министерства обороны. Как и в случае с проверкой макетов, процессы измерения рабочих характеристик имитатора и работающей системы зависят от особых обстоятельств (таких, как наличие требований испытывать данную модификацию системы); иногда эти измерения выполняются в исследовательских целях (например, чтобы подтвердить возможность использования тренажера для обучения персонала).

Имитатор - физическое устройство, в котором воспроизводятся те особенности реальной аппаратуры, которые имеют отношение к интерфейсу человек - машина. Следует различать имитационные системы и компьютерные модели, которые по существу являются концептуальными. Помимо оценки эффективности обучающего имитатора ИЧФ обычно предпочитает использовать не реальную систему, а имитатор в следующих случаях: 1) нет возможности проводить измерения с работающей системой; 2) необходимо изменить параметры системы, чтобы провести экспериментальное сравнение, а параметры действующей системы для этой цели менять нельзя; 3) проверка аварийных условий, что для реальной аппаратуры слишком опасно.

Кроме того, измерения с помощью имитатора имеют определенные преимущества, заключающиеся в возможностях 1) запустить и остановить моделируемую систему в любой нужный момент, 2) зафиксировать некоторый этап функционирования системы и исследовать его более тщательно, 3) изменить режим работы и 4) обеспечить автоматическую регистрацию данных.

С другой стороны, есть и ряд недостатков: 1) с помощью имитатора нельзя воспроизвести полный цикл работы системы (разумеется, это относится к процессу эксплуатации); 2) качество моделирования может оказаться ниже, чем желательно; 3) тестируемый персонал обычно не обладает такими навыками, как эксплуатационный персонал; 4) при моделировании системы могут быть нроиграны только сценарии обучения, которые не полностью отражают все условия эксплуатации; 5) время, на которое ИЧФ может получить имитатор исключительно для измерений, может быть ограниченным.

Остальные ситуации испытаний имеют только им свойственные недостатки. Поскольку эксплуатируемая система включена во внешнюю среду, иногда возможны внешние воздействия на нее, которые снижают чистоту исследований (например, в случае прерываний, вызванных командами с более высоким приоритетом). Именно это является причиной многих известных случаев нарушения управления при работе в реальных условиях. Может так случиться, что предпосылки РИ системы- прототипа не будут полностью удовлетворены, например в случае устойчивых конфигураций аппаратуры (как оборудования, так и процедур); из-за непрерывно возникающих в процессе разработки трудностей испытываемое оборудование может давать больше отказов, чем в реальных условиях. Макет настолько ограничен по возможностям предъявления стимулов и по соответствующим ответным реакциям персонала, что при анализе результатов испытаний требуется проводить тщательную экстраполяцию.

Главными задачами оценки эффективности систем могут быть следующие: 1) проверить, может ли персонал решать стоящие перед ним задачи без существенных ошибок или перегрузки; 2) проверить, не являются ли процедуры управления и другие характеристики оборудования и системы непреодолимыми препятствиями для эффективной работы персонала и удовлетворяют ли эти характеристики критериям инженерной психологии; 3) определить, какое влияние на работу персонала оказывают некоторые резко различающиеся переменные, непосредственно связанные с назначением аппаратуры и всей системы (например, операции, выполняемые днем, и операции, выполняемые ночью); 4) определить с поведенческой точки зрения адекватность той или иной модификации в работе, аппаратуре, всей системе или ее назначении, а также адекватность того или иного конструктивного решения задачи; 5) посредством оценки работы персонала в условиях эксплуатации системы определить, является ли эта работа адекватной, и если нет, то выяснить, какие факторы вызывают снижение эффективности работы.

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

Вот почему можно осуществить только- часть целей тестирования с помощью статического м:акета (наиболее распространенного типа макета). Это означает, что можно получить частичные данные, которые не полностью удовлетворяют целям тестирования. Например, допустим, что имеется статический макет кабины истребителя. Тогда с его помощью устанавливается, что органы управления досягаемы, а показания приборов считываются, что и требуется для эффективного функционирования самолета. Однако это лишь частичное испытание {только с точки зрения антропометрии), которое позволяет установить, что персонал может выполнять свои задачи. Требуется еще имитатор по крайней мере для того, чтобы проверить, достаточно ли быстро реагирует летчик на изменение окружающей обстановки.

Описанные выше задачи тестирования относятся как к системам, работающим в реальных условиях, так и к процессу разработки систем. По мере того как система создается, выясняются все новые ее характеристики, на основе которых модифицируется оборудование и процедуры. Чтобы определить, насколько опрапданны эти модификации, необходимо проводить тестирование. Система должна повторно тестироваться в процессе работы, поскольку при испытаниях нельзя получить данные относительно того, насколько хорошо она соответствует поставленным целям; например, военные системы не программируются лля работы в условиях боя до тех пор, пока ие начнутся боевые действия. Проверка боевых систем может осуществляться в военных играх, например при соревновании двух подразделений пехоты с поддержкой в виде танков, артиллерии и самолетов. Если в работе системы возникают перебои, то необходимо исследовать параметры задачи. Или же ИЧФ должен определить влияние на качество работы потенциально важных внутренних переменных (например, чередования рабочих смен). Иногда РИ и испытания имитатора проводятся просто для того, чтобы собрать исследовательские данные.
Оценка эффективности системы (РИ) имеет особенности, которые мало связаны с особенностями традиционных исследований в режиме управляемого эксперимента (например, в лабораторных условиях): 1) ориентация на реальные задачи, но с наличием помех: 2) ограничение по времени и ресурсам; 3) измерения выполняются скорее в макроединицах, чем в микроединицах (в минутах, а не в секундах); 4) оценивается как аппаратура, так и персонал; 5) используется системный подход; 6) характеризуется высокой обоснованностью; 7) имеется меньше возможностей для управления испытаниями; 8) множе- ствениые цели и множественные критерии (как промежуточные, так и конечные); 9) наличие многих уровней входа в процесс испытания и/или в систему.

Термин «оценка эффективности системы» означает, что ИЧФ измеряет характеристики деятельности персонала. Тестирование по характерным признакам (которое состоит в получении субъективных оценок характеристик системы, оборудования и работы в отличие от деятельности персонала, взаимодействующего с этими характеристиками) не является оценкой деятельности. Наиболее распространенный вид тестирования по признакам - оценка адекватности инженерно-психологических характеристик оборудования. Гир проводил различие между неформальными и формальными процедурами И и О, причем первые относятся к тестированию по признакам (оценка характеристик конструкции аппаратуры, представленной в виде либо чертежей, либо неработающего макета или оборудования), а вторые относятся к измерению деятельности. Оценка характеристик оборудования иногда составляет часть процесса тестирования эффективности работы и поэтому также рассматривается здесь. Изложенное применимо также к таким субъективным инструментам измерения, как интервью, вопросники и ранжирование, которые используются для получения информации об эффективности работы, хотя и не могут использоваться для непосредственного измерения деятельности.

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

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

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

Зачем тестировать прототип?

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

• финальная версия дизайна предпочтительнее для проведения тестов, поскольку она представляет собой рабочую систему, и пользователи, взаимодействуя с ней, будут чувствовать себя гораздо естественнее и спокойнее, а значит и результаты испытаний будут более достоверными;
• некоторые сторонники концепции Lean Startup отмечают, что без тестирования прототипа не понадобится избавляться от него, если он провалит тесты, а значит — не будет и дополнительных расходов;
• отсутствие настроек в гибкой или каскадной модели разработки при согласовании UX и итеративного дизайна.

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

Интерактивные и статичные прототипы

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

Интерактивные (кликабельные) прототипы

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

Статичные прототипы

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

1. «Волшебник страны Оз»

Метод назван в честь популярной книги Фрэнка Баума (Frank Baum). В произведении, как вы помните, волшебником оказался обычный человек. В опыте «волшебник» (роль которого играет дизайнер, хорошо знакомый с прототипом) удаленно контролирует экран участника, находясь в другой комнате. Ни один из кликов пользователя на самом деле ничего не значит. Когда человек совершает действие, «волшебник» за стенкой решает, что должно произойти дальше, и вносит изменения в экран пользователя. При этом испытуемым неизвестен источник изменений и откликов системы. И как правило, они возмущаются, что система постоянно тормозит и долго реагирует.

Этот метод полезен при тестах систем на основе искусственного интеллекта — до его имплементации, поскольку «волшебник», управляющий компьютером, имитирует реакции ИИ на основе естественного интеллекта.

2. Бумажный прототип компьютера

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

3. «Захваченная» мышь (Steal-the-Mouse)

Версия «Волшебника страны Оз», где «волшебник» сидит в той же комнате, что и пользователь (роль «волшебника» может сыграть ведущий). Прототип демонстрируется пользователю на экране компьютера. Как только участник совершает клик, ведущий просит его отвернуться, а сам вносит изменения на экране. Затем человек продолжает работу с прототипом.

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

2. Ведущий должен удерживаться от комментариев и объяснения дизайна пользователю.

Чтобы определить наиболее подходящий вам прототип, ответьте на вопросы:

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

Если большинство ответов утвердительные, то попробуйте кликабельный вариант, если — нет, то подойдет и статичный.

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

Прототип может иметь высокую или низкую точность по всем или некоторым перечисленным компонентам. Ниже объяснено, в чем выражена высокая и низкая точность этих элементов:

Преимущества высокоточных прототипов

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

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

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

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

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

4. Точные в плане интерактивности прототипы освобождают от необходимости имитировать работу системы и дают сосредоточиться на ходе эксперимента.

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

Преимущества прототипов низкой точности

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

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

2. Проще корректировать дизайн в ходе эксперимента

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

3. Неточные прототипы не оказывают давления на пользователей

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

4. Дизайнеры относятся к прототипам без лишнего трепета

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

5. Инвесторы и прочие заинтересованные стороны не докучают вам

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

Взаимодействие с пользователем в ходе испытаний любого прототипа

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

• ведущему необходимо объяснить природу прототипа (но не то, как работает дизайн);
• иногда ведущему необходимо объяснить текущее состояние системы (например, «Эта страница пока не работает») или спросить «Что, как вы ожидали, должно было произойти?»;
• бывает, что ведущему необходимо выяснить, по какой причине участник эксперимента прекратил работу: потому что ожидает отклика или потому что думает, что он выполнил задачу.

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

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

• сказать: «Этот элемент не работает»;
• спросить: «Что, как вы ожидали, должно было произойти?»;
• попросить пользователя щелкнуть по следующему элементу.

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

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

Ошибки «компьютера» искажают данные

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

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

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

Заключение

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

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