Guia para construtores não técnicos
Decida o que seu primeiro aplicativo precisa provar.
Transforme uma ideia ampla em um resumo curto e testável antes de solicitar telas e recursos.
01 — Descreva uma pessoa e uma tarefa
Suponha que você ajude um grupo comunitário a organizar turnos de voluntariado. Uma primeira pergunta útil pode ser se um voluntário consegue encontrar um turno adequado e saber como expressar interesse. Isso é menor e mais fácil de revisar do que um sistema de agendamento completo com lembretes, permissões e folha de pagamento.
- Descreva o que a pessoa faz hoje e o que é difícil.
- Escolha a ação que deseja tornar mais clara ou fácil.
- Escreva o que você observaria se a primeira versão funcionasse.
02 — Acompanhe a jornada no papel
Para o exemplo do voluntário, esboce uma lista de turnos, detalhes do turno e um formulário de interesse. Dê a cada tela um trabalho. Use alguns exemplos de turnos realistas, incluindo um turno completo ou uma lista vazia, para que a revisão cubra mais do que um caminho feliz e polido.
- Nomeie a tela inicial e a próxima ação.
- Liste os campos necessários para este teste.
- Inclui um estado vazio e um estado de ação com falha.
- Mantenha informações pessoais reais longe de solicitações e exemplos exploratórios.
03 — Separar uma demonstração de um serviço operacional
Decida se esta versão demonstra apenas a jornada ou deve salvar uma solicitação real. Uma demonstração pode mostrar um exemplo de confirmação claramente identificado. Um serviço operacional precisa de um destino, acesso apropriado e uma forma de recuperar a solicitação. Confirme estes requisitos antes de convidar participantes reais.
- Marque cada ação apenas de exemplo no briefing.
- Liste conexões, permissões e necessidades de publicação separadamente.
- Deixe contas, pagamentos e lembretes para depois, a menos que o primeiro teste dependa deles.
- Peça ajuda qualificada quando a tarefa envolver informações confidenciais ou acesso complexo.
04 — Analise o resultado em relação ao briefing
Use a planilha abaixo e siga o guia de solicitação do produto para transformá-la em uma solicitação de build. Após a geração, percorra a mesma jornada e observe o que aconteceu. Para o exemplo do voluntário, uma demonstração bem-sucedida pode significar que um novo visitante pode encontrar a mudança certa e entender a próxima etapa sem sua explicação.
- Peça a alguém não familiarizado com a ideia para tentar a tarefa.
- Registre etapas confusas antes de solicitar mais recursos.
- Faça uma alteração específica e repita a mesma verificação.
- Expanda o escopo somente quando a primeira jornada responder à sua pergunta original.
Um ponto de partida
Torne o briefing específico.
Adapte este exemplo ao seu negócio. Mantenha os dados de amostra separados das informações reais do cliente.
Planilha de escopo da primeira versão Pessoa que a utiliza: ___ Problema que enfrenta hoje: ___ Uma tarefa que deve concluir: ___ Páginas necessárias para essa tarefa: ___ Informações mostradas ou inseridas: ___ O que acontece após a ação principal: ___ O que permanece apenas como amostra: ___ Recursos deixados para depois: ___ A primeira versão é aprovada quando posso observar: ___
Quando você precisar da próxima etapa
Siga a documentação do produto.
Antes de começar.
Preciso escolher uma linguagem de programação primeiro?
Comece com o usuário, tarefa, informações e resultado observável. Se um sistema existente ou restrição técnica determinar o idioma ou plataforma, inclua-o no briefing e confirme com o responsável por esse sistema.
Quantos recursos uma primeira versão deve incluir?
Use o menor conjunto que permite inspecionar uma viagem completa. Não há contagem universal de recursos. Um recurso pertence à primeira versão quando a tarefa não pode ser testada de forma significativa sem ele.
Encontre seu próximo passo.
Comece com uma tarefa útil