Создайте трекер с минимальным вводом и высоким сигналом

Что действительно означает «минимальный ввод, высокий сигнал»

«Минимальный ввод» не значит, что ваше приложение примитивно. Это значит, что пользователь может зафиксировать произошедшее за секунды — часто одним тапом — без ввода текста, прокрутки или множества решений.

«Высокий сигнал» означает, что эти быстрые записи надёжно приводят к полезным паттернам: что меняется со временем, что что-то вызывает что-то, и какие действия помогают. Цель не в том, чтобы собирать больше данных — а в том, чтобы собирать правильные данные.

Определите это для своего приложения

Минимальный ввод — это конкретное ограничение, которое вы проектируете, например:

• Один экран для записи
• 1–3 выбора на запись
• Ниже 10 секунд на ввод

Высокий сигнал тоже конкретен. Запись — «высокосигнальная», если она поддерживает понятный инсайт, например «сон меньше 6 часов увеличивает дневные тяги» или «головные боли чаще после долгих встреч».

Примеры в разных категориях отслеживания

Принцип работает в разных вариантах:

• Настроение: оценка 1–5 + опциональный тег (например «работа», «семья», «общение»)
• Привычки: сделал/не сделал + контекст («утро», «после обеда»)
• Симптомы: степень тяжести + область тела + один подозреваемый триггер как тег
• Траты: сумма + категория; торговая точка и заметки — опционально
• Тренировки: тип + длительность; интенсивность как быстрый слайдер

Обратите внимание, чего нет: длинных опросников, подробных дневников и обязательных заметок.

Самая распространённая ошибка

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

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

Результат, к которому вы стремитесь

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

Начните с одной цели отслеживания

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

Выберите один вопрос, на который вы даёте ответ

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

• «Какие ситуации запускают мои дневные перекусы?»
• «Какие тренировки дают энергию на следующий день?»
• «Сплю ли я лучше в дни, когда гуляю более 20 минут?»

Хороший вопрос достаточно конкретен, чтобы подсказывать, что логировать (и что не логировать). Если вопрос не подразумевает небольшой набор событий, он, вероятно, слишком широк.

Определите решение, которое примет пользователь

Отслеживание важно только если оно ведёт к действию. Определите решение, которое пользователь примет на основе данных, затем проектируйте назад от него.

Например:

• Решение: «Я буду избегать кофе после 14:00»
• Значит нужно зафиксировать: время кофе (быстро), качество сна на следующее утро (быстро) и опционально простой тег контекста.

Если вы не можете назвать решение, вы проектируете не трекер, а дневник.

Определите метрики успеха для первого релиза

Установите измеримые сигналы, которые покажут, работает ли цель:

• Ежедневный процент выполнения: % активных пользователей, которые записали минимальный необходимый ввод в день
• Просмотры инсайтов: как часто пользователи открывают экран «результаты» (или просматривают сгенерированный вывод)
• Удержание: пользователи, вернувшиеся на 2/4 неделю (выберите одну как основную)

Держите эти метрики привязанными к единой цели; избегайте показательной аналитики вроде общего числа записей.

Список допущений для проверки в v1

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

• Пользователь может ответить на требуемый запрос за менее чем 5 секунд.
• Записанные данные достаточно последовательны, чтобы заметить паттерны в течение 7–14 дней.
• Пользователи доверяют приложению в этой категории информации.
• Первый «инсайт» ощущается явно полезным, а не просто интересным.

Зафиксируйте цель и сопротивляйтесь добавлению функций до тех пор, пока эти допущения не будут проверены.

Проектируйте цикл отслеживания (Log → Learn → Act)

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

Отобразите путь: триггер → лог → обратная связь → следующее действие

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

• Триггер: что-то происходит (приём пищи, тяга, тренировка, смена настроения).
• Лог: пользователь фиксирует минимум, сохраняющий смысл.
• Обратная связь: приложение немедленно отражает, что изменилось (оценка дня, стрик, тренд, предупреждение или победа).
• Следующее действие: одна рекомендация, которую легко выполнить (выпить воды, короткая прогулка, спланировать задачу на завтра).

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

Выберите минимальный набор событий, объясняющих прогресс

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

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

Размечайте поля как «обязательно / опционально»

Для каждого экрана логирования помечайте вводы:

• Обязательно: нужно для генерации обратной связи (часто просто время + одно значение)
• Желательно: полезно позже, но не обязательно (заметки, теги, фото)

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

Планируйте работу с неполными данными

Реальные пользователи пропускают дни и логируют частично. Спроектируйте это:

• Позвольте заполнять задним числом без чувства вины (быстро зафиксировать вчера)
• Поддерживайте неизвестные значения вместо вынуждения угадывать
• Обращайтесь с разрывами как с данными (например, «нет записи» отличается от «нет события»)

Хороший цикл поощряет честность и последовательность, а не идеальность.

Паттерны ввода, минимизирующие усилия

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

Подход «по умолчанию в первую очередь» (уберите решения)

Начните каждый экран записи с уже выбранным значением. Предзаполняйте поля последним использованным значением, наиболее частым вариантом или разумным базисом (например, «30 мин» для тренировки или «Средне» для интенсивности настроения). Позвольте менять его только при необходимости.

Умные подсказки лучше работают, когда они предсказуемы:

• Показывайте сначала «недавно использованные» варианты
• Предлагайте короткий список типичных значений вместо длинного меню
• Запоминайте предпочтения на уровне пользователя (не глобальные средние)

Это превращает логирование в подтверждение, а не в конфигурацию.

Логирование в один тап (сократите время выполнения)

По возможности логирование должно быть одним действием:

• Большие кнопки для частых событий (например, «Принял лекарства», «Прогулка», «Кофеин»)
• Быстрые пикеры (чипсы) для дискретных значений вроде «Низкая / Средняя / Высокая»
• Слайдеры для быстрых диапазонов, когда точность не критична

Если запись требует деталей, пусть первый тап сохраняет лог сразу, а «добавить детали» будет опциональным. Многие пользователи пропустят лишнее — и это нормально, если основной сигнал захвачен.

Шаблоны для повторяющихся записей

Люди повторяют рутины. Дайте им шаблоны вроде «Обычная тренировка» или «Типичное меню», которые сворачивают несколько полей в один тап. Шаблоны должны быть редактируемыми со временем, но не требовать настройки до того, как приложение станет полезным.

Простое правило: если пользователь записал одинаковую комбинацию дважды, приложение должно предложить сохранить её как шаблон.

Офлайн-первый подход (сохраняйте импульс)

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

Простая модель данных, которая всё ещё даёт инсайты

Высокосигнальное приложение не требует сложной БД. Ему нужна ясная «единица» отслеживания и структура, сохраняющая правду случившегося при этом позволяющая быстро выдавать дружелюбные инсайты.

1) Выберите единицу отслеживания

Решите, какое одно действие пользователя представляет ваша система:

• Запись: одна быстрая пометка (например «кофе», «головная боль», «принял лекарства»)
• Сессия: ограниченная активность (например тренировка со старт/стоп)
• День: один чек-ин в день (например оценка настроения, качество сна)
• Событие: отметка с меткой времени (лучше всего для минимального ввода: один тап = один факт)

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

2) Храните сырые события плюс лёгкие сводки

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

Практический базис:

• Event: id, user_id, type, timestamp, опционально value (число), опционально note
• Daily summary: date, type, total_count, total_value, streak, last_event_time

Сырые события защищают вас от потери деталей в будущем. Сводки делают диаграммы мгновенными и дают возможности вроде стриков без переработки всего объёма данных.

3) Захватывайте контекст только если он улучшает сигнал

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

• Время: часто бесплатно (автозахват) и очень информативно
• Местоположение: только если оно объясняет паттерны (и только с явным разрешением)
• Теги: отличны, когда пользователь хочет один дополнительный тап для пояснения (например «с друзьями», «на работе»)

Если поле контекста опционально и редко используется, подумайте о автоподсказках или умолчаниях вместо принудительного ввода.

4) Планируйте правки и удаления без поломки графиков

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

• Делайте сводки производными: пересчитывайте дневные итоги при изменении события.
• Используйте мягкое удаление (deleted_at) для аудита и чтобы избежать запутывающих артефактов «пропавших данных».
• Когда событие перемещается на другой день (редактирование timestamp), обновляйте сводки обоих дней.

Эта модель даёт надёжные тренды, стрики и дружелюбную обратную связь без перегрузки формами.

Превращение логов в высокосигнальные инсайты

Собирать логи — это только половина работы. Ценность минимального трекера в том, чтобы маленькие точки данных превращались в ответы, по которым человек может действовать.

Начните с нескольких производных метрик, которые кажутся «очевидными»

Вместо того чтобы тонуть в сырых событиях, вычислите небольшой набор метрик, которые суммируют прогресс:

• Средние (например «Вы логируете 4 раза в неделю»)
• Стрики (например «3 дня подряд», а также «последовательность по неделям»)
• Вариативность (например «ваш показатель сна стабильный или скачущий»)

Они просты для понимания и хорошо работают даже при пропусках.

Обнаруживайте значимые изменения (без чрезмерной реакции)

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

• 7‑дневный тренд: хорош для краткосрочной динамики и «эта неделя против прошлой»
• 30‑дневный тренд: хорош для стабильности, сезонности и того, прижилась ли перемена

Используйте простые, обоснованные сигналы: пересечение порога (например «меньше 3 дней/нед»), устойчивое улучшение в течение двух недель или заметный сдвиг в среднем. Избегайте рассматривать один удачный (или плохой) день как перелом.

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

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

• Диапазоны («обычно 3–5 раз в неделю») вместо десятичных дробей
• Подсказки про уверенность («на основе 6 записей в этом месяце»), вместо притворства, что вы знаете больше, чем есть
• Простые объяснения («Ваши чек‑ины были более последовательны в этом месяце») рядом с графиком

Рекомендуйте «что попробовать дальше» (без медицинских заявлений)

Преобразуйте инсайты в лёгкие рекомендации, которые не звучат клинически:

• «Вам лучше логировать до полудня — поставить утреннее напоминание?»
• «Последовательность просела по выходным — попробуйте более простой вариант на выходные.»
• «Вы в тренде роста за 30 дней — держите тот же план еще неделю и пересмотрите.»

Формулируйте рекомендации как эксперименты, которые пользователь может выбрать, а не как диагнозы или обещания. Цель — меньше цифр, больше ясности и один следующий шаг.

UX для обратной связи: делайте результаты очевидными

Минимальный трекер кажется «стоящим», когда вознаграждение очевидно. Если пользователь что‑то логирует и не видит, что изменилось, он бросит приложение — даже если данные технически собираются.

Ставьте «сегодня» в центр

Главный экран должен отвечать на два вопроса за секунду:

• Какое одно действие нужно сделать (или залогировать) сегодня?
• Какой прогресс я уже сделал?

Спроектируйте домашний экран вокруг действия на сегодня + быстрого вида прогресса. Быстрый вид может быть простым числом («3‑дневный стрик»), мини‑спарклайном или статусом («В графике на этой неделе»). Главное — это видно без перехода в дашборд.

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

Последовательность важнее разнообразия. Выберите 1–2 типа диаграмм и используйте их везде, чтобы пользователи выучили «визуальный язык».

Хорошие варианты:

• Линейный график для трендов
• Столбчатая диаграмма для сумм/сравнений
• Календарная heatmap для ежедневной последовательности

Что бы вы ни выбрали, делайте графики читаемыми:

• Всегда показывайте чёткие подписи (что, единицы)
• Начинайте с честной базы (часто ноль для столбиков)
• Предлагайте простой переключатель диапазона (7 дней / 30 дней / 12 недель)

Избегайте мелкого текста, блеклых цветов или «умных» осей. График, требующий интерпретации, — это график, который не будут использовать.

Заметки не должны быть дефолтом — используйте их для объяснения всплесков

Свободные заметки могут быстро превратить «минимальный ввод» в домашнее задание. Добавляйте заметки экономно, только когда они помогают объяснить выбросы.

Хороший паттерн — опциональный, лёгкий подсказ после необычного события:

• «Это выше обычного — хотите добавить причину?»

Это сохраняет быстрый цикл и всё же ловит контекст, когда он важен.

Умные напоминания без раздражения

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

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

Общие «Не забудьте записать!» быстро игнорируются. Связывайте подсказки с моментами, которые уже происходят:

• Утренний кофе → «Залогировать сон в один тап»
• После обеда → «Быстрая проверка настроения?»
• Время тренировки → «Записать сессию?»

Напоминание «пристёгивается» к существующей привычке и потому кажется своевременным, а не случайным.

Дайте пользователям контроль: частота и «тихие часы»

Люди по‑разному терпимы к уведомлениям. Разместите управление на виду и сделайте его простым:

• Выбор частоты (ежедневно, только в будни, 3×/нед, пользовательская)
• Тихие часы (без звука во время встреч, вечером или сна)
• Опции «отложить на 1 час / до завтра»

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

Делайте уведомления одношаговыми (логирование в один тап)

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

Проектируйте уведомления, которые могут логировать в один тап, например:

• Кнопки: «Сделано», «Пропустить», «Не сегодня»
• Один слайдер или быстрая оценка (например стресс 1–5)
• Подтверждение: «Записано — молодец» с опцией отмены

Это удерживает цикл «напоминание → действие» в пределах нескольких секунд.

Реактивация после пропусков без вины

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

• Пропуск 2 дня: «Хотите перезапустить с меньшей целью?»
• Пропуск 5 дней: «Перейти на напоминания 3×/нед?»

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

Приватность, доверие и основы безопасности данных

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

Собирайте минимум (и помечайте остальное как опциональное)

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

Если что‑то опционально — делайте это явным в интерфейсе. Опционные данные не должны блокировать основной опыт и не должны тихо менять поведение приложения без уведомления пользователя.

Объясните использование данных простым языком при первом запуске

Экран первого запуска должен ясно отвечать на три вопроса:

• Какие данные сохраняются?
• Почему это нужно (что пользователь получит взамен)?
• Где это хранится (на устройстве, в облаке или и там, и там)?

Избегайте юридического языка. Используйте короткие предложения и конкретные примеры, например «Мы используем ваши чек‑ины, чтобы показать недельные паттерны», а не «Мы обрабатываем персональные данные для улучшения сервисов».

Предпочитайте хранение на устройстве и защищайте его

Для многих минимальных трекеров локальное хранение достаточно для MVP и снижает экспозицию.

Если вы храните данные локально:

• Используйте встроенные средства безопасного хранения платформы
• Шифруйте чувствительные записи в покое, если утечка может навредить
• Защищайте доступ с помощью аутентификации устройства (PIN/биометрия) для «приватного режима»

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

Дайте контроль: экспорт, удаление и правила хранения

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

Включите:

• Экспорт (CSV/JSON обычно достаточно) чтобы пользователи не были в заложниках
• Удаление (одна запись, диапазон дат, и полная очистка аккаунта/устройства)
• Правила хранения (например «мы храним бэкапы X дней», если используете облако)

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

Объём MVP и варианты сборки

MVP минимального трекера — это не «уменьшенная версия полного приложения». Это тщательно ограниченный продукт, доказывающий одну вещь: люди будут логировать быстро, и приложение даст результат, ради которого стоит возвращаться.

Определите MVP: 1 трекер, 1 инсайт, 1 напоминание

Ограничьте объём намеренно:

• 1 основной трекер: выберите одно поведение/тип события (например «кофе», «головная боль», «учебная сессия»). Поддерживайте одно быстрое взаимодействие для логирования.
• 1 экран инсайта: один экран, отвечающий на ясный вопрос (например «Как часто на этой неделе?» или «В какое время это обычно случается?»). Если он не меняет решение — не нужен в MVP.
• 1 поток напоминаний: один стиль напоминания (по времени или контексту) с одним ясным действием («Залогировать сейчас»). Пока не добавляйте расписания, стрики, виджеты и несколько типов уведомлений.

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

Выберите подход к сборке в зависимости от рисков

Есть три практичных пути:

• Нативно (iOS/Android): лучшая производительность и интеграция с ОС (уведомления, данные здоровья, системный UI). Выбирайте, если логирование должно быть мгновенным и вы планируете долгосрочно.
• Кросс‑платформенно (Flutter/React Native): быстрее итерации с одной базой кода, хороший контроль UI. Выбирайте, если нужно быстро тестировать несколько идей трекеров.
• No‑code / прототипы: самый быстрый способ валидировать дизайн взаимодействия. Выбирайте, когда главный риск — будут ли люди действительно логировать и понимать обратную связь.

Лучший вариант — тот, который позволяет протестировать основной цикл с наименьшими затратами на инфраструктуру.

Если хотите двигаться быстро, не привязываясь к тяжёлому пайплайну, подход vibe‑кодинга может помочь. Например, Koder.ai позволяет строить и итеративно развивать трекер из чат‑интерфейса, генерировать React веб‑приложение (с бэкендом Go + PostgreSQL) и даже расширять до Flutter для мобильных — полезно, когда приоритетом является проверка цикла (log → feedback → next action) прежде чем доводить до идеала все детали.

Прототипируйте скорость и ясность логирования в первую очередь

Прежде чем строить реальное хранилище и графики, сделайте кликабельный прототип, симулирующий:

• открытие приложения и лог в 1–2 тапа
• подтверждение лога (тонко, но явно)
• просмотр единственного экрана инсайта

Тестируйте с несколькими людьми и измеряйте: Сколько секунд на лог? Где они сомневаются? Понимают ли они, что даст им приложение после записи?

Планируйте аналитику, показывающую успех

Определите «события успеха» заранее, чтобы учиться быстро:

• Воронка логирования: открытие приложения → начало лога → сохранённый лог
• Сигнал возврата: просмотр экрана инсайта после лога
• Прокси удержания: логи на день 2 и день 7
• Качество напоминаний: уведомление доставлено → открыто → лог сохранён (и процент отписавшихся)

Если MVP не может ясно ответить, легко ли логировать и полезны ли инсайты, он плохо спланирован.

Чек‑лист для тестирования, запуска и итераций

Минимальный трекер работает только если логировать легко, а обратная связь — полезна. В тестировании ваша цель — доказать (или опровергнуть), что люди могут логировать за секунды, понимают, для чего приложение, и возвращаются, потому что инсайты помогают.

Наберите правильных 10–20 тестеров

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

Перед стартом задайте два вопроса:

• Что вы сейчас пытаетесь улучшить?
• Что заставит вас перестать пользоваться через 3 дня?

Проведите фокусный тест на 7 дней

Держите тест коротким и структурированным, чтобы можно было сравнить результаты.

Измеряйте:

• Время на лог: сколько времени от открытия до завершения лога
• Процент выполнения: в скольких днях они сделали хотя бы одну запись

Также отслеживайте точки отсева: дни 2 и 5 — частые моменты «молчунов».

Собирайте качественную обратную связь (почему)

Числа показывают что; интервью объясняют почему. Проведите 10–15‑минутный звонок или голосовую заметку в середине недели и в конце.

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

• «Что показалось запутанным?»
• «Что показалось лишним?»
• «Если бы вы могли удалить один экран или шаг, что бы это было?»
• «Говорило ли приложение вам когда‑нибудь что‑то полезное? Когда?»

Подготовьте материалы для запуска, снижающие нагрузку поддержки

Создайте простые материалы, предотвращающие недопонимания:

• Онбординг, объясняющий цель трекера одной фразой
• Короткое FAQ про логирование, напоминания и обработку данных
• Скриншоты для магазина приложений, показывающие: скорость логирования, один инсайт и что пользователь получает через неделю

План итераций после запуска (продолжайте сокращать)

Планируйте еженедельные ревью первый месяц. Приоритеты:

• Удалять поля, которые не дают инсайтов или решений
• Улучшать значения по умолчанию, чтобы первый лог занимал меньше тапов
• Дорабатывать инсайты, чтобы отвечать «Что мне попробовать дальше?», а не только «Что случилось?»

Если ваша сборка поддерживает быструю итерацию (snapshots/rollback и быстрые деплои — функции, доступные на платформах вроде Koder.ai), будет проще упростить без страха сломать рабочее.

Если удержание растёт после упрощения — вы двигаетесь в правильном направлении.