UX/UI Designer · 2022 - 2025
Спроектировала флоу, где родители подают заявление онлайн, а школа видит даты, причины и статусы без звонков, бумажных заявлений и ручных уточнений.
Schooly — MIS-система для частных школ. Сотрудники управляют учениками и административными процессами в веб-приложении, родители взаимодействуют со школой через мобильное приложение.
Уход ученика происходил за пределами Schooly: родитель писал или звонил в школу, сотрудник получал информацию в свободной форме и вручную переносил её в систему. В результате данные о дате, причине и статусе ученика зависели от переписки и ручных действий сотрудников.
Собрать уход ученика в единый цифровой процесс: дать родителю способ самостоятельно сообщить об уходе, а школе — получить структурированные данные и синхронизировать дату и статус ученика без ручного переноса информации.
Автоматизация сценария должна была повлиять не только на опыт родителя, но и на операционную эффективность школы, качество данных и управляемость оттока учеников.
Операционная эффективность
Сократить время обработки ухода, количество ручных действий, звонков, переписок и передач информации между сотрудниками и отделами.
Качество данных
Повысить актуальность статусов учеников, сократить количество ручных ошибок и собирать причины ухода в структурированном виде.
Бизнес-ценность
Дать школе данные для анализа оттока: понимать, почему ученики уходят, отделять внешние причины от тех, на которые школа может повлиять, и использовать эту информацию для работы с retention, планирования количества учеников и связанных финансовых процессов.
На первый взгляд сценарий мог ограничиться несколькими экранами для подачи заявления. Но за простым действием «сообщить об уходе» скрывалась гораздо большая продуктовая логика.
Нужно было определить, как уход ученика повлияет на его статус и связанные процессы, где и в каком виде будет храниться эта информация, как будут пересчитываться и распределяться оплаты, что произойдёт с уже внесёнными средствами и как связанные статусы будут меняться в разных частях системы.
При этом изменения затрагивали сразу несколько разделов Schooly: мобильное приложение родителя, профиль и список учеников в веб-приложении, настройки школы, статистику, уведомления и email-коммуникации.
Поэтому основная сложность была не в проектировании формы, а в том, чтобы встроить новый сценарий в существующую продуктовую систему и согласовать поведение всех связанных процессов.
До проектирования я собрала черновой flow и список открытых вопросов. Вместе с продакт-менеджером мы прошли сценарий от подачи заявления до изменения статуса ученика и зафиксировали правила системы.
В результате до UI были определены основные состояния, ограничения и edge cases: кто может подать заявление, когда оно доступно, какую дату можно выбрать и как заявление влияет на статус ученика.
Перед проектированием я изучила, как похожие задачи решены в других образовательных продуктах. Посмотрела демо-версии систем-конкурентов, а также смогла пройти реальные сценарии в МЭШ благодаря доступу через учащуюся сестру и знакомых учителей.
Дополнительно изучила механики отмены подписок и удаления аккаунтов в продуктах из других сфер — как примеры действий с серьёзными последствиями для пользователя.
Я сравнивала не визуальные решения, а саму механику сценариев: как объясняются последствия, когда запрашивается причина, требуется ли дополнительное подтверждение, что происходит после отправки и можно ли изменить принятое решение.
Я собрала решение из шести продуктовых механизмов.
Родитель выбирает дату ухода, указывает причину и отправляет заявление непосредственно в Schooly. Система сразу учитывает правила конкретной школы и блокирует даты, в которые уход невозможен, поэтому некорректное заявление нельзя отправить изначально.
Подача заявления не создаёт новый статус ученика: до даты ухода он сохраняет текущее состояние, а в назначенный день Schooly автоматически переводит его в следующий статус. Это позволило встроить новый сценарий в существующую модель, не усложняя её дополнительными состояниями.
Школа самостоятельно задаёт допустимые сроки уведомления и формирует список причин ухода. Schooly учитывает эти настройки при заполнении заявления: блокирует недоступные даты и показывает родителю актуальные для конкретной школы причины.
При этом всегда остаётся вариант «Другая причина» — родитель может выбрать его и описать ситуацию своими словами.
Если родитель передумал до даты ухода, заявление можно отменить без последствий для данных ученика. Система автоматически возвращает прежнее состояние и связанные сущности — статус, платежи, счета и другие процессы, которые были затронуты заявлением.
Это снижает риск потери данных и избавляет сотрудников школы от ручного восстановления информации.
Сотрудники школы видят всех учеников с запланированным уходом, даты и причины в привычном рабочем пространстве. Это позволяет работать с заявлениями как с частью системы, а не собирать информацию из писем, звонков и переписок.
Уход ученика автоматически учитывается во всех связанных процессах Schooly: профиле ученика, списках, статистике, продлении обучения, коммуникациях и, особенно, в платежах и выставлении счетов.
Система должна корректно учитывать дату ухода при формировании будущих начислений, счетов и других финансовых обязательств, чтобы школе не приходилось вручную пересчитывать платежи, отменять или перевыставлять счета и проверять, что ничего лишнего не начислилось после ухода.
Одно действие родителя запускает изменения сразу во всей системе и снижает риск рассинхронизации между статусом ученика и его финансовой историей.
В первую версию вошли все пять механизмов: цифровое заявление, автоматическая смена статуса, централизованная работа с заявлениями, гибкие правила школы и уведомления.
При этом сценарий ухода проектировался не как изолированная функция. В дальнейшем эта механика должна стать основой для других изменений в жизненном цикле ученика: перевода между классами, факультетами или группами, смены программы и других переходов, связанных с изменением статуса.
Важно было заложить достаточно универсальную логику и потому, что Schooly рассчитан не только на частные общеобразовательные школы. Похожие процессы возникают в спортивных секциях, музыкальных школах и других образовательных организациях, где отличаются структура обучения, статусы учеников и правила переходов.
Поэтому мы проектировали не только сценарий ухода, а основу для более гибкой системы управления изменениями в статусе ученика.
Собрала единый end-to-end flow, который связывает действия родителя, логику Schooly и процессы школы.
Отдельно проработала отзыв уже поданного заявления, ограничения на выбор даты, альтернативные состояния, edge cases и сценарии, которые могли привести пользователя в тупик. Для каждого определила, как система должна реагировать и куда вести пользователя дальше.
Low-fidelity-прототип помог проверить сценарий до работы над UI: последовательность шагов, ограничения дат, необратимые действия, состояния после отправки и синхронизацию двух интерфейсов.
После согласования логики подготовила Screen Flow со всеми ключевыми состояниями и пограничными сценариями. Такой порядок позволил не тратить время на детальный UI до того, как команда согласовала продуктовые правила.
1. Родитель самостоятельно сообщает об уходе
В мобильном приложении появился единый сценарий подачи заявления. Родитель выбирает ребёнка, дату ухода и причину, проверяет данные и подтверждает отправку.
При этом интерфейс сразу учитывает правила конкретной школы: даты, в которые заявление подать нельзя, недоступны для выбора, а список причин школа может настроить самостоятельно. Если подходящей причины нет, родитель может выбрать «Другая» и указать её вручную.
После отправки родитель видит актуальную информацию о статусе ребёнка и запланированных изменениях — заявление не исчезает в «чёрном ящике», а становится частью его профиля.
2. Под простым действием работает системная логика
Отправка заявления запускает не только изменение интерфейса. Schooly сохраняет дату и причину ухода, связывает их с профилем ученика и передаёт информацию в связанные процессы системы.
При этом мы не стали расширять статусную модель дополнительными промежуточными статусами. Ученик сохраняет актуальный статус до назначенной даты, а когда она наступает, система автоматически переводит его в следующий статус.
Логика учитывает и процессы, которые почти не видны родителю в интерфейсе: связанные оплаты, расчёты и возвраты, данные ученика, списки и статистику школы. За счёт этого заявление становится не отдельной формой, а событием, которое корректно меняет состояние ученика во всей системе.
3. Школа получает данные внутри привычного рабочего процесса
Сотруднику больше не нужно получать заявление по телефону или в переписке, уточнять необходимые данные и вручную переносить их в Schooly.
Дата ухода, причина и связанные изменения доступны непосредственно в профиле ученика и других рабочих разделах системы.
В профиле сохраняется история изменений, поэтому сотрудник может видеть не только текущее состояние ученика, но и запланированную смену статуса и дату, когда она произойдёт.
Изменения автоматически учитываются в связанных списках и статистике, поэтому разные части Schooly работают с одной и той же актуальной информацией.
4. Продумала сценарии за пределами happy path
Отдельно проработала ситуации, в которых основной сценарий отклоняется от ожидаемого: отмену уже поданного заявления, ограничения на выбор даты, изменение доступности функции, альтернативные состояния и сценарии, которые могли привести пользователя в тупик.
Для каждого такого случая определила, что должно происходить с заявлением, данными и статусами и какое состояние интерфейса увидят родитель и сотрудник школы.
После согласования flow я описала бизнес-правила, состояния, роли и переходы статусов в Confluence и Jira и синхронизировала спецификацию с продуктом и разработкой.
Уход ученика превратился из ручной цепочки действий в автоматизированный процесс.
Раньше заявление запускало целую серию звонков, переписок, уточнений и ручной передачи информации между сотрудниками. Теперь процесс проходит end-to-end внутри Schooly — от решения родителя до обновления данных школы.
1. Для родителя
Не нужно писать или звонить в школу, искать нужного сотрудника и подстраиваться под время работы. Заявление подаётся самостоятельно в приложении, а его дальнейший статус всегда виден там же.
2. Для школы
Заявление автоматически попадает в систему, а сотрудники нужных отделов получают уведомления. Не нужно отдельно подключать администрацию, бухгалтерию и других участников процесса — у каждого уже есть необходимые данные.
В результате мы сократили количество ручных действий на всём пути — не только при оформлении ухода, но и при обработке его последствий внутри школы.