Quando mostrar porcentagem de progresso

Saiba quando usar porcentagem de progresso e quando preferir um indicador indeterminado, sem inventar precisão.

Wireframe minimalista comparando progresso determinado e indeterminado
Nível de impácto
Médio
Status
Recomendado
Nível de evidênica
Evidência moderada

Contexto

Uma porcentagem só ajuda quando o sistema conhece o total e consegue relacionar o valor exibido ao trabalho restante. Se o total não é conhecido, a porcentagem cria falsa precisão.

A decisão depende de quatro fatores: o avanço é mensurável, a medida é estável, a tarefa tem começo e fim definidos e a pessoa precisa acompanhar o trabalho. Quando esses critérios não existem, use um indicador indeterminado ou comunique apenas o estado da operação.

Antes de exibir uma porcentagem, confirme que o sistema consegue medir o avanço de forma honesta. Use uma barra determinada quando o sistema conhece o tamanho total do trabalho, como arquivos, itens ou etapas quantificáveis.

Mostre o valor atual real, de 0 a 100%, ou uma medida mais útil, como “42 de 100 itens”. O avanço não deve diminuir nem reiniciar sem explicar a mudança. Arredonde o valor quando necessário e evite casas decimais que não representam uma medição real.

Quando o total ou o avanço não forem conhecidos, use um indicador indeterminado com um rótulo claro, sem inventar porcentagem, tempo restante ou etapa.

Use etapas quando a pessoa avança entre fases relacionadas e controladas por ela. Não transforme etapas de duração desigual em uma porcentagem enganosa.

Em tarefas longas, mantenha a tarefa nomeada, informe o resultado ao terminar e ofereça cancelar, continuar, tentar novamente ou retomar quando essas ações forem seguras.

Se o total só se tornar conhecido durante o processamento, comece com um indicador indeterminado e mude para determinado quando houver uma medida confiável.

Base da recomendação

A recomendação cruza orientação normativa do W3C, documentação de componentes do Carbon, GOV.BR e Primer e evidências contextuais da Baymard e da NN/g. Um Design System mostra uma solução adotada; não é, sozinho, prova de uma regra universal.

Página do Design System GOV.BR mostrando um loading determinado em 75% e um loading indeterminado
Exemplo real: o Design System GOV.BR mostra no mesmo componente um loading determinado, com 75% e opção Cancelar, e um loading indeterminado, com o estado Carregando. A imagem demonstra a diferença entre avanço conhecido e espera sem duração especificada. Fonte: https://www.gov.br/ds/components/loading

Porque isso importa?

Uma porcentagem comunica uma promessa: a pessoa entende que existe um total e que o valor representa o caminho até a conclusão. Se o número é inventado, muda de forma inexplicável ou fica parado, a confiança cai e a espera parece mais longa.

Carbon, GOV.BR e Primer distinguem progresso determinado de carregamento indeterminado e recomendam associar o indicador a um rótulo e a um valor compreensível. O Primer também mostra que “4 de 12 tarefas concluídas” pode dar mais contexto do que uma barra isolada.

Em fluxos de checkout, a pesquisa da Baymard reforça que um indicador precisa representar o caminho real; isso apoia o uso de etapas em jornadas sequenciais, mas não transforma checkout em modelo para qualquer operação. Para tecnologia assistiva, o W3C exige que o progresso e as mudanças de status sejam determináveis por programa, sem roubar o foco.

  • O total de arquivos, itens ou bytes é conhecido.
  • O sistema calcula o avanço com dados reais.
  • A tarefa tem início, fim e estados de conclusão definidos.
  • O processamento demora e o avanço muda de forma significativa.
  • Uma medida como “4 de 12” ajuda a entender o trabalho restante.
  • O total se torna conhecido depois do início e pode substituir o estado indeterminado.
  • O total ou o avanço não são conhecidos.
  • A porcentagem vem apenas do tempo decorrido.
  • O número é uma estimativa sem base verificável.
  • O total muda e reinicia a barra sem explicação.
  • O fluxo é formado por etapas de duração muito desigual.
  • A operação é tão rápida que o indicador só acrescenta ruído.
  • Cor, movimento ou ícone são a única forma de comunicar o estado.
Página do GitHub Primer mostrando uma barra de progresso em 33% com código e rótulo acessível
Exemplo real: o GitHub Primer combina uma barra em 33% com o texto acessível “4 of 12 tasks completed”, dando contexto verificável ao avanço. A imagem mostra a documentação oficial do componente. Fonte: https://primer.style/product/components/progress-bar/

Recomendações

Faça

Práticas recomendadas
  • Confirme o total.
  • Mostre dados reais.
  • Mantenha o valor estável.
  • Use “4 de 12” quando ajudar.
  • Nomeie a tarefa.
  • Comunique o resultado final.
  • Ofereça uma saída segura.
Wireframe de tarefa com barra de progresso mensurável e avanço coerente
Exemplo correto: uma tarefa apresenta avanço mensurável, contexto visual, estado atual e ações de saída. Ilustração criada para a CamaraUX com base em Carbon, GOV.BR, W3C e Primer; não representa uma interface de empresa específica.

Evite

Práticas a evitar
  • Inventar porcentagem.
  • Prometer prazo incerto.
  • Reiniciar sem explicar.
  • Usar precisão falsa.
  • Converter etapas desiguais em %.
  • Depender só de cor.
Wireframe com indicadores de progresso conflitantes e falsa precisão
Exemplo incorreto: vários indicadores competem entre si, falta contexto e a tela parece bloqueada; a composição sugere avanço sem uma métrica confiável. Ilustração criada para a CamaraUX para fins didáticos.
Documentação do Carbon mostrando uma barra determinada em uma tarefa de upload
Exemplo real: o Carbon Design System mostra uma tarefa de upload com barra determinada e avanço parcial, relacionando o progresso à operação em andamento. A captura demonstra quando uma porcentagem pode representar avanço mensurável. Fonte: Carbon Design System — Progress bar: https://carbondesignsystem.com/components/progress-bar/usage/.

Acessibilidade

Forneça um rótulo visível e um nome acessível para a tarefa. Em progresso determinado, use role="progressbar" com aria-valuemin, aria-valuemax e aria-valuenow coerentes com o valor exibido. Se o progresso for indeterminado, omita aria-valuenow; não forneça um número fictício.

Use aria-describedby e aria-busy="true" na região afetada quando apropriado. Para atualizações que precisam chegar ao leitor de tela, use uma mensagem de status, como role="status" ou aria-live="polite", sem mover o foco a cada mudança.

Não dependa apenas de cor, movimento ou som. Teste nome acessível, contraste, zoom, reflow, teclado, leitor de tela, conclusão, erro e cancelamento.

Checklist

  • O total é conhecido?
  • O valor atual vem de dados reais?
  • A porcentagem representa o trabalho restante?
  • O valor não diminui nem reinicia sem explicação?
  • O rótulo identifica a tarefa?
  • “4 de 12” seria mais claro neste caso?
  • O estado indeterminado é usado quando não há medida confiável?
  • O resultado final é comunicado?
  • Há uma saída ou recuperação segura?
  • O progresso é anunciado sem mover o foco?
  • Foram testados teclado, zoom e leitor de tela?

Referências

Carbon Design System — Progress bar. Distingue o estado determinado, usado quando o progresso pode ser calculado contra um objetivo específico, do indeterminado, usado quando o avanço ou a duração são desconhecidos. Também orienta rótulos, valores e acessibilidade. Consultar a orientação de uso.

Design System GOV.BR — Loading. Documenta loading determinado e indeterminado e mostra que a porcentagem deve aparecer quando existe avanço conhecido, enquanto o estado indeterminado comunica processamento sem prometer duração. Consultar o componente Loading.

GitHub Primer — ProgressBar. Mostra como expor o valor da barra com contexto textual, como “4 of 12 tasks completed”, e como associar o progresso a um nome acessível. Consultar o componente ProgressBar · Consultar acessibilidade.

W3C — ARIA Authoring Practices, propriedades de faixa. Define que aria-valuenow deve ser omitido quando o valor do progressbar é indeterminado ou desconhecido; quando o valor é conhecido, ele deve respeitar os limites informados. Consultar a orientação do W3C.

W3C — WCAG 2.2, Status Messages. Inclui progresso, espera, sucesso e erro entre as mensagens de status que precisam ser determináveis por programa sem receber foco automaticamente. Consultar o critério 4.1.3.

Baymard Institute — Checkout Flow UX. Em checkout de múltiplas etapas, a pesquisa recomenda que o indicador seja um mapa de uma etapa para cada etapa real; isso apoia o uso de etapas em fluxos sequenciais, não o uso universal de porcentagens. Consultar a pesquisa sobre fluxo de checkout.

Nielsen Norman Group — Progress Indicators. Reúne orientação sobre indicadores visíveis para tornar esperas longas mais compreensíveis. É apoio sobre percepção da espera, não um limite universal para decidir quando usar porcentagem. Consultar o artigo.

Veja também

Esta recomendação foi útil para você?