С чего всё началось
Это был обычный пользовательский запрос. Мама хотела подключить к ребёнку папу и бабушку — чтобы они тоже могли работать с ним и видеть что происходит.
Самый простой ответ — добавить кнопку «пригласить пользователя». Но когда я начал разбираться, оказалось что проблема глубже, и решать её точечно — значит чинить симптом, а не причину.
Что было не так со старой моделью
В старой архитектуре всё было завязано на аккаунт родителя. Связь выглядела так: аккаунт родителя + профиль ребёнка, и сбоку — эксперт.
На практике это ломалось в простом сценарии. Чтобы на выходные отдать ребёнка бабушке вместе с приложением, маме приходилось отдавать бабушке свой аккаунт — логин и пароль. Никаких отдельных доступов, никакой настройки, что бабушке видно, а что нет. Всё или ничего.
Та же проблема упиралась в потолок при работе со специалистами и тем более с центрами. Продукт строился вокруг аккаунта одного родителя — а реальная жизнь ребёнка устроена иначе. Вокруг него много взрослых: оба родителя, близкие, няня, специалист, центр. И все они работают с одним и тем же ребёнком.
Как я пришёл к решению
Я часто думаю через ассоциации с физическим миром. И здесь сработала именно такая.
У ребёнка есть медицинская карта. Она лежит у мамы в ящике. Идёшь к врачу — отдаёшь карту ему. Едешь на каникулы к бабушке — карта едет с ребёнком. Карта одна, а людей вокруг неё много, и каждый работает с ней по-своему.
Я посмотрел как устроены медкарты в медицинских приложениях, и понял: вот эта модель — «карта в центре, люди вокруг» — это именно то что нужно FlyMind для дальнейшего роста.
Так родилось ключевое решение: профиль ребёнка перестаёт быть придатком родительского аккаунта и становится центром всего продукта.
Решение выросло не из головы, а из реальности — сначала из родительских запросов, потом из запроса одного из центров. Я собрал это вместе и предложил перевернуть модель.
Новая архитектура
Профиль ребёнка — центр. В нём живёт всё: анкета, особенности, цели, наблюдения, тренинги, материалы, прогресс, логи, рекомендации.
Вокруг профиля — подключения. Родители, близкие, няня, специалисты, врачи, центры. У каждого свой собственный аккаунт. Профиль при этом один, общий.
Что это меняет на практике: бабушке больше не нужен мамин логин. У неё свой аккаунт, и она подключается к профилю ребёнка как отдельный человек. Все взрослые видят общий контекст и могут действовать согласованно.
И эта модель открывает то что раньше было невозможно:
Гибкие права доступа (на будущее). Каждому подключению — свой объём. Бабушке нужно только визуальное расписание. Няне не нужно видеть какие протоколы запускались или к каким ещё профилям подключён ребёнок. Специалисту — полный профессиональный доступ. Один профиль, разные роли.
Авторство данных. Кто какие данные вносил. Это позволит специалисту видеть как ребёнок ведёт себя с разными людьми — а это уже клиническая ценность, а не просто удобство.
Где дизайн встретился с монетизацией
Самое важное в этом кейсе — то что архитектурное решение напрямую переопределило модель монетизации.
Раньше подписка была завязана на аккаунт. Я перенёс её на профиль ребёнка.
Теперь логика такая. Платит главный родитель — за профиль ребёнка. Подключение близких — бабушки, няни — бесплатно. Они привязаны к профилю, но не платят. Подключение специалиста поднимает тариф, но платит всё равно главный родитель.
А если к профилю подключается центр — платит центр. Потому что в этом сценарии именно центр приводит родителя в продукт: родитель начинает пользоваться приложением потому что им пользуется его центр. Центр в плане монетизации всегда выше по ценности, и модель это учитывает.
Снаружи это изменение почти незаметно. Но под капотом оно полностью меняет то как продукт может зарабатывать и масштабироваться — и открывает прямую дорогу к работе с ABA центрами, которые теперь привязываются к профилю ребёнка, а не к случайной связке «аккаунт родителя + какой-то эксперт».
Самое сложное
Самым трудным было не спроектировать систему, а защитить её перед бизнесом.
Для бизнеса первая реакция была прямой: если близкие подключаются бесплатно — значит денег станет меньше. И это честное возражение.
Я заходил со стороны удобства и разумной монетизации. Аргумент был такой: мы не теряем деньги на бесплатных подключениях — мы снимаем барьер, из-за которого продукт вообще не приживался в семье. Чем больше взрослых реально работают с ребёнком через приложение, тем глубже продукт встроен в жизнь семьи, тем выше удержание. А настоящие деньги приходят оттуда где им и место — от специалистов и центров. Бизнес согласился.
Права доступа я сознательно оставил на будущее — технически это самая тяжёлая часть, и у разработки были более приоритетные задачи. Архитектура спроектирована так чтобы их можно было ввести позже, не ломая модель.
Что я вынес из этого проекта
Иногда решения, которые меняют продукт, не видны снаружи. Их нельзя показать красивым экраном — визуально как будто ничего не произошло.
Но именно такие решения меняют весь продукт целиком: то как он устроен внутри, как с ним взаимодействуют пользователи, и какие возможности для роста он открывает.
Здесь так и вышло. Одно изменение модели данных переопределило и пользовательский опыт, и монетизацию, и стратегию выхода на центры — при том что на экране почти ничего не поменялось.