Registro reformulado

Descrição do fluxo de registro recomendado para o portal do CCB, organizada como direcionamento de experiência, conteúdo, hierarquia e conversão da Biblioteca de Registro Autoral.

1. Diagnóstico

Papel do registro no portal

O registro de obras deve ser tratado como uma das principais jornadas de valor do portal. Ele não deve parecer apenas um formulário antigo por CPF nem uma sequência de telas administrativas. A experiência precisa transmitir que o usuário está protegendo uma obra, criando uma prova de autoria e avançando para um certificado que depende de informações corretas, conteúdo enviado e, quando aplicável, pagamento concluído.

Esse fluxo precisa atender públicos diferentes: autor que está registrando pela primeira vez, associado com créditos ou benefícios, usuário que quer apenas imprimir certificado, pessoa que precisa pagar registros pendentes e visitante que ainda quer entender preços, validade jurídica e tipos de obra aceitos. A reformulação deve organizar essas intenções sem colocar todas elas competindo no primeiro painel.

Diagnóstico do fluxo atual

O fluxo atual possui os elementos essenciais para registrar uma obra, mas a hierarquia visual não ajuda o usuário a entender a jornada completa. A primeira tela combina banner, menu auxiliar, três opções de rádio, CPF, certificação, modais informativos, letreiro e rodapé. Essa composição comunica confiança e história, mas cria ruído no momento em que a pessoa precisa tomar uma decisão simples: começar um registro, consultar certificado ou acessar pagamentos.

Nas etapas seguintes, o usuário encontra formulários longos, avisos de alta importância visual, seleção de quantidade de títulos, blocos dinâmicos por obra, envio de arquivos e textos, declaração de autoria, confirmação e pagamento. A sequência funciona, mas cada tela parece independente. Falta uma linha narrativa consistente que mostre o progresso, explique o motivo de cada etapa e separe decisão, preenchimento, envio, confirmação e pagamento.

No mobile, o empilhamento resolve a adaptação básica, mas aumenta muito a rolagem. Quando há quatro títulos, coautores ou múltiplos tipos de obra, a experiência fica longa e pouco orientada. O usuário precisa confiar que está no caminho certo mesmo sem um resumo persistente do lote, do valor, dos tipos de registro e do que ainda falta.

2. Oportunidades de Melhoria

Princípio de reformulação

O registro reformulado deve transformar a Biblioteca de Registro em um fluxo guiado de proteção de obra. Cada etapa precisa ter uma função clara, uma ação principal e uma explicação curta sobre o que está sendo decidido naquele momento.

O foco deve ser:

1. Explicar a finalidade do registro antes de pedir dados.
2. Separar claramente registro, certificados e pagamentos.
3. Mostrar progresso do usuário em todas as telas.
4. Organizar cadastro, lote, envio de conteúdo, confirmação e pagamento como uma jornada única.
5. Reduzir textos longos em favor de blocos escaneáveis e apoio contextual.
6. Deixar preço, gratuidade, status do certificado e próximo passo sempre compreensíveis.

3. Proposta de Redesign

Estrutura recomendada do fluxo

O fluxo principal de novo registro deve ser organizado em cinco momentos:

1. Entrada e identificação por CPF.
2. Cadastro do autor e montagem do lote.
3. Envio do conteúdo das obras.
4. Confirmação do registro e resumo financeiro.
5. Pagamento e liberação do certificado, quando houver cobrança.

Essa estrutura preserva a lógica do estado atual, mas muda a percepção da experiência. O usuário deve sentir que está avançando por uma trilha de registro, e não saltando entre páginas com layouts e mensagens diferentes.

Primeira etapa: entrada e identificação

A primeira tela deve funcionar como uma página de decisão curta. O topo precisa deixar claro:

1. O que é o registro de obra no CCB.
2. Quais tipos de obra podem ser registrados.
3. Como o usuário inicia o processo.
4. Quais caminhos secundários existem para certificado e pagamento.

O CPF continua sendo a chave principal de entrada, mas deve aparecer dentro de um bloco com linguagem mais orientadora. O usuário precisa entender que o CPF será usado para localizar cadastro anterior, benefícios, registros existentes e pendências.

As três opções atuais devem continuar existindo, mas com hierarquia mais clara:

1. Registrar nova obra.
2. Consultar ou imprimir certificado.
3. Acessar painel de registros e pagamentos.

A opção de registrar nova obra deve ser a ação principal da tela. Certificados e pagamentos devem aparecer como caminhos secundários, visíveis e confiáveis, mas sem disputar o mesmo peso visual da entrada de novo registro.

Conteúdo de apoio da entrada

O Menu Registro atual concentra informações importantes, como passo a passo, primeiro registro grátis, preços, modelo de certificado, quem registra no CCB e direitos autorais. Essas informações não devem depender apenas de um dropdown que cobre o formulário.

A reformulação deve transformar esse conteúdo em apoio escaneável ao redor da decisão principal. A primeira tela pode apresentar:

1. Um resumo curto de como funciona o registro.
2. Um destaque para primeiro registro grátis, quando aplicável.
3. Um bloco de preços e tipos de obra.
4. Um bloco de confiança com validade jurídica, certificação e leis citadas.
5. Um acesso claro ao modelo de certificado.
6. Links de orientação para direitos autorais e execução pública.

Os textos longos dos modais devem virar conteúdo de apoio progressivo. O usuário deve conseguir começar rapidamente, mas também encontrar explicações quando estiver inseguro.

Segunda etapa: cadastro do autor e montagem do lote

A etapa de cadastro deve ser percebida como preparação do registro. Hoje ela mistura dados pessoais, criação de senha, quantidade de títulos, dados de obra, coautores, avisos e promoção de desconto em uma coluna longa.

A tela reformulada deve dividir esse momento em seções claras:

1. Dados do autor.
2. Contato e endereço.
3. Acesso para acompanhar registros.
4. Obras deste envio.
5. Coautores, quando houver.

Quando o CPF já tiver cadastro, a tela deve reconhecer isso de forma explícita e encurtar o caminho. Em vez de apenas ocultar parte dos campos, a interface deve mostrar uma confirmação compacta do autor encontrado e permitir que o usuário siga para os títulos com mais confiança.

Quando o CPF não tiver cadastro, o formulário completo deve explicar que esses dados serão usados para identificação do autor, comunicações, acompanhamento e certificado.

Montagem do lote de obras

O registro permite montar um lote de até quatro títulos. Essa possibilidade deve ser tratada como uma decisão de lote, não apenas como um seletor numérico.

A interface deve explicar:

1. Quantas obras o usuário quer registrar agora.
2. Se existe benefício ou desconto ao registrar mais de um título.
3. Que cada título pode ter tipo de registro e conteúdo exigido diferentes.
4. Que coautores podem ser informados por obra.

Os blocos de título devem parecer itens de uma lista revisável. Cada item precisa exibir título da obra, tipo de registro, estilo ou categoria, coautores e status de preenchimento. Quando houver quatro títulos, o usuário deve conseguir entender rapidamente quais itens estão completos e quais ainda exigem atenção.

Tipos de registro e expectativas de conteúdo

A escolha do tipo de registro precisa preparar o usuário para a próxima etapa. O fluxo trabalha com música por equivalência sonora, letra ou poesia, livro ou texto, partitura e outros trabalhos. Cada tipo exige um conteúdo diferente, e essa diferença deve aparecer no momento da escolha.

A tela de montagem do lote deve mostrar pequenas orientações:

1. Música por equivalência sonora exige gravação, mesmo caseira, em arquivo de áudio.
2. Letra ou poesia exige texto digitado ou colado.
3. Livro, trabalho, roteiro, pesquisa ou texto exige arquivo em formato aceito.
4. Partitura exige arquivo de partitura e pode exigir letra associada.

Esse apoio reduz erros na etapa seguinte e evita que o usuário descubra tarde demais que precisa de arquivo, letra ou formato específico.

Terceira etapa: envio do conteúdo

A etapa de envio do conteúdo deve ser organizada como uma lista de obras a concluir. Cada card deve representar uma obra e mostrar apenas os campos necessários para aquele tipo de registro.

O bloco de cada obra deve conter:

1. Número e título da obra.
2. Tipo de registro escolhido.
3. Conteúdo exigido.
4. Instruções curtas de formato.
5. Estado de envio ou preenchimento.
6. Alerta apenas quando houver risco real de erro.

As instruções atuais são importantes, mas devem ser reduzidas e posicionadas perto do campo correspondente. O aviso sobre não digitar no campo de arquivo deve aparecer como microorientação do upload, e não como alerta dominante.

Para letras, a área de texto precisa favorecer cópia e revisão. Para arquivos, o campo deve deixar claro quais formatos são aceitos e se o arquivo já foi selecionado. Para música, o fluxo deve orientar que a gravação pode ser simples, desde que seja suficiente para identificar a obra.

Declaração de autoria

A declaração de autoria deve permanecer como momento claro e consciente antes do envio. Ela não deve aparecer como um checkbox solto no fim de uma tela longa.

O ideal é que a tela apresente uma área de revisão antes da declaração, com a lista de obras, tipos, arquivos anexados e letras preenchidas. Em seguida, o usuário confirma que é autor ou responsável pelo envio do conteúdo.

A ação final deve deixar claro que o usuário está protocolando o registro. Textos genéricos como Enviar devem ser substituídos por uma chamada mais específica, como Protocolar registro ou Enviar obras para registro.

Quarta etapa: confirmação e resumo do registro

A tela de confirmação precisa ser mais do que uma mensagem de sucesso seguida de tabela. Ela deve explicar o estado real do registro após o envio.

O primeiro bloco deve responder:

1. O envio foi gravado com sucesso?
2. O registro já está liberado ou depende de pagamento?
3. O certificado está provisório, pendente ou definitivo?
4. Qual é o próximo passo?

Quando houver cobrança, a tela deve apresentar o pagamento como parte natural da conclusão do processo. A mensagem principal deve dizer que o registro foi recebido, mas que o certificado definitivo depende da quitação.

O resumo do lote deve ser mais escaneável do que uma tabela simples. Ele deve destacar títulos, data, quantidade de registros, valor total e situação. Em lotes com mais de uma obra, cada título deve aparecer em uma lista clara para evitar que o usuário perca a relação entre quantidade e valor.

Quinta etapa: pagamento

A etapa de pagamento já tem uma base compreensível, porque apresenta resumo da compra e métodos em cards. Ainda assim, ela deve reforçar melhor o contexto do registro.

O resumo deve destacar:

1. Produto ou serviço: registro de obra.
2. Títulos incluídos no pagamento.
3. Data do envio.
4. Quantidade de registros.
5. Valor total.
6. Relação entre pagamento e liberação do certificado.

Os métodos de pagamento devem continuar organizados como opções comparáveis:

1. Pix ou depósito.
2. Boleto bancário.
3. Cartão de crédito.
4. PayPal para residentes fora do Brasil.

Cada método precisa ter uma ação específica e previsível. O usuário deve saber se vai ver informações de depósito, gerar boleto, abrir pagamento por cartão ou seguir para PayPal.

O bloco de segurança deve permanecer, mas com texto mais curto e menos protagonismo. Sua função é aumentar confiança no momento da cobrança, não competir com a escolha do método.

Certificados, pesquisa e pagamentos pendentes

A Biblioteca de Registro também precisa atender quem não está iniciando uma nova obra. Por isso, certificados, pesquisa e pagamentos pendentes devem ser tratados como trilhas secundárias fortes, com acesso claro desde a entrada.

Essas trilhas devem ter linguagem própria:

1. Consultar ou imprimir certificado.
2. Ver meus registros.
3. Pagar registros pendentes.
4. Acompanhar situação de um título.

O usuário que chega para imprimir certificado não deve atravessar uma interface desenhada principalmente para novo registro. O usuário que chega para pagar pendências também precisa entrar direto em uma lógica de lista, seleção e quitação.

Indicador de progresso

Todas as etapas do novo registro devem exibir progresso. Uma estrutura recomendada:

1. Identificação.
2. Dados e obras.
3. Conteúdo.
4. Confirmação.
5. Pagamento.

No desktop, esse progresso pode aparecer como linha horizontal com nomes curtos. No mobile, pode aparecer como etapa atual e total de etapas, com o título da etapa em destaque. O importante é o usuário saber onde está, o que já concluiu e o que ainda falta.

Resumo persistente do lote

Durante o fluxo, o usuário deve ter acesso a um resumo simples do lote. Esse resumo deve ser especialmente importante a partir da segunda etapa.

O resumo pode apresentar:

1. CPF ou autor identificado.
2. Quantidade de obras no envio.
3. Títulos informados.
4. Tipos de registro.
5. Coautores informados.
6. Valor estimado ou indicação de gratuidade.
7. Estado do envio de conteúdo.

No desktop, esse resumo pode aparecer como painel lateral ou bloco de apoio. No mobile, deve aparecer como bloco compacto entre seções ou como resumo antes da ação principal.

Gratuidade, benefícios e preço

As regras de gratuidade precisam ser explicadas em linguagem de decisão. O usuário não precisa ver a lógica operacional, mas precisa entender quando um registro pode sair grátis, quando depende de créditos e quando será cobrado.

A interface deve diferenciar:

1. Primeiro registro gratuito, quando aplicável.
2. Créditos de registro para associados.
3. Registros pagos para não sócios.
4. Tipos de obra que não entram na mesma gratuidade.
5. Valor total do lote antes de seguir para pagamento.

O desconto por registrar quatro títulos deve ser apresentado como benefício de lote, perto da escolha de quantidade, e não como uma dica solta entre campos do formulário.

Direção visual

O registro deve usar a mesma direção visual recomendada para o portal, com azul institucional sustentando navegação, títulos estruturais, botões e áreas de confiança. O amarelo-dourado deve aparecer como assinatura de destaque para benefícios, primeiro registro grátis, resumo de preço e informações importantes, sem virar faixa repetida em excesso.

Cards devem ser usados para elementos que realmente representam unidades de decisão ou revisão: obras do lote, métodos de pagamento, resumo financeiro, certificado e estados de retorno. Textos explicativos longos devem entrar em blocos de apoio, modais mais leves ou páginas de orientação, não dentro do caminho principal de preenchimento.

A certificação, leis e validade jurídica devem continuar visíveis, mas como prova de confiança organizada. Esses elementos devem ajudar o usuário a se sentir seguro, sem roubar o foco da ação principal.

Direção mobile

No mobile, a prioridade é encurtar a percepção de esforço. O fluxo pode continuar em coluna única, mas precisa de seções curtas, progresso compacto e resumo do lote antes das ações principais.

As decisões devem aparecer antes dos textos longos. Na entrada, o usuário precisa ver primeiro a ação principal e os caminhos secundários. No cadastro, campos relacionados devem ficar agrupados. Na montagem do lote, cada obra deve ter um bloco fácil de escanear. No envio de conteúdo, cada card deve mostrar o que falta concluir.

Os métodos de pagamento devem ser empilhados como lista de escolha, com valor e segurança próximos da ação. O certificado ou a pendência de pagamento deve ficar claro sem depender de leitura extensa.

4. Recomendações de Conversão

Linguagem dos CTAs

Os botões devem indicar a ação real e o próximo passo. Textos genéricos como Acessar e Enviar podem continuar em ações simples, mas não devem dominar as etapas principais.

Sugestões de ações:

1. Começar registro.
2. Consultar certificado.
3. Ver registros e pagamentos.
4. Continuar para obras.
5. Adicionar título.
6. Continuar para envio.
7. Protocolar registro.
8. Continuar para pagamento.
9. Pagar registro.
10. Imprimir certificado.

A linguagem deve ser direta e corresponder ao estado real. Quando o registro ainda depende de pagamento, o botão não deve sugerir que o processo já terminou completamente.

Estados de retorno e bloqueio

O fluxo deve prever mensagens claras para estados que hoje podem ser percebidos como desvios ou interrupções.

Cada estado deve conter:

1. Mensagem principal curta.
2. Explicação do motivo.
3. Ação recomendada.
4. Caminho alternativo quando existir.

Estados importantes:

1. CPF sem cadastro.
2. CPF com cadastro encontrado.
3. CPF com registros pendentes.
4. Registro enviado com pagamento pendente.
5. Registro gratuito ou com créditos.
6. Certificado ainda não liberado.
7. Arquivo ausente ou formato incorreto.
8. Coautores informados de forma incompleta.

O objetivo é reduzir a sensação de erro e transformar cada estado em orientação de próximo passo.

Recomendações de conversão

A conversão principal do fluxo é concluir um registro válido, não apenas preencher CPF. Para isso, a experiência deve reduzir dúvidas em três pontos sensíveis: validade do registro, conteúdo exigido e custo final.

As melhorias mais importantes são:

1. Fazer o usuário entender a proposta de valor antes do formulário.
2. Mostrar tipos de obra e exigências antes da etapa de upload.
3. Dar visibilidade ao preço ou gratuidade antes do pagamento.
4. Reforçar confiança jurídica no início e na conclusão.
5. Usar CTAs específicos para cada etapa.
6. Separar novo registro, certificados e pagamentos desde a entrada.
7. Evitar que avisos técnicos ocupem mais atenção do que a decisão principal.

Síntese do registro recomendado

O registro reformulado deve combinar confiança autoral, formulário guiado, montagem clara do lote, envio de conteúdo sem ambiguidade, confirmação honesta do estado do certificado e pagamento simples. O usuário precisa entender desde o início que está protegendo uma obra, quais informações precisa fornecer, que conteúdo deve anexar ou digitar, quanto pagará ou se tem gratuidade, e quando o certificado será liberado.

O objetivo não é remover a riqueza informativa da Biblioteca de Registro, mas organizar essa riqueza em camadas. A melhor experiência para o novo portal é aquela em que o usuário começa com segurança, avança com orientação e termina sabendo exatamente se seu registro está definitivo, pendente de pagamento ou disponível para certificado.

Texto Narrativo e Explicativo

O registro de obras no CCB deve ser compreendido como uma jornada de proteção autoral, e não como um simples conjunto de formulários. Trata-se de um fluxo público, independente de login prévio, no qual a identificação principal acontece por CPF e não pela existência de uma sessão autenticada. Desde a entrada por CPF, a interface precisa comunicar que o usuário está iniciando um processo formal de comprovação de autoria, formação de protocolo e futura emissão de certificado. Isso muda a lógica da experiência: cada etapa deixa de ser apenas preenchimento e passa a representar uma parte do compromisso entre autor, obra registrada e documentação emitida ao final.

No primeiro contato, a experiência deve separar com clareza três intenções que hoje convivem no mesmo território funcional: iniciar um novo registro, consultar ou imprimir certificado e tratar pagamentos ou pendências já existentes. Embora essas ações pertençam ao mesmo universo da Biblioteca de Registro, elas respondem a momentos de uso completamente diferentes. A nova interface precisa refletir essa diferença para evitar que o usuário entre em uma trilha inadequada, percorra etapas desnecessárias ou precise retroceder para encontrar a função correta.

Para quem está começando um novo registro, o fluxo deve ser percebido como uma progressão contínua em cinco momentos de negócio: identificação, dados e obras, envio de conteúdo, confirmação e pagamento. Esses momentos não precisam se traduzir obrigatoriamente na mesma quantidade de telas nem na mesma ordem visual rígida, mas a interface gerada precisa preservar seu sentido operacional. Essa percepção de continuidade é importante porque o negócio não depende apenas de coletar dados, mas de garantir que o autor entenda o que está registrando, em que estágio está e o que ainda condiciona a liberação do certificado. O conteúdo de apoio da entrada, como passo a passo, primeiro registro grátis, preços, modelo de certificado e orientação sobre direitos autorais, deve continuar presente, mas como camada de confiança e esclarecimento, não como obstáculo à ação principal.

Em termos de fidelidade, a liberdade de solução não pode eliminar algumas obrigações estruturais do fluxo. A experiência precisa preservar a entrada por CPF como chave de decisão, o caráter público e independente de autenticação prévia, a distinção entre novo registro, certificado e pagamentos, o reconhecimento de CPF já existente, a montagem de lote com até quatro obras, a variação de exigência conforme o tipo de registro, a revisão antes do protocolo, a diferenciação entre registro gratuito, provisório, pendente e definitivo, a relação entre pagamento e liberação do certificado e a existência de trilhas de retorno independentes para consulta e regularização. A interface pode decidir como distribuir esses elementos, mas não pode tratá-los como opcionais.

Na etapa de cadastro e montagem do lote, o sistema precisa deixar explícita a razão de cada informação pedida. Dados pessoais, contato e endereço não são burocracia isolada; eles sustentam identificação do autor, comunicação do processo, vinculação do protocolo e emissão correta do certificado. Quando o CPF já existir na base, a interface deve reconhecer esse histórico e encurtar o caminho com uma confirmação objetiva de quem foi encontrado, sem transformar isso em exigência de login para prosseguir. Quando não existir, o preenchimento completo precisa ser apresentado como criação da base mínima necessária para que o registro tenha rastreabilidade e continuidade.

A lógica do lote também precisa ser tratada como uma decisão de negócio real. O usuário não está apenas escolhendo um número de campos para abrir na tela; ele está definindo quantas obras serão protocoladas naquele envio, quantas decisões de tipo de registro serão tomadas e qual poderá ser o impacto financeiro ou promocional dessa escolha. Por isso, a experiência deve mostrar com nitidez quantas obras entram no envio atual, quais títulos já foram informados, quais itens ainda estão incompletos e onde existe benefício por quantidade de títulos. Essa clareza ajuda a interface a representar a operação do registro de forma íntegra e compreensível.

A escolha do tipo de registro é um dos pontos mais críticos da jornada, porque ela determina a natureza do conteúdo exigido na etapa seguinte. Música, letra, livro, partitura e outros formatos não são apenas categorias de exibição; eles alteram o que o usuário deverá anexar, digitar, revisar e declarar. A interface precisa antecipar essa consequência no momento da escolha, para que a pessoa saiba previamente se precisará enviar áudio, colar texto, anexar arquivo ou combinar materiais complementares. Esse preparo reduz erro de arquivo, ausência de conteúdo, retrabalho com coautoria e sensação de surpresa na fase de envio.

É também nesse ponto que o fluxo deve explicitar orientações que traduzem regras de operação e limites do serviço. Se o registro for por equivalência sonora, a experiência precisa deixar claro que o autor deve enviar sua própria gravação digital, mesmo que simples, desde que suficiente para identificar a obra. Se for partitura, a lógica precisa comunicar que o usuário deve possuir e enviar o arquivo correspondente, sem induzir a expectativa de que o CCB vá confeccionar, fornecer, imprimir ou comercializar partitura em papel como parte do processo. Se for letra, poesia, livro, roteiro, pesquisa ou trabalho, a interface precisa esclarecer que o conteúdo deve ser entregue pelo próprio autor em formato compatível com o registro pretendido. Em outras palavras, o fluxo não deve apenas pedir anexos; ele deve enquadrar corretamente o que é responsabilidade do usuário preparar e o que efetivamente será entregue pelo serviço.

No envio de conteúdo, cada obra deve aparecer como unidade autônoma, revisável e claramente identificável. O usuário precisa localizar com facilidade o título, o tipo de registro, a exigência correspondente, o estado do preenchimento e o que ainda falta concluir. A função dessa etapa não é reproduzir uma longa sequência de campos, mas permitir que o autor finalize cada obra com segurança, sabendo se já anexou o material correto, se ainda precisa revisar texto ou se há alguma pendência objetiva para seguir. Quanto mais a interface tratar cada obra como item vivo do lote, mais coerente ela será com a realidade do processo de registro.

Nessa mesma etapa, algumas orientações precisam deixar de ser alertas genéricos e passar a funcionar como instrução contextual de alta utilidade. A interface deve orientar que campos de upload servem para seleção de arquivo, não para digitação manual; que letras instrumentais exigem uma indicação clara dessa condição; que coautores devem representar apenas outros autores efetivamente vinculados à obra, sem repetir o próprio titular do envio; e que diferentes obras no mesmo lote podem exigir materiais diferentes. Também precisa ficar claro que lotes mistos são legítimos e que a experiência deve acomodar, no mesmo envio, obras com exigências distintas sem simplificar indevidamente a lógica do processo. Esse tipo de detalhamento parece pequeno, mas é ele que transforma um fluxo apenas navegável em um fluxo operacionalmente confiável.

Antes do protocolo, a declaração de autoria deve funcionar como fechamento consciente da revisão. Ela precisa vir depois de uma leitura consistente de títulos, anexos, textos e coautores, para que o usuário saiba exatamente o que está enviando em seu nome. Nesse momento, a ação principal deve comunicar com precisão que o conteúdo será protocolado, substituindo verbos genéricos por chamadas que traduzam a consequência real da ação. O ponto central aqui é que a confirmação não marca apenas o fim de uma tela: ela marca a formalização do envio perante o processo do CCB.

Depois do protocolo, o estado do registro precisa ficar totalmente transparente. A confirmação deve esclarecer se o envio foi recebido com sucesso, se o registro já está liberado, se depende de pagamento, se o certificado está provisório, pendente ou definitivo e qual é o próximo passo esperado do usuário. Essa etapa tem papel decisivo na coerência da experiência, porque o negócio do registro não termina no clique de envio; ele continua até que a situação do título esteja compreendida e, quando necessário, regularizada financeiramente.

Para que uma interface gerada seja de fato fiel, ela também precisa prever e tornar legíveis os estados mínimos que organizam a jornada, mesmo que escolha representá-los de outro modo. Entre eles estão: CPF sem cadastro, CPF com cadastro encontrado, obra ou lote com preenchimento incompleto, coautoria informada de forma insuficiente, conteúdo ausente ou incompatível com o tipo escolhido, registro enquadrado em gratuidade, registro dependente de pagamento, certificado ainda não liberado e certificado disponível para emissão. O ponto central é garantir que a lógica de transição entre esses estados não desapareça na abstração visual.

Quando houver cobrança, o pagamento deve aparecer como continuação natural da conclusão do registro, e não como desvio inesperado. O resumo financeiro precisa amarrar títulos, quantidade, data do envio, valor total e relação direta entre quitação e liberação do certificado. Ao mesmo tempo, as regras de gratuidade, uso de créditos, benefícios de associado e exceções por tipo de obra precisam estar claras antes de a cobrança acontecer. Isso inclui deixar evidente que o primeiro registro gratuito não se aplica indistintamente a todos os formatos, que livros e trabalhos seguem outra lógica de cobrança e que benefícios recorrentes de associado obedecem regras próprias. Esse cuidado reduz surpresa, desconfiança e abandono, além de permitir que a interface organize com clareza a lógica econômica do serviço.

As trilhas de retorno precisam continuar fortes e independentes dentro do mesmo ambiente. Consultar certificado, acompanhar registros e quitar pendências são jornadas legítimas, com começo, meio e fim próprios. Quem retorna para emitir um documento não deve atravessar a narrativa de novo registro, e quem retorna para pagar precisa encontrar diretamente a lista de itens pendentes, a seleção do que será quitado e a ação de regularização. Também é importante que o sistema explique, no momento certo, que a emissão do certificado é uma ação posterior de consulta e impressão vinculada ao estado do registro, e não uma entrega automática indistinta ao fim de qualquer envio. Essa separação preserva eficiência operacional e mantém a arquitetura da experiência alinhada à lógica do serviço.

No mobile, toda essa lógica deve permanecer íntegra, mas com foco ainda maior em contexto e progressão. A experiência precisa manter avanço visível, blocos escaneáveis, decisões agrupadas e resumo recorrente do lote para reduzir percepção de esforço, sobretudo quando houver múltiplas obras, coautores ou combinações diferentes de conteúdo. O objetivo é traduzir a jornada de negócio para uma navegação mais clara, na qual o usuário consiga continuar, revisar, pagar quando necessário e concluir com segurança.

Referências cruzadas

1. Estado atual do fluxo em Interface e Navegacao > Registro de Obras.
2. Regras de negócio do registro em Regras de Negocio > Registro de Obras.
3. Emissão de certificados em Regras de Negocio > Certificados.
4. Pagamento por título em Regras de Negocio > Pagamentos por Titulo.
5. Direcionamento da home em Home Reformulada.
6. Direcionamento da associação em Associacao Reformulada.
7. Direção cromática em Paleta Recomendada.
8. Direção tipográfica em Tipografia Recomendada.