Os requisitos muitas vezes falham porque começam muito tarde no processo de desenvolvimento. Um briefing de funcionalidades pode descrever telas, regras e casos extremos, mas ainda assim não captar a sequência real de passos que uma pessoa deve seguir. Os gerentes de produto podem reduzir essa lacuna mapeando os fluxos de usuário antes mesmo de qualquer tarefa de design ou desenvolvimento ser criada. Isso torna o trabalho menos reativo e proporciona à equipe uma visão mais clara do que o produto deve ajudar o usuário a realizar.
Mapeando as jornadas do usuário: da intenção ao sucesso.
Um mapa de fluxo de usuário deve mostrar o caminho da intenção ao resultado. Deve incluir onde o usuário entra, quais pontos de decisão aparecem, quais informações são necessárias e onde o produto pode perder o usuário. Uma referência prática, o Biblioteca de fluxos de usuário PageFlows, Isso pode ajudar os gerentes de produto a estudar os fluxos reais de aquisição, ativação, monetização, retenção e suporte antes de transformar suposições em requisitos. O valor não está em copiar um padrão, mas em observar como os produtos reais estruturam etapas, atritos, recuperação e conclusão.
Comece com o objetivo de negócios e, em seguida, traduza-o em movimento do usuário.
Um fluxo não deve começar com um nome de usuário. Deve começar com um objetivo mensurável do produto. Aquisição pode significar fazer com que um visitante comece a se cadastrar, enquanto ativação pode significar ajudar uma nova conta a alcançar um primeiro resultado útil. Monetização pode envolver um upgrade, uma finalização de compra ou uma decisão de assinatura. Retenção pode envolver lembretes, progresso salvo, avisos de renovação ou reengajamento. Suporte pode envolver a resolução de um problema sem forçar o usuário a um longo ciclo de contato humano. Uma vez que o objetivo esteja claro, o gerente de produto pode descrever qual ação deve ocorrer por parte do usuário.
Separe o fluxo principal dos caminhos de recuperação.
O fluxo principal é a rota limpa. Ele mostra o que acontece quando o usuário entende a oferta, tem as informações corretas e completa cada etapa sem problemas. Esse fluxo é importante porque fornece à equipe uma base de comparação. Ele também ajuda a eliminar trabalho desnecessário da primeira versão do requisito. Se a rota principal parecer confusa no papel, o produto provavelmente terá uma experiência pior em uso.
Os caminhos de recuperação são onde muitas fragilidades nos requisitos são expostas. Um usuário esquece a senha, seleciona o plano errado, abandona a finalização da compra, insere dados de pagamento inválidos ou precisa alterar o endereço de e-mail.
Esses casos não são secundários do ponto de vista do usuário. Frequentemente, são os momentos em que a confiança é restaurada ou perdida. Um gerente de produto deve mapeá-los antes de escrever os critérios de aceitação, pois desenvolvedores e designers precisam saber como o produto se comporta quando o fluxo de comportamento falha.
Aquisição, ativação, monetização, retenção e suporte de mapas como sistemas separados.
Os fluxos de aquisição tratam da transição do interesse externo para a entrada no produto. O gerente de produto deve definir a origem da intenção, a promessa feita e a primeira ação esperada do usuário. Um visitante que chega por meio de busca, indicação, mídia paga ou campanha de e-mail pode precisar de um contexto diferente antes de agir. O requisito não deve pressupor que todos os usuários começam com o mesmo nível de conhecimento. Um bom mapeamento de aquisição mostra o que precisa ser compreendido antes do início do cadastro.
Os fluxos de ativação merecem um mapa próprio, pois o cadastro não é ativação. Criar uma conta pode ser necessário, mas raramente é o resultado que comprova o valor do produto. O gerente de produto deve definir o primeiro momento de sucesso significativo e traçar o caminho mais curto e razoável até ele. Esse caminho pode incluir integração, permissões, preferências, dados de amostra, etapas de configuração ou a conclusão da primeira tarefa. Cada etapa deve justificar sua importância ajudando o usuário a alcançar a utilidade do produto mais rapidamente.
Os fluxos de monetização exigem uma redação cuidadosa antes mesmo da elaboração dos requisitos. O gerente de produto deve definir quando uma oferta paga é exibida, o que o usuário já sabe, qual comparação é necessária e o que acontece após o pagamento. Páginas de preços, solicitações de upgrade, telas de finalização de compra, faturas, término do período de teste e avisos de renovação pertencem ao mesmo sistema. Os requisitos também devem abranger cancelamentos, reembolsos e alterações de plano, pois esses momentos afetam a conversão futura. Um fluxo de pagamento que omite opções de saída pode aumentar a movimentação a curto prazo, mas pode gerar demanda de suporte desnecessária posteriormente.
Transforme cada fluxo em decisões, entradas, estados e resultados.
Após o fluxograma ser desenhado, ele deve ser traduzido em blocos de requisitos simples. Cada etapa precisa de uma decisão, uma entrada, um estado do sistema ou um resultado. Uma decisão solicita que o usuário escolha. Uma entrada solicita que o usuário forneça informações. Um estado informa à equipe o que o produto sabe naquele momento. Um resultado confirma o que mudou após a etapa. Essa estrutura impede que o requisito se torne uma descrição vaga da tela.
Use o mapa de fluxo para escrever tickets melhores.
Um ticket bem elaborado deve apontar para um local claro no fluxo. Deve explicar a intenção do usuário, a condição de entrada, a ação esperada, o estado de sucesso e os principais estados de falha. Isso facilita a estimativa e o teste do ticket. Também proporciona às equipes de design e engenharia uma justificativa comum para o trabalho. Sem esse contexto de fluxo, as equipes frequentemente debatem detalhes superficiais antes de concordarem sobre qual problema a etapa resolve.
Um hábito útil de gerenciamento de projetos é tratar os requisitos como resultado do pensamento de fluxo, e não como ponto de partida. Um fluxo mapeado pode revelar que uma funcionalidade planejada é, na verdade, composta por cinco fluxos conectados, ou que uma tela solicitada é totalmente desnecessária. Pode mostrar que a pressão sobre o suporte técnico surge de uma ativação pouco clara, ou que a monetização falha porque a comparação de planos chega cedo demais. Essas descobertas não são uma estratégia abstrata. Elas transformam o trabalho que é escrito, projetado, construído e mensurado.
Mapeie o fluxo antes de escrever os requisitos, e o trabalho se tornará mais preciso em cada etapa. O pensamento em fluxo expõe telas redundantes, falhas de recuperação ocultas e avisos em momentos inadequados antes que cheguem a um chamado, garantindo que o que for desenvolvido resolva o problema certo desde o início.
Leave A Comment