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 vivido como um percurso de proteção autoral com começo, meio e conclusão verificável. Na entrada por CPF, o usuário precisa entender que está iniciando um processo de comprovação de autoria e emissão de certificado, e não apenas preenchendo campos isolados.

Já no primeiro painel, a experiência deve separar com clareza três intenções que coexistem no mesmo universo: iniciar novo registro, consultar ou imprimir certificado e tratar pendências de pagamento. Essa distinção evita desvio de rota e reduz retrabalho para quem chega com objetivo específico.

Para quem inicia novo registro, a progressão precisa aparecer em cinco momentos contínuos: identificação, dados e obras, envio de conteúdo, confirmação e pagamento. O conteúdo de apoio da entrada, como passo a passo, primeiro registro grátis, preços, modelo de certificado e direitos autorais, deve permanecer acessível sem bloquear o início da ação principal.

Na etapa de cadastro e lote, o usuário precisa compreender por que cada dado é solicitado e como isso se conecta ao certificado final. Quando o CPF já existir, o reconhecimento deve encurtar caminho com confirmação objetiva. Quando não existir, a coleta completa deve ser orientada por finalidade de identificação, acompanhamento e comunicação.

A montagem do lote deve traduzir decisão real, não apenas seleção numérica. O usuário precisa visualizar quantas obras vai protocolar, quais títulos já foram informados, que tipo de registro foi escolhido para cada item e o que ainda falta concluir. Benefício por quantidade de títulos deve aparecer no momento dessa decisão, e não como informação deslocada.

A escolha do tipo de registro precisa antecipar exigência de conteúdo. Música, letra, livro, partitura e outros formatos devem indicar previamente o que será exigido na etapa seguinte para reduzir erro de arquivo, texto e coautoria. No envio de conteúdo, cada obra deve aparecer como unidade revisável com orientação curta, status de completude e foco no que falta para finalizar.

Antes do protocolo, a declaração de autoria deve ser precedida por revisão consistente de títulos, anexos, textos e coautores. A confirmação deve comunicar claramente que o envio está sendo protocolado. Depois disso, o estado do registro precisa ser transparente: recebido, liberado, pendente de pagamento, provisório ou definitivo, sempre com próximo passo explícito.

Quando houver cobrança, o pagamento deve ser continuidade natural da conclusão do registro. O resumo financeiro precisa relacionar títulos, quantidade, data e valor total com a liberação do certificado. Regras de gratuidade, créditos e exceções por tipo de obra devem ser entendidas antes da etapa de cobrança, para reduzir surpresa e desconfiança.

As trilhas de retorno devem permanecer fortes e independentes no mesmo ambiente: consultar certificado, acompanhar registros e quitar pendências. Quem retorna para emitir documento não deve atravessar o caminho de novo registro, e quem retorna para pagar deve entrar direto em lista, seleção e regularização.

No mobile, toda essa lógica deve manter progressão visível, blocos escaneáveis e resumo de lote recorrente para reduzir percepção de esforço em cenários com múltiplas obras. A experiência precisa preservar contexto para que o usuário consiga continuar, 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.