DS Razac
Figma
PRJ-FIELD-MAP

Mapeamento UX — variações de campos

O DS Razac precisa de uma fonte única de verdade sobre QUAIS tipos de campo existem no portal real (text, select, multiselect, date, autocomplete, etc), ONDE estão (em que telas) e COMO se comportam (validação, máscaras, hover, focus, erro). Sem esse mapa, cada PRJ inventa novamente.

TributárioPlanejamentoAlta26 de mai. de 2026
Mapa do site Portal Real (DS)
Em resumo
VD
Victor Dias
Design Lead
Área
Tributário
Squad
Razac Team
PlanningPrioridade altaSquad · Razac Team

Catálogo único de todas as variações de campo usadas no portal real (text, select, multiselect, date, autocomplete, switch, radio, checkbox, file upload, currency, etc). Pra cada tipo: onde aparece, como se comporta (hover/focus/error/disabled), com que validação. Base do futuro componente <Field> unificado.

Contexto

Cada tela do portal hoje implementa seus próprios campos. Pequenas variações de padding, fonte, cor de borda e label aparecem entre telas vizinhas — mesmo quando a função é idêntica. Sem um inventário, designers inventam variações e devs implementam de novo do zero a cada PRJ.

A DS v1.2.0 começou a quebrar isso documentando o MatField (Material outlined Angular). Este projeto é o passo natural seguinte: ir tela por tela mapeando CADA campo encontrado.

Problema

  • Inputs com paddings diferentes (p-2, p-3, py-2 px-3) pra mesma função
  • Selects estilizados de 4-5 jeitos diferentes (chip Google, dropdown nativo, popover custom, Material…)
  • Labels às vezes flutuantes, às vezes inline acima, às vezes placeholder-só
  • Validação com cores diferentes (border-red-500 vs text-red-600 inline vs ambos)
  • Hover states implementados em algumas telas e ignorados em outras

Hipótese

Se mapearmos cada campo do portal real numa tabela mestre — { tipo, label, placeholder, comportamento, telas } — e consolidarmos no DS, conseguimos:

  1. Cortar ~40% do tempo de design de novas telas (decisões prontas)
  2. Cortar retrabalho dev (um único <Field type="…" /> cobre tudo)
  3. Fonte única de verdade pra QA: "esse hover está certo? Confere com /design-system/portal-real/campos"

Solução proposta

Sprint de inspeção

Pra cada tela do /portal-map, abrir no portal real via dev-browser + capturar:

  • Tipos de campo presentes (mat-form-field, custom selects, native inputs)
  • Variantes encontradas (com label/sem label, com placeholder/sem, com clear/sem)
  • Estados (default, hover, focus, error, disabled, loading)
  • Comportamento de overflow (truncate? wrap? scroll?)
  • Validação (sync vs async, mensagem inline vs tooltip)

Catálogo final

Saída: página /design-system/portal-real/campos com:

  • Anatomia de cada tipo
  • Tabela de telas que usam (com link clicável)
  • Spec técnica (Tailwind classes, paddings exatos, transições)
  • Variantes do mesmo tipo justificadas (quando é OK ter 2 estilos diferentes)
  • Recomendação consolidada: "use isso, evite aquilo"

Próximas evoluções

  • Componente unificado <Field type='text|select|multiselect|date|currency|file' /> em components/ds/Field/
  • Codemod pra trocar instâncias antigas pelas novas
  • Linter rule pra bloquear <input> cru fora do <Field>

Outcomes

A medir. Sprint começa em 27/05/2026.

Telas-alvo da inspeção (primeira leva)

| Tela | Inputs principais a inspecionar | |---|---| | Clientes | Pesquisa, filtros, formulário de cadastro | | Fornecedores | Mesmos da Clientes + autocomplete de país | | Fichas Operacionais | Form longo com mix de tipos | | Lead Time | Date pickers, currency, ranges | | Kanban | Já mapeado (MatField outlined) ✓ | | Análise Tributária Detalhada | Selects encadeados, alíquotas, modais | | Workspace (qualquer) | Cards com campos inline editáveis | | Detalhe Processo | 8 abas com tipos diferentes |