Comece pela pessoa que usa o dApp
Um dApp deve tornar sua tarefa principal fácil de entender antes que uma ação de wallet ou contrato apareça. Começamos mapeando o que um membro vem fazer, depois conectamos cada etapa às telas e aos dados que o aplicativo precisa.
Essa primeira conversa pode ser simples. Conte-nos para quem é o produto, o que as pessoas devem poder fazer e o que já existe. Um esboço ou algumas anotações são suficientes para começar. Nós os transformamos em uma visão compartilhada do primeiro lançamento, incluindo as partes que exigem decisões técnicas.
Por exemplo, um projeto NFT pode querer que os membros explorem uma coleção e depois realizem uma ação on-chain. Podemos separar as partes que precisam de uma wallet conectada daquelas que devem permanecer abertas a todos. Se o produto também precisar de novos contratos, podemos coordenar o plano do aplicativo com o desenvolvimento de smart contracts. Para o panorama técnico mais amplo, o desenvolvimento Web3 cobre o trabalho de produto conectado além de um dApp.
Mapeie a construção em três passos claros
Um plano útil de dApp leva a ideia por tarefas do usuário, integrações e uma decisão de primeiro lançamento. Esses três passos mantêm as escolhas importantes visíveis antes do desenvolvimento começar.
- Descreva a jornada. Listamos as ações que um membro deve realizar, desde abrir o aplicativo até concluir a tarefa principal. Observamos onde a interface precisa explicar uma escolha ou mostrar uma resposta.
- Reúna as conexões. Revisamos os contratos, wallets, redes e serviços existentes com os quais o produto deve funcionar. Também anotamos as informações que cada tela precisa mostrar.
- Escolha o primeiro lançamento. Concordamos quais telas e integrações pertencem à construção inicial. Outras ideias podem ficar em uma lista de acompanhamento, em vez de se juntarem silenciosamente ao trabalho no meio do caminho.
Imagine que sua equipe já tem um esboço do produto e um contrato, mas as visualizações de dados ainda são incertas. Podemos marcar as partes confirmadas, listar as perguntas abertas e concordar o que deve ser respondido antes da implementação. Se o produto precisar de um site público separado, o desenvolvimento de sites e landings Web3 pode cobrir essa superfície sem misturá-la ao plano do aplicativo.
Onde wallets e dados on-chain devem se encontrar?
O fluxo da wallet e a visualização de dados devem apoiar a mesma tarefa do usuário. Planejamos juntos, para que um membro entenda o que o aplicativo mostra e por que uma conexão é necessária.
Etapas da wallet
Mapeamos os momentos que precisam de um endereço de wallet ou de uma ação aprovada pelo usuário. A interface deve considerar 3 estados básicos: desconectado, conectado e retornando ao aplicativo. Também acordamos como o aplicativo explica o próximo passo, em vez de deixar as pessoas interpretarem um prompt de wallet sem contexto.
Dados que as pessoas podem usar
A indexação vale a pena considerar quando os membros precisam encontrar ou organizar registros on-chain. Começamos com as perguntas que a tela deve responder, depois identificamos a fonte e a apresentação para essa informação. Uma visão de conta única pode exigir um trabalho de dados diferente de um histórico de atividad pesquisável.
Digamos que um colecionador retorna para verificar uma ação anterir. Podemos rastrear que informação a tela precisa e decidir se uma fonte existente é suficiente. Traga exemplos dos registros ou visões que você quer mostar. Quando a funcionalidade de wallet é um produto mais amplo por si só, o desenvolvimento de wallet cripto é uma opção separada.
Torne os momentos silenciosos parte do design
Imagine um artista NFT com um pequeno público, bem quando a única pessoa que responde sai de férias. Um novo membro chega com uma pergunta sobre a coleção e uma ação no dApp. Faríamos o próximo passo visível na interface, para que o produto não dependa de alguém estar online para explicá-lo.
Esse tipo de momento pertence à revisão do produto, não apenas a um plano de suporte. Olhamos para o que um membro de primeira viagem vê, o que acontece quando a informação está faltando e como o aplicativo responde após uma ação. Então acordamos quais estados precisam ser desenhados e testados.
Antes do trabalho de construção, verifcamos:
- A tarefa principal que um novo membro deve concluir.
- O que pode ser explorado sem conectar uma wallet.
- Qual mensagem aparece quando os dados ainda estão carregando ou indisponíveis.
- O que o membro vê após uma ação ser submetida.
Esta revisão mantém a interface fundamentada no uso real. Também ajuda você a decidir o que pertence ao primeiro lançamento e o que pode esperar até que você tenha mais feedback.
Mantenha o trabalho visível até a entrega
Uma boa entrega mostra o que foi construído, como os fluxos de usuário acordados foram verificados e quais dependências permanecem. Usamos dois pontos de revisão, um antes da implementação e outro perto da entrega. Antes da implementação, confirmamos as funcionalidades acordadas. Perto da entrega, percorremos o trabalho concluído com você.
Durante a construção, verificamos os estados do frontend planejados e as integrações em relação à jornada do usuário. Mantemos as perguntas abertas visíveis e discutimos novas solicitações antes que elas alterem o trabalho acordado. Na entrega, percorremos o aplicativo, compartilhamos notas de implementação e identificamos quaisquer tarefas de acompanhamento que sua equipe queira considerar.
Os provedores de wallet, redes, contratos e serviços de dados permanecem fora do nosso controle. Sua disponibilidade, manuseio de transações, atualizações e compatibilidade podem mudar, então verificamos o comportamento acordado do aplicativo sem prometer como esses sistemas externos operarão.
Para começar, envie suas notas do produto, rascunho da interface, detalhes do contrato disponível e exemplos dos dados que os membros precisam. Brand Community os revisará com você, esclarecerá as perguntas abertas e moldará um plano de primeiro lançamento sobre o qual você possa tomar uma decisão clara.
Como funciona
- Compartilhe a visão do produtoConte-nos para quem o dApp serve, o que os membros precisam fazer e o que você já tem.
- Trace as conexõesRevisamos as wallets, contratos, redes e necessidades de dados que suportam essas tarefas.
- Acorde o primeiro lançamentoDecidimos quais funcionalidades pertencem à construção e o que a entrega deve cobrir.
- Construa e verifique os fluxosImplementamos o trabalho acordado e o revisamos em relação à jornada do membro.
- Percorra a entregaMostramos o trabalho concluído, compartilhamos notas e identificamos dependências restantes.
Perguntas frequentes
O que devo levar para nossa primeira conversa sobre dApp?
Traga uma breve descrição do produto, as principais tarefas dos membros e qualquer coisa já construída. Esboços da interface, detalhes do contrato e exemplos dos dados que você quer mostrar também são úteis. Até uma lista simples de 3 ações do usuário nos dá um ponto de partida prático.
Vocês construirão a interface do dApp em torno dos nossos contratos existentes?
Sim. Podemos planejar o frontend e o fluxo da wallet em torno de contratos existentes. Compartilhe as informações do contrato disponível e explique o que os membros precisam fazer. Revisaremos os pontos de conexão, anotaremos o que ainda não está claro e acordaremos quais funcionalidades pertencem ao primeiro lançamento.
Como vocês decidem se um dApp precisa de indexação?
Começamos com as perguntas que seus membros precisam que o aplicativo responda. Se eles precisam encontrar, organizar ou visualizar registros em várias atividades, a indexação pode ser útil. Compartilhe alguns exemplos dos registros ou telas que você tem em mente, e mapearemos a necessidade de dados para o produto.
O aplicativo pode mostrar informações úteis antes de alguém conectar?
Sim, quando o fluxo do produto permitir. Identificamos quais informações podem ser exploradas sem uma wallet e quais ações precisam de uma conexão. Por exemplo, uma visão pública de coleção pode ser planejada separadamente de uma ação de membro que precisa de aprovação da wallet.
Quanto tempo leva uma construção de dApp geralmente?
Definimos o cronograma após revisar as funcionalidades, os materiais existentes e as integrações. Um fluxo de frontend focado e um aplicativo com várias conexões de contrato ou dados precisam de planos diferentes. Acordamos marcos em relação ao trabalho, para que você possa ver o que vem a seguir em cada revisão.
Vocês podem garantir que toda conexão de wallet e dados continuará funcionando?
Não. Provedores de wallet, redes, contratos e serviços de dados podem alterar sua disponibilidade, manuseio ou compatibilidade. Podemos construir e testar o comportamento acordado do aplicativo para integrações selecionadas e depois documentar as dependências. Por exemplo, a entrega pode mostar qual conexão o aplicativo espera e o que sua equipe deve monitar.
Conte sobre seu projeto
Responda quatro perguntas rápidas e um gerente enviará um plano, prazos e uma faixa de preço em até uma hora. Tudo fica confidencial.
Carregando formulário…