Webiio
Uma aplicação começa por um problema concreto. Antes de desenhar ecrãs ou escolher tecnologia, é preciso perceber quem a vai usar, que tarefa precisa de concluir e o que hoje torna essa tarefa difícil. Uma boa primeira definição pode poupar funcionalidades que parecem interessantes, mas não fazem falta.
Descreva uma situação real de utilização
Em vez de começar por “quero uma app de gestão”, descreva o percurso atual. Quem recebe o pedido? Onde guarda a informação? Quem precisa de aprovar? Em que momento se perde tempo ou se repete trabalho?
Por exemplo, uma equipa pode copiar pedidos de email para uma folha de cálculo e avisar o responsável por mensagem. A primeira necessidade talvez seja reunir os pedidos e mostrar o seu estado, não construir uma plataforma com dezenas de módulos.
Identifique as pessoas e as regras de acesso
Um cliente, um colaborador e um responsável podem precisar de ver informação diferente. Estas diferenças alteram os ecrãs, as permissões e a forma como o processo é acompanhado. Não devem ser deixadas para o fim.
Anote as ações de cada pessoa: criar, consultar, corrigir, aprovar ou eliminar um registo. Identifique os dados necessários a cada tarefa e evite pedir informação que não tem uma utilidade definida.
Escolha o essencial para a primeira versão
Uma primeira versão útil completa um percurso importante do princípio ao fim. Pode ter poucas funcionalidades, desde que permita resolver a tarefa com clareza. Uma lista extensa de ecrãs incompletos não substitui esse percurso.
- A tarefa principal que tem de funcionar no lançamento.
- Os dados mínimos para a executar.
- Os perfis de utilização envolvidos.
- As notificações ou confirmações necessárias.
- O que pode esperar por uma fase posterior.
Valide os ecrãs antes do desenvolvimento
Um protótipo ajuda a discutir a utilização sem depender de uma aplicação já construída. Peça às pessoas que vão usar o produto para percorrerem uma tarefa concreta. Observe onde hesitam e que informação procuram.
Este exercício não serve apenas para escolher cores. Pode mostrar que faltam estados de erro, que uma aprovação está no sítio errado ou que os nomes dos campos não correspondem à linguagem da equipa.
Combine como a aplicação vai ser entregue e acompanhada
A proposta deve identificar o âmbito, as integrações, os critérios de entrega e as responsabilidades pelas contas e pelos dados. Uma integração depende também das permissões e das interfaces disponibilizadas pelo serviço externo.
Na Webiio, a conversa inicial serve para delimitar o problema e preparar uma proposta para a primeira versão. O prazo depende das funcionalidades e da complexidade. Depois do lançamento, o feedback ajuda a decidir a evolução com base no uso real.
