Comece com um resumo
Comece com um usuário, uma tarefa e a tela em que essa tarefa começa. App Design mostra como transformar esse resumo em um plano prático de design de aplicativos antes de iniciar um fluxo de trabalho no navegador.
Um resumo inicial útil precisa de menos detalhes que uma especificação, mas de mais direcionamento que o nome de um aplicativo.
Anote o público, a ação que ele precisa concluir e as informações que o aplicativo deve mostrar. Depois, escolha uma abordagem inicial adequada ao trabalho.
Você precisa explicar um conceito de agendamento sem criar todas as telas de configurações e de conta.
Esboce primeiro os estados de busca, seleção e confirmação; avalie um software de design de aplicativos quando o conceito precisar de um conjunto mais completo de telas.
Você quer um fluxo de inscrição em eventos que as pessoas entendam de imediato.
Liste os campos obrigatórios e a mensagem de sucesso; avalie modelos gratuitos de design de aplicativos para dispositivos móveis para encontrar um layout inicial adequado.
Uma solicitação de recurso diz que os usuários devem salvar itens, mas nunca descreve o que acontece depois.
Mapeie os estados salvo e não salvo antes de escolher um software de design de aplicativos para um trabalho de produto mais detalhado.
Você tem uma ideia de aplicativo móvel para acompanhar hábitos e precisa de uma primeira tela com foco claro.
Defina os estados de registro diário e de dia perdido; use modelos gratuitos de design de aplicativos móveis como referência de layout, não como substitutos para as decisões.
Veja um exemplo concreto de design de aplicativos para uma ideia de agendamento de consultas, desde uma solicitação inicial até um plano de telas que você pode revisar.
Escreva: um paciente precisa encontrar um horário disponível para uma consulta e saber que ele foi reservado. Registre as informações mínimas necessárias: serviço, data, horário e uma forma de confirmar a escolha. Deixe as funcionalidades administrativas fora desta primeira etapa.
Esboce uma tela de seleção de serviço, uma tela de horários disponíveis e uma tela de confirmação. Para cada uma, indique a ação principal e o que o usuário deve ver em seguida. Na tela de horários disponíveis, considere o caso de uma data sem horários livres.
Revise o caminho da seleção até a confirmação. Pergunte se o horário escolhido continua claro, se há uma explicação para um horário indisponível e se a confirmação identifica a consulta. Revise a descrição antes de refinar os detalhes visuais.
Uma ferramenta gratuita de design de aplicativos é um ponto de partida para tomar decisões, não uma prova de que uma interface funciona em produção.
Um layout plausível não comprova que usuários reais encontrarão a próxima ação ou entenderão os rótulos.
O que fazer em vez disso
Mostre o fluxo proposto a alguém que não conheça a ideia e peça que explique em que tocaria.
Botões, dados de disponibilidade, validação e mensagens de confirmação ainda exigem decisões de produto e engenharia.
O que fazer em vez disso
Anote cada estado importante com o evento que o aciona, os dados necessários e a resposta esperada.
Não presuma que todas as ferramentas usadas no navegador incluem os mesmos recursos ou permitem qualquer tipo de exportação sem condições.
O que fazer em vez disso
Confira os termos atuais de acesso e exportação do destino antes de depender de um fluxo de trabalho específico.
Neste exemplo de agendamento, compare duas maneiras de começar o trabalho de design de aplicativos. Estas são abordagens de planejamento, não afirmações sobre os recursos do destino vinculado.
| Abordagem a partir de uma tela em branco | Abordagem baseada em modelo | |
|---|---|---|
| Melhor ponto de partida | Uma tarefa do usuário e uma lista curta de informações necessárias | Um padrão de tela relevante e a mesma descrição da tarefa |
| Primeira decisão | Escolher a sequência de telas | Decidir quais partes do padrão se encaixam na tarefa |
| Exemplo de agendamento | Organizar serviço, data e horário em uma ordem planejada | Verificar se um layout de exemplo para agendamento segue essa ordem |
| Principal vantagem | Liberdade para estruturar um fluxo pouco familiar | Um layout visível para avaliar e adaptar |
| Principal risco | Gastar tempo demais organizando elementos básicos | Manter campos ou etapas de que os usuários não precisam |
| Próxima revisão | Testar se cada tela apresenta uma próxima ação clara | Teste se o padrão adaptado ainda atende aos requisitos |
Um layout refinado não serve como plano de design de aplicativos quando esconde resultados vazios, entradas inválidas ou o que acontece após um toque. Leve seus requisitos para o fluxo de trabalho no navegador e, depois, avalie a direção resultante à luz dos estados e das decisões listados acima.
Prepare uma frase que descreva a quem o aplicativo se destina e o que essas pessoas precisam realizar. Acrescente as informações que a primeira tela deve mostrar e uma situação em que a tarefa pode falhar. Isso oferece mais elementos para trabalhar do que apenas um pedido de estilo visual.
O fluxo de trabalho desta página serve para planejar telas e decisões, não para prometer um aplicativo funcional. Dados, interações, testes e implementação continuam sendo trabalhos à parte.
Use uma tela em branco quando a tarefa ou a sequência for incomum e você precisar definir sua estrutura. Use um modelo quando o padrão dele corresponder bem à sua tarefa, mas remova os campos ou as etapas que não se aplicarem.
Acompanhe a tarefa do usuário desde o ponto de entrada até o resultado e identifique a ação em cada tela. Verifique pelo menos um estado vazio, de erro ou de indisponibilidade antes de considerar o plano pronto para receber comentários.