KjerrUm modelo de feature request
para você copiar.
Um bom modelo de feature request pergunta pelo problema, não pela solução: o que a pessoa está tentando fazer, o que atrapalha, quem é afetado e como seria um bom resultado. Copie o modelo abaixo para um documento, um formulário ou um gerenciador de tarefas, ou use um quadro que faz essas perguntas por você.
O modelo de feature request
Seis perguntas. Só o título deve ser obrigatório.
Título
Uma linha que diz o resultado, não a solução.
Exemplo: Exportar relatórios em CSV
O que você está tentando fazer?
A tarefa, com as suas palavras.
O que atrapalha hoje?
O que você faz no lugar e quanto isso custa a você.
Quem é afetado, e com que frequência?
Só você, sua equipe, todos os clientes de um plano? Todo dia, todo mês?
Como seria um bom resultado?
Como você saberia que o problema está resolvido. Deixe o design com a equipe.
Tem algo para mostrar?
Uma captura de tela, um arquivo de exemplo, um link.
Para que serve cada campo
- Título. Um resultado em uma linha torna os pedidos fáceis de buscar e faz as duplicatas se encontrarem.
- O que você está tentando fazer? O objetivo sobrevive mesmo quando a solução proposta não sobrevive.
- O que atrapalha? A solução improvisada de hoje mostra quanto o problema custa.
- Quem, e com que frequência? Alcance e frequência: o alcance de uma nota RICE, nas palavras do usuário.
- Como seria um bom resultado? Um teste de aceitação nas palavras do usuário.
- Tem algo para mostrar? Uma captura de tela vale por três parágrafos.
Como transformar o modelo em um formulário de feature request
O formulário deve ser mais curto que o modelo. Deixe nele o título e uma pergunta aberta, e pergunte o resto em um comentário, quando precisar.
- Exija só o título.
- Mostre os pedidos parecidos antes do envio, para a pessoa poder votar em vez de escrever.
- Deixe anexar uma captura de tela só colando a imagem.
- Confirme o e-mail uma vez, e não a cada pedido.
- Diga o que acontece depois: onde o pedido aparece e como a resposta vai chegar.
O mesmo modelo para feedback de produto
As mesmas perguntas servem de modelo de feedback de produto, para bugs e comentários em geral. Mantenha a primeira pergunta aberta e tire as duas últimas.
- Para bugs, pergunte o que a pessoa esperava e o que aconteceu no lugar. O modelo de bug report traz a lista completa de perguntas.
- Para elogios e reclamações, as duas primeiras perguntas bastam.
- Mantenha tudo em uma lista só, para que uma reclamação e um pedido sobre a mesma coisa se encontrem.
Como o formulário de ideias do Kjerr cobre o modelo
O formulário do Kjerr começa como a versão curta: título, detalhes opcionais e capturas de tela. O resto do modelo fica por conta do quadro em volta do formulário.
- O campo de detalhes pergunta: “O que você está tentando fazer e o que atrapalha?”
- Até 5 capturas de tela ou arquivos de 10 MB cada.
- Ideias parecidas aparecem enquanto o título é digitado, cada uma com seu botão de voto.
- Quem é afetado aparece nos votos e em Users & Companies, com empresa, plano e MRR.
- O formulário é seu para editar: mude o nome dos dois campos padrão, torne os detalhes obrigatórios e acrescente até 8 campos seus, cada um de uma linha ou de parágrafo.
Perguntas, com respostas diretas.
O que é um modelo de feature request?
Um modelo de feature request é um conjunto curto de perguntas que ajuda o usuário a descrever o que precisa: o objetivo, o que o impede hoje, quem é afetado e como seria um bom resultado. Ele torna os pedidos comparáveis e poupa à equipe uma rodada de perguntas de esclarecimento.
O que um formulário de feature request deve perguntar?
O mínimo possível. Um título e uma pergunta aberta coletam mais pedidos do que dez campos obrigatórios. Pergunte pelo problema, não pela solução, e deixe a pessoa anexar uma captura de tela.
O formulário deve ter campos obrigatórios?
Só o título. Cada campo obrigatório a mais reduz o número de pessoas que terminam o formulário, e os detalhes podem ser pedidos depois, em um comentário.
Em que um modelo de feedback de produto é diferente?
Um modelo de feedback de produto cobre tudo o que o usuário quer dizer, inclusive bugs e elogios; o modelo de feature request é a parte sobre o que ainda não existe. As mesmas perguntas servem para os dois, desde que a primeira continue aberta.
Como o formulário de ideias do Kjerr se compara a este modelo?
Por padrão, ele pede um título curto e detalhes opcionais, com a pergunta “O que você está tentando fazer e o que atrapalha?”, e aceita até 5 capturas de tela ou arquivos. Você pode renomear os dois campos e acrescentar até 8 campos seus. Enquanto o título é digitado, aparecem ideias parecidas com botão de voto, e assim muitos pedidos viram um voto em vez de uma duplicata.
Páginas relacionadas
Dê uma resposta aos seus usuários.
O Kjerr é gratuito durante o acesso antecipado: todos os recursos, sem cartão de crédito. Quando os planos pagos chegarem, o preço será por workspace, nunca por assento de administrador.