Perspectiva
A revisão dos stakeholders deve resolver decisões
Solicitações abertas de feedback convidam edições conflitantes. Dê a cada revisão uma decisão, um padrão de evidência e um responsável que possa resolver desacordos.
Você envia o storyboard para feedback. Um revisor quer mais detalhes. Outro quer menos texto. Alguém reescreve o objetivo. Outra pessoa pergunta por que isso é um curso.
Todos esses comentários podem ser importantes. Mas pertencem a decisões diferentes, e você os convidou para a mesma conversa sem explicar qual conversa você precisa ter.
"Por favor, revise" soa eficiente. Isso deixa os revisores inventarem seus próprios critérios.
Eu tornaria o pedido mais específico: o que precisa ser decidido, quais evidências devem informá-lo e quem pode fechar a decisão?
"Por favor, revise" é um pedido incompleto.
Uma revisão útil reduz a incerteza sobre o trabalho.
Se uma revisão produz vinte comentários, mas deixa a questão central do projeto não resolvida, temos mais atividade sem necessariamente ter mais direção.
Combine o revisor com a decisão.
Pessoas diferentes sabem coisas diferentes. Um especialista em conteúdo pode confirmar uma regra. Um funcionário da linha de frente pode identificar uma situação que parece errada. Um proprietário de processo pode decidir como uma exceção deve ser tratada. Um patrocinador pode aprovar uma mudança de escopo.
Essas contribuições são valiosas, mas não são intercambiáveis.
A preferência de um patrocinador por um vídeo mais longo não estabelece que os aprendizes precisam de mais explicação. A preferência de um designer por um cenário mais simples não resolve uma questão de política não resolvida. A aprovação de um especialista em políticas não nos diz se alguém pode usar a referência durante um turno movimentado.
Antes de enviar o trabalho, nomeie a decisão e a expertise que ela requer. Se a pessoa que está revisando não puder resolvê-la, peça que identifique o proprietário apropriado.
Isso também facilita a acolhida de descobertas inesperadas. Um aprendiz testando a interface pode descobrir uma contradição de política. Essa descoberta deve chegar ao proprietário da política em vez de ser enterrada em uma lista de edições de design.
Escreva um breve resumo da revisão.
Eu colocaria um breve resumo da revisão acima do link ou anexo. Cinco linhas costumam ser suficientes:
- Decisão: O que deve ser resolvido nesta revisão?
- Material: Qual parte do trabalho os revisores devem inspecionar?
- Critérios: O que tornaria isso aceitável?
- Propriedade: Quem contribui com expertise e quem toma a decisão final?
- Tempo: Quando uma resposta é necessária e o que acontece se a decisão permanecer em aberto?
Para um primeiro protótipo, a decisão pode ser se a atividade reflete a tarefa-alvo e é compreensível para os usuários pretendidos. Uma revisão final tem perguntas diferentes sobre funcionalidade, precisão, acessibilidade e prontidão.
Peça que comentários fora da decisão imediata sejam identificados separadamente. Isso dá a eles um espaço sem permitir que cada observação reabra automaticamente todo o projeto.
Um problema urgente de precisão ainda precisa de atenção. Um escopo de revisão definido deve organizar as preocupações, não suprimi-las.
Revise uma decisão em vez de um curso inteiro.
Imagine um projeto hipotético para ajudar novos coordenadores de serviço a encaminhar solicitações de reparo de equipamentos. O protótipo contém um formulário de entrada e uma breve atividade de prática de encaminhamento. A questão incerta é o que fazer quando uma solicitação se encaixa em duas categorias de serviço.
Um pedido aberto de feedback pode gerar edições nos rótulos do formulário, nas ilustrações, na introdução e no número de perguntas. Nenhuma dessas edições resolve a regra de encaminhamento.
Um resumo de revisão que você pode adaptar
Decisão: aprove a lógica de encaminhamento para solicitações que se encaixam em mais de uma categoria.
Material: inspecione as três solicitações de exemplo e as rotas propostas no protótipo vinculado.
Critérios: a rota deve seguir o procedimento de serviço atual, identificar o proprietário receptor e explicar quando a consulta é necessária.
Propriedade: os líderes de serviço identificam exceções; o proprietário do processo resolve conflitos; o designer atualiza a prática após essa decisão.
Tempo: por favor, responda até a data de revisão acordada. Se a regra permanecer não resolvida, reteremos os casos de prática afetados e identificaremos o impacto no lançamento.
Agora o revisor sabe qual contribuição importa. O designer também tem um motivo para parar de editar o caso afetado até que a regra governante esteja clara.
Uma vez que a regra esteja definida, um teste de usuário separado pode examinar se novos coordenadores entendem e aplicam isso. A aprovação da lógica e da usabilidade da experiência estão relacionadas, mas cada uma precisa de suas próprias evidências.
Trate a discordância como informação.
Quando os revisores discordam, resista à tentação de combinar cada sugestão em uma tela de compromisso.
Dois comentários conflitantes podem revelar diferentes suposições sobre o público, a tarefa ou as condições de uso. Pergunte a cada revisor para qual situação eles estão projetando e qual risco estão tentando prevenir.
No exemplo de encaminhamento, um líder pode assumir que o coordenador pode consultar um colega sênior imediatamente. Outro pode estar pensando em um turno noturno com cobertura limitada. Essa é uma diferença de contexto que vale a pena resolver antes de escolher o suporte.
Registre a discordância como uma pergunta. Quais condições o processo precisa cobrir? Qual fonte governa a resposta? Quem tem autoridade para decidir?
Se a discordância for uma questão de preferência, volte aos critérios de design. Se se tratar de um requisito, envolva o proprietário responsável. Se refletir incerteza sobre os usuários, colete uma observação relevante.
Uma revisão é útil quando responde à preocupação. Adicionar mais conteúdo apenas para fazer um comentário desaparecer pode deixar a verdadeira questão intocada.
Feche o ciclo por escrito.
Após a revisão, mantenha um breve registro de decisões. Anote a pergunta, a resposta acordada, a justificativa, a fonte ou evidência e o proprietário. Identifique qualquer suposição que ainda precise ser verificada.
Isso é especialmente útil quando alguém pergunta um mês depois por que uma seção foi removida ou por que uma exceção foi tratada de forma diferente. Você pode revisitar a razão em vez de reconstruí-la a partir de comentários espalhados por arquivos.
A IA pode ajudar a resumir notas de revisão e agrupar preocupações semelhantes. Verifique seu resumo em relação aos originais. Não deixe que um resumo gerado transforme uma sugestão em aprovação ou apague um requisito dissidente.
O silêncio não é um sinal confiável de concordância. Se um proprietário necessário não respondeu, marque a decisão como aberta e explique a consequência. As equipes podem concordar com a escalada ou autoridade delegada, mas esse acordo precisa ser explícito.
Meça a qualidade da revisão pela resolução das perguntas necessárias e pela visibilidade dos riscos materiais. Um retorno mais rápido é útil apenas quando as decisões são sólidas o suficiente para avançar o trabalho.
Em seu próximo pedido de revisão, substitua “Deixe-me saber o que você pensa” por uma decisão específica e os critérios para julgá-la. Você dará aos seus revisores uma tarefa mais clara e a si mesmo uma base mais clara para agir com base no feedback deles.
A revisão deve deixar o projeto com uma resposta que ele possa usar.
Leitura relacionada
Seu SME lhe deu 74 slidesComece a conversa com as partes interessadas esclarecendo o problema de desempenho e as decisões que a aprendizagem precisa apoiar.
Learning Rewired Lab™
Mantenha as decisões do projeto conectadas.
O Lab é o espaço profissional completo para transformar um pedido de aprendizado em uma solução de desempenho defensável. Desafie o pedido, investigue o sistema, projete a resposta e planeje as evidências em um projeto conectado.
Desafie o pedido, examine o sistema e projete para o desempenho antes que a produção comece.
- Um registro de projeto conectado
- Diagnóstico de pedido e desempenho
- Ferramentas de aprendizado com foco em produto
- Fluxos de trabalho de design assistidos por IA
- Aplicação prática no local de trabalho