tgoop.com/ielearning/5132
Last Update:
Добрый день, коллеги 👋🏼
С вами Осипов Михаил.
Методическое качество образовательного продукта связано не только с раздаточным материалом, которые мы создаём для студентов: инструкции, чек-листы, рабочие тетради и т.д., но и готовыми шаблонами (или фреймворками), которые используем командами для ускорения создания таких образовательных продуктов.
На просторах интернета я изучил более 200 готовых методических фреймворков. Многие из их авторов — это практикующие методологи, педагогические дизайнеры, методисты и т.д.
В ходе анализа были выявлены ошибки по составлению фреймворков. Хотелось бы ими с вами поделиться, опираясь на свой опыт👇🏼
1️⃣ Отсутствие терминологического аппарата.
Автор методического фреймворка на ходу выдумывает новые термины. Либо не обозначает определение терминов. Чем усложняет применение фреймворка пользователями (т.е. теми, кто проектирует образовательные продукты).
Как нужно 👉🏼 если фреймворк разрабатывается в документе Word, то полезно в самом начале (так часто делаю) формировать глоссарий. Например, как показала практика, «формат обучения» интерпретируется сотнями коллег по-разному, а если вы сперва сформулируете теоретическую рамку, то всем станет понятно, что имеется ввиду.
Ещё один способ — это всплывающие определения при наведении на термины мышкой. Но это возможно, например, если фреймворк создаётся на платформе для создания лонгридов. Наблюдал данную механику в Яндекс. Практикуме.
2️⃣ Высокая акцентуализация на оформлении.
Безусловно эмоциональный дизайн влияет на восприятие и вовлеченность пользователя. Но иногда «красота разум перекрывает», или «как бы красивее оформить, чтобы быстрее продать».
Но когда являешься практиком, то первое на что обращаешь внимание — это содержание.
Как нужно 👉🏼 больше времени уделять проработке структуры и содержания: анализировать различные источники (от научных статей до книг), собственные базы знаний, наработанный опыт на проектах и т.д.
У меня, например, на разработку фреймворка по созданию тестовых заданий ушло больше месяца. Естественно, можно было потратить меньше времени и красивее его оформить. Но стояла другая цель — создать содержательный методический инструмент, который можно брать и применять на практике вне зависимости от опыта пользователя.
3️⃣ Отсутствие проверенных источников.
Автор фреймворка берёт первые попавшиеся материалы из поисковика, или нейросети. Редактирует их за пару часов и выдаёт пользователям. Ни источников, ни упоминания личного опыта в сносках, ни-че-го.
В целом, где-то 2-3% авторов из тех, что я просмотрел, указывают источники при разработке фреймворков.
Как нужно 👉🏼 указывать источники, на которые опиралась разработка методического фреймворка. Так вы не только покажете глубину проработки, но и подчеркнете доказательность всего того, что рекомендуете вашим пользователям. Я, например, в каждом фреймворке указываю ссылки на книги, научные статьи, интернет-ресурсы, опыт коллег и так далее.
4️⃣ Отсутствие примеров как правильно делать.
Автор описывает только теоретическую рамку фреймворка. Например, что такое модель 4C/ID и из каких компонентов она состоит.
Как нужно 👉🏼 указывать примеры, кейсы или успешные практики использования модели. Если нет возможности, то использовать максимально аутентичные условия, чтобы пользователям было понятно как применять фреймворк на практике.
5️⃣ Отсутствие популярных ошибок (авторских)
Практика видно издалека — он может рассказать об ошибках. Иногда «как надо делать» понятно, а «как не надо» — не совсем.
Как нужно 👉🏼 крайне ценно, когда автор может подстраховать пользователей фреймворка, а не просто рассказать как выполнять тот или иной алгоритм действий. Например, если фреймворк посвящен разработке дорожной карты студента (Students journey map), то можно описать наиболее популярные ошибки, которые совершаются при прогнозировании образовательного опыта. Одной из ошибок, например, является отсутствие проведения рефлексии с командой разработчиков по SJM после реализации образовательного продукта.
Коллеги, а вы используете методические фреймворки
