Mom's Helper: трекер режима младенца

Контекст

В июне 2024 у меня родился сын.

С первых недель существующие приложения для учёта режима ребёнка больше раздражали меня, чем помогали. Я начал делать своё — для себя и близких, потому что это было действительно нужно.

Первые 20 человек, прошедших онбординг, дали положительные отзывы, и я увидел в продукте кейс. Опыта продуктового дизайнера у меня не было, поэтому я создал его сам: довёл продукт от исследования до работающей версии.

Моя роль в проекте

Исследование, проектирование, дизайн и продуктовые решения я делал сам, без команды.

Ресурсы

• Время разработки до текущей версии (v2.19.140): ~4 месяца активной работы параллельно с основной работой и маленьким ребёнком
• Бюджет на инфраструктуру и ИИ-инструменты: ~$300 (VPS, БД, Coolify, Claude, Cursor)
• Команда: 1 человек

Бот, PWA, платёжная система, аналитика и деплой уложились в такой срок и бюджет только благодаря работе с ИИ-агентами. Архитектурные решения, продуктовые гипотезы и логика интерфейса — моя работа, код я писал вместе с агентами.

Бота я начинал делать в чате с ИИ, потом перешёл на VS Code и Claude Code.

Метрика, которую хотел улучшить

Время на запись — это время от решения «записать кормление» до сохранённой записи. У конкурентов это ~20 секунд. Это критично, когда ребёнок кричит и руки заняты.

Проблема

Откуда взялась

Я сам был пользователем. В хроническом недосыпе мне нужно было записывать, когда последний раз кормили, сколько выпил и когда уснул. Существующие приложения создавали барьер на каждом шаге.

Данные

Я сравнил четыре популярных приложения: Baby Tracker, Glow Baby, Baby Connect и The Wonder Weeks.

Вывод из сравнения

Все конкуренты проектировали для «спокойного родителя за столом». Мой пользователь — «измотанный родитель в 3 ночи с ребёнком на руках». Регистрация, навигация, лишний тап в обычном состоянии незаметны. В недосыпе каждый такой барьер останавливает.

Исследование

Глубинные интервью

Я провёл 5 интервью с родителями детей до 9 месяцев.

Критерий отбора: используют или пробовали использовать трекеры.

Ключевые вопросы:

• Как вы сейчас фиксируете кормления и сон?
• Когда данные теряются?
• Почему перестали пользоваться трекером (если перестали)?
• Что должен делать идеальный трекер?

Синтез интервью

JTBD — Job-to-be-Done

Из интервью я сформулировал три ключевых Job Story:

Job 1 (основной)

Когда ребёнок только что поел или уснул и у меня есть 5 свободных секунд, я хочу быстро записать событие, чтобы не держать его в голове и не путаться.

Job 2

Когда муж или жена берёт ребёнка, я хочу, чтобы второй родитель автоматически видел последнее состояние и нам не приходилось передавать информацию словами.

Job 3

Когда педиатр спрашивает, как младенец спит и ест, я хочу показать ему точную статистику, чтобы врач мог принять правильное решение.

Гипотезы и их проверка

Часть гипотез я сформулировал до проектирования, часть появилась по ходу работы. Проверял их на работающем боте.

❌ Про смеси

Пользователи просили добавить конкретные бренды смесей. Я изучил дозировки и убрал этот выбор совсем: разницы между брендами нет, а лишний шаг в онбординге создаёт барьер.

❓ Про меню

Клавиатура отображалась нестабильно из-за совместимости с платформой, сам сценарий был правильным. Переход на Inline-кнопки сохранил логику взаимодействия, но потребовал переделать весь интерфейс бота.

Вывод: проверять совместимость с платформой нужно до проектирования интерфейсных компонентов.

v1 — MVP: только Telegram-бот

Первая версия продукта — только бот, без PWA. Вся логика и весь интерфейс внутри Telegram.

Онбординг в боте

Согласие → Создание ребёнка → Дата рождения → Тип питания → Часовой пояс → Ночной режим → Подтверждение.

В Telegram не нужна регистрация, поэтому эти вопросы можно задать: пользователь ещё не устал от форм. Часовой пояс — единственное поле, которое подставляется автоматически, остальное можно поменять позже.

Бот сам определяет, что нужно сейчас

Вместо привычного дерева экранов я спроектировал линейный сценарий, который зависит от состояния ребёнка (State-Aware Flow). Бот сам выбирает точку входа и показывает единственное действие, которое нужно сейчас.

Проблема стандартного подхода

Каждый раз: Вход → Добавить → Выбор действия → Форма с полями. Это 3–5 нажатий и когнитивная нагрузка.

Моё решение

Всё построено на Inline-кнопках и текстовых сообщениях. Без собственного интерфейса это максимум того, что даёт Telegram.

Что бот показывает при записи кормления:

• Норму по возрасту прямо в сообщении: родитель видит «220 мл — норма» ещё до ввода
• Последние кормления как контекст

Метрики — v1

Я проводил измерения сам и на малой выборке. Это проверка MVP, формального юзабилити-теста не было.

v1 → v2: почему добавил PWA

MVP подтвердил гипотезу: бот работает как инструмент быстрой записи. Но в использовании проявилась граница: с «глубокими» функциями бот не справляется.

Что не помещалось в бота:

• История событий за несколько дней. В боте это либо бесконечная лента сообщений, либо кнопки навигации по неделям, и в обоих случаях листать события в чате неудобно
• Статистика. Отдельные блоки по кормлению и сну в сообщениях, без визуализации и сравнения периодов
• Настройки. Они занимали много экранов бота

Всё это было сделано и проверено в v1. Сам формат чата не подходит для такого взаимодействия: аналитике и настройкам нужен экран.

Решение

Бот стал проще: часть функций ушла в PWA. Она взяла на себя всё, что требует экрана и времени.

Настройки ребёнка переехали из модалок на отдельный экран. Первую версию раздела «Настройки» в PWA я собрал быстро и без продуманной структуры: несколько отдельных модалок (уведомления, доступ, профиль, режим дня), лишь бы функция была.

Когда редизайн дизайн-системы дошёл до этого раздела, встал вопрос формы. Настроек ребёнка оказалось больше, чем контента в остальных разделах приложения, а шторка (паттерн для быстрых действий с малым числом шагов) для такого объёма не подходила.

Решение: я вынес настройки ребёнка на отдельную полноэкранную страницу, а в самой форме оставил только необходимые поля.

Это плановая зачистка технического долга: дизайн-система дошла и до этого раздела.

v2 — Бот + PWA (в тестировании)

PWA не дублирует бот. Её задача — показать, что произошло, и дать контекст. Бот отвечает за запись (скорость), PWA — за статус и анализ (глубину).

Общие паттерны

Сводка (дашборд) → История → Статистика → Настройки — четыре вкладки нижней навигации. Порядок повторяет частоту использования: сводку открывают чаще всего, статистику реже, настройки редко.

Три паттерна я закрепил как правило для всего приложения, чтобы не выбирать их каждый раз заново:

Например, запись кормления и сна открывается в шторке: действие короткое, после него сразу возврат на дашборд. Настройки ребёнка — полноэкранная страница, их объём перерос шторку. Ниже — как это правило работает на каждой странице.

Страница: Дашборд

Хедер

Хедер решает три задачи одновременно: контекст, доступ и персонализация.

По тапу на иконку и имя ребёнка сразу открываются настройки профиля. Рядом кнопка смены ребёнка: она появляется, только если детей больше одного, иначе не занимает место.

Переключатель темы я вынес в хедер намеренно: тему меняют часто, поэтому ей не место в настройках.

Статус-карточки и персонализация

• Статус-карточки «следующее действие». Приложение само считает и показывает «Через 1 ч 20 мин — около 14:45»
• Карточка возраста и периода развития. Объясняет, почему ребёнок ведёт себя именно так
• Акцентный цвет под ребёнка. На Free цвет можно задать одному ребёнку, в Premium у каждого ребёнка свой. По цвету сразу видно, какой ребёнок активен
• Светлая и тёмная тема. Выбирает пользователь

Логика статус-карточек:

Каждая показывает два числа: сколько осталось до события, чтобы оценить, скоро ли оно, и в котором часу оно будет, чтобы привязать его к привычному времени. Обе карточки равнозначны — это не иерархия кормление > сон, а плотность данных.

Быстрая запись — разделение обязательного и настраиваемого

Блок прошёл несколько итераций, прежде чем сложился в текущий вид. Пара «Кормление + Сон» всегда закреплена сверху: это два самых частых действия (Job 1), и их доступность не должна зависеть от настроек пользователя.

Ниже — до четырёх настраиваемых кнопок для второстепенных действий. Набор у каждого родителя свой: кому-то важен «Подгузник», кому-то «Прогулка».

Состав и порядок кнопок я вынес в отдельную шторку. Если разрешить менять их прямо на дашборде, одна и та же кнопка становится и «нажми — запишется», и «нажми — настроится», и непонятно, в каком она сейчас режиме. Шторка явно разводит эти два состояния.

Порядок внутри шторки меняется перетаскиванием пальцем. Стрелки ▲▼ технически работали, но выбивались из остальных прямых жестов приложения: свайпов шторок и перетаскивания карточек в «Статистике».

Сетка подстраивается под число включённых кнопок (1–4 колонки), поэтому пустых мест под выключенные кнопки нет.

Тот же принцип я применил к кнопке смены ребёнка в хедере: если решение не готово, временно убрать его, а не латать. В попапе выбора был шеврон «настройки ребёнка». Выяснилось, что иконка не сообщает о своей функции, а для активного ребёнка вообще не срабатывает, и я убрал шеврон целиком.

Страница: Фиксация кормления и сна

Здесь шторка, по тому же правилу, что и везде в приложении: действие короткое, шагов мало, после него пользователь сразу возвращается на дашборд. Паттерн я взял из анализа банковских приложений: шторка открывается поверх экрана, закрывается свайпом и не требует возврата назад.

Табы внутри шторки нужны потому, что у каждого типа кормления свои параметры ввода: у смеси объём, у груди сторона, у таймера запуск, пауза и стоп. Табы разделяют три разные формы внутри одного действия.

Страница: История

Free: последние 7 дней, редактирование только за сегодня. Premium: 90 дней, навигация по месяцам, редактирование за 3 дня. Лимиты — часть модели монетизации, интерфейс от тарифа не меняется: пользователь видит одну и ту же структуру (группировка по дням, редактирование) на обоих тарифах, разница только в глубине.

Крайние случаи: пустой день, баннер Premium при достижении лимита.

Страница: Настраиваемая статистика

Бар-чарты по дням: кормления (грудь и смесь) и сон (ночной и дневной). Период — неделя или месяц. Для педиатра есть выгрузка в Excel.

Страница состоит из трёх независимых слоёв, у каждого своя настройка.

Карточки-показатели. Все доступные показатели (кормления, объём, сон, подгузники и ещё 8 будущих метрик) собраны в отдельной шторке с переключателями и перетаскиванием для порядка. Готовые метрики работают сразу. Неготовые показаны в том же списке притушенными, с бейджем «скоро»: их видно, но рабочими они не притворяются.

Это правило появилось после конкретного промаха: кнопка «Прикорм» выглядела полностью готовой, но по тапу ничего не происходило, и пользователь не мог отличить баг от «пока не сделано».

С тех пор правило одинаково действует для всех типов событий везде, где они встречаются: в быстрой записи на дашборде, в выборе типа события и в карточках статистики.

Графики. Одновременно можно показать до 3 графиков. Для каждого отдельно выбирается метрика (только из тех, где есть данные по дням) и вид: столбцы или линия. Дублирование я предотвратил заранее: метрику, которую уже занял один график, нельзя выбрать в другом. Вместо сообщения об ошибке постфактум её просто невозможно совершить.

Сравнение периодов я не добавлял для галочки: оно прошло полный цикл итераций за одну сессию. Требование выросло из Job 3 (показать педиатру динамику): «если закралось подозрение, что ребёнок стал меньше есть или спать — увидеть разницу».

Сначала сравнение включалось отдельным тумблером, потом я его убрал: сравнение с предыдущим периодом теперь включено всегда, выключить его нельзя. Одна шкала без сравнения почти ничего не говорит, а по двум периодам видна тенденция.

Контрол сравнения сначала был внутри карточки первого графика. Когда появился второй график, он переехал в общую шапку страницы, потому что относился к обеим карточкам сразу.

Во всех трёх слоях работает один паттерн настройки: шторка со свичами и, где нужно, drag-реордер. Это одно решение на разный контент страницы вместо трёх случайных.

Дизайн-система

Продукт построен на shadcn/ui (примитивы Radix UI) поверх собственного слоя токенов и компонентов.

Почему shadcn/ui:

• Компоненты копируются в проект: код полностью под контролем, зависимости от внешней библиотеки нет
• Примитивы Radix UI дают доступность из коробки
• Tailwind и CSS-переменные упрощают управление темой

Шрифт системный, типографика своя. Собственного шрифта нет: приложение использует системные шрифты платформы (-apple-system/Segoe UI/Roboto, в проекте нет ни одного @font-face).

При этом размеры и начертания собраны в одну последовательную шкалу, от мелких подписей и лейблов до крупных акцентных чисел на статус-карточках. У каждой ступени понятная роль, случайных значений на отдельных экранах нет.

Акцентный цвет привязан к ребёнку, от темы он не зависит. Цвет можно настроить и на Free, но только для одного ребёнка: Free ограничен одним профилем. Premium снимает именно это ограничение. Детей может быть несколько, и у каждого свой цвет из 6 вариантов.

При переключении активного ребёнка цвет переопределяется через CSS-переменную. Весь UI-кит и собственные компоненты перекрашиваются сразу, заходить в настройки темы не нужно.

Цвет виден и в боте: в шапке главного меню стоит цветной кружок, который меняется вместе с активным ребёнком. Так цвет решает две задачи: персонализацию и быструю ориентацию. Если детей двое и больше, по цвету сразу понятно, кто сейчас выбран, имя читать не нужно.

В данных цвет хранится как токен: в базе лежит семантический ключ («pink»), hex-кода там нет. Конкретный оттенок целиком задаёт тема PWA, поэтому смена оттенка не требует миграции данных.

Компромисс: «чистые» примитивы shadcn (Select, Popover, Calendar) используют статичные дизайн-токены и не подхватывают акцентный цвет. Они остаются фиолетовыми при любом цвете ребёнка. Риск задеть уже работающие элементы не оправдывал исправление ради идеальной картинки на некритичных элементах управления.

UI-кит — своя надстройка над shadcn. Базовые интерактивные элементы (кнопка, кнопка-иконка, аватар, бейдж) я вынес в собственный слой. Он повторяет паттерн shadcn, но работает на своих CSS-переменных вместо статичных токенов shadcn, иначе тема и акцентный цвет ребёнка не работали бы в новых компонентах.

Цель — одна точка изменения: радиус или цвет правится в одном файле и сразу применяется везде, без ручной правки каждой страницы.

Тему пользователь переключает вручную, по системе она не определяется. Светлая и тёмная темы сделаны на CSS-переменных, переключатель в хедере.

Кому-то в целом нравится светлая тема, но ночью нужно быстро убрать яркость экрана. Переключатель позволяет сделать это сразу при входе в приложение, независимо от системных настроек телефона. Автоматическое определение темы по системе технически возможно, но пока не сделано: без проверки на пользователях не вижу смысла добавлять эту сложность заранее.

Документация системы — рабочий инструмент проверки. Токены, компоненты и соответствие переменным Figma сведены на одну страницу, и я постоянно сверяю её с реальным кодом. Документация описывает то, как есть на самом деле.

Такая сверка уже находила настоящие расхождения между документацией и рабочей версией. Например, у BottomNav не было фокус-кольца, хотя у всех остальных интерактивных компонентов оно есть. Баг всплыл, когда я сводил всё в одну систему. Подробнее о том, как устроена документация и что она нашла, — на странице дизайн-системы.

Почему так

UI

• Фиолетовый как основной цвет. Он стоит между синим и розовым и не привязан к полу ребёнка. Родитель может сразу сменить цвет под своего ребёнка, это доступно без Premium.
• Размеры под палец. Размеры кнопок и шапок я взял из норм iOS и Android. До этого я проектировал сайты и внутренние системы, а мобильный интерфейс хотел освоить на живом продукте.
• Плотность как в банковских приложениях. Я считаю их удобными: мало текста, крупные кнопки, понятные с первого взгляда. У родителя с ребёнком на руках нет времени искать и читать.
• Системный шрифт. Так принято в приложениях на разных платформах: на iOS, Android и в вебе приложение выглядит родным.
• Скругления. За основу взял радиус из shadcn, а дальше подгонял так, чтобы вложенные друг в друга скругления сочетались между собой.
• Зелёный для активного кормления и сна. Это привычный для людей сигнал «идёт сейчас».
• Отступы. Шкала отступов из shadcn и Tailwind, без своих значений.

UX

• Из онбординга убрал индикатор прогресса. В сообщении Telegram он добавлял шум и смещал акцент с вопроса на полоску.
• Убрал шаг «спит или бодрствует». Изменилась логика записи, а онбординг стал короче.
• Убрал экран пробного периода из онбординга. Он приходит позже автосообщением, лишний шаг на входе не нужен.
• Отключил выбор языка. Не тратил время разработки: юридические документы были только на русском, их пришлось бы переводить.
• Экран согласия стоит первым. Это требование закона (152-ФЗ).
• История на 90 дней в Premium. По моим ощущениям, родитель пользуется приложением первые 9–12 месяцев жизни ребёнка. За это время всё быстро меняется, а запись трёхмесячной давности почти никому не нужна.
• Запись кормления и сна не упрощал дальше. Я проверил её на себе, лишних полей в ней нет.

Что не сработало

Фидбек первых пользователей не отражал реальных проблем

20 первых пользователей знали мою жену по общему чату, и их просьбы шли от желания помочь, реальной боли за ними не было. Просьба про выбор бренда смеси (см. «Гипотезы и их проверка») как раз оттуда. Я научился отличать «хотелки» от реальных проблем.

Медицинские данные — юридический барьер

Я хотел добавить медицинский блок: прививки, визиты к педиатру, историю болезней. Данные о диагнозах и прививках в России относятся к специальным персональным данным (152-ФЗ, ст. 10), для их обработки нужны отдельная инфраструктура и сертификация. Этот блок я отложил. Пока в продукте только бытовые данные: кормление, сон, замеры.

Бизнес-модель

Продукт построен как подписка. Free закрывает основную задачу: один ребёнок, запись кормления и сна, история за 7 дней. Premium снимает ограничения:

• история за 90 дней;
• неограниченное число детей;
• добавление родителей и нянь;
• расширенная статистика;
• детальные графики и аналитика.

Цены: 199 ₽ в месяц, 499 ₽ за 3 месяца, 1 599 ₽ за год. Ориентир по цене — месяц стоит как чашка кофе. Платил бы родитель, который ведёт учёт. Платёжный сценарий я проверил в боевом режиме: оплатил подписку сам.

Почему продукт пока не в публичном релизе. Публичный запуск требует времени и вложений, а сейчас мои силы уходят на поиск работы. Идею запуска я не отменял. Прежде чем выпускать, нужно ответить на два вопроса:

• Платформа. Вход в продукт построен на Telegram: без регистрации и паролей, так я его задумал. Доступ к Telegram в России ограничивается, и опираться на него одного для публичного запуска рискованно. Эту зависимость можно убрать на этапе разработки: вход в PWA вынести из Telegram, а бота оставить для уведомлений.
• Данные. Прививки, заболевания и диагнозы относятся к специальным персональным данным (152-ФЗ, ст. 10), для их хранения нужна отдельная инфраструктура. Сейчас в продукте только бытовые данные.

Выводы

Что сработало:

• Бот сам определяет, что нужно сейчас: пользователь видит одно нужное действие вместо меню
• Telegram как платформа: без регистрации и с мгновенной синхронизацией
• Решения на основе данных вместо просьб пользователей (убрал выбор смеси)
• Разделение ролей бота и PWA: скорость и глубина

Что бы поменял

• Проверил бы отображение Reply-клавиатуры до проектирования сценария. На части устройств она отображалась нестабильно, пришлось переделывать весь слой бота на Inline-кнопки.
• Фиксировал бы фидбек MVP формально. Первые 20 пользователей знали мою жену по общему чату, и без записи, кто и о чём просил, я не мог отделить заботу от реальной проблемы.
• Раньше выделил бы PWA в отдельный слой. История, статистика и настройки не помещались в чат, я это понял только по использованию.

Что доделал бы дальше

• остальные типы записей, где сейчас заглушки;
• календарь скачков развития и советы по возрасту ребёнка.

Кейс обновляется по мере развития продукта. Последнее обновление: 2026-10-12