Comece pelo problema observável

“Precisamos de um sistema” é um ponto de partida, mas ainda não explica o trabalho que o produto deve tornar possível. O pedido pode esconder uma demora na aprovação, informação espalhada por planilhas, dificuldade para acompanhar um estado ou uma tarefa que depende da memória de uma pessoa. Cada situação pode pedir uma solução diferente. Antes de desenhar páginas, escreva uma frase sobre o que hoje não funciona e para quem isso tem consequência.

Uma boa formulação identifica uma situação concreta. Por exemplo: “Quando uma solicitação muda de equipe, ninguém sabe quem deve agir a seguir.” A frase não escolhe uma plataforma nem presume que a resposta é uma nova interface. Ela oferece uma tarefa para investigar: transferência de responsabilidade, estado e comunicação. Ao observar o processo, talvez apareça uma regra ausente, uma fonte de dados duplicada ou uma decisão que ninguém assumiu.

Registre o que foi visto e o que é hipótese. Uma pessoa pode dizer que um painel resolveria o problema, mas o que foi observado pode ser uma atualização que não chega ao destino. Ambas as informações importam; têm graus diferentes de evidência. Separá-las impede que uma preferência inicial se torne requisito incontestável.

O problema deve ter um limite. “Melhorar a operação” é amplo demais para orientar um primeiro ciclo. “Permitir que responsáveis encontrem solicitações sem dono em menos passos” já delimita público e tarefa, embora ainda precise de validação. O limite não precisa ser perfeito: serve para decidir o que investigar primeiro e o que fica fora do escopo inicial.

Pergunte também o que aconteceria se nada fosse construído. Se uma mudança de processo ou uma instrução clara resolver a tarefa, talvez um sistema novo seja desnecessário. A melhor decisão de produto pode ser menor do que a solução inicialmente imaginada.

Desenhe pessoas, tarefas e estados

Liste os papéis que participam do trabalho sem inventar perfis genéricos. Quem inicia a tarefa? Quem a recebe? Quem pode corrigir, aprovar, cancelar ou apenas consultar? O mesmo indivíduo pode exercer mais de um papel em momentos diferentes. Um mapa simples com responsabilidades costuma revelar dependências que uma lista de telas não mostra.

Descreva o caminho principal em verbos: criar, rever, decidir, comunicar, encerrar. Depois acrescente as exceções. O que acontece quando falta informação? Quando alguém está ausente? Quando um pedido é duplicado? Quando o estado muda depois de aprovado? O caminho “feliz” é útil, mas é nas exceções que muitas ferramentas deixam as pessoas sem uma próxima ação clara.

Para cada etapa, anote o que a pessoa precisa saber e o que o sistema precisa guardar. Se uma decisão depende de informação externa, marque essa dependência. Uma interface não pode tornar confiável um dado cuja origem ou atualização não foram definidas. Se o dado vier de outra ferramenta, a disciplina de integrações ajuda a organizar o contrato entre as partes.

Não transforme todo desejo de visibilidade em notificação. Pergunte quem precisa ser interrompido e quem pode consultar um estado quando desejar. Alertas demais criam ruído; alertas de menos escondem bloqueios. O desenho do fluxo deve permitir que uma pessoa entenda o estado atual, o motivo e a próxima ação sem depender de uma conversa paralela.

É útil observar como a tarefa ocorre hoje, mesmo que pareça improvisada. Atalhos, anotações e planilhas podem carregar regras importantes. Copiar esses passos literalmente para o software talvez perpetue o problema, mas ignorá-los pode eliminar informações de que as pessoas dependem. O trabalho de descoberta é distinguir adaptação necessária de hábito que pode ser simplificado.

Defina os dados antes dos componentes

Para cada informação importante, responda: quem cria, quem valida, quem atualiza e quando deixa de ser válida? Se o mesmo campo existe em vários lugares, escolha qual fonte deverá prevalecer ou descreva como o conflito será resolvido. Um desenho de dados não precisa começar como um esquema técnico completo; pode ser uma tabela de entidades, relações e responsabilidades escrita em linguagem comum.

Permissões merecem o mesmo cuidado. “Todos podem editar” é simples de implementar e difícil de corrigir quando uma mudança afeta decisões relevantes. “Ninguém pode editar” pode tornar a operação impossível. Escreva uma matriz por papel e ação: visualizar, criar, alterar, aprovar, exportar e apagar. Acrescente a razão das restrições. Assim as regras podem ser questionadas e revistas.

Pense no ciclo de vida dos dados. Uma solicitação aberta, concluída ou cancelada pode ter regras diferentes. Informações pessoais podem exigir tratamento específico; o desenho deve evitar coletar dados que não são necessários para a tarefa. Antes de escolher uma solução técnica para segurança ou conformidade, identifique os tipos de informação envolvidos e consulte profissionais responsáveis pelo contexto aplicável.

Também é preciso decidir como perceber e recuperar falhas. Se um envio for repetido, surgirá um duplicado? Se a conexão cair, a pessoa pode continuar? Se uma integração demorar, a interface mostra que o estado ainda é incerto? Essas perguntas influenciam tanto a arquitetura quanto a experiência de uso. Um protótipo pode representar esses estados antes de existir a infraestrutura completa.

Escolha o primeiro recorte verificável

Com problema, tarefas e dados mapeados, selecione um percurso completo para o primeiro ciclo. “Completo” significa que a pessoa consegue iniciar, acompanhar e concluir uma tarefa real, ainda que o sistema tenha poucas funções. Uma coleção de telas parcialmente conectadas pode impressionar numa demonstração e falhar na operação diária.

Defina o que permitirá julgar esse percurso. Pode ser uma sessão de observação com pessoas familiarizadas com a tarefa, uma revisão dos estados de erro, uma análise de qualidade dos dados ou uma combinação. Não prometa uma melhoria numérica antes de estabelecer como ela seria medida. O critério serve para aprender, não para justificar a escolha anterior.

Só então compare opções técnicas. Uma plataforma pronta pode cobrir uma tarefa comum; uma implementação personalizada pode ser necessária quando regras, fluxos ou integrações são particulares. Em ambos os casos, documente custos de manutenção, dependências e possibilidades de mudança. A tecnologia deve responder às decisões descritas, não determinar silenciosamente o problema que a equipe aceita resolver.

Um registro curto de decisões torna o processo mais transparente: pergunta, opções, evidência, escolha provisória, risco e data de revisão. Quando a realidade mudar, a equipe poderá saber por que seguiu determinado caminho. Sem esse registro, uma hipótese temporária tende a parecer uma verdade permanente.

Antes de iniciar a implementação, reúna algumas situações de verificação em linguagem simples. Uma pessoa sem permissão tenta alterar um pedido; outra precisa continuar uma tarefa interrompida; um dado chega duplicado; uma aprovação é desfeita. Para cada situação, escreva o comportamento esperado e a dúvida que ainda existe. Esse conjunto não é uma especificação definitiva, mas permite testar se a proposta cobre o trabalho real em vez de apenas a apresentação visual.

Inclua quem terá de manter o sistema depois da primeira entrega. Uma solução fácil de demonstrar pode ser difícil de corrigir se ninguém souber como atualizar regras, conteúdos ou conexões. Pergunte quais decisões precisam ser documentadas, quais alertas exigem atenção e quem poderá observar uma falha. A manutenção não é uma etapa distante: ela influencia o recorte inicial, o desenho dos dados e a escolha da tecnologia.

Este roteiro não substitui pesquisa com as pessoas envolvidas nem revisão técnica do contexto real. Ele organiza o começo. Se a principal incerteza estiver na sequência da tarefa e na clareza da interface, continue em UX/UI design. Se o desafio envolver um produto já utilizado, leia redesign de produtos. O método reúne estas decisões num ciclo de descoberta, modelagem, construção e revisão.