План разработки криптокошелька, ориентированный на ваших пользователей

Начните с кошелька, который нужен вашим участникам

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

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

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

Примите важные решения до того, как экраны размножатся

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

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

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

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

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

Сопоставьте действие, а не только экран

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

Выберите поверхность, которая подходит моменту

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

Представьте, что участник проверяет актив на телефоне, затем открывает Telegram Mini App, чтобы продолжить. Мы бы сопоставили, где меняется опыт и какая информация должна оставаться понятной. Для размещения в Telegram см. разработку Telegram-ботов и мини-приложений.

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

Дайте каждому решению по кошельку место в сборке

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

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

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

Держите готовность кошелька на основе того, что ваша команда может проверить

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

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

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

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

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

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