Ниже приводится небольшая выдержка из нашей книги « Проектирование UX: прототипирование» , написанной Дэном Гудвином и Беном Коулманом. Это полное руководство по прототипированию. Члены SitePoint Premium получают доступ к своему членству, или вы можете купить копию в магазинах по всему миру.
Что мы можем сделать прототипом?
Проще говоря, для создания прототипа мы могли бы рассмотреть те вещи, которые мы могли бы использовать для эскизов и каркасов, чтобы исследовать и разрабатывать их.
Теперь мы рассмотрим некоторые элементы, прототипы которых особенно полезны при разработке веб-сайта.
Информационная архитектура и структурные элементы
Представление структуры сайта в виде диаграммы карты сайта команде проекта и заинтересованным сторонам часто неэффективно. С такой диаграммой еще сложнее протестировать конструктивные элементы пользователем. На более детальном уровне мы имеем ту же проблему тестирования и представления других аспектов информационной архитектуры, включая структуру, поведение и маркировку в навигации или таксономии (например, категории, которые пользователи могут использовать для сегментирования и запроса продуктов в онлайн-магазине).
Можно создать интерактивный прототип и наполнить его реальными структурными элементами (например, первичной и вторичной навигацией по страницам, категориями продуктов). Затем мы можем проверить эти структуры: иерархию страниц, поведение навигации и метки, которые мы предлагаем реальным пользователям, которым даны реальные задачи для выполнения. Мы можем представить заинтересованным сторонам нашу информационную архитектуру захватывающим, осязаемым способом, который они могут визуализировать и исследовать.
Это особенно хорошо подходит для загрузки реального контента для создания прототипов, которые затем используются для производства. Мы можем начать с низкого уровня точности, загрузив структуру веб-сайта в базу данных системы управления контентом (CMS) для прототипа. Затем мы можем повысить точность, добавив заполнитель контента, а затем еще больше, добавив реальный контент. Этот контент затем может быть потенциально использован в производственной реализации. Мы поговорим об этом подробно в главе 7 .
Макет и визуальная иерархия
Мы можем использовать прототип для разработки, тестирования и передачи общего макета и иерархии элементов, составляющих страницу. Это тот тип дизайна, в котором мы традиционно использовали каркасы.
Возьмите пример сайта, на котором представлен ассортимент пылесосов. У нас мог бы быть список всех уборщиков, сгруппированных или категоризированных определенным способом; например, страница для каждого отдельного уборщика, показывающая спецификации, опции и отзывы пользователей. Мы должны решить, какой контент показывать в листинге и что отображать на одной чистой странице, а также как их размещать.
Мы можем использовать данные исследований пользователей, чтобы помочь нам, например, задачи, которые пытаются достичь различные типы пользователей, какая информация необходима для решения этих задач, а также что считается важным / менее важным. Оттуда мы можем предложить предложенный макет для листинга и для одной страницы. Затем мы можем реализовать это предложение в прототипе, в идеале используя некоторый реальный контент.
Прототип позволяет нам представить предложение заинтересованным сторонам и протестировать его с реальными пользователями. За время существования нашего прототипа мы можем добавлять, удалять и изменять контент, а также изменять макеты, которые мы предлагаем. Мы можем проверить небольшие изменения или радикальные альтернативы макету. Если реализация нашего прототипа имеет хорошее разделение контента и представления, процесс изменения макета при сохранении того же базового контента будет простым. Это означает, что мы можем тестировать больше макетов, быстрее и проще.
Интерактивные элементы
Все веб-сайты имеют по крайней мере некоторые интерактивные элементы (например, ссылку), но многие имеют интерактивные элементы, которые являются более сложными и сложными. Это требует значительного количества дизайна пользовательского интерфейса.
Рассмотрим пример интернет-магазина по продаже одежды и аксессуаров. Пользователи, как правило, предъявляют различные требования к сужению своего поиска одежды, будь то по размеру, цвету, сезону, типу одежды, ткани, бренду и так далее. Это часто приводит к тому, что дизайнеры магазина электронной торговли рассматривают многогранный шаблон навигации , где пользователи могут сузить свой поиск по нескольким наборам критериев — например, среднего размера, желтого цвета и хлопчатобумажной ткани — и быстро увидеть результаты.
Хотя это звучит достаточно просто, это удивительно сложная функция для проектирования. Способность прототипа помочь нам опробовать идеи для разметки категорий, их метода взаимодействия и того, какими категориями можно сузить результаты, значительно повысит наши шансы на справедливость. Мы можем использовать приличный набор репрезентативного контента для быстрой реализации ряда идей для представления и взаимодействия с этим контентом. Мы можем поделиться своими идеями с заинтересованными сторонами и протестировать их с реальными пользователями — повторяя, изменяя и экспериментируя по ходу работы.
Без прототипа такая быстрая итерация могла произойти только после того, как интернет-магазин был (хотя бы) частично реализован. Прототипирование позволяет нам делать это раньше, быстрее и дешевле.
Что мы не можем сделать с прототипом?
К настоящему времени, я надеюсь, у вас есть много идей для прототипа и что можно достичь, создав его. Тем не менее, стоит обратиться к тому, чего мы вряд ли достигнем с прототипом.
Используйте количественные исследования для принятия решений
Если вы хотите опробовать некоторые дизайнерские идеи с целью использования метрик для оценки того, что «лучше» (например, больше регистраций, больше конверсий, самый высокий уровень выполнения задач), прототип вряд ли поможет. Для такого рода тестов вам нужен большой размер выборки — обычно в тысячи или десятки тысяч; однако использование количественных исследований для принятия таких решений выходит за рамки этой книги.
Стоит отметить, однако, что прототипы, как правило , помогут вам протестировать свои проекты с большим количеством пользователей более успешно, чем альтернативы, такие как эскизы или каркасные модели. Это объясняется простотой реализации, совместного использования, публикации и запуска тестов с прототипами, а также повторения этих тестов над другими методами.
Тестирование на выполнение последовательности выполнения / конверсии
Обычно плохой идеей является попытка измерить успех воронки завершения / конверсии задачи (например, как далеко продвигаются пользователи сайта электронной коммерции вдоль воронки продаж) с помощью пользовательских тестов, будь то прототип или производственный сайт. Количественный измерение прогресса в последовательности целей описано в книге SitePoint Researching UX: Analytics : https://www.sitepoint.com/premium/books/researching-ux-analytics .
Это связано с тем, что в наблюдаемом сценарии пользовательского тестирования пользователи мотивированы на выполнение задач, с которыми они сталкиваются, просто по своей природе участия в пользовательском тесте. Мы можем ожидать услышать комментарии в духе «я бы уже сдался», которые в некоторой степени полезны. Но поскольку то, что пользователи говорят, что они делают, и то, что они на самом деле делают, могут быть двумя совершенно разными вещами, такие комментарии только помогают до некоторой степени. При использовании сайта в естественном контексте поведение пользователя в действительности может сильно отличаться, а терпимость к плохому дизайну значительно ниже.
Тестирование доступности
Большинство методов создания прототипов не соответствуют конечной производственной реализации и, как следствие, не могут использоваться для проверки доступности проекта; например, измерение способности пользователей вспомогательных технологий получать доступ к контенту и функциям.
Как правило, прототипирование HTML выполняется очень грубо и готово, поэтому стандарты кодирования и доступ к ним практически не учитываются.
Доступная реализация важна, и ее лучше проверять и тестировать на производственной площадке до запуска и на постоянной основе. Тем не менее, если вы хотите проверить доступность определенных функций в прототипе (например, сложный интерактивный элемент), нет никаких причин, по которым вы не могли бы построить эти функции в соответствии с соответствующими стандартами и протестировать их.
Тестирование влияния визуального дизайна
Как правило, прототипы создаются с уровнем точности, который слишком низок, чтобы проверить влияние визуальных элементов дизайна, таких как размеры шрифта, цвета фона или границы, на визуальную иерархию дизайна.
Некоторые инструменты и методы создания прототипов (такие как InVision, обсуждаемые в главе 6 ) позволяют создавать прототип из макетов дизайна высокой точности. Следовательно, если вы можете придумать разумную стратегию пользовательского тестирования, вы можете использовать ее для проверки влияния ваших изменений визуального дизайна.
Быть единственным источником документации
Agile (будь то маленький или большой Agile) предпочитает рабочее ПО, а не всеобъемлющую документацию, поэтому для некоторых команд вполне естественно полагаться исключительно на свой развивающийся прототип при документировании своих действий.
Прототипы сами по себе не документируют историю создания дизайна (хотя здесь может помочь хороший рабочий процесс контроля версий). Поэтому важно, чтобы вы позаботились о том, чтобы документировать изменения между версиями при разработке своего прототипа. Точно так же, один прототип не всегда показывает достаточно, чтобы предоставить достаточную документацию для полного проектирования и разработки. Кроме того, заинтересованным сторонам или членам проектной команды слишком легко упустить важную функцию, потому что они не смогли нажать на эту часть прототипа.
Чтобы смягчить эти проблемы, подумайте, как вы можете создать достаточно вспомогательной документации и истории принятия решений, чтобы группа могла понять, что было реализовано и почему.