O design começa no momento em que seu produto precisa ficar claro
O design UI/UX Web3 conecta o que seu produto faz com o que uma pessoa precisa entender em seguida. Começamos pela tarefa do usuário, depois moldamos uma jornada e uma interface em torno dela.
Imagine um líder de programa de embaixadores abrindo um painel do projeto depois de um mês tranquilo de postagens. Ele quer ver o que precisa de atenção, mas o próximo passo não é óbvio. Nós olharíamos para a tarefa que ele veio realizar, mapearíamos onde começa a confusão e tornaríamos as escolhas importantes mais fáceis de seguir.
Essa mesma abordagem funciona para uma dApp, wallet, exchange ou fluxo de landing. Revisamos o produto, seus usuários pretendidos e quaisquer materiais existentes. A pesquisa e a revisão de concorrentes nos ajudam a perceber contextos ausentes e etapas estranhas antes que telas detalhadas sejam desenhadas.
O ponto de partida depende do que sua equipe já sabe. Se a jornação estiver clara, podemos focar no design de interface e em um protótipo. Se não estiver, podemos primeiro esclarecer o fluxo. Quando o trabalho também precisar de suporte visual, podemos conectá-lo com design e visuais Web3.
Como uma interface Web3 deve guiar alguém durante uma ação na wallet?
Um fluxo de wallet útil mostra o que alguém pode fazer, o que acontece em seguida e como a interface responde. Mapeamos cada ação importante antes de polir suas telas.
Digamos que um novo usuário chegue a um prompt de conexão de wallet e não tenha certeza de por que ele é necessário. Examinaríamos quais informações pertencem antes do prompt e o que o usuário vê após conectar. Também mapearíamos onde o fluxo deve explicar uma transação ou erro. O objetivo é tornar a próxima decisão compreensível, não esconder a etapa técnica.
Frequentemente mapeamos 3 momentos em uma jornada de transação: conexão, revisão e resposta. Os wireframes permitem que sua equipe verifique a ordem e a linguagem antes que o design visual comece. O protótipo então torna caminhos selecionados mais fáceis de discutir como uma experiência conectada.
Para uma primeira revisão útil, traga a tarefa principal, os requisitos atuais, quaisquer telas existentes e estados conhecidos de wallet ou transação. Se a redação do produto precisar de atenção própria, o copywriting Web3 pode ajudar a manter a linguagem da interface consistente. Um responsável pelo produto deve confirmar quaisquer regras que a equipe de design não possa inferir.
Os arquivos de trabalho que sua equipe de produto pode revisar
Você recebe um conjunto conectado de materiais de design para revisar a jornada do usuário e preparar a implementação. Acordamos quais tarefas e telas focar antes que o design detalhado comece.
Um conjunto típico de trabalho pode incluir:
- Notas de pesquisa e revisão de concorrentes.
- Fluxos de usuário e wireframes para tarefas prioritárias.
- Um sistema de design visual e biblioteca de componentes.
- Um protótipo clicável para caminhos selecionados.
- Testes de usabilidade e entrega para desenvolvedores no Figma.
O fluxo e os wireframes mostram como uma tarefa é estruturada. O sistema de design e os componentes ajudam sua equipe a revisar a linguagem visual entre as telas. Um protótipo clicável torna a jornada selecionada mais fácil de percorrer. Os testes de usabilidade dão à equipe a chance de observar onde as pessoas precisam de mais contexto.
A entrega final organiza o trabalho Figma acordado para os desenvolvedores. Se a identidade mais ampla do produto ainda estiver se formando, alinhe as decisões de interface com branding para projetos cripto antes de definir a direção visual. Sua equipe pode então revisar a linguagem e o design do produto juntos.
Da primeira revisão à entrega em Figma
O trabalho avança do contexto do produto para fluxos, decisões de interface, um protótipo e entrega para desenvolvedores. Definimos pontos de revisão para que sua equipe possa responder antes que a próxima camada seja construída.
Na Brand Community, usamos uma checklist de kickoff para reunir o público, a tarefa prioritária, os arquivos de design existentes, os requisitos do produto e as perguntas conhecidas. Então acordamos quem pode responder perguntas sobre o produto e quem revisará o trabalho. Dois pontos de revisão podem ajudar a manter o feedback claro: um para o fluxo e os wireframes, e outro para a direção visual e o protótipo selecionado.
| Etapa | O que sua equipe revisa |
|---|---|
| Revisão do produto | Usuário, tarefa prioritária e requisitos existentes |
| Fluxo e wireframes | Ordem da tarefa, estrutura da tela e informações principais |
| Interface e protótipo | Direção visual e caminhos de usuário selecionados |
| Entrega Figma | Arquivos de design organizados para implementação |
O cronograma segue o número e a complexidade das jornadas, o material já disponível e a rapidez com que as decisões retornam. O trabalho também pode se conectar com criação de conteúdo cripto ou com a equipe mais ampla de mídias sociais e conteúdo por meio de linguagem de produto compartilhada.
Traga as decisões de produto que moldam a interface
A revisão de design é mais útil quando sua equipe pode explicar o usuário, a tarefa e as regras do produto por trás dela. Podemos tornar perguntas não respondidas visíveis em um fluxo, mas não devemos preenchê-las com suposições.
Um protótipo Figma pode mostrar estados pretendidos de wallet e transação, mas não pode determinar o que uma wallet conectada exibe. Também não pode determinar se uma transação de rede é concluída. Esses comportamentos e as regras do produto por trás deles permanecem com a plataforma e sua equipe de produto.
Para iniciar a primeira revisão, prepare estas 3 coisas:
- Uma visão geral curta do produto e as pessoas que você espera que o usem.
- A jornada que mais importa, além de quaisquer arquivos Figma ou requisitos atuais.
- Uma pessoa que possa confirmar decisões de produto e reunir feedback.
Você não precisa de um briefing polido. Envie-nos o que você tem, incluindo as telas ou perguntas que parecem não resolvidas. Revisaremos o material com você, acordaremos a primeira jornada e os pontos de revisão, e mapearemos uma rota clara em direção a um protótipo e entrega Figma.
Como funciona
- Compartilhe a visão do produtoEnvie a visão geral do produto, os usuários pretendidos, a tarefa prioritária e quaisquer arquivos de design ou requisitos existentes.
- Acorde o que revisarConfirmamos em qual jornada focar, quem pode responder perguntas sobre o produto e quando sua equipe revisará as decisões.
- Mapeie a tarefa do usuárioPreparamos o fluxo e os wireframes acordados para que sua equipe possa verificar a estrutura antes do design de interface.
- Projete e teste caminhos selecionadosCriamos o sistema visual e as telas, construímos um protótipo clicável e realizamos testes de usabilidade conforme acordado.
- Prepare a entrega FigmaOrganizamos os arquivos de design aprovados para os desenvolvedores e orientamos sua equipe sobre as escolhas de interface relevantes.
Perguntas frequentes
O que posso compartilhar se nosso briefing de design ainda estiver preliminar?
Comece com uma descrição curta do produto, o usuário pretendido e a tarefa que você quer tornar mais fácil. Arquivos Figma existentes, requisitos ou uma lista de perguntas em aberto também são úteis. Por exemplo, mesmo uma tela atual pode nos dar um ponto útil para iniciar a primeira revisão.
Vocês podem focar em apenas uma jornada de dApp ou wallet?
Sim. Podemos concordar em focar em uma jornada prioritária, como conexão de wallet ou revisão de transação. Primeiro verificaremos o que a jornada precisa cobrir, depois acordaremos quais fluxos, telas e trabalho de protótipo fazem parte do plano.
Nossos desenvolvedores conseguirão usar a entrega Figma?
O serviço inclui entrega para desenvolvedores no Figma para o trabalho de design acordado. Organizamos os arquivos aprovados e orientamos sua equipe sobre as decisões de interface relevantes. Compartilhe qualquer configuração de design existente ou necessidades de implementação no início, para que possamos considerá-las durante o planejamento.
Vocês podem melhorar uma interface de produto existente sem alterar seus recursos?
Sim. Podemos revisar as telas atuais e focar na jornada, na linguagem ou nos estados de interface que precisam de atenção. Por exemplo, se as regras do produto estão definidas, mas os usuários podem não entender uma etapa de transação, podemos explicar essa etapa com mais clareza. Não definiremos novos comportamentos do produto.
Como vocês decidem o cronograma para um projeto de design Web3?
Acordamos o cronograma após revisar as jornadas, os materiais disponíveis e as necessidades de revisão. Caminhos mais complexos ou decisões de produto não resolvidas podem exigir mais discussão. Ter uma pessoa que toma decisões de produto disponível pode ajudar o feedback a permanecer claro em cada ponto de verificação.
Um protótipo pode prometer o que acontece em uma transação de wallet ao vivo?
Não. Um protótipo mostra os estados de interface que a equipe projetou. Ele não controla exibições de wallet, condições de rede, resultados de transação ou a decisão de uma pessoa de continuar. Podemos testar se o protótipo acordado comunica o caminho com clareza e entregar o design para implementação.
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…