Роль:
Product Designer
Срок:
2 месяца / In Dev
Команда:
Founder, разработка
Платформа:
iOS/Android, десктопная админка
Мобильное приложение для семей, где взрослые дети или внуки заботятся о пожилом родственнике на расстоянии. Ключевая функция — сигнал SOS с передачей последнего местоположения и состояния устройства.
Проект начался не с рынка, а с задачи фаундеров: нужен был продукт с социальной значимостью для подачи на «Валдай». Это определило и сроки, и то, что концепт пришлось собирать с нуля — улучшать было нечего.
Проект начался не с рынка, а с задачи фаундеров: нужен был продукт с социальной значимостью для подачи на «Валдай». Это определило и сроки, и то, что концепт пришлось собирать с нуля — улучшать было нечего.
Мобильное приложение, в котором родственник видит последнее местоположение и заряд телефона пожилого близкого, а тот может подать сигнал SOS. Всё по обоюдному согласию.
Приложение заботы о близких
Целевая аудитория
Администратор — заботящийся родственник
30–50 лет, живёт отдельно от родителя, часто в другом городе. Со смартфоном на «ты». Он платит за подписку и он же решает, что приложение вообще появится в семье. Его боль не «хочу знать, где мама», а «не знаю, всё ли у неё в порядке, а звонить каждые два часа неудобно обоим».
Близкий — пожилой пользователь
60+, из телефона использует звонки, мессенджер и иногда камеру. Сам приложение не установит и другого пользователя в нём не найдёт. Любой лишний экран для него барьер. При этом именно он в критический момент должен нажать одну кнопку.
Конкуренты
Прямые конкуренты на рынке РФ и СНГ: Life360, «Где мои дети», встроенные «Локатор» и Find My Device, GPS-часы и трекеры для пожилых.
Оси сравнения: наличие SOS · режим трекинга (постоянный / периодический) · расход батареи · кто заводит связь · обоюдное согласие · монетизация · порог входа для пожилого.
Большинство продуктов спроектированы вокруг сценария «родитель следит за ребёнком». Пожилой человек там не пользователь, а объект наблюдения. Мы проектировали его как полноценную сторону — со своим действием и своим согласием.
Оси сравнения: наличие SOS · режим трекинга (постоянный / периодический) · расход батареи · кто заводит связь · обоюдное согласие · монетизация · порог входа для пожилого.
Большинство продуктов спроектированы вокруг сценария «родитель следит за ребёнком». Пожилой человек там не пользователь, а объект наблюдения. Мы проектировали его как полноценную сторону — со своим действием и своим согласием.
Цели
— Превратить идею фаундеров в проектируемый MVP с внятными границами первой версии
— Спроектировать сценарий, где пожилой человек — участник, а не объект наблюдения
— Обеспечить работоспособность главной функции: SOS должен сработать тогда, когда он нужен
— Спроектировать сценарий, где пожилой человек — участник, а не объект наблюдения
— Обеспечить работоспособность главной функции: SOS должен сработать тогда, когда он нужен
Боли
Администратор:
— Не знает, всё ли в порядке, и не может проверить, не побеспокоив
— Звонки «просто проверить» воспринимаются как контроль и раздражают обе стороны
— В экстренной ситуации не понимает, где человек находится
— Не знает, всё ли в порядке, и не может проверить, не побеспокоив
— Звонки «просто проверить» воспринимаются как контроль и раздражают обе стороны
— В экстренной ситуации не понимает, где человек находится
Близкий:
— Не может быстро позвать на помощь, если растерялся или стало плохо
— Не хочет чувствовать себя под наблюдением
— Не разберётся в приложении с несколькими экранами и настройками
— Не может быстро позвать на помощь, если растерялся или стало плохо
— Не хочет чувствовать себя под наблюдением
— Не разберётся в приложении с несколькими экранами и настройками
Гипотезы
Если всю сложность настройки перенести на администратора, а близкому оставить два действия — принять приглашение и подтвердить передачу данных, — доля успешно установленных связей вырастет
Периодический запрос геолокации вместо постоянного трекинга снизит расход батареи и повысит долю устройств, доступных в момент SOS
Показ заряда наравне с местоположением снизит число ложных тревог: разряженный телефон объясняет, почему данные не обновились
Пейвол сразу после регистрации снижает конверсию в активацию, потому что пользователь ещё не увидел ценность продукта
Гипотеза Г4 — моё возражение против принятого решения по монетизации. Аргументацию вынес в отчетность по проекту, а саму гипотезу сформулировал так, чтобы спор можно было закрыть данными после запуска, а не мнениями.
Метрики
Продукт в разработке, аналитики на старте не существовало. Метрики определены заранее вместе с тем, каким событием измеряется каждая — базовую линию разработка собирает вместе с запуском.
Доля приглашений, дошедших до установленной связи
Г1 — главная гипотеза продукта
Доля устройств, доступных в момент запроса геолокации
Г2 — жив ли канал SOS
Время от нажатия SOS до открытия уведомления
Основной сценарий end-to-end
Конверсия из регистрации в первую связь
Г4 — влияние пейвола
Retention администратора на 30 день
Возвращаются ли вообще
Доля приглашений, дошедших до установленной связи
Г1 — главная гипотеза продукта
Доля устройств, доступных в момент запроса геолокации
Г2 — жив ли канал SOS
Время от нажатия SOS до открытия уведомления
Основной сценарий end-to-end
Конверсия из регистрации в первую связь
Г4 — влияние пейвола
Retention администратора на 30 день
Возвращаются ли вообще
Роли и зоны ответственности
Концепт продукта, UX, user flow, макеты мобильного приложения и десктопной админки, лендинг, дизайн-документация, передача в разработку
Приоритизация, границы MVP, коммуникация с фаундерами
Продуктовое видение, требования к монетизации, финальные решения
Близкий нажимает кнопку — администратор получает уведомление с последним известным местоположением, временем этого местоположения и уровнем заряда устройства.
Вокруг главной функции построены поддерживающие: периодический запрос геолокации с передачей заряда, приглашение и установление связи, управление связями на стороне администратора, десктопный кабинет для нескольких подключённых людей, функция AI-звонков.
Вокруг главной функции построены поддерживающие: периодический запрос геолокации с передачей заряда, приглашение и установление связи, управление связями на стороне администратора, десктопный кабинет для нескольких подключённых людей, функция AI-звонков.
Сценарий установления связи
- Администратор регистрируется и проходит онбординг
- Настраивает параметры, формирует приглашение
- Близкий открывает приглашение
- Подтверждает передачу данных о местоположении
- Связь установлена, данные начинают поступать
Экстренный сценарий
- Близкий нажимает SOS — одно действие, без вложенных экранов
- Администратору приходит push с местоположением, временем и зарядом
- Администратор открывает карточку и связывается с человеком
Временные и технические рамки
Сроки. Два месяца на весь объём: концепт, лендинг, регистрация и логин, мобильное приложение по принципу Mobile First, десктопный кабинет администратора. Дата подачи проекта на «Валдай» была жёсткой.
Заряд батареи как критическое ограничение. Постоянный трекинг разряжает устройство, а телефон пожилого человека — это и есть канал для SOS. Продукт, который сажает аккумулятор ради точности на карте, ломает собственную главную функцию.
Разный уровень цифровой грамотности. Один интерфейс на уверенного пользователя и на человека, который открывает в телефоне три приложения.
Правовое. Продукт передаёт данные о местоположении живого человека — нужно согласие и работа в рамках 152-ФЗ.
Продуктовое от заказчика. Пейвол размещается сразу после регистрации — требование к воронке монетизации.
Заряд батареи как критическое ограничение. Постоянный трекинг разряжает устройство, а телефон пожилого человека — это и есть канал для SOS. Продукт, который сажает аккумулятор ради точности на карте, ломает собственную главную функцию.
Разный уровень цифровой грамотности. Один интерфейс на уверенного пользователя и на человека, который открывает в телефоне три приложения.
Правовое. Продукт передаёт данные о местоположении живого человека — нужно согласие и работа в рамках 152-ФЗ.
Продуктовое от заказчика. Пейвол размещается сразу после регистрации — требование к воронке монетизации.
Как принимались решения
Продукта не существовало, поэтому работа шла от концепта к MVP через итерации с заказчиком, а не от гипотез к тестам.
Это не был Design Thinking в чистом виде — не было ни бюджета на полевые исследования, ни времени на цикл «прототип — тест — итерация» с реальными пользователями. Честная рамка проекта: проектирование от структуры задачи и ограничений при отсутствии данных.
Это не был Design Thinking в чистом виде — не было ни бюджета на полевые исследования, ни времени на цикл «прототип — тест — итерация» с реальными пользователями. Честная рамка проекта: проектирование от структуры задачи и ограничений при отсутствии данных.
Ресёрч
Что было. Глубинные интервью с founder и co-founder — не как с заказчиками, приносящими ТЗ, а как с носителями продуктового видения. Разбирали: что обязательно в MVP, что можно отрезать, каким они видят пользователя, какой сценарий считают главным. По результатам собрал концепт и прошёл несколько итераций согласования.
Чего не было и почему. Интервью с реальной ЦА — пожилыми людьми и их взрослыми детьми. Причина: сроки под подачу и отсутствие бюджета на исследование. Это главное ограничение проекта.
Чего не было и почему. Интервью с реальной ЦА — пожилыми людьми и их взрослыми детьми. Причина: сроки под подачу и отсутствие бюджета на исследование. Это главное ограничение проекта.
UX-артефакты
User flow со swimlane-диаграммами
Продукт двусторонний: действие одного пользователя вызывает реакцию у другого. Линейный флоу здесь не работает — нужно было развести дорожки администратора и близкого и показать точки пересечения. Без этого невозможно объяснить разработке, что происходит при приглашении и при SOS
Спецификация сценариев
Документ для разработки: что происходит в каждом состоянии связи — приглашение отправлено, принято, отклонено, связь разорвана
Компоненты согласия под 152-ФЗ
Отдельные компоненты чекбоксов с корректными формулировками и ссылками на документы. Продукт передаёт персональные данные, согласие должно быть явным действием
Десктопные адаптации
Кабинет администратора: другая роль, другая частота, другой объём данных. Проектировался под десктоп отдельно, а не растягиванием мобильных макетов
Продукт двусторонний: действие одного пользователя вызывает реакцию у другого. Линейный флоу здесь не работает — нужно было развести дорожки администратора и близкого и показать точки пересечения. Без этого невозможно объяснить разработке, что происходит при приглашении и при SOS
Спецификация сценариев
Документ для разработки: что происходит в каждом состоянии связи — приглашение отправлено, принято, отклонено, связь разорвана
Компоненты согласия под 152-ФЗ
Отдельные компоненты чекбоксов с корректными формулировками и ссылками на документы. Продукт передаёт персональные данные, согласие должно быть явным действием
Десктопные адаптации
Кабинет администратора: другая роль, другая частота, другой объём данных. Проектировался под десктоп отдельно, а не растягиванием мобильных макетов
Что бы сделал иначе
Согласия. Сейчас это чекбоксы со ссылками на документы. Для продукта, передающего местоположение живого человека, мало: пользователь должен понимать, кто и как часто видит его данные, и уметь отозвать доступ в одно действие, а не через поддержку.
Ресёрч. Даже пять коротких разговоров с реальными пожилыми пользователями и их детьми изменили бы приоритеты в MVP. На этом стоит настаивать даже при сжатых сроках.
Аналитика. Метрики надо было закладывать в разработку сразу, а не определять постфактум при выкате MVP.
Ресёрч. Даже пять коротких разговоров с реальными пожилыми пользователями и их детьми изменили бы приоритеты в MVP. На этом стоит настаивать даже при сжатых сроках.
Аналитика. Метрики надо было закладывать в разработку сразу, а не определять постфактум при выкате MVP.
Установление связи
Что было. Обоюдная регистрация: оба пользователя ставят приложение, регистрируются и находят друг друга внутри по номеру телефона.
Что не сработало. При разборе сценария стало ясно, что пожилой человек этот путь не пройдёт. Он не установит приложение по своей инициативе, не пройдёт регистрацию и не найдёт другого пользователя в интерфейсе. Продукт умирал бы на первом шаге у половины пар.
Что изменил. Развернул путь: всё начинается от администратора. Он регистрируется, настраивает и отправляет приглашение. На стороне близкого остаётся два действия — открыть приглашение и подтвердить передачу данных.
Как проверил. Обсуждение с фаундерами. Побочно решение закрыло вопрос согласия: связь физически не возникает, пока вторая сторона её не приняла.
Что не сработало. При разборе сценария стало ясно, что пожилой человек этот путь не пройдёт. Он не установит приложение по своей инициативе, не пройдёт регистрацию и не найдёт другого пользователя в интерфейсе. Продукт умирал бы на первом шаге у половины пар.
Что изменил. Развернул путь: всё начинается от администратора. Он регистрируется, настраивает и отправляет приглашение. На стороне близкого остаётся два действия — открыть приглашение и подтвердить передачу данных.
Как проверил. Обсуждение с фаундерами. Побочно решение закрыло вопрос согласия: связь физически не возникает, пока вторая сторона её не приняла.
Как принимались решения
Работа шла полным циклом: разбор пользовательских сценариев, UX, прототипы, UI, внутренние тестирования у заказчика, доработка по обратной связи. Три итерации.
Основа ресёрча — разбор реальных рабочих сценариев сервисного центра: как принимается изделие, как определяется неисправность, как заказывается деталь, что попадает в документы. Требования приходили от заказчика, но логику сценариев я разбирал сам.
Временные и предметные рамки
Сроки. Три месяца на 18 экранов с библиотекой компонентов, три полных итерации с внутренними тестированиями заказчика.
Пользователь знает предметную область лучше системы. Интерфейс не может объяснять человеку то, что он знает лучше — он должен убирать шаги, а не добавлять подсказки.
Цена ошибки. Не та запчасть, не тот договор, перепутанный серийный номер — и ремонт теряет статус сертифицированного. Точность важнее скорости.
Согласование внутри крупной компании. Требования приходили и уточнялись через ЛПР, каждое решение должно было быть не просто верным, а объяснимым.
Доступ. Продукт закрытый, мой доступ ограничивался разделом дизайна. Аналитику и внутренние данные я не затрагивал.
