Что отправить команде вместо списка экранов
Чтобы подготовиться к разработке мобильного приложения, отправьте всем командам одну страницу с четырьмя ответами и отдельным списком неизвестного.
Эти ответы не назначают мобильное приложение победителем. Иногда они показывают, что задачу быстрее проверить сайтом, которым удобно пользоваться с телефона, ботом, ручным сервисом или интеграцией. Подробное сравнение цифровых форматов полезно читать после того, как главный сценарий уже назван.
Почему список функций даёт несравнимые оценки
Представьте сервис записи. В заметке написано: регистрация, каталог специалистов, календарь, чат, оплата, отзывы, уведомления и программа лояльности. Первая команда предполагает маркетплейс с личными кабинетами двух сторон. Вторая видит приложение одной клиники. Третья закладывает только запись постоянных клиентов. Названия экранов совпадают, а пользователи, данные, роли и объём серверной работы разные.
В результате вы сравниваете не ставки команд, а три додуманных продукта. Самая низкая цена может означать узкий сценарий без нужной интеграции. Самая высокая может включать роли и функции, которые вы не просили. Пока вводные разные, цифры рядом в таблице не становятся сопоставимыми.
Проверка: уберите из описания слова «приложение», «экран» и названия технологий. Если всё ещё понятно, кто что делает, какой результат получает и зачем возвращается, у команды есть основа для разговора. Если остаётся только перечень кнопок, нужно вернуться к задаче.
Вопрос первый: кто пользователь и какую задачу он решает
Ответ «наша целевая аудитория» слишком широкий. У продукта могут быть покупатель, фактический пользователь, плательщик, оператор и руководитель. Их цели расходятся. В сервисе записи посетитель хочет выбрать время и получить подтверждение; администратор хочет не допустить двойной записи; владелец следит за загрузкой и отменами.
Начните с одного приоритетного человека и конкретной ситуации. Не «женщины 25–45 лет», а «постоянный клиент салона, который вечером хочет повторить знакомую услугу у свободного мастера и не звонить администратору». Такая формулировка уже меняет продукт: важны история посещений, доступные слоты и понятное подтверждение, а публичный чат может подождать.
Слабый и рабочий ответ
Слабо
«Приложение для клиентов салона. Им нужны услуги, акции и удобная запись».
Рабочая версия
«Постоянный клиент повторяет знакомую услугу, выбирает мастера и свободное время, затем получает подтверждение без звонка».
Добавьте текущий обход: как человек решает задачу без нового продукта? Звонит, пишет администратору, открывает сайт, хранит номер заказа в сообщениях, ведёт таблицу? Текущий путь показывает реального конкурента приложения. Часто это не другое приложение, а привычный способ, который уже «достаточно хорош».
Руководство GOV.UK по изучению пользовательских потребностей предлагает выяснять, кто пытается выполнить задачу, как делает это сейчас и где сталкивается с проблемой. Мнение владельца остаётся гипотезой, пока его не сверили с пользователями. Для коммерческого продукта это не бюрократия, а защита от функции, которую никто не просил.
Вопрос второй: когда задача возникает снова
«Люди будут пользоваться регулярно» ничего не объясняет. Назовите событие, которое снова создаёт потребность. Закончились расходные материалы. Пришло время следующей тренировки. Появилась новая смена. Клиенту нужно повторить заказ. Врач назначил контрольный визит. Событие существует вне интерфейса; уведомление лишь помогает не пропустить его.
Теперь укажите ритм и контекст. Несколько раз в день на складе, раз в неделю в спортзале, раз в месяц при заказе, раз в год при продлении документа. Частота влияет не только на удержание. Она меняет допустимое трение входа, ценность установки, работу без сети, объём сохранённых данных и стоимость поддержки отдельного приложения.
Допустим, человеку раз в год нужно подать заявление по ссылке из письма. Требовать установку, регистрацию и разрешение на уведомления ради одного действия может быть хуже быстрого сайта с сохранением черновика. У приложения нет обязанности возвращать человека каждый день. У продукта есть обязанность честно решить задачу.
Формула ответа: «Когда происходит [событие], [пользователь] снова хочет [результат]. Сейчас он делает это [способ]. Новый продукт должен сократить или сделать надёжнее [часть пути]».
Вопрос третий: какой путь обязан сработать целиком
Список обязательных функций обычно растёт из пожеланий разных участников. Маркетингу нужен промокод, продажам чат, руководителю отчёт, пользователю быстрый вход. Если всё назвать обязательным, первая версия станет большой, но логика приоритета останется скрытой.
Опишите один путь от события, которое запускает задачу, до результата. Для записи он может выглядеть так: открыть свободные слоты, выбрать услугу и мастера, подтвердить время, получить итог записи, затем увидеть её в истории. Если календарь показывает устаревшие данные или подтверждение не дошло до администратора, красивый профиль не спасает сценарий.
Путь включает не только экран
- Вход: откуда человек приходит и что система уже знает о нём.
- Действие: какие решения принимает пользователь и какие данные вводит.
- Проверка: что подтверждает сервер, платёжный сервис, CRM (система с клиентами и записями) или оператор.
- Результат: что видит человек и что меняется в рабочей системе бизнеса.
- Ошибка: что происходит при занятом слоте, повторном нажатии, пропавшей сети или отказе оплаты.
Функция обязательна, если без неё пользователь не получит главный результат, бизнес не сможет выполнить обещание или команда не проверит критическое предположение. Остальное можно вынести в следующий цикл. Если вопрос упирается в риск идеи, а не в полный продукт, посмотрите, когда нужна первая версия для проверки идеи (MVP) и что она должна доказать.
GOV.UK рекомендует начинать с узнаваемой пользователем задачи и не расширять границы без необходимости. Это не запрет на многофункциональные продукты. Это способ убедиться, что первая версия завершает хотя бы один путь, а не показывает десять его начал.
Вопрос четвёртый: почему человек вернётся и как вы увидите пользу
Причина возврата не равна уведомлению, скидке или баллам. Сначала появляется новая потребность, затем канал помогает вернуться в нужный момент. Если повторной задачи нет, механика лояльности создаёт шум вокруг пустого сценария.
Сформулируйте повод обычной фразой: «через месяц клиенту снова нужна услуга», «каждое утро сотрудник получает новый список заданий», «после покупки меняется статус доставки», «в конце недели пользователь сверяет прогресс». Затем решите, какое полезное действие вы хотите увидеть, а не сколько раз человек открыл приложение.
Цель, сигнал, метрика, решение
Сначала назовите цель и видимый признак успеха, затем метрику. Для сервиса записи цель состоит в самостоятельной повторной записи, а признаком станет подтверждённый слот в календаре. Число ежедневных открытий здесь ничего не доказывает. Такой порядок выбора метрик предлагают исследователи Google.
- Цель: клиент сам повторяет запись без звонка.
- Сигнал: запись подтверждена, а слот появился в рабочем календаре.
- Событие: завершение повторной записи пользователем, который уже посещал салон.
- Группа и период: например, за месяц среди клиентов, которым уже пора записываться снова.
- Решение: если путь не завершают, исследовать конкретный шаг; если завершают, проверить следующую гипотезу.
Не подставляйте чужой «хороший процент». Даже официальная статистика магазина Google для Android различает активных и возвращающихся пользователей, периоды и способы расчёта. Сначала дайте собственное определение: кто считается подходящим пользователем, какое действие считается возвратом и за какой период вы его наблюдаете.
Как проверить четыре ответа перед отправкой команде
Хороший ответ можно опровергнуть или уточнить. В нём есть человек, момент, действие и результат. Слабый ответ звучит солидно, но подходит почти любому продукту. Используйте таблицу как быструю проверку.
| Вопрос | Слабый ответ | Рабочий ответ | Что меняется |
|---|---|---|---|
| Кто и зачем | Все клиенты хотят удобство | Постоянный клиент повторяет знакомую услугу без звонка | Контекст, данные, первый сценарий |
| Когда снова | Будут заходить регулярно | Новая потребность возникает по циклу услуги | Канал, вход, уведомления |
| Что обязательно | Каталог, чат, профиль, оплата | Свободный слот, выбор, подтверждение, история | Границы версии и интеграции |
| Зачем вернётся | Уведомления и программа лояльности | Появилась новая задача; повторное действие завершено | Сигнал, период, метрика |
Когда приложение не нужно, а четырёх ответов недостаточно
Четыре ответа могут привести к решению не строить приложение. Это нормальный результат. Если задача редкая, начинается из поиска или сообщения и не требует работы без сети, функций устройства или постоянного личного контекста, сайт, которым удобно пользоваться с телефона, может дать человеку более короткий путь.
Мобильный формат не должен быть пустой оболочкой. В правилах App Store от 8 июня 2026 года Apple отдельно требует достаточной полезности сверх переупакованного сайта; магазин Google для Android также запрещает продукты с крайне ограниченной функциональностью. Эти правила не доказывают спрос и не назначают технологию, но добавляют ещё одну причину не начинать с иконки ради присутствия в магазине.
Ответов также недостаточно, если за ними скрыты большие неизвестные: медицинские или финансовые правила, сложные роли и права доступа, миграция данных, нестабильная интеграция, работа без сети, платежи, оборудование, несколько стран или критичные требования к безопасности. Тогда бриф открывает исследование задачи, прототип или технический эксперимент. Полный процесс от идеи до требований и оценки начинается именно с разборки этих неизвестных.
Как обязательный путь выглядит в реальном проекте 13FOX
В проекте приложения для студии маникюра мы собрали не набор несвязанных экранов, а последовательность: клиент видит услуги и доступный контекст, выбирает мастера, дату и время, получает подтверждение, затем может проверить предстоящие и прошедшие записи. История сохраняет основу для следующего визита.
Для другого салона отдельно проверьте правила слотов, предоплаты, отмены, бонусы, роли администраторов и источник расписания. Сначала зафиксируйте задачу и зависимости, затем переносите экранную логику.
Реальный проект 13FOX
От выбора услуги до следующего визита
Четыре экрана показывают один путь: выбор, запись, подтверждение и сохранённый контекст.
Одностраничный бриф на мобильное приложение
Заполните блоки коротко. Факты отделите от предположений. Если ответа нет, так и напишите: «неизвестно, нужно проверить». Это полезнее уверенной догадки, которая незаметно попадёт в смету.
- Кто пользователь и какая у него задача? Приоритетный сегмент, ситуация, текущий способ, проблема и желаемый результат.
- Когда задача возникает снова? Внешнее событие, примерная частота, место и условия использования.
- Какой путь обязателен? Вход, главное действие, подтверждение, результат, критичные ошибки и запасной путь.
- Почему человек вернётся и как вы увидите пользу? Новый повод, полезное действие, событие измерения, период и решение по результату.
Зависимости до оценки
- Данные: откуда берутся каталог, статусы, цены, слоты, документы и история.
- Интеграции: CRM, учёт, платежи, вход, аналитика, доставка, оборудование.
- Роли: кто пользуется, платит, подтверждает, исправляет ошибку и принимает решение.
- Ограничения: право, безопасность, доступность, устройства, магазины, языки и страны.
- Неизвестные: какие предположения нужно проверить до состава работ и оценки.
«Хорошая команда сама разберётся»
Да, сильная команда не ждёт от вас готовой архитектуры. Она уточняет роли, проверяет сценарий, предлагает более простой формат и называет риск. Но есть решения, которые подрядчик не может принять вместо бизнеса: кого считать приоритетным, какую проблему решать первой, какие правила нельзя менять и какой результат оправдывает следующий этап.
Вы приносите четыре ответа. Мы проверяем, каких данных не хватает, какие интеграции меняют объём и действительно ли задаче нужно приложение. Затем фиксируем неизвестное, чтобы оно не превратилось в молчаливое допущение и строку счёта.
После первичного брифа возможны разные маршруты: короткое исследование пользователей, схема процесса, прототип, проверка интеграции, MVP или предварительная оценка уже понятного объёма. Если формат приложения подтверждён и нужно понять полный цикл, переходите к материалу о разработке приложения под ключ.
Оставьте контакт: обсудим четыре ответа
Сохраните заполненный бриф и оставьте имя и телефон. На первом разговоре вы передадите четыре ответа, а мы проверим логику сценария, возможный формат, зависимости и неизвестные до оценки. После разговора вы получите одностраничный продуктовый бриф и список вопросов для следующего шага: исследования задачи, прототипа, MVP или предварительной декомпозиции.
Источники и дата проверки
Правила магазинов обновляются. Перед отправкой приложения проверьте действующую редакцию. Руководства ниже помогут подготовить интервью и выбрать меру успеха.
- GOV.UK: как работает этап исследования задачи, обновлено 21 июня 2021 года.
- GOV.UK: как изучать пользователей и их потребности, обновлено 23 марта 2017 года.
- GOV.UK: как задать границы одной пользовательской задачи, обновлено 1 мая 2019 года.
- Исследование Google: связь цели, признака успеха и метрики, CHI 2010.
- Справка магазина Google: определения статистики использования, проверено 10 августа 2026 года.
- Правила проверки приложений Apple, обновлено 8 июня 2026 года.
- Требования магазина Google к функциональности и содержанию, проверено 10 августа 2026 года.
Частые вопросы
Нужно ли писать готовое техническое задание до обращения в студию?
Нет. Техническое задание появляется после исследования сценариев, данных, интеграций, ограничений и критериев готовности. На входе полезнее факты о задаче и явные предположения, чем самостоятельно угаданные технологии и число экранов.
Как проверить идею мобильного приложения до разработки?
Сначала проверьте, существует ли проблема у выбранных пользователей и как они решают её сейчас. Затем выберите самый дешёвый способ проверить главное рискованное предположение: интервью, схему процесса, прототип или узкий технический эксперимент. Полноценная разработка нужна не для каждой проверки.
Какие вопросы задать разработчику после заполнения брифа?
Спросите, какие предположения команда считает критичными, что нужно проверить до оценки, какой путь войдёт в первую версию, какие данные и интеграции влияют на объём, что исключено из предложения и при каких новых фактах оценка изменится.
Можно ли получить точную цену приложения по четырём ответам?
Нет. Четыре ответа помогают выровнять вводные, понять формат и обнаружить неизвестные. Обоснованная оценка появляется после проработки сценариев, данных, интеграций, ограничений, границ первой версии и критериев приёмки.