- Кейс
- 64 просмотра
Как за 10 дней собрать цифровой вход в художественное образование
хакатон / образование / мобильный продукт / геймификация
Я был единственным дизайнером в команде. За десять дней разобрал входящие документы, превратил таблицу на 2 464 строки и набор разрозненных механик в один маршрут — от интереса к курсу, школе или событию — и спроектировал все экраны приложения.
- Единый маршрутРазрозненная экосистема школ, курсов, материалов и событий сложилась в понятную траекторию пользователя.
- Выбор направленияПрофориентация помогла начать с интересов и уровня подготовки, а не с разбора всех направлений сразу.
- Механика возвращенияЗадания, баллы, достижения и рейтинг сделали прогресс видимым и создали повод возвращаться.
- Связь с городомКарты школ и мероприятий связали обучение со следующим офлайн-шагом.
- Компания
- Московские Школы Искусств
- Роль
- Продуктовый дизайнер
- Период
- 10 дней, 2023 год
- Зона ответственности
- Разбор требований и данных, продуктовый маршрут, все UX/UI-сценарии приложения, механика геймификации, передача сценариев в разработку, подготовка и защита проекта.
- Профориентация и выбор направления
- Курсы и образовательный контент
- Задания, баллы и прогресс
- Карта школ и культурных событий
- CMS и управление контентом
В этой задаче за 10 дней нам предстояло разобраться в системе художественного образования Москвы, собрать продукт, подключить реальные данные и подготовить защиту.
Я отвечал за продуктовую логику и весь дизайн приложения. Пока разработчики собирали один сценарий, я проектировал следующий, поэтому к финалу разрозненные функции сложились в работающий маршрут.
На финальной защите я один представлял работу команды и за шесть минут показал аудиторию, маршрут пользователя, мобильные сценарии, технологии и экономику решения.
Переизбыток идей — тоже проблема
Московские Школы Искусств объединяли 151 учреждение: школы, колледжи, институт и учреждение общего образования. Внутри сети — музыкальные, изобразительные, театральные, хореографические и цирковые направления.
Во входящих материалах уже было почти всё:
- концепция цифровой платформы;
- справочник сети;
- таблица на 2 464 строки;
- 6 413 записей направлений в разных программах и моделях оплаты;
- 21 страница подробных механик заданий;
- готовые факты, квизы, интервью и материалы о школах.
Профориентация, задания, соревнование, видеокурсы, карта и лента стояли в одном ряду. Если просто перенести их в приложение, главный вопрос останется без ответа: что человеку делать дальше?
Задача была в том, чтобы связать уже заданные функции в маршрут и после каждого шага отвечать пользователю на вопрос: что дальше?
Геймификация поддерживала маршрут, но не заставляла зарабатывать баллы перед поиском школы или события.
Во время хакатона этот маршрут был распределён между отдельными сценариями. Схема собирает их в одну логику: выбрать направление, попробовать его и решить, куда идти дальше.
Из таблицы в поиск школ
Исходная таблица описывала учреждения, направления, количество учащихся, программы и модели оплаты, но данные были не структурированы и одно направление встречалось как короткое «фортепиано» и как полное «дополнительная предпрофессиональная программа в области музыкального искусства Фортепиано 8(9) лет обучения».
Для человека это одно направление. В таблице — разные текстовые значения. Я выделил сущности, задал фильтры и связал направление, учреждение и карточку школы. Команда распарсила массив, связала интерфейс с backend и загрузила реальные данные.
Вместо ведомственной таблички получился поиск по 151 учреждению и реальным учебным программам.
Статус нельзя тратить
Во входящем задании про геймификацию была одна общая фраза, что геймификация нужна.
Я сам определял, какие действия поощрять, как считать прогресс и как связать задания, рейтинг, награды и доступ к материалам.
Самая очевидная модель ломала собственную мотивацию: если пользователь тратит рейтинговые баллы на курс, обучение наказывает его потерей позиции.
Поэтому я разделил статус и расходуемую награду.
- Рейтинг фиксировал достижение. Накапливался и показывал прогресс пользователя относительно других;
- Очки разблокировки можно было тратить и они начислялись отдельно. После каждых 100 рейтинговых баллов пользователь получал одно очко разблокировки и мог открыть выбранный бесплатный материал. Покупка материала не отнимала место в рейтинге
Этот сценарий работал в сборке. Подробные достижения, расширенный профиль и часть социальных механик оставались следующим контуром.
Человек сохранял достигнутый рейтинг и сам выбирал награду.
Из этого правила выросли задания дня, уровни сложности, достижения, рейтинг друзей и ежедневные серии.
Обучение не должно ухудшать статус пользователя
Экономика работала, но десяти дней не хватало, чтобы проверить её влияние на возвращаемость учеников. Поэтому в кейсе это гипотеза, а не доказанный эффект.
Как мы довели ядро до работающей сборки
Я отвечал за все UX/UI-сценарии, Сергей Колчин — за backend и DevOps. Продуктовую рамку мы держали вместе.
Я шёл на один сценарий впереди разработки. Мы выбирали следующий кусок, я проектировал состояния и экраны, передавал их разработчикам и сразу переходил дальше.
К финалу приложение работало с backend, CMS и реальными данными.
Рабочим мы считали сценарий, который проходил через интерфейс, backend, реальные данные и управление контентом.
В сборке пользователь открывал курс, смотрел материал и отправлял домашнее задание файлом или видео. Кабинета преподавателя и обратной связи ещё не было.
Через Strapi команда создавала, редактировала и публиковала материалы, после чего они появлялись в приложении.
Поиск школ работал на нормализованной таблице: пользователь переходил от направления к связанным учреждениям и фильтровал их по округу и району.
В приложении работали: профориентация, задания, экономика баллов, курсы, домашние задания, поиск школ и мероприятий и профиль.
За приложением работали: backend, реальные данные, CMS и публикация контента.
Следующим контуром оставались: подробные достижения, часть мини-заданий, кабинет преподавателя и полноценная интеграция с билетным API.
К финалу команда собрала мобильное приложение, backend, CMS, API со Swagger, документацию и макеты в Figma.
Защита: что работало, а что нет
На защите я один представлял работу команды. За шесть минут успел показать основной маршрут, работающие сценарии и техническую часть; время закончилось на дорожной карте.
Жюри спросило, как устроена покупка билета и работают ли домашние задания. Билеты открывались в browser view, а домашнюю работу можно было отправить без кабинета преподавателя — эти границы я проговорил прямо на защите.
После ответов прозвучала оценка:
Хочется отдельно отметить очень много проработанных игровых механик.
В конкурсе участвовали 65 команд. NoTryCatch вошла в шорт-лист, заняла первое место в кейсе Московских Школ Искусств и выиграла 1 млн рублей.
За десять дней мы собрали приложение, backend, CMS и реальные данные в один работающий комплект. Хакатон не проверял удержание, экономический эффект и операционную модель контента.
После победы
После хакатона мы сузили продолжение проекта до сайта-каталога школ.
Около трёх месяцев шли согласования и оформление документов с участием трёх государственных структур. Проект дошёл до дня подписания, но согласования остановились, и контракт не был заключён.
Мобильное приложение осталось работающим хакатонным прототипом. В городской продукт оно не выросло.
Если бы мы продолжили проект сейчас, я бы начал с одного маршрута: выбрать направление, попробовать его и найти подходящую школу. Курсы, события и геймификацию добавлял бы только после проверки этого пути на учениках и родителях.
За десять дней я разобрался в незнакомой предметной области, собрал разрозненные требования в один продукт и вместе с разработчиками довёл его до работающей сборки.
