Подарили студентам приложение вместо сайта: как Umed решил проблему доступа к учебной информации
Большинство цифровых решений в сфере образования развиваются по схожему сценарию: сначала создаётся веб‑сайт или личный кабинет, который постепенно обрастает функциональностью, но при этом остаётся ориентированным на десктопное использование. В результате интерфейсы оказываются перегруженными, мобильная версия работает неудобно, отсутствуют нативные механики вроде push‑уведомлений, а взаимодействие с системой требует больше времени, чем это допустимо в повседневных сценариях.
Проблемы в IT‑разработках для сферы образования и инсайты из аналитики
В сфере образования в целом наблюдается устойчивая проблема: классические сайты постепенно перестают удовлетворять реальные потребности пользователей.
Студенты, преподаватели и абитуриенты всё чаще взаимодействуют с сервисами со смартфонов, ожидая привычного уровня удобства — быстрого отклика, интуитивного интерфейса и мгновенных уведомлений, аналогичных современным мобильным приложениям.
Для учебных заведений это приводит к разрыву между ожиданиями пользователей и возможностями веб‑платформ. Даже при наличии функционального личного кабинета он зачастую оказывается неудобным в мобильном сценарии использования.
Тем не менее, использование этих возможностей со смартфонов вызывало затруднения. Отсутствовали push‑уведомления, а сам интерфейс не был оптимизирован под мобильное взаимодействие, что снижало удобство работы с системой.
Инсайты, сделанные во время аналитики:
- Классический сайт колледжа переставал удовлетворять реальные потребности студентов, абитуриентов и преподавателей: мобильный доступ был неудобным, уведомления не приходили вовремя, а интерфейс не адаптирован под смартфоны.
- Пользователи теряли время на поиск информации и взаимодействие с системой, а администрация колледжа испытывала трудности с контролем процессов и коммуникацией.
- Готовые решения для образования часто не интегрируются с существующими платформами и не учитывают роли пользователей, что делает их неприменимыми для реального колледжа.
- В России резко выросло количество объявлений о продаже готовых ПВЗ
- Сокращения из‑за ИИ не помогли компаниям заработать
- Wildberries запустил аналитического ИИ‑ассистента для селлеров
- Россияне стали чаще уходить из найма в работу на себя: новый тренд на рынке труда
- Wildberries повысит тарифы на возврат товаров с 21 мая
- В Москве заработала система цифрового контроля за курьерами
Поэтапная методология создания приложения
Аналитика и подготовка. Идея проектировалась как веб‑решение и не была ориентирована на работу в формате мобильного приложения. Отсутствовала готовая API‑логика, а взаимодействие с данными было завязано на внутренние механизмы Bitrix, что затрудняло интеграцию.
Дополнительную сложность создавала неоднородность пользовательских сценариев, потому что участники по‑разному взаимодействуют с системой: одни используют её для подачи документов, другие — для отслеживания расписания и оценок, третьи — для управления учебным процессом. При этом часть сценариев была сформирована «исторически» и не имела формального описания.
В рамках аналитического этапа были решены следующие задачи:
- выполнена декомпозиция структуры существующей системы и логики работы Bitrix;
- описаны роли пользователей и их ключевые сценарии взаимодействия с платформой;
- определён перечень функций, критичных для мобильного приложения, и исключены второстепенные элементы;
- сформированы требования к интеграции и ограничения, связанные с использованием мобильных платформ.
Отдельное внимание уделялось вопросам корректного разделения функциональности между форматами. Ошибки на этом этапе могли привести к перегруженности интерфейса или попытке перенести в мобильный формат лишние сценарии, неэффективные для смартфонов.
UX/UI‑дизайн. Основная сложность этапа заключалась в том, что брендбук и дизайн сайта были ориентированы на десктопную среду и не учитывали ограниченное пространство экрана, а также специфику взаимодействия через сенсорный ввод.
Дополнительным вызовом стало проектирование интерфейса для разных категорий пользователей с различными целями и частотой использования системы. Интерфейс должен был оставаться одинаково понятным как для абитуриентов, так и для студентов и преподавателей, при этом обеспечивая быстрый доступ к наиболее востребованным функциям.
В рамках данного этапа были решены следующие задачи:
- адаптация фирменного стиля под мобильные экраны и различные разрешения устройств;
- проектирование пользовательских сценариев с акцентом на минимальное количество действий до целевого действия;
- разработка интерфейсных компонентов, обеспечивающих масштабируемость и дальнейшее развитие функционала;
- упрощение навигационной структуры с учётом ограничений мобильного UX.
Основное внимание уделялось снижению когнитивной нагрузки и сокращению времени доступа к ключевой информации. В результате интерфейс стал более компактным, логичным и удобным для ежедневного использования.
Архитектура и API. На этапе архитектурного проектирования ключевой задачей стало обеспечение корректного взаимодействия мобильного приложения с существующей системой на Bitrix.
Основная сложность заключалась в том, что Bitrix не предоставляет гибких механизмов для использования в качестве backend‑основы мобильного приложения. Прямое подключение к системе могло привести к высокой связности компонентов и сложностям при сопровождении и развитии.
Дополнительным критическим фактором являлась безопасность: приложение работало с персональными данными пользователей, что требовало надёжной системы авторизации и контроля доступа.
В рамках этого этапа были выполнены следующие работы:
- проектирование структуры API и определение форматов обмена данными;
- реализация слоя абстракции над Bitrix для безопасного доступа к данным;
- внедрение механизмов авторизации и разграничения прав пользователей.
Такой подход позволил избежать прямой зависимости от Bitrix и обеспечил устойчивость системы к изменениям на стороне веб‑платформы.
Нативная разработка. На этапе разработки основной задачей стало создание стабильных и производительных мобильных приложений для двух платформ с сохранением единой логики работы.
Дополнительным вызовом стала интеграция push‑уведомлений, которые являются критически важным элементом коммуникации в образовательной среде. Их корректная работа требовала настройки как на уровне клиентских приложений, так и на стороне серверной инфраструктуры.
В рамках данного этапа были решены следующие задачи:
- создание iOS‑приложения на Swift с реализацией push‑уведомлений;
- разработка Android‑приложения на Kotlin с аналогичной бизнес‑логикой;
- интеграция с API и реализация обработки ошибок сетевых запросов;
- обеспечение устойчивости работы при нестабильном подключении к интернету.
В результате удалось достичь стабильной работы приложений, обеспечить единообразие пользовательского опыта на разных платформах и реализовать полноценную систему уведомлений для оперативного взаимодействия с пользователями.
Уникальные фичи в разработке
Интеграция с Bitrix. Для решения этой задачи:
- был реализован отдельный API‑слой на PHP (Symfony), который обращался к данным Bitrix и преобразовывал их в формат, удобный для мобильного приложения;
- мобильное приложение было изолировано от внутренней логики сайта, что исключило зависимость от изменений в веб‑части;
- реализованы механизмы авторизации и проверки прав доступа на стороне API для обеспечения безопасности персональных данных пользователей.
Такой подход позволил аккуратно интегрировать мобильное приложение с существующей системой без необходимости глубокой переработки ядра Bitrix.
Единая логика для разных ролей. Система должна была учитывать различия в поведении пользователей: абитуриенты, студенты и преподаватели взаимодействуют с платформой по‑разному и имеют доступ к различной информации.
Для реализации этой задачи:
- были детально описаны сценарии использования для каждой категории пользователей;
- на уровне API внедрена ролевая модель, определяющая набор доступных данных и функций для каждого типа пользователя;
- в приложении реализовано динамическое отображение интерфейса в зависимости от роли.
Результат
В результате был реализован и запущен комплекс мобильных приложений для iOS и Android, полностью интегрированных с существующей системой колледжа на Bitrix через выделенный API‑слой. Мобильное приложение стало удобным каналом и обеспечило более быстрый и привычный сценарий взаимодействия с учебной информацией.
Исходя из опыта разработки для Umed собрал рекомендации для создания подобных решений:
- анализируйте реальные пользовательские сценарии и потребности, а не пытайтесь перенести весь функционал веб‑системы в мобильное приложение;
- проектируйте архитектуру с использованием промежуточного API‑слоя, чтобы избежать жёсткой связности с существующей системой и упростить дальнейшее развитие;
- разделяйте пользователей по ролям и заранее закладывайте для каждой роли отдельные сценарии, интерфейсы и уровни доступа к данным.
Проект Umed позволил повысить удобство работы с системой, сократить время доступа к информации и улучшить коммуникацию между пользователями и администрацией колледжа. После запуска приложение продолжило развиваться за счёт регулярных доработок и адаптации под новые задачи.
