Peça a cinco pessoas de uma equipe de produto para descrever como um novo usuário vai do cadastro ao primeiro resultado de verdade e você vai ouvir cinco respostas diferentes, todas mais curtas do que a realidade. O designer lembra das telas que desenhou. O engenheiro lembra dos endpoints. O suporte lembra dos três lugares onde as pessoas travam, e nenhum deles aparece na versão dos outros. Ninguém está mentindo; cada um segura um fragmento. Um fluxo de usuário é o que você desenha quando decide parar de discutir a partir de fragmentos.
Um fluxo de usuário é o diagrama de uma tarefa, do momento em que o usuário entra até o momento em que termina: cada tela que ele vê, cada ação que ele realiza e (a parte que o torna útil) cada decisão que o produto toma por ele sobre para onde ele vai em seguida. Ele é propositalmente sem glamour. Não há cores para discutir nem layout para criticar. O que ele produz é um acordo sobre o que realmente acontece, que é a condição para conseguir mudar isso.
Este guia cobre o assunto inteiro: o que é um fluxo de usuário (e o que não é), o pequeno conjunto de símbolos usado em um diagrama de fluxo de usuário, como os fluxos se diferenciam de task flows, wireflows, funis e mapas da jornada do usuário, um método em sete etapas para criar um a partir de dados reais do produto, seis exemplos de fluxo de usuário comentados de produtos SaaS, as boas práticas que mantêm um fluxo fiel à realidade e o que fazer depois que o diagrama mostrou onde os usuários vão embora.
Principais conclusões
- Um fluxo de usuário é uma tarefa desenhada de ponta a ponta: as telas, ações e decisões em ordem entre um ponto de entrada e um estado concluído. Não é um sitemap, não é um wireframe.
- As ramificações são o que importa. Um fluxo sem losangos de decisão é um task flow: o caminho ideal. Usuários reais quase nunca estão no caminho ideal.
- Cinco formas bastam: pílula para início e fim, retângulo para tela ou ação, losango para decisão, paralelogramo para entrada ou saída de dados e seta para a direção, com cada ramificação rotulada.
- Fluxos e mapas da jornada diferem pela altitude: o mapa da jornada diz qual etapa dói entre os canais; o fluxo de usuário diz qual clique causa a dor dentro do produto.
- Desenhe a partir do produto lançado, não da memória, e depois associe um número real de abandono a cada etapa; um fluxo sem medição é uma opinião em forma de diagrama.
- O diagrama é o diagnóstico, não a cura: quando você sabe qual etapa vaza, a correção geralmente é orientação naquela etapa (um tooltip, um checklist, um tour), e não o redesenho do caminho inteiro.
O que é um fluxo de usuário? (Significado e definição)
Um fluxo de usuário é a sequência ordenada de telas, ações e decisões pela qual uma pessoa passa para concluir uma tarefa específica em um produto. Ele começa em um ponto de entrada (uma página de marketing, um e-mail de convite, uma notificação, um item de menu) e termina em um estado que você consegue verificar de fato: o projeto está publicado, o colega foi convidado, os dados foram importados. No meio fica tudo o que o produto pede ao usuário e tudo o que o produto decide sobre o usuário.
Fluxo de usuário: a definição. Um fluxo de usuário é o diagrama de uma única tarefa em um produto, desenhado do ponto de entrada até o estado concluído, que mostra cada tela ou ação como um nó e cada caminho possível entre eles como uma seta rotulada, inclusive os caminhos que não levam a lugar nenhum. A função dele não é descrever a aparência do produto, mas tornar visível onde o caminho se bifurca, entra em loop, emperra ou termina silenciosamente.
Duas palavras dessa definição carregam o peso. Única: um fluxo de usuário cobre uma tarefa, não o produto inteiro; "convidar um colega", não "colaboração". No momento em que um fluxo tenta cobrir tudo, ele vira um sitemap, e nenhum sitemap jamais explicou um abandono. E possível: um fluxo que só desenha o caminho que você esperava que os usuários seguissem é uma especificação, não um mapa. O valor está nas ramificações: a verificação de permissão que manda metade dos seus convidados para uma tela que ninguém desenhou, o workspace vazio que recebe um usuário que não importou nada.
Os fluxos de usuário às vezes são chamados de fluxogramas de usuário ou diagramas de fluxo, e a notação é emprestada abertamente dos fluxogramas. Esse empréstimo é uma vantagem: um product manager, um designer, um engenheiro e um líder de suporte conseguem ler um losango sem treinamento, e é exatamente por isso que o formato sobrevive em uma disciplina que reinventa seus artefatos a cada poucos anos.
Símbolos do diagrama de fluxo de usuário: a notação completa
O vocabulário é pequeno de propósito. Cinco formas cobrem quase todos os fluxos que valem ser desenhados, e cada símbolo extra que você inventa é um símbolo que vai precisar explicar na reunião:
Três convenções transformam essas formas em algo legível. Desenhe da esquerda para a direita, porque o tempo se lê da esquerda para a direita e um fluxo que ziguezagueia é um fluxo que ninguém confere. Rotule toda seta que sai de um losango ("sim / não", "tem dados / vazio", "admin / membro"), já que uma ramificação sem rótulo é uma decisão que você ainda não tomou de verdade. E dê um nó a cada beco sem saída: se um caminho termina com o usuário abandonado, desenhe o abandono. Apagá-lo do diagrama não o apaga do produto.
Cinco formas e duas ramificações rotuladas. A ramificação que importa costuma ser a que ninguém desenhou: aqui, o convidado que chega a um workspace sem nenhuma licença sobrando.
Fluxo de usuário vs. task flow vs. wireflow vs. mapa da jornada vs. funil
Esses cinco artefatos são usados como sinônimos nas reuniões e depois geram cinco conversas diferentes. Eles não são formatos concorrentes; respondem a perguntas diferentes, e o jeito mais rápido de escolher um é saber em qual pergunta você realmente está travado:
| Artefato | O que mostra | Pergunta que responde | Ramificações? |
|---|---|---|---|
| Fluxo de usuário | Telas, ações e decisões de uma tarefa, com todos os caminhos incluídos | Onde o caminho se bifurca, emperra ou chega a um beco sem saída? | Sim, esse é o objetivo |
| Task flow | O único caminho ideal por uma tarefa | Qual é a sequência prevista? | Não |
| Wireflow | Um fluxo de usuário desenhado com wireframes como nós | Como é cada etapa, em ordem? | Geralmente poucas |
| Mapa da jornada do usuário | Uma persona por etapas e canais, com emoções e dores | Qual etapa da relação dói, e por quê? | Não estruturalmente |
| Funil / relatório de conversão | Contagem de usuários que passam por um pequeno número de etapas ordenadas | Quantas pessoas chegam até o fim? | Não, só dados agregados |
Fluxo de usuário vs. mapa da jornada do usuário
Essa é a dupla que as pessoas mais confundem, e a diferença é a altitude. Um mapa da jornada do usuário vive ao redor do produto: ele acompanha uma persona por etapas e canais (o anúncio, a demo, o primeiro login, o chamado de suporte, a renovação) e registra o que ela pensava e sentia em cada um. Um fluxo de usuário vive dentro do produto e é puramente mecânico: esta tela, aquele clique, esta bifurcação, em uma sessão. O mapa da jornada diz que "a primeira semana parece esmagadora"; o fluxo de usuário diz que 41% dos usuários chegam à tela de projeto vazio e nunca mais voltam. A maioria das equipes precisa dos dois, nessa ordem: monte o mapa da jornada para encontrar a etapa dolorosa e depois desenhe o fluxo da tarefa dentro dela para encontrar o passo que dá para corrigir.
Fluxo de usuário vs. funil
Um funil é um fluxo de usuário sem todas as partes interessantes. Ele entrega quatro barras e uma taxa de conversão; o fluxo entrega o motivo. Quando o seu analytics de produto mostra uma queda de 60% entre "conta criada" e "primeiro projeto", o funil cumpriu o seu papel e não consegue fazer mais nada; as seis telas, as duas verificações de permissão e o erro de validação silencioso escondidos dentro daquela única barra são o que o fluxo existe para expor. Use funis para descobrir qual fluxo desenhar e depois o fluxo para descobrir o que corrigir.
Por que os fluxos de usuário importam para o onboarding e a ativação
Fluxos de usuário são um artefato de design, mas o maior retorno deles está no onboarding de usuários, onde a distância entre o caminho previsto e o caminho real é maior e mais cara:
-
Eles transformam um número de abandono em um local
"A ativação é de 22%" não gera ação; "62% dos usuários que chegam à tela de importação saem sem escolher um arquivo" gera. Um fluxo obriga a métrica agregada a descer até um nó específico, que é a única altitude em que alguém consegue de fato lançar uma correção.
-
Eles expõem os estados que ninguém desenhou
Todo produto tem telas que só existem por meio de uma ramificação: o workspace sem nenhum dado, o trial que expirou no meio de uma tarefa, o membro somente leitura que clicou em um link de admin. É ali que os novos usuários caem com mais frequência e onde a atenção do design chega por último, e é por isso que os estados vazios merecem um nó próprio em todo fluxo.
-
Eles tornam visível o número de etapas, e o número de etapas é o tempo até o valor
Nada encurta o tempo até o valor como eliminar etapas, e nada revela etapas elimináveis como ver onze retângulos em sequência onde a equipe achava que havia quatro. Contar nós é o exercício de otimização mais barato do trabalho de produto.
-
Eles mostram que usuários diferentes precisam de caminhos diferentes
Um admin que configura um workspace e um membro convidado que entra nele estão fazendo tarefas diferentes e não deveriam receber a mesma orientação. Fluxos desenhados por persona deixam isso óbvio e reforçam o argumento a favor de segmentar o onboarding em vez de lançar um único tour para todo mundo.
-
Eles dizem onde a orientação deve ficar, e onde não deve
Um fluxo mostra quais etapas os usuários concluem sozinhos; essas etapas não precisam de ajuda, e acrescentá-la ali é pura fricção. Os dois ou três nós que vazam são onde um tooltip, um item de checklist ou uma etapa de tour justificam a interrupção.
O resultado real do fluxo não é o diagrama; é a seta apontando para baixo. Um único nó está causando a maior parte do estrago, e agora você sabe qual.
Como criar um fluxo de usuário em 7 etapas
Desenhar um fluxo de usuário leva uma tarde se você resistir a duas tentações: começar pelas telas em vez de pelas tarefas e desenhar de memória em vez de a partir do produto lançado. A sequência abaixo prioriza os dados de propósito; o diagrama só vale a pena porque você pode confiar nele.
- Escolha uma tarefa e escreva-a como uma frase
- Nomeie os pontos de entrada e o estado concluído
- Liste as etapas entre eles, em ordem
- Adicione uma decisão sempre que o produto encaminhar usuários de formas diferentes
- Percorra o fluxo no seu produto em produção e corrija-o
- Associe um número real a cada etapa
- Marque o que você vai mudar e o que vai deixar como está
1. Escolha uma tarefa e escreva-a como uma frase
Comece com uma frase na linguagem do usuário: "Como novo admin, quero os dados da minha equipe no workspace para poder gerar meu primeiro relatório." Não "fluxo de onboarding", não "o módulo de projetos": uma tarefa com começo e fim. A frase faz um trabalho de verdade: ela fixa o escopo, nomeia a persona e declara o resultado que você vai medir depois. Fluxos fracassam mais por serem amplos demais do que por serem rasos demais, e a cura é sempre a mesma: dividir um fluxo em dois.
2. Nomeie os pontos de entrada e o estado concluído
A maioria dos fluxos tem mais de uma porta. Os usuários chegam a "convidar um colega" a partir de um estado vazio, de uma página de configurações, de um nudge dentro de um checklist e de um link em um relatório compartilhado, e cada porta os deixa entrar com um contexto e expectativas diferentes. Liste todos os pontos de entrada, porque uma etapa que parece óbvia a partir de uma porta parece totalmente sem sentido a partir de outra. Depois defina o estado concluído com precisão suficiente para virar uma consulta: não "o usuário concluiu o onboarding", mas "o convidado aceitou o convite e abriu um projeto compartilhado". Se você não consegue escrever isso como uma consulta, não consegue saber se o fluxo funciona.
3. Liste as etapas entre eles, em ordem
Agora escreva o meio em texto simples, uma linha por tela ou ação, antes de desenhar qualquer coisa. O texto mantém você honesto; é muito fácil pular uma etapa em um diagrama e muito óbvio quando uma lista salta de "clica em Importar" para "vê os resultados". Inclua as etapas que pertencem ao produto e não ao usuário, como um e-mail de confirmação ou uma sincronização em segundo plano, porque é durante a espera que os usuários decidem se algo quebrou.
4. Adicione uma decisão sempre que o produto encaminhar usuários de formas diferentes
Esta é a etapa que separa um fluxo de usuário de uma lista de tarefas. Percorra a sua lista e pergunte em cada linha: dois usuários poderiam ver coisas diferentes aqui? Os suspeitos de sempre são papel e permissões, plano e limites, dados vazios versus preenchidos, erros de validação, primeira visita versus retorno e dispositivo. Cada "sim" vira um losango com uma seta rotulada por resultado, e cada seta precisa de um lugar para chegar, mesmo que o destino honesto seja uma tela que não diz nada de útil. Isso é uma descoberta, não um erro de desenho.
5. Percorra o fluxo no seu produto em produção e corrija-o
Abra uma conta realmente nova e faça a tarefa você mesmo, devagar, anotando cada tela que de fato aparecer. O produto lançado sempre tem mais etapas do que a equipe lembra: uma tela intermediária adicionada por uma exigência de compliance, um modal de um lançamento de dois trimestres atrás, um e-mail de verificação que agora leva noventa segundos. Depois assista a algumas gravações de sessão de usuários reais fazendo a mesma tarefa. O seu percurso dá a estrutura verdadeira; as gravações mostram as hesitações, e é na hesitação que a orientação deve ficar.
6. Associe um número real a cada etapa
Um fluxo sem dados é um diagrama de opiniões. Coloque ao lado de cada nó a quantidade de usuários que chegam a ele e a porcentagem que continua. Dois padrões importam, e eles pedem correções opostas: um problema de descoberta, em que poucos usuários chegam a um nó, significa que o problema é o ponto de entrada: ninguém está encontrando a porta. Um problema de execução, em que muitos chegam a um nó e poucos saem dele, significa que a própria etapa é difícil demais, vaga demais ou exigente demais naquele momento. Erre o diagnóstico e você vai passar uma sprint deixando mais bonita uma tela que quase ninguém vê.
7. Marque o que você vai mudar e o que vai deixar como está
Encerre o exercício marcando no máximo três nós no diagrama: o vazamento que você vai corrigir, o beco sem saída que vai ganhar um destino real e a etapa que você vai eliminar de vez. A eliminação merece uma linha própria porque é a ação de maior alavancagem disponível e a que as equipes pulam: uma etapa removida nunca mais confunde ninguém. Todo o resto do fluxo fica como está de propósito, e escrever "manter" ao lado de cada item é o que impede o exercício de virar um redesenho que ninguém planejou.
A armadilha: desenhar o fluxo que você gostaria de ter. Um fluxo de usuário montado a partir da especificação e dos arquivos de design vai ficar organizado, curto e errado, e errado justamente do jeito que esconde o seu problema, porque as etapas com mais chance de serem esquecidas (o e-mail de verificação, a verificação de permissão, o estado vazio) são exatamente as etapas onde os usuários vão embora. Se o diagrama faz o seu produto parecer melhor do que a sua taxa de ativação, você desenhou o task flow sem querer.
6 exemplos de fluxo de usuário para produtos SaaS
Em vez de um modelo abstrato, aqui estão os seis fluxos que mais valem ser desenhados em um produto SaaS, com a decisão que costuma se esconder dentro de cada um. Desenhe-os nesta ordem: eles estão classificados pelo quanto afetam diretamente a receita.
1. Do cadastro ao primeiro valor
O fluxo que decide tudo o que vem depois: da página de preços ou do anúncio, passando pela criação da conta, verificação, configuração do workspace, até a primeira ação que entrega um resultado real. A decisão escondida quase sempre é a verificação de e-mail, uma etapa que divide os novos usuários entre os que continuam e os que voltam para a caixa de entrada, se distraem e nunca mais voltam. Desenhe-a como um losango próprio e coloque um número nas duas ramificações. Boa parte do que um fluxo de cadastro bem desenhado conquista se perde de novo nas quatro telas seguintes, e é por isso que o fluxo não pode parar em "conta criada".
Dois losangos decidem a maior parte da taxa de ativação deste produto: se o e-mail é verificado e se o workspace vazio oferece uma próxima ação.
2. Configuração inicial de uma conta vazia
O fluxo que começa depois do cadastro e termina quando a conta contém realidade suficiente do usuário para ser útil: integração conectada, registros importados, colega convidado, projeto configurado. Geralmente é um fluxo que se estende por várias sessões, e é essa característica que quebra a maioria dos designs: um usuário que sai na etapa três e volta amanhã precisa retomar, não recomeçar. Esse único requisito é o argumento a favor de um checklist de onboarding em vez de um assistente linear, e o diagrama de fluxo é onde o formato de várias sessões se torna impossível de ignorar.
3. Convidar um colega
Simples só na aparência, e um dos fluxos de maior valor em qualquer produto colaborativo, porque um segundo usuário em uma conta muda completamente a economia da retenção. Ele também tem dois protagonistas, quem convida e quem é convidado, e o fluxo do segundo é o que geralmente fica sem ser desenhado. As decisões escondidas se concentram ali: o convidado já tem uma conta, ainda há licenças disponíveis no plano, ele cai no workspace para o qual foi convidado ou em uma tela inicial genérica sem a menor ideia do motivo de estar ali?
4. Descobrir e adotar uma segunda funcionalidade
A adoção além da primeira funcionalidade quase nunca acontece por acaso, e este fluxo mostra por quê: os pontos de entrada dele são fracos. Ninguém acorda querendo o seu módulo de relatórios; as pessoas chegam até ele por um item de menu em que nunca clicaram, um anúncio que talvez tenham fechado ou um momento de necessidade que o produto não percebeu. Desenhá-lo geralmente revela que o fluxo não tem nenhum ponto de entrada real, o que reformula o problema como descoberta de funcionalidades e não como usabilidade da funcionalidade, e direciona a correção para um nudge contextual em vez de um redesenho.
5. Chegar a um limite e fazer upgrade
O fluxo da receita. Um usuário esbarra em um teto do plano (licenças, registros, exportações) e o produto decide naquele instante se o momento parece um próximo passo natural ou uma extorsão. Desenhe cada caminho até o paywall separadamente, porque o contexto é tudo: um usuário bloqueado no meio de uma tarefa precisa de uma tela diferente da de um usuário que está olhando os planos nas configurações. A decisão que vale rotular é o que acontece no "agora não", já que essa ramificação determina se você terá uma conversão mais tarde ou uma conta perdida por churn.
6. Recuperar-se de um erro
O fluxo que as equipes quase nunca desenham, e aquele em que a confiança realmente se decide. Importação com falha, sessão expirada, pagamento recusado, conflito de sincronização: cada um tem um momento em que o produto diz ao usuário que algo deu errado, e a pergunta do fluxo é para onde aponta a seta que sai desse nó. Se a resposta honesta é "para lugar nenhum: espera-se que o usuário se vire", você encontrou um defeito real que nenhum teste de usabilidade do caminho feliz teria revelado.
Um atalho que vale a pena. Se você só for desenhar um fluxo, desenhe o que vai do cadastro até o momento em que o usuário obtém o primeiro resultado real do seu produto. Todo o resto do negócio (ativação, retenção, expansão) depende de esse caminho ser percorrível, e é o fluxo em que uma única etapa eliminada tem mais chance de aparecer nos números do mês seguinte.
Boas práticas de fluxo de usuário: o que fazer e o que evitar
✅ Faça
- Limite cada fluxo a uma tarefa com um estado final verificável
- Desenhe da esquerda para a direita, um nó por tela ou ação
- Rotule cada ramificação que sai de cada decisão
- Inclua os pontos de entrada: todos eles, não só o principal
- Dê um nó aos becos sem saída para que não fiquem invisíveis
- Percorra o produto em produção antes de confiar no diagrama
- Coloque um número real de abandono ao lado de cada etapa
- Desenhe fluxos separados para segmentos realmente diferentes
❌ Evite
- Tentar cobrir o produto inteiro em um único diagrama
- Desenhar só o caminho feliz e chamar isso de fluxo de usuário
- Confundi-lo com um sitemap, um wireframe ou um relatório de funil
- Montá-lo a partir da especificação em vez do produto lançado
- Inventar símbolos novos que a equipe precise aprender
- Esconder as ramificações feias para deixar a imagem limpa
- Deixar o diagrama ficar desatualizado depois do próximo release
- Responder a cada vazamento com "adicione uma etapa de tour"
Do diagrama de fluxo ao fluxo guiado
Um fluxo de usuário pronto entrega duas coisas: uma lista de etapas que vazam e um diagnóstico do motivo de cada vazamento. Esses dois fatos se encaixam diretamente no tipo de ajuda que os corrige, e fazer essa correspondência corretamente é a maior parte da habilidade, porque a intervenção errada na etapa certa continua não resolvendo nada:
| O que o fluxo mostra | O problema real | O que resolve |
|---|---|---|
| Poucos usuários chegam a um nó | Descoberta: ninguém encontra a porta | Um hotspot ou um anúncio in-app no ponto de entrada |
| Muitos chegam, poucos continuam | Execução: a etapa é confusa ou difícil | Um tooltip ou um product tour curto exatamente naquele momento |
| Os usuários saem e voltam mais tarde | Várias sessões: o progresso não é lembrado | Um checklist que persiste e é retomado por usuário |
| Uma ramificação não leva a lugar nenhum | Um estado que ninguém desenhou | Um destino real mais uma explicação contextual |
| Segmentos diferentes travam em nós diferentes | Um único caminho para várias tarefas | Fluxos segmentados por papel ou por plano |
É nesta parte que a maioria dos exercícios de fluxo de usuário morre em silêncio. O diagrama é desenhado, as etapas que vazam são identificadas e depois as correções entram no backlog de engenharia atrás de todo o resto, de modo que o fluxo continua exato um ano depois, e esse é justamente o problema. Com o Kompassify, a camada de orientação fica por cima do seu produto em produção, e não dentro do seu ciclo de release:
- Oriente exatamente a etapa que vaza. Crie um tour, um tooltip ou um hotspot na tela específica que o seu fluxo apontou, em um editor visual por cima do seu produto real: sem código, sem deploy.
- Dê memória aos fluxos de várias sessões. Um checklist de onboarding acompanha a conclusão por usuário, então quem saiu na etapa três volta para a etapa quatro em vez de voltar ao início.
- Mande caminhos diferentes para pessoas diferentes. Segmente a orientação para que admins, membros convidados e usuários em trial recebam cada um o fluxo que você desenhou para eles.
- Resgate os becos sem saída. Coloque uma mensagem contextual nas ramificações que ninguém desenhou (o workspace vazio, a permissão que falta, o trial expirado) enquanto a correção definitiva não chega.
- Feche o ciclo com números. O analytics integrado mostra a conclusão e o abandono por etapa, para que a próxima versão do diagrama seja desenhada a partir de evidências, e não da memória.
O Kompassify está em conformidade com o GDPR e hospedado na UE, é gratuito até usuários ativos mensais e tem planos pagos a partir de US$ 129/mês.
Corrija a etapa que o seu fluxo acabou de encontrar
O Kompassify adiciona product tours, checklists de onboarding, tooltips e hotspots ao seu produto atual (sem código, sem ciclo de release), para que o nó que vaza no seu diagrama receba ajuda nesta semana, e não no próximo trimestre. Segmente por público, acompanhe a conclusão por etapa e veja se a correção funcionou. Em conformidade com o GDPR, hospedado na UE e gratuito até usuários ativos mensais.
Comece grátis →Perguntas frequentes
O que é um fluxo de usuário?
Um fluxo de usuário (user flow) é a sequência ordenada de telas, ações e decisões pela qual uma pessoa passa para concluir uma tarefa específica no seu produto: criar a conta, convidar um colega, publicar o primeiro projeto. Ele é desenhado como um diagrama: pontos de entrada como ovais, telas e ações como retângulos, decisões como losangos e setas para cada movimento possível entre eles. Ao contrário de um wireframe, um fluxo de usuário não diz nada sobre layout; ao contrário de um funil, ele mostra cada ramificação e cada beco sem saída em vez de uma única porcentagem agregada. O objetivo é tornar visível o caminho real, para que você veja onde ele se bifurca, onde entra em loop e onde termina silenciosamente.
Qual é a diferença entre um fluxo de usuário e um mapa da jornada do usuário?
Escopo e altitude. Um fluxo de usuário fica dentro do produto e é mecânico: esta tela, aquele clique, esta decisão, para uma tarefa em uma sessão. Um mapa da jornada do usuário fica ao redor do produto e é emocional: ele acompanha uma persona por etapas e canais (um anúncio, uma call de demo, o primeiro login, um chamado de suporte, uma renovação) e registra o que ela pensa e sente em cada etapa. O mapa da jornada diz qual etapa dói; o fluxo de usuário diz qual clique causa a dor. A maioria das equipes precisa dos dois, e geralmente nessa ordem: mapeie a jornada para encontrar a etapa dolorosa e depois desenhe o fluxo de usuário da tarefa dentro dela para encontrar o passo que dá para corrigir.
Quais símbolos são usados em um diagrama de fluxo de usuário?
A notação vem dos fluxogramas e é propositalmente enxuta. Um oval ou uma pílula arredondada marca um ponto de entrada ou um estado final. Um retângulo é uma tela que o usuário vê ou uma ação que ele realiza. Um losango é uma decisão, uma bifurcação com uma ramificação rotulada para cada resultado, inclusive os ruins. Um paralelogramo marca dados que entram ou saem, como o envio de um formulário ou um link enviado por e-mail. As setas indicam a direção do percurso, e toda seta que sai de um losango precisa ser rotulada com a condição que leva o usuário por ela. Qualquer coisa além dessas cinco formas costuma custar mais em explicação do que acrescenta em precisão.
Como criar um fluxo de usuário?
Comece por uma tarefa, não por uma tela: escolha uma coisa que o usuário quer realizar e nomeie os pontos de entrada que levam a ela e o estado concluído que a encerra. Liste as etapas necessárias entre eles e depois adicione um losango de decisão sempre que o produto puder mandar usuários diferentes para lugares diferentes: permissões, limites do plano, contas vazias, erros de validação. Desenhe da esquerda para a direita, rotule cada ramificação e então percorra o fluxo no seu produto em produção e corrija o desenho, porque o produto lançado sempre tem mais etapas do que alguém lembra. Por fim, coloque os dados do seu analytics de produto ao lado, para que cada etapa tenha um número real de abandono, e marque as etapas que você quer mudar.
Quais são exemplos de fluxos de usuário em produtos SaaS?
Os fluxos que valem ser desenhados primeiro são os que decidem a receita: do cadastro ao primeiro valor, a configuração inicial de uma conta vazia, o convite a um colega, a descoberta e adoção de uma segunda funcionalidade, a chegada a um limite do plano e o upgrade, e a recuperação de um erro ou de uma importação que falhou. Cada um tem uma tarefa clara, um estado concluído mensurável e pelo menos uma decisão que, sem alarde, leva os usuários a um beco sem saída: um e-mail não verificado, um workspace vazio, uma permissão que quem convidou não tinha, uma tela de upgrade sem nenhum contexto sobre o que mudou.
Qual é a diferença entre um task flow e um fluxo de usuário?
Um task flow (fluxo de tarefa) é o único caminho ideal por uma tarefa: uma linha, sem ramificações, a versão que um designer mostraria em uma demo. Um fluxo de usuário mantém as ramificações: pontos de entrada diferentes, segmentos de usuários diferentes, decisões diferentes e os caminhos que as pessoas seguem quando algo falha. Task flows são úteis para escrever uma especificação ou um teste do caminho feliz; fluxos de usuário são o que você precisa quando tenta explicar por que a ativação está travada, porque usuários travados quase nunca estão no caminho ideal.
Como transformar um fluxo de usuário em orientação dentro do produto?
Quando o fluxo está desenhado e cada etapa tem um número de abandono, você sabe exatamente onde o usuário precisa de ajuda e de que tipo. Uma etapa que as pessoas nunca alcançam precisa de descoberta: um hotspot ou um anúncio. Uma etapa que as pessoas alcançam e abandonam precisa de explicação naquele momento: um tooltip ou um product tour curto. Um fluxo que se estende por várias sessões precisa de um checklist que lembre o progresso. Com uma plataforma no-code como o Kompassify, você cria cada um desses elementos por cima do seu produto em produção em um editor visual, segmenta para o grupo que trava e publica sem ciclo de release. O Kompassify está em conformidade com o GDPR e hospedado na UE, é gratuito até usuários ativos mensais e tem planos pagos a partir de US$ 129/mês.