Прототипирование

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

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

В дизайн-мышлении прототип не служит доказательством правоты автора. Его цель — проверка гипотез.

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

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

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

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

Прототип служит мостом от слов к реальной проверке. Пока идея существует лишь в виде описания, она может казаться автору совершенной и логичной. Однако пользователь может воспринимать её по-другому: не уловить суть сценария, пропустить важный элемент, запутаться в последовательности действий или ожидать чего-то иного. Прототип позволяет выявить эти различия.

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

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

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

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

Для описания сценария можно использовать простую схему:

триггер → барьер → действие → результат → следующий шаг

Триггер — что запускает ситуацию. Например: студент получает новое задание от преподавателя.

Барьер — что мешает пользователю. Например: дедлайн указан в сообщении, но не занесён в общий список задач.

Действие — что пользователь должен сделать с помощью решения. Например: добавить задание в недельный планер.

Результат — что пользователь получает после действия. Например: он видит задачу, срок и приоритет в общей системе.

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

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

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

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

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

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

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

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

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

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

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

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

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

В прототипе необходимо четко прояснить:

— Для кого предназначен — Какой сценарий пользователя он иллюстрирует — Какую задачу помогает разрешить — Какие действия должен выполнить пользователь — Каков ожидаемый результат — Какую предположение студент намерен проверить

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

Допустим, проектный вызов звучит так: «Каким образом мы можем облегчить для студентов 1 курса навигацию по учебным заданиям и срокам на протяжении недели?»

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

Возможный сценарий может выглядеть так:

Триггер: студент получает новое задание. Барьер: задание приходит не в той же системе, где хранятся остальные задачи. Действие: студент заносит задание в недельный планер. Результат: студент видит дедлайн, сложность и приоритет задачи. Следующий шаг: студент распределяет выполнение задания по дням.

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

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

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

Перед демонстрацией прототипа необходимо убедиться:

1. Понятно ли, что это за решение?
2. Понятно ли, для какой ситуации оно создано?
3. Есть ли в прототипе ключевой пользовательский сценарий?
4. Можно ли дать пользователю простое задание?
5. Понятно ли, какую обратную связь нужно получить?

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

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

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