Разработка dApp, которая понятна с первого касания

Начните с человека, использующего dApp

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

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

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

Спланируйте сборку в три понятных этапа

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

1. Опишите путь. Мы перечисляем действия, которые должен выполнить пользователь: от открытия приложения до завершения основной задачи. Мы отмечаем, где интерфейсу нужно объяснить выбор или показать ответ.
2. Соберите подключения. Мы проверяем контракты, кошельки, сети и существующие сервисы, с которыми продукт должен работать. Также отмечаем информацию, которую должен показывать каждый экран.
3. Выберите первый релиз. Мы согласовываем, какие экраны и интеграции войдут в начальную сборку. Другие идеи могут остаться в списке на будущее, а не незаметно присоединиться к работе в середине.

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

Где должны встречаться кошельки и ончейн-данные?

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

Шаги кошелька

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

Данные, которые можно использовать

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

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

Сделайте тихие моменты частью дизайна

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

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

Перед началом сборки мы проверяем:

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

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

Держите работу видимой до сдачи

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

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

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

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

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

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