Introdução
Então, você decidiu dar uma chance ao design sprints da Agência Fort, muito bem! Você passou cerca de cinco dias concentrando-se intensamente em um problema específico. Você teve a sorte de obter comentários úteis, diretos e, com sorte, positivos dos usuários sobre o seu protótipo. Agora você está se perguntando o que fazer com todo esse feedback que coletou e como transformá-lo em um produto de sucesso.
Dependendo do seu estilo de trabalho, os sprints de design podem se encaixar no desenvolvimento de uma maneira diferente:
Você pode ter um sprint de trilha dupla (também conhecido como mini-cascata), onde o design geralmente está um sprint à frente do desenvolvimento.
Você pode ter picos de design como parte de seus sprints ágeis, onde toda a sua equipe multifuncional é capaz de se concentrar em um problema por um período de tempo.
Você pode ter um fluxo de trabalho Kanban mais tranquilo, com sprints de design feitos quando necessário.
Obviamente, os sprints de design não acontecem no vazio. Você precisa descobrir como enviar os resultados do design sprint de volta para sua equipe de desenvolvimento. Para implementar os resultados, você pode tentar estas coisas:
Combinando resultados com conhecimento prévio
Priorizando e dividindo as coisas
Revalidando e rastreando o sucesso
Seguindo esses pontos, você manterá uma visão holística de sua meta de negócios, aumentará a produtividade e garantirá o fornecimento do conjunto certo de recursos aos usuários. Neste artigo, veremos algumas dicas sobre como fazer exatamente isso – com exemplos completos!
Combine os resultados com o conhecimento prévio
Ter todos esses resultados do sprint pode parecer opressor. Você precisa de alguma forma dar sentido a eles. A melhor coisa é colocar os resultados do sprint de design em uma perspectiva mais ampla, para dar sentido ao conhecimento novo e existente. Isso é importante, pois um dos resultados do design sprint não é apenas o protótipo em si, mas também o alinhamento entre os membros da equipe sobre o que é valioso.
Pense nas seguintes coisas:
Quais são os principais pontos que você aprendeu em um design sprint?
Como esses pontos refletem o estado atual de sua solução?
O que foi validado?
O que precisa mudar?
Existem suposições que ainda precisam ser esclarecidas?
O business case é afetado pelos pontos de aprendizagem?
Vejamos o protótipo do aplicativo de faturamento como exemplo.
Queríamos aprender como os usuários podem usar o aplicativo móvel para emitir faturas para seus clientes. O sprint nos forneceu a validação de que o faturamento em trânsito é uma necessidade, mas também é difícil para os usuários digitar todas as informações necessárias em trânsito. Isso abriu a questão de saber se há necessidade do aplicativo da web, para permitir a entrada de dados mais fácil.
Priorize bem e divida
O resultado do sprint de design às vezes pode parecer opressor e fechado em si mesmo. Por isso, é importante dividir a solução em partes significativas e decidir o que deve vir primeiro. Você pode fazer isso de forma colaborativa, com base na opinião de sua equipe. Agora é a hora de se perguntar:
Quais são os casos extremos que o sprint de design não considerou?
Quais ações do usuário estão disponíveis por meio do protótipo?
Quais dessas ações são cruciais para garantir uma jornada do usuário de ponta a ponta?
Vejamos nosso protótipo de aplicativo de faturamento novamente. As ideias que acabaram fazendo parte do protótipo do design sprint eram de alto nível e não cobriam toda a jornada do usuário. Isso significa que tivemos que trabalhar um pouco mais para cobrir diferentes casos. Por exemplo:
Estávamos perdendo todo o fluxo de integração, então tivemos que defini-lo, já que era uma parte crucial da jornada.
Não pensamos em todas as opções de configuração da conta, como modelos de faturamento ou opções de segurança. Descobriu-se que alguns deles eram importantes para os usuários.
Com todas essas novas ideias coletadas, era hora de priorizá-las. Existem algumas técnicas de priorização que considero úteis para decidir o que realmente será construído. Vamos examiná-los abaixo, observando um protótipo de aplicativo de faturamento como exemplo.
Mapeamento de história de usuário
User Story Mapping é uma ferramenta para visualização de backlog, introduzida por Jeff Patton. Ele promove uma compreensão compartilhada do que você deseja construir e por quê, e faz isso exibindo histórias como parte do fluxo de trabalho do usuário.
Como você pode usar isso? Agora, você tem o objetivo geral definido pelo sprint de design. Você pode usar a jornada do usuário definida durante a sprint como a espinha dorsal da história para o mapeamento da história. O backbone é essencialmente uma lista de ponta a ponta de etapas de alto nível da jornada do usuário – uma linha do tempo. Em seguida, você deseja identificar as atividades que agrupam as etapas da jornada do usuário e, em seguida, dividir as etapas da jornada em tarefas e subtarefas. Para fazer isso, observe as restrições e casos extremos, diferentes funções de usuário ou quaisquer detalhes do produto que sejam específicos ao seu caso de negócios. A última etapa é decidir como agrupar tarefas e subtarefas em versões.
Você pode encontrar alguns ótimos guias sobre como mapear a história do usuário aqui e aqui e, claro – há um livro sobre isso.
Matriz de Priorização
Matriz de priorização é provavelmente uma das técnicas de priorização mais simples e eficazes que existem. A ferramenta também é conhecida como Matriz de Eisenhower e ajuda a classificar as tarefas com base na urgência e na importância. Uma versão alternativa – com foco em informar as decisões de UX. Ele permite que você mapeie recursos de acordo com o valor do usuário e o esforço de desenvolvimento. Os quadrantes então lhe dizem:
o que você deve absolutamente focar,
no que você talvez deva se concentrar, e
o que você provavelmente pode deixar para trás.
Como você pode usar isso? Faça uma matriz em um quadro branco onde o eixo X mostra alto a baixo esforço e o eixo Y mostra o valor do usuário de baixo a alto. Em seguida, coloque suas ideias onde você acha que elas pertencem, fazendo perguntas como:
Qual é o valor desse recurso para nossos usuários?
Quão complexo é a construção desse recurso e quanto tempo levaríamos para criá-lo?
Na minha opinião, a Matriz de Priorização é especialmente interessante quando combinada com o mapeamento da história do usuário (a.k.a se você não tiver certeza de como agrupar seus lançamentos). Isso porque fará você pensar sobre qual é o valor do usuário versus esforço para desenvolver algo.
O Teste NUF
O Teste Novo, Útil e Viável é uma matriz simples que pode ajudá-lo a priorizar várias ideias, classificando-as e somando suas pontuações. No final, você classifica suas ideias pela pontuação geral.
Como você pode usar isso? Liste todas as suas ideias de recursos à esquerda e adicione as colunas Novo, Útil e Viável à direita. Em seguida, valide cada ideia de 0 a 10 com base em:
Quão novo é – já é visto em seu produto ou uma ideia completamente nova?
Quão útil é – quanto valor traria para os usuários ou para a empresa?
Quão viável é – é possível desenvolver dentro do prazo e das restrições que você tem?
Depois de somar as pontuações, aqueles com o valor mais alto devem se tornar a prioridade de sua equipe.
Revalide, desenvolva e acompanhe o sucesso
Depois da sprint de design e da priorização, é hora de uma última verificação de protótipo com os usuários. A equipe de design pode adicionar interações mais profundas que refletem o escopo priorizado e executar o protótipo atualizado pelos usuários para garantir que tudo esteja claro.
Para nosso aplicativo de faturamento, isso significava que tínhamos que projetar a experiência de integração e as interações detalhadas para as configurações da conta. Com essas melhorias implementadas, executamos o protótipo mais uma vez pelos usuários.
Com isso concluído, é hora de desenvolvimento. Claro, você ainda não terminou – você deseja rastrear o que acontece em estado selvagem depois de implantar sua solução para os usuários. Você pode coletar dados qualitativos (também conhecidos como análises) e quantitativos (também conhecidos como feedback do cliente) e usá-los como base para suas próximas etapas e fases de implantação.
Em conclusão
O final de um design sprint é realmente o início do desenvolvimento do produto ou recurso, e o aprendizado nunca para. Depois de pegar o jeito de priorizar e obter feedback do usuário sobre os itens enviados, você poderá ajustar o escopo de qualquer nova iteração de seu produto, com base nas necessidades do usuário. Isso fará com que sua equipe seja mais produtiva e fique de olho apenas no que é importante.
A priorização requer que você combine seu conhecimento de negócios, bem como novas descobertas do design sprint. Ele também pode mudar com o novo feedback depois que o produto estiver no ar. A chave é que você é capaz de reagir rapidamente a isso.