Course Management System
How I designed a system from scratch that removed manual data transfer from course production
Savings:
up to RUB 4,200,000 per year
About the project
Context
The team kept course programs in Google Sheets and moved them into the admin panel by hand. Every edit meant another transfer, and errors reached students. I designed a system where methodologists and coordinators work with the program directly, with no manual transfer and no duplicate documents. By a preliminary estimate, the system saves RUB 1.8 to 4.2 million per year on manual data syncing
Before implemantation
Context and business goal
Many people build a single course. A methodologist prepares the program, a coordinator moves it into the admin panel, and everything configured there shows up for the student in their account, on the web and in the app. Any edit restarts the transfer. A transfer error lands on the student’s screen immediately
User problems and insights
The team worked in Google Sheets. The methodologist and the coordinator kept separate files, and after every edit the coordinator moved the data into the admin panel by hand
Duplicate documents
One program meant several documents with overlapping content. They had to be updated in parallel
Lack of standards
Each department documented in its own template. There was no shared format and no shared process
Changes are not tracked
Edits were not saved in one place. The only way to recover history was to ask whoever was responsible
Scattered storage
There was no single repository. Program passports lived in different folders and files, so finding the right one was hard
Discovery
Process mapping
To see these problems as a whole, I mapped the process from scratch. No process diagram existed, the methodologist did not know how the coordinator worked, and the coordinator did not know how the methodologist worked. I built the picture interview by interview, with each group separately
Business process
User Story alignment
I studied the needs of each role separately. The result was a set of agreed User Stories with priorities: what ships first, what moves to later stages
User Story
Hypotheses
Single interface with role switching
One interface with a “methodologist / coordinator” switch and a shared set of screens that adapt to the selected role. This approach saves development effort: one set of components instead of two
❇️ Pros
Development speed
One set of components instead of two, so development is cheaper
No duplicated logic
Versioning and storage work the same on every screen, with no second implementation
Edits in one place
Changes to shared elements, such as the program structure, are made once instead of twice
🛑 Risks
Overloaded screen
You either show the scenarios of both roles at once or hide part of the functions behind a switch
Coordinators get in the way of methodologists, and the reverse
To quickly see the current state of a program, the coordinator would have to dig through the methodologist’s functions
Role switching
An action that solves no user task
Two separate interfaces
A separate interface for the methodologist and a separate one for the coordinator, each with its own navigation and its own set of tasks. I chose this hypothesis because it removes the core friction: each role no longer has to dig through someone else’s scenarios to find its own
❇️ Pros
Only relevant scenarios
Only relevant scenarios
Each role sees only what it needs, with no extra navigation
Each role sees only what it needs, with no extra navigation
Independent evolution
The methodologist’s interface can be changed and refined separately from the coordinator’s
Error isolation
A fix or a failure in one interface does not affect the other.
🛑 Risks
Two interfaces instead of one
More development and maintenance effort, at the start and later
Syncing shared entities
Programs, versions, and history have to stay consistent across two interfaces
Role overlap
If the roles’ tasks start to overlap over time, the two interfaces will have to be merged again
What we chose
I chose the second hypothesis. The methodologist and the coordinator work with the same data set but solve different tasks: one creates and versions the program, the other accepts changes and launches course streams. A shared interface would have to be either overloaded with every scenario at once or hide part of the functions behind a switch, and both options would make the work harder instead of easier
User Flow
I designed a separate user flow for each role. The shared principle: every action happens inside the system, with no manual syncing
UX-Flow
Testing
UX Test
I built two interactive prototypes, one for the methodologist and one for the coordinator. Each prototype covered its own key scenarios
Prototype
Что работало хорошо
Структура и логика редактирования читались сразу
Подсказки модератора никому не понадобились. Навигацию и правку модулей и занятий считывали уверенно, и ни один респондент не переспросил, как что-то поменять
Черновик понятен с первого взгляда
Большинство респондентов верно поняли, что это такое: правки в черновике не затрагивают версию в проде. Поэтому и экспериментировать не боялись
Программа делается без внешних сервисов
Никто не искал способ выйти за пределы системы. Программу создавали и правили прямо в ней, а экспорт в CSV не вызвал ни одного уточняющего вопроса
Изменения прозрачны, передача занимает один шаг
Респонденты видели, кто и что менял: история хранит авторство и время правок. А передачу изменений координатору закрывали без лишних действий
Что работало плохо
Непонятные элементы таблицы
Чекбокс и кнопка «+» сбивали с толку. Было неясно, за что отвечает каждый
Похожие кнопки с разным смыслом
«Утвердить УП» и «Обновить УП по последнему потоку» пользователи путали между собой
Незаметный чекбокс
Чекбокс передачи изменений координатору часто оставался незамеченным. Важное действие терялось на экране
Неожиданный автопереход
Автоматический переход внутрь созданного элемента заставал врасплох. Система действовала за пользователя и не предупреждала об этом
Что ушло в реализацию
Итерация после UX-теста
После теста я доработал интерфейс и упростил ключевые сценарии. В итоге получились два отдельных интерфейса под две роли, с разной логикой и разным набором задач
Методист
Программу теперь создают и правят целиком в системе. Методист больше не держит несколько файлов и не синхронизирует их руками. Версии, черновики и передача правок живут в одном месте
Координатор
Больше не переносит данные в админку руками после каждой правки. Актуальное состояние программы всегда под рукой
Результаты
Эффект в масштабе портфеля
В портфеле компании 261 курс. Каждый обновляется минимум раз в год, и ещё 4-5 новых запускаются ежегодно
до 4 200 000 ₽
в год ожидаемой экономии на ручной синхронизации данных
Обновление курсов
На синхронизацию одного обновления уходило от 8 до 20 часов одного человека, то есть 5 000–12 500 ₽ на каждое обновление. При 261 обновлении в год это 1 305 000–3 262 500 ₽ в год
Новые курсы
На производство нового курса уходило около 200–300 часов синхронизации, то есть 125 000–187 500 ₽ на каждый новый курс. При 4-5 запусках в год это 500 000–937 500 ₽ в год
Что я бы сделал иначе
Я не тестировал похожие по смыслу кнопки «Утвердить УП» и «Обновить УП по последнему потоку» до UX-теста. Проблема всплыла только на прототипе, а могла быть пойманной раньше, на этапе интервью с демонстрацией черновых макетов