Painel de leitura da documentação, planejamento e implementação por feature, com seleção centralizada antes da navegação.
stepsCompleted:
Author: Thiago Date: 2026-04-09
O objetivo de UX da chronos-titulos nao e criar uma nova experiencia, e sim tornar o dashboard_cobrador.php confiavel para operacao de uma carteira consolidada. O cobrador deve continuar usando os mesmos grids, botoes e filtros que ja conhece, mas agora vendo tambem os titulos da Travessia com identificacao clara de origem e sem ambiguidade sobre o fluxo em que cada linha se encontra.
A proposta visual correta, portanto, e evolutiva. A feature deve preservar o modelo mental atual do cobrador e introduzir apenas os sinais minimos necessarios para responder tres perguntas que hoje ficam obscuras: de qual empresa vem o titulo, qual proposta deve ser reconhecida pelo operador e por que aquele item esta naquele grid. O UX precisa reduzir duvida operacional, nao adicionar camadas visuais desnecessarias.
O usuario primario e o cobrador, que trabalha diariamente no dashboard_cobrador.php com foco em velocidade de leitura, triagem e acao operacional. Esse usuario nao quer aprender uma interface nova; ele quer bater o olho no grid e entender rapidamente cliente, proposta, atraso/pagamento, origem do titulo e proximo passo. O custo de um UX ruim aqui e alto porque a tela e usada repetidamente durante a rotina de cobranca.
O usuario secundario e a gerencia, especialmente na leitura de recebimentos 30 dias e coerencia dos indicadores. Para esse perfil, o ponto principal nao e interacao detalhada em cada linha, e sim confianca de que a carteira consolidada continua legivel e numericamente coerente.
Travessia/Bralar nos grids sem poluir a leitura atual nem aumentar confusao visual.contractNumber + numberDescription.quebras, que ja concentra sinais visuais como status de trabalho, 30 dias e Advogado.30 dias intuitivo para linhas Travessia, sem criar excecao visual desnecessaria.proposta_exibicao que torne a linha Travessia imediatamente reconhecivel pelo cobrador.O centro da experiencia desta feature nao e navegar, configurar ou explorar uma nova interface. O centro e bater o olho no dashboard e confiar no que esta sendo mostrado. O cobrador abre o dashboard_cobrador.php, aplica os filtros normais e percorre os grids para entender rapidamente quais titulos exigem acao, quais ja foram recebidos e em qual etapa operacional cada item se encontra. A integracao com a Chronos precisa encaixar exatamente nesse loop, sem exigir reinterpretacao da tela.
A acao mais frequente, portanto, e ler e decidir. Em quebras, o usuario precisa localizar titulos em aberto vencidos e decidir se registra 30 dias ou segue outra tratativa. Em 30 dias e renegociacoes, ele precisa validar que o titulo pago esta no grid correto e reconhecer se a origem e Bralar ou Travessia. Se essa leitura estiver clara e imediata, o restante do fluxo continua natural. Se essa leitura falhar, a feature perde valor mesmo que os dados estejam tecnicamente corretos.
A interacao absolutamente critica a acertar e a confianca da linha individual. Cada linha precisa responder sem esforco as perguntas: quem e o cliente, qual e a proposta/titulo, de qual empresa vem, por que esta neste grid e qual acao ainda faz sentido. O UX nao deve criar uma nova camada de interpretacao; deve apenas tornar explicito o que hoje estaria invisivel para os titulos da Travessia.
A plataforma continua sendo uma aplicacao web interna, desktop-first, com uso predominante de mouse e teclado em ambiente operacional. O contexto de uso nao pede gestos, experiencia mobile-first ou comportamento offline. O que importa e preservar legibilidade em monitores corporativos, navegacao rapida entre filtros e resposta visual consistente nos grids existentes.
Como a feature entra em uma tela ja produtiva e conhecida, a estrategia correta e evolutiva. Os componentes existentes devem continuar estruturando a experiencia: cards no topo, grids abaixo, acoes inline e filtros ja conhecidos. A insercao de Travessia/Bralar nao deve deslocar os sinais atuais que o cobrador ja usa, como status do item, marcacao de 30 dias, informacao de Advogado e campos financeiros. Qualquer ajuste de layout precisa respeitar a hierarquia atual da tabela.
Tambem faz parte da estrategia de plataforma tratar degradacao de forma silenciosa e segura. Se a Chronos estiver indisponivel, a tela nao pode parecer quebrada. O dashboard deve continuar utilizavel com os dados atuais da Bralar e, se houver indicacao de degradacao, ela deve ser discreta, textual e operacional, sem bloquear a leitura nem gerar alarme desproporcional.
As interacoes que devem ser completamente naturais sao as que dependem de leitura de linha e decisao imediata. O usuario nao pode precisar abrir detalhe ou fazer correlacao mental externa para descobrir a origem de um titulo. A marcacao Travessia ou Bralar deve estar visivel diretamente no grid, em posicao consistente, com tratamento compacto. A decisao de origem precisa acontecer em menos de um segundo de leitura.
A segunda interacao que deve ser sem atrito e o reconhecimento da proposta exibida. Para linhas da Travessia, o sistema deve montar uma proposta_exibicao reconhecivel a partir dos dados da Chronos, mantendo o padrao visual que faca sentido para o operador. O usuario nao deve ter que entender contractNumber, creditId ou qualquer conceito tecnico da API. Ele deve enxergar uma proposta operacionalmente identificavel.
A terceira interacao essencial e o fluxo de registrar 30 dias. Para o cobrador, a origem do titulo nao pode criar uma excecao operacional. Se a linha estiver no grid de quebras e for elegivel para registro, o botao e o comportamento devem permanecer equivalentes aos atuais. O que muda e apenas o backend e a rastreabilidade. No UX, a acao precisa continuar reconhecivel e confiavel.
Outra area que precisa ser effortless e a comparacao entre linhas de origens diferentes no mesmo grid. O usuario deve conseguir percorrer uma lista mista de Bralar e Travessia sem alterar estrategia de leitura. Isso exige consistencia visual: mesma ordem logica das colunas, mesmo padrao de dados financeiros, mesmo tratamento de datas e o mesmo estilo de acoes. A origem deve diferenciar a linha, mas nao transformar a linha em outra experiencia.
O primeiro momento critico de sucesso acontece quando o cobrador abre o grid de quebras e encontra um cliente da Travessia que antes nao aparecia no sistema. Se ele entender imediatamente que aquele item e valido, porque esta ali e o que fazer com ele, a feature demonstra valor real.
O segundo momento critico ocorre quando o usuario registra 30 dias em uma linha da Travessia e depois consegue reencontrar esse cliente refletido corretamente no fluxo seguinte. Essa continuidade operacional e a prova de que a integracao nao so exibiu dados novos, mas respeitou o processo ja consolidado.
O terceiro momento critico esta na leitura de renegociacoes e 30 dias. O usuario precisa confiar que o titulo Chronos entrou no grid certo e nao esta duplicado em outro lugar. Se o sistema falhar nesse ponto, a percepcao do usuario sera de carteira inconsistente, mesmo com totalizadores corretos.
O momento em que o usuario percebe que isso esta melhor nao vem de animacao ou novidade visual. Vem de duas sensacoes objetivas: agora eu vejo o que faltava e nao precisei reaprender a tela para isso. O make-or-break da experiencia e exatamente esse equilibrio entre ampliar cobertura da carteira e preservar a memoria operacional do cobrador.
Preservar memoria operacional: a tela deve continuar familiar para quem ja trabalha no dashboard todos os dias.Explicitar a origem sem poluir: Travessia/Bralar precisa ser visivel e consistente, mas sem competir com os dados financeiros e de cobranca.Uma linha, uma leitura, uma decisao: cada registro deve explicar rapidamente origem, proposta, contexto operacional e acao possivel.Mesma experiencia, fontes diferentes: Bralar e Travessia podem ter origens tecnicas distintas, mas a interacao deve parecer parte do mesmo sistema.Nao esconder classificacao: quando um titulo estiver em quebras, 30 dias ou renegociacoes, os sinais da linha devem ser suficientes para que o usuario aceite aquela classificacao como plausivel.Falha externa nao quebra operacao: indisponibilidade da Chronos deve degradar com seguranca, sem comprometer a utilizacao do dashboard.O sentimento principal que a tela deve transmitir e confianca. O cobrador precisa sentir que o dashboard voltou a representar a carteira real, inclusive com os titulos da Travessia, e que pode agir com seguranca sem recorrer a conferencias paralelas fora do sistema. Essa confianca precisa surgir da clareza do grid, da coerencia entre cards e listas e da estabilidade do comportamento ja conhecido.
O segundo sentimento desejado e controle. Mesmo com uma nova fonte de dados entrando no fluxo, o usuario nao deve sentir perda de dominio da rotina. A tela precisa continuar previsivel, com os mesmos padroes de leitura e as mesmas acoes principais, para que a introducao da Chronos seja percebida como ampliacao de capacidade, nao como ruptura do processo.
Tambem queremos uma sensacao de produtividade calma. O dashboard nao deve provocar duvida, tensao ou sobrecarga cognitiva. A experiencia correta e aquela em que o usuario percorre a tela com ritmo continuo, entende a origem do titulo rapidamente e segue o trabalho sem friccao mental desnecessaria.
No primeiro contato com a tela apos a integracao, o usuario deve sentir clareza imediata. Ele precisa perceber que algo foi melhorado, mas sem estranhar a interface. O ideal e que a leitura seja: agora a tela esta mais completa, e nao mexeram em tudo.
Durante a experiencia central de uso, o sentimento dominante deve ser seguranca operacional. Ao percorrer quebras, 30 dias e renegociacoes, o cobrador precisa confiar que a linha esta no lugar certo, que a marca Travessia/Bralar faz sentido e que pode executar a proxima acao sem hesitar.
Depois de concluir a tarefa principal, especialmente ao registrar 30 dias ou validar recebimentos, o usuario deve sentir confirmacao. A jornada precisa terminar com a percepcao de que o sistema acompanhou o raciocinio dele e manteve a continuidade do processo.
Se algo der errado, como falha temporaria da Chronos, o sentimento desejado e estabilidade, nao panico. O usuario deve entender que houve indisponibilidade de uma fonte complementar, mas que o dashboard continua operando e que o restante da rotina nao foi comprometido.
Quando voltar a usar a tela em dias seguintes, o sentimento ideal e familiaridade confiavel. A experiencia precisa se consolidar rapidamente como parte natural do processo diario.
As micro-emocoes mais criticas para o sucesso desta feature sao:
Confianca em vez de confusao: a linha deve explicar a si mesma.Conforto em vez de estranhamento: a tela deve parecer a mesma ferramenta de sempre, apenas mais completa.Seguranca em vez de ceticismo: o usuario precisa acreditar que os titulos da Travessia sao validos e estao corretamente classificados.Satisfacao em vez de frustracao: a inclusao da nova fonte deve eliminar a sensacao de carteira incompleta.Baixa ansiedade em vez de sobrecarga: mais informacao nao pode significar mais desgaste mental.Continuidade em vez de ruptura: registrar 30 dias ou validar renegociacao deve parecer extensao do fluxo atual, nao um caso especial.Se queremos transmitir confianca, a UX precisa priorizar explicabilidade. Isso exige identificacao textual clara de origem, colunas previsiveis, proposta exibida legivel e ausencia de ambiguidades visuais entre Bralar e Travessia.
Se queremos transmitir controle, as acoes existentes nao devem mudar de posicao, nome ou comportamento sem necessidade. O usuario nao pode sentir que precisa reaprender a operar para lidar com a Travessia.
Se queremos transmitir produtividade calma, devemos evitar excesso de destaque visual. Badge, coluna de origem e sinais de classificacao precisam ser discretos, consistentes e suficientes. O objetivo nao e chamar atencao para a nova fonte, e sim torná-la operacionalmente compreensivel.
Se queremos evitar ceticismo, o sistema precisa mostrar coerencia entre a linha, o grid e os indicadores. Um titulo Travessia listado no grid errado ou parecendo duplicado compromete a emocao principal mais do que qualquer problema estetico.
Se queremos reduzir ansiedade em falhas externas, a degradacao da Chronos deve ser tratada com mensagem curta, contextual e nao bloqueante. O sistema deve comunicar o problema sem transformar a tela em estado de erro generalizado.
Confianca antes de novidade: a feature deve parecer correta antes de parecer nova.Completude sem barulho: a carteira fica mais completa, mas a tela nao pode ficar mais cansativa.Previsibilidade gera controle: os mesmos gestos e leituras devem continuar funcionando.Sinal minimo, significado maximo: pequenos marcadores de origem e contexto devem resolver grandes duvidas operacionais.Erro externo, impacto contido: falhas da Chronos devem ser percebidas como degradacao localizada, nao como quebra do sistema.Para esta feature, as referencias mais uteis nao sao produtos de marketing ou apps de consumo. O melhor paralelo esta em sistemas com alto volume de leitura tabular e operacao repetitiva, como ERPs financeiros, CRMs operacionais e paineis de atendimento com filas. Nesses produtos, o valor de UX aparece quando o usuario consegue tomar decisao rapida em uma linha sem abrir detalhes desnecessarios.
O primeiro grupo inspirador sao ERPs e backoffices financeiros. O que esses sistemas fazem bem, quando acertam, e manter a informacao mais importante visivel no grid principal, com hierarquia clara entre identificacao, valor, vencimento, status e acao. A licao transferivel aqui e simples: a tabela precisa carregar quase toda a decisao operacional sem exigir navegacao secundária.
O segundo grupo inspirador sao CRMs de atendimento e cobranca. O melhor padrao desses sistemas e explicitar contexto com pequenos badges ou chips compactos, sem competir com o conteudo principal. Quando funcionam bem, esses marcadores permitem que o operador entenda rapidamente origem, prioridade ou etapa do item, mantendo a linha escaneavel. Isso conversa diretamente com a necessidade de mostrar Travessia/Bralar.
O terceiro grupo inspirador sao dashboards analiticos-operacionais que combinam indicadores no topo e listas acionaveis abaixo. O padrao bem-sucedido nesses produtos e a coerencia entre card e grid: o numero resumido no topo precisa se materializar em registros plausiveis nas listas. Essa inspiracao e importante porque a Chronos vai impactar exatamente a confianca entre indicadores e grids.
Tambem ha uma inspiracao negativa recorrente: sistemas internos que tentam resolver novas regras de negocio adicionando cores demais, colunas demais e excecoes visuais demais. Esses produtos se tornam mais informativos em tese, mas menos operaveis na pratica. A feature chronos-titulos deve evitar esse caminho.
Os padroes mais transferiveis para o nosso caso sao:
Badge textual compacto por contexto: usar um marcador curto e discreto para Travessia e Bralar, sem transformar a origem em protagonista visual.Coluna ou area de leitura estavel: manter a identificacao da linha sempre na mesma zona da tabela, para que a origem e a proposta sejam lidas dentro de um padrao previsivel.Acoes inline sem bifurcacao visual: preservar botoes e links existentes, evitando tratamentos especiais para Travessia no nivel da interacao.Densidade com hierarquia: aceitar que a tela e densa, mas garantir que o olho encontre primeiro cliente, proposta, valor/data, origem e acao.Resumo no topo, evidência no grid: garantir que qualquer aumento em cards ou contadores encontre correspondencia concreta nas listas que o usuario percorre.Feedback de degradacao localizado: se a fonte complementar falhar, exibir indicacao pontual e calma, sem contaminar a tela inteira com estado de erro.Aplicados ao dashboard_cobrador.php, esses padroes sugerem um UX de evolucao controlada. O grid continua sendo o centro da decisao, a origem entra como marcador auxiliar, e os fluxos operacionais permanecem iguais.
Criar uma identidade visual separada para Travessia: se as linhas Travessia parecerem pertencer a outro sistema, o usuario perde continuidade cognitiva.Resolver tudo com cor: usar cor como principal diferenciador de origem ou classificacao aumenta ruido e fragiliza acessibilidade operacional.Adicionar excecoes de botao ou fluxo: mudar o comportamento visual do registrar 30 dias para Travessia criaria desconfiança e curva de reaprendizado.Exibir campos tecnicos da API: creditId, parcelId, contractNumber cru ou outros identificadores tecnicos nao devem invadir a leitura principal.Espalhar a mesma regra em pontos visuais diferentes: origem, classificacao e contexto nao podem ser sinalizados de formas contraditorias entre os grids.Usar mensagens de erro alarmistas: falhas da Chronos nao podem transformar o dashboard em uma tela de incidente generalizado.Aumentar a largura do grid sem disciplina: cada nova coluna tem custo real de escaneabilidade e pode comprometer a leitura em monitores menores.What to Adopt:
contexto discreto no grid, usando badges ou texto curto para origem, porque isso suporta a leitura rapida sem romper a estrutura atual.coerencia entre resumo e detalhe, garantindo que cards e grids contem a mesma historia operacional.acao inline invariavel, mantendo o comportamento atual das tratativas principais.What to Adapt:
What to Avoid:
Essa estrategia de inspiracao fixa um criterio importante para as proximas decisoes de UX: a feature deve parecer uma melhora silenciosa no instrumento de trabalho do cobrador, nao uma nova camada de interface competindo com a operacao.
Para a chronos-titulos, a escolha correta nao e criar um design system novo nem importar um sistema estabelecido de componentes. A fundacao de design deve ser o sistema visual existente do cobranca, complementado por um conjunto pequeno de regras especificas da feature para origem, proposta exibida, estados de degradacao e consistencia entre grids.
Na pratica, isso significa adotar uma abordagem de custom local extension: preservar classes, espacamentos, tipografia, densidade de tabela, botoes e convencoes ja em uso no sistema, e introduzir apenas os elementos minimos necessarios para a nova fonte de dados. O objetivo nao e reestilizar o produto, e sim impedir que a feature pareca um enxerto visual desconectado.
Essa decisao e a mais adequada por cinco motivos centrais:
Tambem ha uma razao de manutencao: a equipe ja conhece o padrao atual do sistema. Quanto menos novas abstrações visuais forem introduzidas nesta fase, mais simples sera implementar, revisar e publicar com seguranca.
A implementacao visual deve seguir a base atual do dashboard_cobrador.php e de seus componentes, especialmente os grids e marcadores ja existentes. A feature deve reutilizar:
quebras, 30 dias e renegociacoes;Os novos elementos visuais da feature devem ser limitados a:
Travessia ou Bralar;proposta_exibicao;Qualquer necessidade adicional deve ser resolvida primeiro por composicao dos estilos existentes. Criar novo componente visual so deve acontecer se a regra de negocio realmente nao puder ser comunicada com o que o sistema ja possui.
A estrategia de customizacao deve ser minima, controlada e rastreavel. As regras principais sao:
origem deve ser diferenciada por texto e contraste moderado, nao por uma paleta agressiva;Travessia e Bralar precisam compartilhar o mesmo formato de exibicao para comunicar que pertencem ao mesmo sistema operacional;proposta_exibicao da Travessia deve entrar no mesmo campo visual onde o operador ja procura proposta, evitando criar uma segunda area de identificacao;Em vez de tokens visuais sofisticados ou guidelines amplas, esta feature precisa de uma mini camada de consistencia. O suficiente para congelar como origem, proposta e degradacao devem aparecer, sem abrir uma frente paralela de redesign.
A experiencia definidora da chronos-titulos e reconhecer rapidamente um titulo valido, entender seu contexto e agir sem hesitacao. O usuario nao deve pensar em fontes de dados, API, ERP ou banco auxiliar. Ele deve olhar uma linha do grid e concluir, em poucos segundos, se aquele titulo exige acao, se ja foi tratado, se pertence a Travessia ou Bralar e qual o proximo passo operacional.
Se essa experiencia estiver correta, o restante segue naturalmente. Os indicadores passam a fazer sentido, os grids deixam de parecer incompletos e a nova fonte entra no processo sem criar um fluxo paralelo. Se ela falhar, nada mais importa: o usuario perde confianca e volta a conferir informacao fora do sistema.
Em termos práticos, o equivalente conceitual do “swipe” desta feature e bater o olho na linha e confiar. Essa e a acao nuclear que define o valor do produto neste ponto da jornada.
O modelo mental atual do cobrador e simples e forte: o dashboard me mostra a carteira do jeito que ela esta agora, e eu trabalho a partir do que vejo. Ele ja espera que quebras represente titulos em aberto vencidos, que 30 dias reflita marcacoes operacionais especificas do MySQL e que renegociacoes represente recebimentos com natureza distinta do pagamento comum.
Quando esse usuario olha um grid, ele nao pensa em camadas tecnicas. Ele pensa em perguntas operacionais:
O problema atual e que esse modelo mental e quebrado pelos titulos ausentes da Travessia. O usuario sabe que existe carteira fora da tela e, por isso, convive com um nivel de desconfiança operacional. A feature precisa restaurar o modelo mental anterior, mas agora com cobertura maior: se e relevante para a cobranca, deve aparecer aqui.
O principal risco de confusao e o usuario sentir que as linhas da Travessia obedecem outra logica. Se ele tiver que decorar excecoes, interpretar um formato visual diferente ou desconfiar do posicionamento no grid, a experiencia fracassa. Por isso, a regra central e manter o modelo mental atual e apenas torná-lo mais completo.
O usuario dira isso funciona quando conseguir:
Travessia ou Bralar sem interromper o ritmo de leitura;quebras, 30 dias ou renegociacoes;registrar 30 dias, sem sentir que entrou em um fluxo especial;Os indicadores concretos de sucesso para a experiencia central sao:
quebras para 30 dias preserva continuidade perceptiva;Em termos de velocidade, a tela deve continuar parecendo imediata no nivel de leitura. O usuario precisa sentir que a nova informacao foi absorvida pelo grid, nao anexada a ele.
Esta feature deve usar padroes estabelecidos, nao interacoes novas. O usuario ja entende leitura tabular, badge contextual, status por linha e acao inline. Esses padroes sao suficientes para resolver o problema, desde que a regra de classificacao e a origem estejam bem comunicadas.
A unica “novidade” aceitavel aqui e a combinacao de elementos familiares para resolver uma necessidade nova:
Travessia/Bralar como marcador contextual;proposta_exibicao ajustada para manter reconhecimento operacional;Ou seja, a inovacao nao esta em ensinar um gesto novo. Esta em usar o mesmo idioma visual da tela atual para incorporar uma nova realidade da carteira. Essa escolha reduz curva de aprendizagem, acelera homologacao e respeita o ambiente brownfield.
1. Initiation
O fluxo comeca exatamente como hoje: o cobrador abre o dashboard_cobrador.php, usa os filtros habituais e percorre os cards e grids na ordem operacional que ja conhece. Nada na iniciacao deve sinalizar que existe um “modo Chronos”; a feature entra como parte do dashboard normal.
2. Interaction
No grid, o usuario percorre cada linha procurando cliente, proposta, valor/data, contexto operacional e acao disponivel. A origem Travessia/Bralar deve aparecer em posicao previsivel. A proposta_exibicao deve ser lida no mesmo campo visual onde hoje o usuario identifica titulos. Quando a linha estiver em quebras, a acao de registrar 30 dias continua com o mesmo padrao de uso.
Para linhas pagas, a interacao principal e de validacao e acompanhamento, nao de descoberta. O usuario verifica se aquele titulo esta em 30 dias ou renegociacoes e aceita essa classificacao pela combinacao entre contexto visual e consistencia do grid.
3. Feedback
O feedback mais importante e visual e imediato:
registrar 30 dias ocorrer, a continuidade do item no fluxo deve confirmar ao usuario que a tratativa foi absorvida pelo sistema.Em caso de erro ou indisponibilidade da Chronos, o feedback deve ser pequeno, objetivo e localizado. O sistema precisa comunicar a degradacao, mas tambem comunicar implicitamente que o restante da tela continua confiavel.
4. Completion
O usuario sabe que concluiu bem sua tarefa quando consegue percorrer o grid, identificar os casos relevantes e executar a tratativa sem consultar outra fonte. No caso do fluxo quebras -> 30 dias, a conclusao correta inclui perceber que a marcacao foi refletida no comportamento esperado da carteira.
O sucesso final da mecanica nao e um toast ou uma celebracao visual. E a sensacao silenciosa de que o dashboard voltou a ser uma fonte unica de trabalho.
Nao ha indicacao de um novo brandbook para esta feature, e a decisao correta e seguir a identidade visual ja existente do sistema de cobranca. A estrategia de cor, portanto, deve ser preservar a paleta atual e reservar cor apenas para significado operacional. Isso evita que a entrada da Chronos pareca uma submarca ou um modulo paralelo dentro da tela.
O uso de cor deve obedecer esta hierarquia:
Travessia e Bralar devem ser diferenciadas por badge textual discreto, com contraste suficiente, sem saturacao alta e sem competir com alertas reais;Em termos praticos, a recomendacao visual e usar uma base neutra para badges de origem, com leve diferenca de tom e forte apoio no texto. O badge precisa ser legivel, mas nao dominante. A leitura correta e isto informa contexto, nao isto exige atencao imediata.
A tipografia deve permanecer a mesma ja usada no produto. Esta feature nao precisa de nova familia tipografica; precisa de disciplina de hierarquia textual dentro de uma tela densa. O objetivo e tornar cliente, proposta, origem e valores rapidamente escaneaveis sem aumentar ruido.
As regras tipograficas para a feature devem ser:
proposta_exibicao como dado operacional importante, mas sem disputar protagonismo com nome do cliente;Travessia/Bralar, sem reduzir a legibilidade abaixo do aceitavel.A hierarquia ideal de leitura por linha deve ser:
Isso significa que a tipografia nao deve criar uma “nova coluna visual protagonista” para a origem. A origem informa, mas nao comanda o olhar.
A tela deve manter uma abordagem densa e eficiente, nao ampla e espaçosa. O dashboard e uma ferramenta operacional. Mais respiro do que o necessario prejudicaria a quantidade de informacao visivel e reduziria produtividade.
A fundacao de espacamento deve seguir o grid ja existente da aplicacao, presumindo continuidade com os espacamentos atuais. O principio geral e:
Para absorver a nova informacao da origem, a solucao preferida e reorganizar a zona de leitura da linha com o menor impacto possivel. Se houver escolha entre adicionar uma coluna inteira ou acoplar a origem a uma area ja existente de identificacao, a opcao deve ser guiada pela escaneabilidade real do grid, nao pela pureza tecnica da modelagem.
Em layouts mais estreitos, a prioridade de preservacao deve ser:
Ou seja, se houver compressao visual, a origem pode ser compactada, mas nao pode sumir.
Mesmo sendo um sistema interno, esta feature precisa respeitar acessibilidade operacional. O principal aqui nao e compliance formal extensa, e sim garantir que a tela continue legivel, compreensivel e segura sob uso intenso.
As consideracoes obrigatorias sao:
Travessia de Bralar;Tambem ha uma forma especifica de acessibilidade cognitiva importante para este caso: consistencia. O usuario precisa reconhecer o mesmo padrao visual entre grids, inclusive quando a origem muda. Repeticao de padrao reduz erro de interpretacao e aumenta confianca, que e o objetivo principal desta feature.
Para esta feature, a exploracao correta de direcoes visuais nao e sobre estilos drasticamente diferentes de produto, e sim sobre formas diferentes de encaixar origem e proposta dentro da tabela operacional. As direcoes consideradas foram:
Direcao A - Coluna dedicada de origem: adiciona uma coluna curta exclusiva para Travessia/Bralar, preservando proposta no lugar atual.Direcao B - Origem acoplada ao bloco de identificacao: cliente e proposta continuam principais, e a origem entra como badge contextual no mesmo agrupamento visual.Direcao C - Origem anexada a proposta: a proposta aparece acompanhada do marcador de origem, concentrando identificacao funcional em uma mesma zona.Direcao D - Origem em estado secundario da linha: a origem fica mais discreta, em texto de apoio ou label menor, com prioridade maxima para cliente, proposta e financeiro.As quatro direcoes foram pensadas para responder a mesma pergunta: onde colocar a nova informacao sem prejudicar a velocidade de leitura. O criterio de avaliacao foi menos estetico e mais operacional: escaneabilidade, densidade, continuidade com a tela atual e risco de ambiguidade.
Tambem foi considerado o impacto nos grids distintos:
quebras, a linha ja carrega mais sinais operacionais, entao qualquer direcao com muito peso visual aumenta ruido rapidamente;30 dias e renegociacoes, ha mais espaco para explicitar contexto, mas ainda assim sem criar leitura mais lenta;A direcao escolhida foi refinada para uma versao ainda mais conservadora do que a Direcao B: badge minimo no inicio da linha, sem alterar a estrutura atual do grid.
Na pratica, isso significa:
B para BralarT para TravessiaBralarTravessia30 dias continua aparecendo somente no grid quebras, exatamente como hoje;Essa direcao e a melhor para o nosso caso porque respeita integralmente o comportamento atual da tela. O print da interface confirmou que os grids ja estao estabilizados visualmente e carregam sinais importantes de operacao, especialmente em quebras, onde convivem status, badge de 30d, indicador de Advogado e botoes de acao. Qualquer reposicionamento de coluna ou redistribuicao de informacao teria alto risco de regressao perceptiva.
Os motivos objetivos da escolha sao:
Proposta, Cliente, Valor, Data ou Acoes;Tambem ha um motivo importante de manutencao: essa direcao e trivial de replicar entre grids diferentes. Se o primeiro elemento da linha carregar o badge de origem, a consistencia de Bralar e Travessia fica garantida sem obrigar cada grid a inventar sua propria solucao.
O caminho de implementacao visual deve seguir esta ordem:
Proposta, Cliente, Valor, Data ou Acoes;quebras, preservar integralmente os indicadores e a acao de 30 dias ja existentes;renegociacoes, 30 dias e demais grids da feature;Regras concretas de implementacao:
B ou T;O HTML comparativo da exploracao visual foi gerado em:
Ele deve ser usado apenas como apoio de conversa. A especificacao oficial agora e esta:
badge inicial B/T em todas as linhasazul = Bralarverde = Travessianenhuma mudanca estrutural no grid30 dias permanece exclusivamente no grid QuebrasEsta e a jornada mais sensivel da feature, porque o grid quebras combina leitura de atraso, contexto operacional e acao direta de 30 dias. O comportamento desejado e que o cobrador veja uma linha da Travessia ou da Bralar exatamente da mesma forma operacional, com o badge inicial apenas informando a origem.
O fluxo esperado e:
dashboard_cobrador.php;quebras;B ou T;30 dias ou segue outra tratativa;O ponto de sucesso desta jornada e a ausencia de hesitacao. O cobrador nao deve parar para entender “como trata um titulo Travessia”; ele deve tratá-lo como parte do mesmo processo, apenas sabendo de qual empresa veio.
flowchart TD
A[Abrir dashboard_cobrador.php] --> B[Aplicar filtros atuais]
B --> C[Visualizar grid Quebras]
C --> D[Ler badge inicial B ou T]
D --> E[Validar proposta cliente vencimento dias e total]
E --> F{Titulo exige acao 30 dias?}
F -->|Sim| G[Usar botao atual Registrar 30 dias]
F -->|Nao| H[Seguir outra tratativa existente]
G --> I[Backend grava regra no MySQL]
I --> J[Usuario entende que a tratativa foi absorvida]
H --> J
C --> K{Chronos indisponivel?}
K -->|Sim| L[Mostrar somente dados disponiveis com degradacao discreta]
L --> ENesta jornada, a UX precisa provar continuidade. O usuario nao esta mais tomando a decisao inicial sobre um titulo vencido; ele esta confirmando que o item foi corretamente absorvido no fluxo de acompanhamento. O badge B/T continua presente no inicio da linha, mas a estrutura do grid permanece intacta.
O fluxo esperado e:
30 dias;O principal risco aqui e parecer que um titulo veio “de outro sistema”. O fluxo precisa reforcar o contrario: ele veio de outra fonte, mas pertence ao mesmo processo de cobranca.
flowchart TD
A[Acessar grid Recebimentos 30 Dias] --> B[Percorrer linhas da tabela]
B --> C[Ler badge inicial B ou T]
C --> D[Conferir proposta cliente valor e data]
D --> E{Registro consta no fluxo 30 dias do MySQL?}
E -->|Sim| F[Exibir no grid mantendo layout atual]
E -->|Nao| G[Nao exibir nesse grid]
F --> H[Usuario valida continuidade do processo]
H --> I[Usa acao existente do grid]
B --> J{Chronos indisponivel?}
J -->|Sim| K[Degradacao discreta sem quebrar grid]
K --> DNo grid de renegociacoes, a experiencia precisa ser ainda mais discreta. O usuario deve apenas perceber que agora existem titulos adicionais corretamente classificados e marcados por origem. A regra tecnica da Chronos (parcelFrequencyName = Renegociação) nao deve aparecer como detalhe de interface; ela so precisa resultar em um posicionamento confiavel do item no grid certo.
O fluxo esperado e:
renegociacoes recebidas;O sucesso dessa jornada depende de coerencia: se o badge mudou, mas o resto da linha continua familiar, o usuario aceita a inclusao da nova origem sem friccao.
flowchart TD
A[Acessar grid Renegociacoes Recebidas] --> B[Percorrer linhas atuais]
B --> C[Ler badge inicial B ou T]
C --> D[Conferir proposta cliente valor e data]
D --> E{Titulo classificado como renegociacao?}
E -->|Sim| F[Exibir no grid atual sem alterar colunas]
E -->|Nao| G[Redirecionar para outro fluxo backend]
F --> H[Usuario confia na classificacao]
H --> I[Usa acao atual do grid]
B --> J{Chronos indisponivel?}
J -->|Sim| K[Operar com dados disponiveis e aviso discreto]
K --> DOs padroes comuns entre as jornadas precisam permanecer fixos:
mesmo ponto de entrada: o usuario sempre entra pela mesma tela e pelos mesmos grids;mesma sequencia de leitura: badge inicial, proposta, cliente, dados financeiros, acoes;mesmo repertorio de acoes: nenhuma acao nova ou reetiquetada por causa da origem;mesma expectativa visual: colunas, ordem e comportamento do grid permanecem iguais;mesma estrategia de degradacao: falha da Chronos nao colapsa a tela nem muda drasticamente o fluxo.Tambem ha um padrao decisional importante:
nao adicionar passos: a feature deve caber nos fluxos existentes, nao criar subfluxos paralelos.nao exigir traducao tecnica: o usuario nao precisa saber como o backend classificou Chronos, apenas confiar no resultado.manter ritmo de leitura: o badge inicial deve acelerar contexto, nao interromper a escaneabilidade.confirmar continuidade: especialmente entre quebras e 30 dias, o sistema deve reforcar que a tratativa surtiu efeito.degradar com serenidade: quando a Chronos falhar, o fluxo restante precisa continuar plausivel e utilizavel.Como a estrategia geral da feature e preservar integralmente o sistema visual atual, a cobertura de componentes vem majoritariamente do proprio produto existente. Os elementos disponiveis e que devem ser reaproveitados sao:
dashboard_cobrador.php;30d e Advogado;Isso significa que a analise de gap e pequena. O produto ja tem praticamente tudo o que precisa para esta entrega. O que falta e apenas um componente de contexto de origem e uma regra consistente de encaixe desse componente nas linhas dos grids.
Purpose: identificar de forma instantanea se a linha pertence a Bralar ou Travessia.
Usage: deve aparecer como primeiro elemento visual de cada registro em todos os grids impactados pela feature.
Anatomy: badge compacto, preferencialmente circular ou quase circular, com uma unica letra central:
B para BralarT para TravessiaStates:
default Bralar: fundo azul, letra B, contraste suficientedefault Travessia: fundo verde, letra T, contraste suficienteloading/unknown: nao deve existir na tela final; se a origem nao estiver resolvida no backend, a linha nao deve improvisar um terceiro estado visualVariants:
Accessibility:
title ou texto acessivel equivalente com o nome completo da origemContent Guidelines:
B ou TInteraction Behavior:
Purpose: garantir que o badge entre no inicio da linha sem alterar o restante da estrutura do grid.
Usage: aplicacao tecnica na primeira area da linha, antes dos campos ja existentes.
Anatomy: pequeno contêiner de alinhamento horizontal/vertical para posicionar o badge com espacamento estavel.
States:
default: alinhado ao centro vertical da linhadense row: mesma regra, sem aumentar a altura perceptivelVariants:
Accessibility:
Content Guidelines:
Interaction Behavior:
Purpose: comunicar de forma discreta quando a Chronos estiver indisponivel, sem quebrar a tela.
Usage: somente quando houver falha real da fonte externa que afete parte da consolidacao.
Anatomy: mensagem curta e contextual, preferencialmente proxima ao grid ou area de filtro correspondente, sem dominar a interface.
States:
hidden: estado normalvisible: aviso discreto de degradacaoVariants:
Accessibility:
Content Guidelines:
Interaction Behavior:
A estrategia de implementacao de componentes deve seguir estas regras:
Origin Badge como unico componente visual realmente novo;B/T;30 dias, Advogado, acoes e demais elementos no mesmo lugar onde ja estao.No nivel tecnico, isso significa que o frontend deve receber algo simples como:
marca_empresa = Bralar | Travessiaorigem_badge = B | Tbralar, travessia)Qualquer logica de traduzir origem, definir classificacao ou decidir cor deve ser resolvida antes do render. O componente de interface deve ser burro e previsivel.
Phase 1 - Core Components
Origin Badgequebras, que e o mais sensivel visualmentePhase 2 - Grid Rollout
30 diasrenegociacoesPhase 3 - Supporting Feedback
O criterio de prioridade aqui e simples: primeiro garantir o componente minimo e sua consistencia, depois expandir para todos os grids, e so por ultimo tratar estados de excecao adicionais.
Os botoes atuais do sistema devem permanecer como referencia absoluta de hierarquia visual. A feature chronos-titulos nao introduz nova taxonomia de acoes. Ela apenas acrescenta origem aos registros, mantendo o usuario dentro do mesmo repertorio operacional.
Padroes obrigatorios:
registrar 30 dias continua com o mesmo peso visual e aparece exclusivamente em quebras;B/T nunca deve parecer botao ou elemento clicavel;Regra de consistencia:
origem informabotao ageOu seja, o badge e passivo, e as acoes continuam sendo reconhecidas pelo mesmo padrao historico da tela.
Os feedbacks da feature devem ser discretos e contextualizados. O sistema nao pode dramatizar a entrada da nova fonte nem transformar a falha da Chronos em uma ruptura visual maior do que o necessario.
Padroes obrigatorios:
Padrao de tom:
Os filtros e buscas do dashboard_cobrador.php permanecem como estao. A feature nao cria novos formularios, novos campos nem novos critérios de entrada visual para o usuario.
Padroes obrigatorios:
Bralar ou Travessia para que a feature funcione;Regra principal:
A navegacao da feature e zero-friccao porque nao ha nova navegacao. O usuario continua entrando pela mesma tela e usando os mesmos blocos do dashboard.
Padroes obrigatorios:
Bralar ou Travessia;quebras, 30 dias e renegociacoes continua sendo entendido pela propria tela, nao por navegacao extra.Regra de consistencia:
Bralar e Travessia devem ser aceitos como estado normal da interface;30d e Advogado, permanecem onde ja estao.A estrategia responsiva da chronos-titulos deve ser desktop-first com degradacao controlada para larguras menores. O dashboard do cobrador e uma tela operacional densa, usada principalmente em contexto corporativo com mouse e teclado. Portanto, a prioridade maxima de design continua sendo a experiencia em desktop.
Isso nao significa ignorar resolucoes menores. Significa que a adaptacao deve preservar a capacidade de uso sem reinventar a interface. Para esta feature, a regra e:
B/T;A feature nao deve tentar converter os grids em cards mobile para este MVP. Isso aumentaria custo, risco e divergencia funcional sem necessidade real para a entrega atual.
A estrategia de breakpoint pode seguir a base comum do projeto, com interpretacao conservadora:
desktop: 1024px+tablet / notebooks estreitos: 768px - 1023pxmobile / larguras menores: ate 767pxRegras de adaptacao por faixa:
desktop: nenhuma mudanca estrutural; badge entra sem alterar gridtablet / notebook estreito: permitir maior compressao horizontal e scroll em containers da tabela, preservando ordem e colunasmobile: nao redesenhar tabela; manter estrutura e permitir leitura parcial com scroll horizontal, apenas garantindo que o badge inicial e a primeira parte da identificacao permaneçam visiveis com prioridadePara esta feature, a melhor abordagem nao e criar novos breakpoints personalizados. E aproveitar a estrategia responsiva ja existente da aplicacao e garantir que o badge nao introduza regressao visual nessas faixas.
A estrategia de acessibilidade adequada para esta feature e WCAG AA como referencia pratica. Mesmo sendo um sistema interno, a tela lida com uso intensivo, alta repeticao e decisao operacional. Isso torna legibilidade, contraste e consistencia mais importantes do que qualquer formalismo superficial.
Requisitos de acessibilidade obrigatorios:
B e no badge verde T;title, aria-label ou equivalente acessivel para expor Bralar e Travessia por completo;Tambem ha uma camada importante de acessibilidade cognitiva:
A validacao desta feature deve combinar teste visual, operacional e de acessibilidade leve.
Responsive Testing
Accessibility Testing
B e T;Operational Testing
quebras com linhas Bralar e Travessia lado a lado;30 dias continua aparecendo so em quebras;30 dias e renegociacoes com badge em todas as linhas;