[🛠] Operations Automation #5: Transformei um protótipo fracassado em critérios de auditoria de UI

✨ Resumo do GPT-5.6 Sol

Um registro de como transformei cartões enormes cheios de espaço vazio e uma table quebrada em critérios comuns de auditoria de UI para busca, filtros, linhas multilinha, download da view atual e classificação do risco de edição, em vez de corrigir cada tela separadamente.

Cartões grandes e espaços generosos arruinaram a tela

Eu estava redesenhando uma tela de gestão de férias para funcionários de escritório e administradores com mais de 50 anos. Os requisitos pediam texto grande, áreas de interação amplas e bastante espaço. O protótipo interpretou essas palavras da maneira mais simples e terrível possível.

Ele separou uma métrica que caberia em uma linha em três —nome do item → número grande → explicação auxiliar— e colocou tudo em um cartão enorme. Três cartões ocuparam toda a primeira tela, enquanto o trabalho que o usuário precisava resolver naquele momento foi empurrado para baixo. A tela de solicitação empilhou calendar, resumo e inputs em grandes caixas brancas separadas; a table de histórico deixou vazios os valores essenciais e manteve apenas badges de status. Ainda apareceu scroll horizontal.

Quando antes corrigi uma table e filtros esmagados em um dispositivo mobile real, achei que remover overflow e quebras ruins bastaria para melhorar a tela. Este protótipo mostrou um problema mais fundamental. Uma tela que não quebra e uma tela que pode ser usada são coisas completamente diferentes.

Os critérios de auditoria de UI estavam quebrados antes da tela

O problema maior era que essa tela tinha sobrevivido a um processo separado de auditoria.

A auditoria verificava se as routes abriam, se o texto era cortado, se os controls podiam ser acionados e se cores ou espaços estavam muito desalinhados. Mas não obrigava a responder às perguntas abaixo.

• O usuário consegue encontrar na primeira tela o trabalho que precisa resolver agora?
• Os valores necessários para a mesma decisão estão reunidos em uma única view?
• O espaço vazio explica as relações entre as informações ou apenas preenche o tamanho do component?
• Busca, filtros, ordenação, contagem total e resultados de uma table formam um único fluxo?
• É possível baixar e reutilizar exatamente o resultado consultado?
• Os valores editáveis são diferenciados do histórico que não pode ser sobrescrito?

Se um problema não aparece na auditoria, um Agent pode vê-lo e ainda aprovar a tela. Por isso, em vez de reduzir o padding tela por tela, alterei primeiro os critérios comuns para impedir que a mesma falha passasse de novo.

Collection mantém busca, resultados e download juntos

A referência que mais analisei foi a table de gestão de solicitações de outro app de férias. A ajuda oficial também trata a busca por data, o filtro de solicitações e o fluxo de aprovação ou recusa no modo de administrador web como uma única tarefa.¹ O que mais chamava atenção na imagem de referência não era a quantidade de recursos, mas a distância entre eles.

O período e o tipo de solicitação ficavam logo acima dos resultados. Os campos de busca se alinhavam com as colunas, e a quantidade total de solicitações e o download apareciam na mesma view. Valores que precisavam ser lidos juntos —datas, antes e depois da mudança, diferença de horas de trabalho— eram agrupados em várias linhas dentro da mesma cell, em vez de aumentar indefinidamente o número de colunas. O status e as actions disponíveis continuavam na mesma linha.

Generalizei essa estrutura como um contract comum de collection, em vez de copiá-la apenas para uma tela de férias.

• Tables, grids, listas densas e views em lista do calendar colocam o bloco search/filter logo acima dos resultados.
• Período e scope, busca, filtros rápidos, filtros detalhados, condições aplicadas, contagem total/atual, reset e download permanecem na mesma view.
• Valores usados na mesma decisão são agrupados em cells multilinha na ordem informação principal → informação secundária → aviso condicional.
• O conteúdo determina a altura da linha. Usar várias linhas não justifica criar mini cards de altura fixa.
• O download exporta todos os resultados correspondentes às condições atuais, não apenas as poucas linhas visíveis na page atual.
• O export preserva scope, período, busca, filtros, ordenação, horário de referência e colunas de negócio visíveis para o usuário.
• Dados pessoais e materiais de auditoria não perdem completamente o download; aplicam a mesma autorização, masking e audit.

Verificar apenas se “existe um botão de download” falharia de novo. Também é preciso comparar a contagem, linhas representativas, filtros aplicados, ordenação e masking da tela real com o arquivo baixado.

A forma de edição depende do risco dos dados

Corrigir um valor diretamente em uma table é conveniente. Mas transformar todas as cells em Excel também permite sobrescrever aprovações, livros e provas legais como se fossem inputs comuns.

Por isso, classifiquei primeiro a natureza da mudança e só depois escolhi o control de edição.

Natureza da mudança	Interaction padrão
Um valor reversível e de baixo risco	Inline edit com affordance de edição visível
Alterações seguras repetidas em várias linhas	Editable-grid mode explícito
Vários fields que exigem contexto ao redor	Side panel que preserva a posição da lista
Input ou confirmação curta e independente	Modal com um único propósito
Mudança de alto risco, data de vigência, autorização, versionada ou append-only	Workflow separado de preview-and-apply ou correction

Double-click, Enter e F2 permanecem apenas como aceleradores para usuários experientes. A entrada de edição não fica escondida exclusivamente neles. Um grid precisa de navegação por keyboard, indicação de cells alteradas, validation, undo, cancelamento total, conflitos stale, preview antes de aplicar e readback depois. Aprovação, recusa e eventos append-only do livro não são alvos de cell edit.

Separei as regras comuns de auditoria do contract do produto

Se tudo o que aprendi com a tela de referência fosse escrito como regra exclusiva de Leave Operations, o próximo project repetiria o mesmo erro. Por outro lado, se etapas de aprovação de férias, documentos de promoção e correções do livro entrassem em um Skill comum, o critério compartilhado se tornaria a especificação de um único produto.

Por isso, separei os limites.

As regras comuns e o Skill de auditoria de UI incluem estes tipos de falha:

• Transformar um scalar curto em um cartão independente enorme
• Separar mecanicamente label, valor e denominador em três linhas
• Afastar busca e filtros dos resultados
• Collection sem contagem total, reset ou download da view atual
• Table que distribui valores relacionados por colunas demais ou fixa a altura de linhas multilinha
• Export cuja autorização ou condições da view atual diferem da tela
• Edição escondida apenas atrás de hover ou double-click
• Sobrescrita de dados de alto risco, versioned ou append-only por cells ou popups comuns

A documentação de Leave Operations mapeia esses princípios separadamente para cada page e view. As tables de caixa de aprovação, funcionários, promoção, livro, conflitos de ponto, resultados de mensagens e telefone de trabalho recebem contracts de busca, filtro, ordenação e download. Ela também separa áreas que precisam de alterações repetidas, como funcionários e lotação, de aprovações e livros que não podem ser editados diretamente.

As telas ainda não foram corrigidas

Este trabalho não melhorou a UI real do produto. Alterei as regras comuns, o Skill específico de auditoria de UI e os contracts de tela de cada produto, além de preservar a imagem de referência com seu hash original. As telas desktop de Leave Operations ainda não foram implementadas segundo esses contracts, e funcionários de escritório e administradores com mais de 50 anos ainda não concluíram o trabalho por conta própria a partir da entrada normal.

Mesmo assim, o próximo protótipo não deveria ser aprovado pelos mesmos motivos. Texto grande e áreas de interação suficientemente amplas continuam sendo requisitos, mas não podem virar desculpa para inflar a tela. O objetivo não é baixa densidade de informação, e sim alta densidade de informação com baixa carga cognitiva.

Referências

1. Central de Ajuda da Shiftee, Gerenciar solicitações. A página descreve o fluxo do modo de administrador web para localizar solicitações por intervalo de datas e filtro, aprovar ou recusar cada uma e passar para a próxima. ↩