Идея ученика может быть хорошей, но без конкретного артефакта остаётся только мыслью. Этот формат помогает превратить школьную проблему в простой тестируемый прототип приложения: не ради идеального кода, а ради продуманного решения, ясной коммуникации и готового макета для проверки.
Вместо долгой разработки проводите короткую, ориентированную на дизайн сборку, где ученики решают реальную школьную проблему с помощью простого прототипа. Суть — в ограничениях и в четком результате, который можно показать и тестировать.
Выберите реальную проблему с понятным «до» и «после»
Начните с обсуждения конкретной задачи и того, кому она мешает. Подходящие проблемы имеют определённого пользователя, повторяющийся момент раздражения и измеримый результат в школьной жизни. Быстрый способ сгенерировать такие проблемы — дать короткое время на список мелких раздражений за обычную неделю и затем отсортировать их по частоте.
Примеры школьных задач, которые хорошо работают в учебных проектах:
- ученики не знают, с чего начать, если пропустили урок;
- клубам тяжело собирать регистрации и отправлять напоминания без хаоса;
- репетиторство есть, но подбор помощников запутан;
- учителя отвечают на одни и те же три вопроса каждый день;
- групповые проекты проваливаются из‑за исчезновения ролей и сроков.
Например, задача «Материалы пропущенного урока»: «До» — ученик спрашивает у нескольких человек, что он пропустил. «После» — одна страница в приложении с повесткой на день, пропущенными материалами, двухминутным резюме и одной самой важной задачей.
Называйте аудиторию и цель. Выберите масштаб проекта: микроприложение в одиночку, парная сборка с разделением ролей или маленькая команда с распределением задач. Чтобы проект не превратился в соревнование по функциям, задайте ограничения заранее.
Одностраничная спецификация, чтобы избежать разрастания
Краткая спецификация помогает держать задачу в рамках. Это тренировочный навык: уметь описать продукт просто и понятно. Такая спецификация — контракт между автором и пользователем.
Минимальная спецификация включает:
- Задача: что нужно сделать за одну минуту;
- Ввод: что пользователь вводит, нажимает или выбирает;
- Выход: что показывает прототип;
- Ограничения: какие данные не собираются и что остаётся за рамками проекта.
Пример: Пользователь — девятиклассники, пропустившие урок; Задача — найти одну наиболее важную задачу и материалы за 60 секунд; Ввод — выбрать урок; Выход — повестка, короткое резюме, одна задача, ссылки на раздаточные материалы; Правила — только вымышленные материалы и пользователи, никаких оценок и личных данных; Успех — ученик наверстывает без просьбы к друзьям.
После спецификации переходите к инструменту прототипирования: бумажные экраны, локальный макет или школьно одобренный сервис. Если используется генеративный инструмент, не передавайте личные или закрытые данные. Установите правила по данным, приватности и критериям «готовности».
Прототипируйте быстро и проводите структурированные тесты
Прототип проверяют на понятность задачи с добровольными тестировщиками. Не ограничивайтесь общими отзывами: проводите тест с задачей, таймером и заметками. Цель — обнаружить расхождение между замыслом автора и опытом пользователя.
Простой спринт из трёх раундов укладывается в пару уроков:
- Раунд 1: 90‑секундный тест удобства использования. Тестировщику дают одну задачу (например, «ты пропустил урок — найди, что делать в первую очередь»). Автор молчит и наблюдает.
- Раунд 2: исправьте одну главную проблему. Выбирают самую большую точку трения и меняют только её.
- Раунд 3: проверка доступности и ясности по короткому чеклисту: кнопки и текст читаются с вытянутой руки; важная информация не передаётся только цветом; первый экран объясняет назначение одной фразой; есть возможность отмены выбора.
Чеклист — начальная проверка, а не полная оценка доступности. Таймер помогает заметить затруднения, но не должен наказывать тестировщика за особенности взаимодействия.
Вымышленный пример: «Помощник по записи в клубы». Первая версия просила много персональных данных сразу — тестировщики уходили. Исправление — упростить поток: сначала показать несколько вымышленных клубов, затем предложить тестовый профиль, затем подтверждение. Приложение стало понятнее без добавления реальных данных.
Оценивайте процесс и мышление, а не только внешний вид
Если ставить слишком высокий вес за визуал, ученики будут гнаться за эстетикой и пропускать дизайн-логики. Сделайте основу оценки за процесс: выбор задачи, спецификация, тестирование и обоснование изменений.
Требуйте рефлексию: ученики должны объяснить, что изменилось из‑за тестирования, а не из‑за личных предпочтений. Для структуры задайте три вопроса:
- что сделал тестировщик и что удивило автора;
- что изменили и почему это важно;
- что бы протестировали дальше при дополнительном времени.
Практическое ограничение, повышающее качество: требование одного обоснованного отказа от лишней функции (например, убрать экран входа или перестать собирать электронную почту). Это учит сдержанности как навыку дизайна.
Завершите проверкой соответствия политике данных в школе. Если прототип собирает персональные данные, это вопрос политики: держите прототипы низкорисковыми и локальными — фиктивные данные, отсутствие аккаунтов и открытой публикации, если нет явного согласия округа.
