Design de painel interno: telas que a equipe entende de primeira

O resumo direto

Design de painel interno é o layout de sistema web que a própria equipe usa todo dia (pedidos, estoque, atendimento, financeiro), pensado para a tarefa repetida e não para impressionar na primeira visita. A diferença para um site ou uma loja é que o usuário não escolhe estar ali: ele precisa usar o painel para trabalhar, muitas vezes por dia. Por isso, o que conta é achar o registro rápido, preencher sem erro, ver o estado de cada coisa sem adivinhar e saber o que fazer agora. Quatro telas concentram quase todo esse trabalho: a tabela, o formulário, a tela de detalhe com status e a tela inicial. Abaixo, o que cada uma precisa ter, com base na pesquisa da Nielsen Norman Group e nas regras de acessibilidade do W3C, e como conferir tudo com a equipe antes de virar código.

1. Design de painel interno não é design de site

Um site precisa convencer quem chega pela primeira vez. Um painel interno precisa servir quem volta todo dia. Isso muda as prioridades do design.

• Velocidade de uso pesa mais que beleza. Um clique a mais numa tarefa repetida o dia inteiro vira muito tempo perdido no fim do mês.
• Densidade é aceitável. A equipe aprende onde as coisas ficam. Uma tabela com mais colunas pode ser melhor que três telas separadas.
• Consistência vale mais que novidade. Se o botão de salvar muda de lugar entre telas, a pessoa erra.
• O erro custa caro. Pedido com endereço errado, estoque baixado duas vezes, desconto aplicado no cliente errado. O design precisa ajudar a evitar, não só avisar depois.

Se você ainda está decidindo se precisa de um painel, o artigo sobre quando substituir a planilha por um sistema trata dessa decisão. Aqui, o ponto de partida é que o painel vai existir, e a pergunta é como desenhar as telas. A página de sistemas e painéis sob medida mostra como esse trabalho de design entra no projeto inteiro.

2. Comece pelas tarefas, não pelas telas

O erro mais comum é começar desenhando "a tela de pedidos" sem saber o que a pessoa faz nela. Antes de abrir o Figma, eu faço uma lista curta com quem vai usar e o que essa pessoa precisa resolver.

Um exemplo de lista para um painel de pedidos:

1. Atendimento: achar o pedido de um cliente que ligou, ver o status e responder.
2. Expedição: ver os pedidos pagos de hoje, separar, marcar como enviados em lote.
3. Financeiro: conferir pagamentos que não bateram e marcar como resolvidos.
4. Gestor: ver o que está atrasado e quem está com o quê.

Cada linha dessa lista vira uma decisão de tela. O atendimento precisa de busca boa. A expedição precisa de filtro salvo e ação em lote. O financeiro precisa de comparação. O gestor precisa de uma tela inicial com o que está fora do normal. Sem a lista, o painel vira um espelho do banco de dados: todas as colunas, todos os campos, nenhuma prioridade.

Uma tela, um trabalho principal

Cada tela deveria ter um trabalho principal, e esse trabalho deveria estar visível sem rolar. Ações secundárias podem ficar num menu. A heurística de design minimalista da Nielsen Norman Group diz que a interface não deve ter informação irrelevante ou que quase ninguém usa. Num painel, isso quer dizer: o que a pessoa usa toda hora fica à vista; o que usa uma vez por mês fica a um clique.

3. A tabela: a tela onde a equipe passa o dia

Na maioria dos painéis, a tela mais usada é uma lista em forma de tabela. A Nielsen Norman Group organiza o uso de tabelas de dados em quatro tarefas: encontrar registros por algum critério, comparar dados, ver, editar ou adicionar uma linha e agir sobre registros. Uma tabela bem desenhada facilita as quatro.

Encontrar

• Primeira coluna com algo que a pessoa reconhece. A recomendação da Nielsen Norman Group é um identificador legível, não um código gerado pelo sistema. Nome do cliente ou número do pedido que aparece no e-mail, não um ID interno de banco de dados.
• Colunas na ordem de importância para quem usa, não na ordem em que os campos foram criados.
• Busca que aceita o que a pessoa tem na mão: nome, telefone, número do pedido, CPF parcial. Uma busca que só funciona com o código exato não ajuda o atendimento.
• Filtros salvos para as visões do dia. "Pagos e não enviados", "atrasados", "meus". A expedição não deveria montar o mesmo filtro toda manhã.

Comparar

• Cabeçalho fixo quando a tabela é longa, para a pessoa não perder qual coluna é qual ao rolar. A Nielsen Norman Group recomenda congelar cabeçalho de linha e de coluna em tabelas grandes.
• Ajuda visual para seguir a linha: borda leve, linhas alternadas ou destaque ao passar o mouse.
• Números alinhados à direita e com a mesma quantidade de casas, para que valores possam ser comparados de olho.
• Esconder e reordenar colunas com pouco esforço, quando perfis diferentes usam a mesma tabela.

Ver e editar

Abrir o registro numa janela que cobre a tabela inteira obriga a pessoa a fechar, voltar e abrir o próximo. A Nielsen Norman Group sugere considerar um painel lateral não modal, que mostra o detalhe sem esconder a lista. Para quem confere vários registros seguidos, isso economiza muito vaivém.

Agir

Quando a mesma ação se repete em vários registros (marcar como enviado, atribuir a alguém, exportar), use caixas de seleção e ações em lote, com um atalho para selecionar todos os que estão no filtro. Sem isso, a pessoa repete a mesma ação linha por linha.

4. O formulário: rótulo visível e erro perto do campo

Formulário é onde o dado errado entra no sistema. O design do formulário é a primeira linha de defesa, antes da validação do banco.

Rótulos e instruções

O critério 3.3.2 da WCAG, do W3C, pede rótulo ou instrução sempre que a pessoa precisa preencher algo, inclusive o formato quando o campo tem regra própria. Na prática:

• Rótulo visível acima ou ao lado do campo, sempre. Texto de exemplo dentro do campo (o placeholder) some quando a pessoa começa a digitar e não substitui o rótulo.
• Formato explicado antes do erro, não depois. "Data no formato dia/mês/ano" embaixo do campo evita a mensagem de erro.
• Campos obrigatórios marcados com texto ou símbolo, não só com cor.
• Agrupamento por assunto: dados do cliente, endereço, pagamento. Formulário longo sem grupos parece maior do que é.

Prevenir antes de avisar

A heurística de prevenção de erro da Nielsen Norman Group lembra que boas mensagens de erro importam, mas que um design cuidadoso evita que o problema aconteça. Em painel interno, isso quer dizer: lista de opções em vez de texto livre quando as opções são conhecidas, campo que já vem preenchido com o valor mais comum, botão de salvar que só fica ativo quando o mínimo foi preenchido, e confirmação clara antes de ações que não têm volta.

Mensagem de erro que ajuda

As diretrizes de mensagem de erro da Nielsen Norman Group pedem:

• mensagem perto do campo que tem o problema, não só no topo da tela;
• linguagem humana, sem código de erro do sistema;
• descrição precisa do problema e o que fazer para corrigir;
• tom neutro, sem culpar quem digitou;
• preservar o que a pessoa já digitou, para ela corrigir e não recomeçar.

Fluxos longos: uma coisa de cada vez

Para cadastros longos que a equipe faz raramente (abrir um fornecedor novo, configurar um produto complexo), vale dividir em etapas. O sistema de design do governo britânico recomenda uma pergunta por página porque isso ajuda a pessoa a entender o que está sendo pedido e a focar naquela resposta. Para a tarefa repetida do dia a dia, um formulário único e bem agrupado costuma ser mais rápido.

5. Status e cor: nunca só cor

Painel interno vive de status: pago, pendente, enviado, atrasado, cancelado. É comum representar isso só com uma bolinha verde, amarela ou vermelha. Funciona para quem enxerga bem as cores e lembra a legenda. Falha para todo o resto.

O critério 1.4.1 da WCAG diz que a cor não pode ser o único meio visual de transmitir informação. O próprio W3C usa como exemplo pintar de vermelho só o campo obrigatório. Para status, a regra prática é:

• Etiqueta com texto ("Atrasado", "Pago"), com a cor como reforço.
• Ícone diferente por estado quando o espaço é curto.
• Contraste suficiente no texto da etiqueta. O critério 1.4.3 pede 4.5:1 para texto normal. Etiqueta com texto branco sobre amarelo quase nunca passa.
• Poucos estados. Se existem cores demais de status, ninguém lembra o que é cada uma. Agrupe ou use texto.

A heurística de reconhecer em vez de lembrar vai no mesmo sentido: deixar visível o que a pessoa pode fazer, em vez de obrigar ela a decorar. Legenda de cor que a pessoa precisa memorizar é o contrário disso.

6. O sistema precisa responder: carregando, salvo, erro

A primeira heurística da Nielsen Norman Group é a visibilidade do estado do sistema: a pessoa precisa saber o que está acontecendo. Em painel interno, a falta disso aparece como clique repetido no botão de salvar, registro duplicado e a pergunta "salvou ou não salvou?".

Jakob Nielsen descreve três limites de tempo de resposta que ajudam a decidir o que mostrar:

• Até 0,1 segundo, a resposta parece instantânea. Basta mostrar o resultado.
• Até 1 segundo, a pessoa percebe a espera, mas não perde o fio do pensamento.
• Por volta de 10 segundos, é o limite para manter a atenção. Acima disso, a recomendação é um indicador de progresso.

Na prática do design:

• Botão que muda de estado ao ser clicado ("Salvando...") e fica desativado até terminar, para evitar clique duplo.
• Confirmação visível depois de salvar, perto de onde a pessoa estava, e que não some antes de ela ler.
• Barra de progresso para importação, exportação e ações em lote que demoram.
• Tela vazia que explica: "Nenhum pedido atrasado hoje" é diferente de uma tabela em branco que pode ser erro de carregamento.

7. A tela inicial: o que fazer agora

Muitos painéis abrem num dashboard empresarial cheio de gráficos que ninguém olha depois da primeira semana. Para quem usa o painel para trabalhar, a primeira tela deveria responder uma pergunta: o que precisa da minha atenção agora?

• Fila de trabalho antes de gráfico. "pedidos pagos para separar", "pagamentos não conferidos", cada um com a contagem do dia, com link direto para a lista filtrada.
• Exceções em destaque. Atrasado, travado, com erro. O que está normal não precisa gritar.
• Tela inicial por perfil, quando os perfis são muito diferentes. O gestor e a expedição não precisam ver a mesma coisa.
• Gráfico só quando ajuda a decidir. Se ninguém muda o que faz por causa de um gráfico, ele ocupa o espaço de algo útil.

Isso é a heurística de design minimalista aplicada à tela que todo mundo vê primeiro: informação irrelevante ou rara compete com a relevante.

8. Conferir com quem vai usar, antes do código

O design de painel interno tem uma vantagem rara: os usuários estão ao alcance. Eles trabalham na empresa. Isso permite conferir as telas antes de qualquer linha de código.

O roteiro que eu uso é simples:

1. Protótipo clicável das tarefas da lista da seção 2, com dados parecidos com os reais.
2. Uma pessoa de cada perfil faz a tarefa dela no protótipo, falando em voz alta o que está pensando. Quem desenhou só observa e anota onde a pessoa hesita.
3. Ajuste e repita com a próxima pessoa.
4. Confira os critérios técnicos da tabela abaixo antes de passar para o desenvolvimento.

O alvo de 24 x 24 pixels CSS do critério 2.5.8 da WCAG 2.2 é o mínimo. Em painel usado com mouse o dia inteiro, ícones de ação muito pequenos e colados um no outro são causa comum de clique errado, como "excluir" no lugar de "editar". Espaço entre ações destrutivas e as outras é parte do design.

Se a dúvida agora é orçamento, o artigo sobre quanto custa desenvolver um sistema web sob medida mostra o que pesa no preço de um projeto como esse.

Perguntas frequentes

Qual a diferença entre design de painel interno e design de site?

O site precisa convencer quem chega pela primeira vez. O painel interno precisa servir quem usa todo dia para trabalhar. Por isso, no painel, velocidade na tarefa repetida, consistência entre telas e prevenção de erro pesam mais que impacto visual.

Preciso de designer para um painel interno ou o desenvolvedor resolve?

Depende do tamanho e de quantas pessoas vão usar. O desenvolvedor resolve bem a estrutura; o design entra para organizar as tarefas, a ordem das informações, os estados e as mensagens. Num painel usado por várias pessoas o dia inteiro, um protótipo conferido com a equipe antes do código costuma evitar retrabalho.

Tabela ou cards para listar registros no painel?

Para comparar e agir sobre muitos registros, tabela costuma funcionar melhor: dá para ordenar, filtrar e selecionar em lote. Cards fazem sentido quando cada item tem imagem ou poucas informações e é visto um de cada vez, ou em tela pequena.

Como mostrar status sem depender de cor?

Use etiqueta com texto ("Pago", "Atrasado") e deixe a cor como reforço. O critério 1.4.1 da WCAG diz que a cor não pode ser o único meio de transmitir informação. Ícones diferentes por estado também ajudam quando o espaço é curto.

O painel interno precisa funcionar no celular?

Depende de quem usa e onde. Se a expedição confere pedidos no galpão pelo celular, essa tarefa precisa funcionar bem em tela pequena. As tarefas feitas só no computador podem priorizar a tela grande. A lista de tarefas da seção 2 responde isso para cada perfil.

Conclusão

Painel interno bom é o que a equipe usa sem pensar: acha o registro rápido, preenche sem erro, vê o estado de cada coisa e sabe o que fazer ao abrir. Isso vem de desenhar a partir das tarefas reais, com tabela, formulário, status e tela inicial pensados para o uso repetido, e de conferir tudo com quem vai usar antes do código. Se a sua equipe roda um processo numa planilha ou num sistema que ninguém gosta de usar, veja como funcionam os sistemas e painéis sob medida e descreve em oailton.dev/contato o processo, quem usa e o que mais dá errado hoje.