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

Контекст

Я работаю Product Designer в рекламном агентстве. В июне 2024 у меня родился сын.

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

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

Полная самостоятельность. Discovery, проектирование, дизайн, продуктовые решения, координация разработки через AI-агентов, тестирование, деплой. Без команды.

Ресурсы

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

Telegram-бот + PWA + платёжная система + аналитика + деплой — стал возможен за такой срок и бюджет только благодаря AI-assisted разработке. Я использую ИИ как инструмент: архитектурные решения, продуктовые гипотезы, UX-логику — всё это моя работа. Кодовая реализация — совместная.

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

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

Проблема

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

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

Данные

Я изучил ТОП-5 приложений рынка: Baby Tracker, Glow Baby, Huckleberry, Sprout Baby, BabyConnect.

Вывод из бенчмарка

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

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

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

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

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

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

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

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

JTBD — Job-to-be-Done

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

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

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

Job 2

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

Job 3

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

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

Перед проектированием я сформулировал 4 гипотезы и проверил их запуском.

❌ Про смеси

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

❓ Про меню

Нестабильный рендеринг — это проблема платформенной совместимости, не UX-флоу. Сам флоу был правильным. Переход на Inline-кнопки сохранил логику взаимодействия, но потребовал переработки всего UI-слоя бота.

Вывод: платформенный тест совместимости должен идти до проектирования UI-компонентов, а не после.

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

Первая версия продукта — исключительно бот. Никакого PWA. Вся логика, весь UX — внутри Telegram.

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

Язык (Выкл.) → Consent → Создание ребёнка / Демо-режим → Дата рождения → Тип питания → Часовой пояс → Ночной режим → Подтверждение.

Демо-режим: добавлен для снижения барьера — дефолтный ребёнок, можно изучить интерфейс без создания профиля. Ключевое преимущество платформы (Telegram = без регистрации) даёт нам право задать эти вопросы: пользователь ещё не устал от форм.

Принципы:

• Только необходимое для Day 1 — ничего лишнего
• Смарт-дефолты: часовой пояс определяется автоматически
• Все настройки можно изменить потом

State-Aware UX

Вместо классического дерева экранов я спроектировал линейный State-Aware Flow — бот сам определяет точку входа по текущему состоянию ребёнка и показывает единственное релевантное действие.

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

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

Моё решение

Бот сам определяет точку входа по текущему состоянию ребёнка.

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

Смарт-функции при фиксации кормления:

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

Метрики — v1

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

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

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

Что не влезало в бота:

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

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

Решение

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

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

Можно потыкать 👉 демонстрационная web-версия.

PWA не дублирует бот — у неё другая роль: показать что произошло и дать контекст. Бот — это фиксация (скорость), PWA — статус и анализ (глубина).

PWA — Dushboard

Хедер

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

4-tab навигация

Сводка (дашборд) → История → Статистика → Настройки

Порядок отражает частоту использования: сводку проверяют чаще всего, статистику — реже, настройки — редко.

Дашборд

• Статус-карточки «следующее действие» — система сама считает и показывает «Через 1 ч 20 мин — около 14:45»
• Карточка возраста и периода развития — контекст почему ребёнок ведёт себя именно так
• Акцентный цвет под ребёнка (Premium) — персонализация без лишних настроек
• Светлая и тёмная тема — выбор пользователя

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

PWA — Фиксация кормления и сна

Фиксация дублируется в PWA через bottom sheet — паттерн взят из анализа банковских приложений. Быстрое действие: открывается поверх, закрывается свайпом, не требует возврата назад.

Почему табы внутри sheet: у каждого типа кормления разные параметры ввода (смесь: объём; грудь: сторона; таймер: запуск/пауза/стоп). Табы разделяют три разных формы под одним действием.

История событий

Free: последние 7 дней. Premium: 90 дней + навигация по месяцам + редактирование.

Edge cases: пустое состояние за день, paywall-баннер при достижении лимита.

[СКРИНШОТ: History — группировка по дням, редактирование]

Статистика

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

[СКРИНШОТ: Stats — бар-чарты кормлений и сна за неделю]

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

Продукт построен на shadcn/ui (Radix UI primitives).

Почему shadcn/ui:

• Компоненты copy-paste — полный контроль над кодом без зависимости от внешней библиотеки
• Radix UI примитивы — доступность из коробки
• Tailwind + CSS-переменные — простое управление темой

Токены:

• -accent — акцентный цвет (настраивается под ребёнка в Premium)
• Surface/Primary, Surface/Secondary — уровни контента
• Action/Primary — интерактивные элементы

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

[СКРИНШОТ: дизайн-система — цвета, типографика, компоненты]

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

Нестабильность Reply-клавиатуры

Первая версия бота использовала Reply-кнопки. На части устройств рендеринг был нестабилен — кнопки перекрывали контент или не появлялись. Переход на Inline-кнопки решил проблему, но потребовал переработки всего UI-слоя.

Вывод: проблема была в платформенной совместимости, не в UX-логике. Нужно тестировать рендеринг компонента на целевых платформах до того как под него проектируется весь флоу.

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

30 первых пользователей знали мою жену — их запросы были продиктованы желанием помочь. Просили добавить бренды смесей. Анализ показал что дозировки идентичны — запрос был ложным. Научился различать «хотелки» и реальные проблемы.

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

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

Что дальше — v3

Выводы

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

• State-Aware UX — пользователь всегда видит одно релевантное действие, не меню
• Telegram как платформа — нет регистрации, мгновенная синхронизация
• Решения на основе данных, а не запросов (убрал выбор смеси)
• Разделение бот/PWA по ролям: скорость vs глубина

Что я бы сделал иначе:

• Протестировал рендеринг Reply-клавиатуры до проектирования флоу
• Задокументировал фидбек от MVP-пользователей формально
• Раньше выделил PWA в отдельный слой

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