Health Tracker & Biomarkers

Проектирование сложного health-трекера от логики до релиза

Health Tracker & Biomarkers начался с понятного вопроса: может ли пользователь увидеть, влияют ли витамины и добавки на анализы.

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

Я работал с UX-логикой, структурой интерфейса, SwiftUI-реализацией, онбордингом, локализацией и стабильностью релиза, чтобы довести продукт от идеи до App Store без потери ясности.

40 дней

от идеи до App Store

Идея и вайрфреймы

Продуктовая логика и информационная архитектура

Главная дизайн-задача — объединить прием, анализы, курсы, цели и историю в одну связанную систему. Я спроектировал флоу, переходы, крайние состояния и постепенное раскрытие функциональности, чтобы пользователь понимал связь между действиями и результатами.

В течение дня

Я хочу отмечать приём добавок и видеть, что запланировано и что пропущено.

Анализы

Я хочу добавлять показатели, ставить цели и видеть динамику.

Курсы

Я хочу управлять курсами, дозировками и понимать, как они влияют на анализы.

Разработка

Создание приложения в Xcode

Я начал с базовой логики и структуры данных, а не с финального UI. Дизайн-система и SwiftUI-архитектура развивались вместе: каждую связь между приемом, курсами и показателями я проверял через реальное поведение продукта.

Прототип

Собрал основные компоненты и проверил базовые сценарии. Навигацию добавил позже, когда логика стала устойчивой.

Промежуточный UI

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

Интерфейс

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

Рабочая версия

После нескольких итераций логика стала понятной. Самая сложная часть — корректно показать зависимость приёма и изменений в показателях.

Реклама App Store

Проработка рекламы

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

Варианты

Дизайн должен был выглядеть серьёзно. Минимум лишних обещаний. Больше фактов и структуры.

Цвет и стиль

Выбрал более живой и яркий стиль с чёткими формулировками.

TestFlight

Проверил сборки, локализацию и стабильность. В этот раз сделал больше тестов до релиза.

Онбординг

Онбординг как взаимодействие

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

Настройка

Добавил отдельный навык для Codex с гайдлайнами и лучшими практиками. Это помогло делать онбординг осознанно и системно.

Взаимодействие

После анализа конкурентов онбординг стал интерактивным. Появились развилки и разные сценарии в зависимости от ответов пользователя.

Доступность

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

Выводы

Не стоит полировать дизайн до финальной логики
Интерактивный онбординг лучше статичного
Стабильность и автопроверки экономят время после релиза

Другие проекты

Part Production Cell — MES & OEE

OpenPLC, Ignition Perspective и SQLite: порядок в событиях, KPI и причинах простоев.

Смотреть кейс

Conveyor Sorting

OpenPLC и Ignition: ladder-логика, Structured Text state machine, обратная связь датчиков и проверяемые циклы.

Смотреть кейс

Monitoring — UPL

Enterprise-мониторинг для АЭС: состояния системы, инженерные ограничения и 3D-логика хранилищ.

Смотреть