Тестирование и интерация

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

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

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

Цель тестирования не в том, чтобы узнать, нравится ли пользователю проект, а в том, чтобы определить, насколько эффективно прототип справляется с поставленной задачей и решает выявленную проблему.

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

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

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

В минимальный план тестирования можно включить:

1. Кого тестируем Представители целевой аудитории, для которой создаётся решение.

2. Что показываем Прототип, сценарий, макет, схема, шаблон, визуальный материал или другой формат решения.

3. Что проверяем Основная гипотеза или ключевой пользовательский сценарий.

4. Какое задание даём пользователю Короткая ситуация, в которой пользователь должен взаимодействовать с прототипом.

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

Например:

Гипотеза: если студент видит задания и дедлайны в одном недельном планере, ему проще оценить нагрузку и спланировать работу. Задание для пользователя: «Представьте, что у вас появилось три новых учебных задания. Добавьте их в планер и объясните, как вы будете распределять работу по дням». Что фиксируем: понял ли пользователь структуру планера, смог ли добавить задачи, какие элементы вызвали трудности, что он предложил изменить.

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

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

В процессе тестирования не стоит давать слишком много подсказок. Если пользователь застрял, можно задать вопросы, например: «Что вы ожидали увидеть на этом этапе?» или «Что именно вызывает у вас затруднения в этом месте?».

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

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

Избегайте вопросов, таких как: — Вам понравилось? — Правда, это удобно? — Вы бы пользовались этим каждый день? — Согласны, что это хорошее решение?

Такие вопросы часто дают поверхностные ответы.

Лучше спросить:

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

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

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

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

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

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

Если студент не успел внести изменения в сам прототип, можно составить план доработки. Главное, чтобы план был конкретным, а не общим.

Плохо: Нужно улучшить дизайн.

Лучше: Добавить пояснение к цветовой маркировке, сделать поле дедлайна заметнее и сократить количество категорий задач, потому что пользователи путались при заполнении планера.

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

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

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

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

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

Оценка за главу 6 = 0,20 × З1 + 0,35 × З2 + 0,45 × З3

Где: Задание 1 — 20% Задание 2 — 35% Задание 3 — 45%