01

Почему именно на телефоне?

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

02

Какое действие будет повторяться?

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

03

Что должно работать при слабой связи?

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

04

Какие разрешения действительно оправданы?

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

05

Что происходит за пределами приложения?

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

06

Кто будет обслуживать продукт?

Кто-то должен проверять пользователей, исправлять контент, разбираться в сбоях и отвечать на обращения в поддержку. До запуска определите, какой будет админка и какие данные нужны операторам.

07

Кому будет принадлежать релиз?

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

08

Пример: осмотр оборудования на объекте

Допустим, техник фотографирует оборудование в подвале, где связь нестабильна. Полезная первая версия сохраняет осмотр на устройстве, помечает его как «ожидает синхронизации» и повторяет отправку, когда связь восстанавливается. Она должна отличать сохранённый черновик от загруженного осмотра. Запрос доступа к камере уместен при первой попытке сделать фото — с возможностью продолжить или повторить, если доступ не дали. Это иллюстративное упражнение по проектированию, а не заявление о выпущенном клиентском проекте.

09

Превратите вопросы в проверку на устройстве

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