1. Если это сложные правки (к примеру, сделать корзину товаров), то необходимо уточнить у программистов - возможно ли это, т.к. не все движки сайтов позволяют сделать таковое.
2. Бывают моменты, когда движок сайта не предусматривает, к примеру, создание той же самой корзины, но программисты могут это реализовать в рамках «платных» правок. Т.е., если программист отвечает вам, что движок сайта не позволяет внести рекомендованные вами правки, то следует спросить о возможности внесения данных правок платно.
3. При создании тестовой версии страницы, ее необходимо закрыть в robots от индекса, дабы избежать дублирования с основной страницей.
Т.е., к примеру, при создании тестовой страницы http://www.site.ru/test/, необходимо в задаче на создание также указать следующее:
Добавить в robots Disallow: /test/
4. Само описание правок по юзабилити должно быть четкими, подробным и исчерпывающим. Желательно наличие подробных скринов с пометками, которые значительно улучшают понимание куда и что вносить.
5. После внесения, прежде чем отправить клиенту на одобрение тестовую версию, необходимо проверить корректность всех внесенных правок.
Важно учитывать так же и коммуникационные факторы. Не всегда все понятно по тексту поставленной задачи – одно и то же предложение несколько людей могут воспринять по-разному. Для этого существует ICQ. Не надо стесняться писать, задавать вопросы.
К примеру, чтобы не тратить время свое и программиста на задачу по вопросу о возможности внесения правок, можно спросить это в ICQ.
Так же, стоит помнить, что электронное общение никогда не заменит живого и иногда проще всего спуститься к программисту и вживую ему все объяснить, затратив на это всего минут 5, нежели целый час переписываться, пытаясь донести свою мысль.
10 Рекомендации по созданию прототипов для юзабилити-тестирования
Исследование пользователей — это изучение человеческого поведения, поэтому лучшие результаты даёт наблюдение за тем, как участники что-либо делают и затем обсуждают свои действия. Исследование мнений и описаний воображаемых реакций не приносит пользы, так как людям бывает сложно представить своё поведение вне контекста или оценить дизайн, не испытав сервис в работе. Таким образом, лучший способ оценить новый проект — создать прототип и дать целевой группе конкретный объект, с которым можно взаимодействовать.
Конечно, тестирование прототипа отличается от тестирования полностью функционирующего сайта или приложения. В этом обзоре собраны рекомендации, касающиеся того, как сделать эффективнее проверку эргономичности и избежать проблем при тестировании прототипов.
Сначала — дизайн, затем — прототип
Не позволяйте технологическим сторонам прототипирования влиять на результат разработки. Лучшие инструменты для создания прототипов не всегда хороши для проектирования. Разрабатывать дизайн одновременно с моделью может быть быстрее, но ограничения, накладываемые на прототип инструментом его создания — последнее, о чём стоит думать в процессе работы. Если вы заметили, что попытки настроить элемент в прототипе отнимают больше времени, чем дизайн, стоит сделать шаг назад и сосредоточиться на проектировании, а затем подумать, как реализовать функцию в прототипе.
Используйте наполнение, связанное с реальным проектом
Пользователи замечают мельчайшие детали модели и неправдоподобные данные. В теории прототипы без актуального наполнения не стоило бы допускать к тестированию, однако на стадии прототипирования реального контента обычно не бывает и приходится использовать «рыбу». Главное, чтобы контент соответствовал теме, не отвлекал участников от задачи и не мог дать ошибочного представления о проекте. Существует несколько видов нежелательных данных.
Не используйте «Lorem Ipsum»
Каждый раз при появлении текста «Lorem Ipsum» (как на Рисунке 1), кто-нибудь из участников спрашивает «Почему здесь всё на испанском?». Кроме того, что текст приводит в недоумение и может спровоцировать ошибки, он лишён какого-либо контекста и не даёт ни малейшего представления о финальном наполнении. Иногда для понимания назначения страницы контекст просто необходим. Старайтесь всегда использовать актуальное наполнение или найти подходящую рыбу.
Избегайте вымышленных имён
Не используйте в прототипах имена известных людей или персонажей. Однажды в качестве авторизованного пользователя выступал Джек Воробей (Рисунок 2). Вы бы не хотели, чтобы в разгар сессии участники забыли о поставленных задачах и погрузились в мысли о Джонни Деппе или о том, как ужасны последние «Пираты Карибского моря». Лучше использовать правдоподобные, но стандартные имена — здесь поможет генератор случайных имён, каких много в интернете.
Аккуратно используйте стандартные заготовки
Использование для замены изображений стандартных заготовок, например, блоков с крестами, может смутить участников теста. Некоторые из них могут воспринять заготовки буквально — решить, что блок со словом «Пиктограмма» будет присутствовать в финальном интерфейсе. Изображения с декоративной функцией вполне разумно замещать заготовками. Но если для понимания интерфейса необходимы тематические иллюстрации, найдите подходящие заглушки.
Используйте подходящее оформление
Иногда условности в оформлении мешают пользователям: акцентируют внимание на деталях, формируют неверное представление или отвлекают от тестируемого интерфейса. Например, на рисунке 4 показан прототип, где часть данных замещена иксами. Использование их вместо полного номера социального страхования вполне логично, но у пользователей может возникнуть вопрос: будут ли они использоваться в финальном варианте или это тоже «рыба»? В любом случае, подобные мысли могут отвлечь тестеров от задач, на которых вы хотели сосредоточить их внимание.
Будьте внимательны, если прототип разрабатывает другая сторона
Старайтесь работать над прототипом самостоятельно или в тесном сотрудничестве с теми, кто его создаёт. Во время исследования прототип прорабатывают в соответствии с поставленными задачами: зачастую приходится исправлять ошибки и добавлять новые функции. Если созданием прототипа занимаетесь не вы — например, клиент — быстро и точно вносить изменения уже не получится.
Убедитесь, что прототип точно соответствует дизайну
Пусть это очевидно, но если созданием прототипа занимается другая сторона, его соответствие дизайну надо проверять. Случай, когда клиент самостоятельно создает модель на основе нашего дизайна; это большая ошибка: прототип может не соответствовать проекту, и внести нужные изменения перед тестированием просто можете не успеть.
Исправления ошибок в прототипе не должны касаться проектной части
Несмотря на всеобщие усилия, ошибки в прототипе неизбежны, и тестирование их выявит. Естественно, клиенты захотят исправить всё между сессиями. Имея доступ к прототипу, они могут не удержаться и попытаться решить все выявленные при тестировании проблемы. Результат поспешных выводов может быть удручающим. В худшем случае «ошибки» исправят без вашего ведома, пока вы заняты тестированием. Будьте начеку и объясните клиенту, почему не стоит вносить изменения до окончания исследования.
Приведите прототип к соответствию с инструкцией
Разработчиков мучает своя версия дилеммы «курица или яйцо»: что должно быть вначале — прототип или инструкция для тестирования? Должна ли инструкция описывать тестирование готового прототипа или прототип должен создаваться для тестирования задач, описанных в инструкции? В большинстве случаев допустимы оба варианта. Обеспечить соответствие прототипа и руководства можно, следуя следующим рекомендациям:
Определите, какие функции вы будете тестировать.
Создайте прототип.
Разработайте инструкцию для тестирования.
Используя прототип, проработайте все задачи в инструкции. Убедитесь, что всё работает.
Внесите необходимые исправления в прототип и инструкцию.
Проводите тестирование в несколько этапов с прототипами разной степени детализации
Одни специалисты выступают за тестирование грубых прототипов на начальном этапе проекта, другие предпочитают подождать и тестировать более точную модель. Однако в идеале тестирование юзабилити следует проводить в несколько этапов, повышая степень детализации прототипа
Тестируйте без прототипа
Начинать тестирование можно ещё до того, как появится прототип. Прежде чем приступать к дизайну страниц, полезно проверить правильность основных решений. Такие аспекты, как организация информации и определение категорий, можно тестировать с помощью прямой и обратной карточной сортировки. Благодаря тестированию важнейших аспектов дизайна ещё до появления прототипа можно оценить структуру и названия категорий независимо от дизайна страниц. После создания работающей модели можно сосредоточиться на тестировании разметки и интерактивных связей.
Тестируйте грубые прототипы
Проверяйте решения, касающиеся организации информации, названий категорий и навигации, на грубых прототипах, как это показано на Рисунке 5. Бумажные прототипы создаются легко и быстро, затем дизайн уточняют в ходе нескольких этапов тестирования. Неформальный вид грубого прототипа даёт понять, что работа не закончена, и это облегчает участникам высказывание критики.
При тестировании бумажного прототипа самая сложная задача — исполнение роли компьютера. Кто-то должен имитировать реакцию системы на действия участников: ему приходится быстро находить и показывать изображения нужных экранов, меню и других элементов. Чем выше уровень проработки прототипа, тем сложнее ориентироваться в страницах, меню и остальных компонентах. Для эффективного выполнения этой работы нужна практика, поэтому перед тестированием с участием целевой группы необходимо провести несколько репетиций. Совмещать обязанности модератора, секретаря и выступать в роли компьютера — для одного человека невозможно, поэтому для тестирования понадобится команда как минимум из двух человек.