Разработка мобильных приложений Web3, ориентированная на ваших пользователей

Полезное приложение начинается с одной реальной задачи пользователя

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

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

Работа может подойти как для нового продукта, так и для мобильной части более широкого Web3-сервиса. Мы связываем план приложения с существующим продуктом, его технической настройкой и людьми, которые будут его поддерживать. Если также требуется браузерный опыт, наша разработка dApp может помочь согласовать мобильный и веб-пути. Для более масштабной разработки продукта смотрите Web3-разработку.

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

Какой мобильный опыт подходит вашему продукту?

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

Когда имеют смысл нативные приложения

Нативная разработка может подойти, когда опыт на iOS и Android требует разного поведения или дизайна, специфичного для платформы. Мы фиксируем эти различия с вашей командой, затем отмечаем, что должна поддерживать каждая версия. Это дает вам более четкое представление о работе до начала разработки.

Когда подходит общая разработка

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

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

Четыре решения, которые мы принимаем до кода

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

1. Назовите основной пользовательский сценарий. Мы определяем первую задачу, которую должно поддерживать приложение. Затем мы отображаем экраны, необходимые человеку для ее выполнения.
2. Отобразите подключения. Мы перечисляем необходимую работу с кошельком, блокчейном, бэкендом и API. Мы также отмечаем, какие существующие сервисы или технические материалы может предоставить команда.
3. Выберите функции первого релиза. Мы отмечаем, что должно быть при запуске, а что может быть добавлено позже. Это помогает сохранить фокус первой сборки, не упуская из виду более широкий продукт.
4. Согласуйте проверки. Мы определяем, как команда будет проверять каждый основной сценарий. Проверки охватывают подтверждения, состояния ожидания и то, что видит человек, когда действие не завершается.

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

От первого экрана до готовой к релизу сборки

Сборка превращает согласованные пользовательские сценарии в работающее приложение. Затем она проверяет эти сценарии перед подготовкой к публикации. Вот как основные части сочетаются:

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

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

Держите план релиза в рамках правил магазина

Хороший план релиза делает обязанности и открытые вопросы видимыми до финальной сборки. Мы анализируем политики крипто-приложений до разработки. Затем мы связываем этот ранний анализ с функциями, дизайном и работой по публикации, которые нужны вашей команде. Это дает всем возможность задать вопросы, пока еще есть время обсудить сценарий продукта.

Мы также согласовываем, кто владеет аккаунтами магазинов приложений и принимает решения по публикации. Мы уточняем, кто предоставляет детали продукта и кто будет заниматься последующими вопросами. В нашем чек-листе для старта Brand Community фиксирует целевые платформы, приоритеты запуска, существующие технические материалы и людей, которые могут утвердить работу. В ходе проекта мы проверяем интерфейс и основные сценарии до того, как реализация продвинется вперед. Затем мы сверяем сборку с тем же согласованным поведением.

Apple и Google устанавливают политики для крипто-приложений и принимают решения о проверке; ни один из результатов не находится под нашим контролем. Мы готовим согласованную работу по публикации, но не можем обещать одобрение.

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

Как мы работаем

1. Поделитесь заметками о продуктеОтправьте цель, предполагаемых пользователей, планы по платформам и любые существующие дизайны или технические материалы. Укажите действия, которые важны при запуске.
2. Спланируйте приложение и его подключенияМы описываем основные сценарии, необходимые связи с кошельком и блокчейном, работу с бэкендом или API, а также открытые вопросы.
3. Проверьте интерфейсМы вместе проходим ключевые экраны и состояния взаимодействия до начала разработки.
4. Создайте и проверьте основные сценарииМы разрабатываем согласованное приложение и тестируем его основные сценарии и интеграции на соответствие требованиям.
5. Подготовьте передачу к релизуМы организуем работу по публикации в плане, уточняем, кто предоставляет каждый элемент, и согласовываем любую пост-релизную поддержку.