Componentes

89. MICROCÓPIA DE INTERFACE

estávelseed-componentes.md v1.43 · §89seção 95 de 9889-microcopia-de-interface-estavel-2026-08-24-f7-7.md · MD5 5fe471fb

Título completo no canon: MICROCÓPIA DE INTERFACE · estável (2026-08-24, F7.7-P4, cinco decisões dele no gate) · MC1–MC18

O que esta seção é, e o que ela não é. O marca-seed.md §10 governa a voz editorial — display, eyebrow, hierarquia, respiro. Esta seção governa o rótulo de controle: o texto que a pessoa lê para decidir o que clicar, o que o erro diz quando algo falha, e o que a tela vazia explica. São camadas diferentes: a §10 escreve para quem lê; a §89 escreve para quem age. Onde as duas se tocam (tom, exclamação, emoji), a §10 é a fonte e esta seção apenas propaga — regra mais antiga vence.

Fontes lidas na rodada de 2026-08-24 (rodada de pesquisa própria, com proveniência declarada arquivo por arquivo): Shopify Polaris (repositório, porque o site redireciona e as content guidelines saíram dele) · Atlassian Design System · IBM Carbon · Material Design 3 · Microsoft (Windows UX Guide, Fluent writing style e o Portuguese (Brazil) Localization Style Guide, 56 páginas) · NN/g (error messages, confirmation dialogs, empty states) · GOV.UK Design System · USWDS · Apple HIG · GNOME Brasil, guia de estilo de tradução · Mozilla L10n · Mailchimp. Mais o estudo-clickup-completo.md §9, que já tinha o produto de referência MEDIDO em pt-BR.

Por que a pesquisa foi necessária, e o que ela mudou: o §9 do estudo mediu um produto real e extraiu padrões que pareciam consenso. A rodada mostrou que três deles são divergência declarada entre guias maduros, não consenso — e que dois têm apoio público em fonte pt-BR que ninguém tinha consultado (o guia de localização da Microsoft e o guia do GNOME Brasil). Copiar o produto medido teria importado escolha alheia como se fosse lei. Medir o vizinho diz o que ele faz; não diz o que nós devemos fazer.

89.1 As cinco decisões do gate#

#	Decisão	Veredito dele	Alternativa descartada, e o número que a derruba
MC1	Rótulo de ação = VERBO + SUBSTANTIVO, sem artigo, sem pontuação. "Criar proposta", "Adicionar unidade consumidora". O substantivo cai somente dentro de diálogo ou painel cujo título já o nomeia	(a)	Verbo nu ("Criar", "Editar"), que é o Polaris — e ele proíbe a forma (a) por redundância. Cai porque três botões "Criar" em três telas soam idênticos para quem navega por teclado ou leitor de tela, e o rótulo perde sentido fora de contexto. Apoio da forma adotada: Microsoft (objeto direto quando o objeto não é evidente), Atlassian ("comece com o verbo e especifique o que está sendo agido") e a prática pt-BR de menu do GNOME Brasil
MC2	Capitalização = SENTENCE CASE em todo rótulo, menu, aba e cabeçalho de ação: "Adicionar unidade consumidora", "Configurações da conta"	(a)	Seguir a fonte inglesa, que é a regra do guia pt-BR da Microsoft ("Add to Contacts" → "Adicionar a Contatos"), desenhada para simplificar localização em escala. Cai por dois custos: a maiúscula no meio da frase soa germânica em português, e cria dúvida caso a caso sobre o que é "nome de produto" — cada rótulo novo viraria discussão. Convergem em sentence case: Polaris, Atlassian, Carbon, Material 3, GOV.UK
MC3	Voz do erro = IMPESSOAL. "Não foi possível gerar a proposta". "Nós" somente quando a falha é comprovadamente da SEED	(a)	Primeira pessoa do plural ("Não conseguimos gerar…"), que é o Atlassian — e ele proíbe a forma impessoal, com o argumento de que ela soa distante. Cai por um motivo local que nenhuma fonte poderia trazer: o produto emite laudo, memorial e documento com ART. Assumir autoria de erro por padrão, em texto que pode ser citado por cliente ou órgão, é risco que a microcópia não deve criar. A exceção do "nós" é a regra do Polaris. Bônus: "Não foi possível" é a fórmula que o guia pt-BR da Microsoft prescreve para "could not" — alinhamento de localização de graça
MC4	Botão de confirmação destrutiva = VERBO ESPECÍFICO que resume o resultado: "Excluir proposta" / "Manter". Nunca OK, nunca Sim/Não	(a)	"Excluir mesmo assim" como regra condicional (Microsoft: atrito deliberado quando a confirmação existe para AVISAR de algo) — que era a minha recomendação e ele preferiu (a). O custo da escolha fica escrito, porque é real e foi enunciado no gate: o rótulo específico é rápido demais — a pessoa acabou de pedir "excluir", então clica no verbo sem ler o aviso. Consequência que a MC5 absorve: se o rótulo não freia, o texto tem de frear, então a MC5 passa a exigir a consequência declarada no corpo do diálogo, com o dado identificador. Convergem em (a): NN/g, Material 3, Apple HIG
MC5	O corpo do diálogo destrutivo declara a CONSEQUÊNCIA, não faz pergunta retórica — com o dado identificador (nome, número, contagem) e a palavra "permanente" quando não há desfazer	consequência de (a)	"Tem certeza que deseja continuar?" — o "Don't" literal do Polaris, e o alvo direto do NN/g: sem detalhe, a única reação sensata a "tem certeza?" é clicar sim sem pensar, o que anula a proteção

89.2 O que a evidência ou o nosso canon já fechavam (sem gate)#

#	Regra	De onde vem
MC6	Zero emoji na UI de produto. Zero exclamação.	Já era lei nossa: a marca §10 diz "sem emojis em material de marca" e que título é afirmação, não grito (o contraexemplo literal lá é "NOVIDADES!!!"). Convergem: Polaris ("no máximo uma por página, só para coisas realmente empolgantes"), Carbon, Atlassian e Material 3 — que proíbe exclamação especificamente em estado vazio e tarefa comum. Nossa regra é mais antiga que todas
MC7	Humor proibido em erro, bloqueio e primeiro uso. Leveza só em conclusão e sucesso, e mais contida quanto mais frequente a mensagem	NN/g ("evite humor: ele fica velho quando a pessoa vê o erro muitas vezes") · Carbon (não faça piada em estado de erro) · GOV.UK (bane "oops") · a fronteira mais precisa é do Atlassian: delight são pequenos floreios, não piada
MC8	"Por favor" e "desculpe" ficam fora.	GOV.UK e Atlassian, com racional: "por favor" faz um passo obrigatório parecer opcional; "desculpe" faz o erro parecer maior do que é. Exceção do Carbon, adotada: permitido quando a pessoa está sendo incomodada ("A indexação pode levar alguns minutos. Aguarde.")
MC9	Estrutura do erro: o que aconteceu → (por quê) → o que fazer agora. O "por quê" é condicional — entra quando ajuda a agir ou quando não há solução a oferecer	Microsoft (a estrutura canônica de três partes) · Polaris (o heading declara o efeito sobre a pessoa; o body diz como corrigir) · Atlassian (título de 3–4 palavras, sem instrução no título) · NN/g · GOV.UK
MC10	Erro nunca culpa. Proibidas as palavras `inválido`, `ilegal`, `incorreto`, `você esqueceu`, `proibido`	Convergência total: NN/g, GOV.UK (que bane até `valid`/`invalid` por não acrescentarem nada), Polaris, USWDS, Microsoft Fluent
MC11	Instrução para campo vazio, descrição para limite excedido — e consistência entre os dois. "Informe o nome do responsável" (vazio) × "O nome deve ter no máximo 35 caracteres" (limite)	GOV.UK, que é a única fonte que separa as duas formas com exemplo — e a régua é copiável
MC12	Código de erro por revelação progressiva: "Mostrar detalhes" → `Código do erro: X`, sempre acompanhado de texto de problema e solução. Um código único por causa	Microsoft. É a única das três posições que serve a um produto de engenharia com atendimento técnico: NN/g manda esconder (e o suporte perde rastreabilidade) e GOV.UK manda banir. O suporte precisa do código; a pessoa não
MC13	Confirmação existe só para o incomum e irreversível. O resto é desfazer com feedback visível — e desfazer sem a pessoa perceber que errou não serve de nada	Apple ("evite alertas para ações comuns e desfazíveis, mesmo destrutivas") · Microsoft (o exemplo canônico: excluir arquivo não confirma porque existe Lixeira) · NN/g (a fábula do lobo: confirmando demais, ninguém lê) · Material 3. A ressalva do feedback é da Microsoft
MC14	Atrito extra — digitar uma palavra para confirmar — reservado ao topo da escala: exclusão de dado de cliente, de UC ou de documento com ART emitida	NN/g é a única fonte que documenta o padrão, e ela mesma manda reservá-lo: se virar rotina, também vira automatismo
MC15	Estado vazio nomeia o CRITÉRIO que faria a lista encher, em vez de dizer que está vazia. "As propostas enviadas nos últimos 90 dias aparecem aqui"	O padrão medido no produto de referência (§9.3 do estudo) tem validação pública: NN/g cita o mesmo padrão como exemplo bom, e o Carbon manda o título ser afirmação positiva. Título orientado à ação (Polaris) e uma CTA primária
MC16	Taxonomia de estado vazio = a nossa, do §25 Z1 (seis tipos), com o mapeamento declarado para os três do Carbon: sem dado ← primeiro uso · ação da pessoa ← zero resultado de busca/filtro · gestão de erro ← sem permissão, falha de sistema, configuração necessária. Em sem permissão, dizer o processo para solicitar acesso; em configuração necessária, dar o primeiro passo	Carbon é a fonte mais completa (tem tabela de o-que-dizer por tipo de erro), e os nossos seis tipos já eram mais granulares que a referência — o mapeamento evita que alguém "adote o Carbon" e perca granularidade
MC17	PROIBIDO string que concorde gramaticalmente com valor injetado. Forma neutra por padrão ("Itens marcados com estrela aparecem aqui"); seletor de plural quando o número é informação. Toda variável leva nota de localização dizendo o que ela vale em tempo de execução	É o defeito medido no produto de referência (§9.4): "Marque um Painéis* com estrela para que apareça aqui"* — o template injeta o nome do hub no plural e funciona por acidente onde singular e rótulo coincidem. Racional da Mozilla L10n: adjetivo cujo substantivo não está na string precisa de declinação por número e gênero; e ID de string descreve o papel na interface, para desencorajar reuso entre contextos
MC18	Estado vazio nunca é mostrado antes de o dado chegar. Enquanto carrega, o lugar é do skeleton (§19) — nunca de "nenhum registro"	O segundo defeito medido (§9.4: primeiro paint em inglês, rótulos trocando quando o bundle carrega) tem fonte pública: NN/g trata "vazio exibido enquanto ainda carrega" como mensagem de status imprecisa, e diz que no melhor caso a pessoa perde confiança, no pior nunca vê o conteúdo

89.3 Registro verbal para pt-BR — a parte que só fonte brasileira resolvia#

O inglês diz "start with an imperative verb" e pronto. Em português o mesmo rótulo tem três registros possíveis e eles significam coisas diferentes: Abrir arquivo (comando), Abre um arquivo (descrição do que o comando faz), Abra um arquivo (ordem à pessoa). O GNOME Brasil é a única fonte pública que separa os três por tipo de elemento, e o guia pt-BR da Microsoft confirma o registro de menu. A tabela adotada:

Elemento	Registro	Exemplo nosso
Botão de comando, item de menu, aba, rótulo de checkbox	INFINITIVO	`Criar proposta` · `Exportar relatório` · `Configurações da conta`
Tooltip, barra de status, descrição longa, texto de ajuda contextual	PRESENTE, 3ª pessoa	`Exporta as linhas selecionadas em CSV`
Instrução dentro de formulário, campo vazio, próximo passo	IMPERATIVO	`Informe o nome do responsável` · `Publique a tabela e gere novamente`
Descrição de tipo/recurso em seletor (o padrão do §9.2 do estudo)	IMPERATIVO, por decisão de MC1 (mesma voz do rótulo que o acompanha)	`Planeje dependências e prazo`
Mensagem de erro	IMPESSOAL (MC3), com "Não é possível" para impossibilidade e "Não foi possível" para tentativa que falhou	`Não foi possível gerar a proposta`

Distinção de tempo que o guia pt-BR da Microsoft prescreve e nós adotamos: "Não é possível" = a operação é impossível naquele estado. "Não foi possível" = a tentativa ocorreu e falhou. São mensagens diferentes e a pessoa age diferente em cada uma. Também adotado dele: Falha ao + infinitivo para "failed to", e erro sempre em sentence case, mesmo quando a fonte inglesa está em title case.

89.4 Pontuação e forma#

Regra	Onde
Sem ponto final em botão, item de menu, rótulo de campo, checkbox, chip, aba	Convergência Microsoft/GNOME: rótulo curto não leva ponto
Com ponto final em tooltip, mensagem de erro, texto de diálogo, descrição longa	idem
Sem artigo em rótulo de ação: `Criar proposta`, nunca `Criar uma proposta`	Atlassian, verbatim: "evite artigos em botões, rótulos e cabeçalhos de ação"
Reticências (`…`) só quando a ação abre outra etapa que exige entrada — `Exportar…` abre diálogo; `Exportar` executa	convenção de plataforma (Microsoft/GNOME), adotada porque distingue ação imediata de ação em duas etapas
Números com o dado identificador em confirmação: `Excluir 3 propostas?`, nunca `Excluir os itens selecionados?`	NN/g (MC5)

89.5 Fronteiras declaradas#

Conteúdo de marketing e display é da §10 da marca, não desta seção.
Terminologia de domínio (unidade consumidora × UC, ART, TUSD/TE, HFP/HR) não é decidida aqui: é vocabulário técnico regulado, e um glossário próprio é trabalho da F9 (publicação), onde ele serve site, ERP e peça ao mesmo tempo. Pendência nomeada MC-P1.
Texto de e-mail transacional segue o contrato da F4 (seed-email.md); esta seção governa a UI. Onde os dois se cruzarem, o mais específico vence.
Tradução para outros idiomas está fora do escopo do DS por decisão do roadmap (PT-BR only até a operação pedir) — mas a MC17 já é a preparação: string que não concorda com valor injetado é string que sobrevive a qualquer idioma futuro.

89.6 O que fica pendente de instrumento#

A microcópia é a primeira seção deste canônico sem guarda automatizada, e isso está escrito para não passar por esquecimento. O que é mecanicamente verificável e vira guarda quando a F7.7 tiver fôlego (pendência MC-P2): rótulo de ação sem artigo · ponto final em botão · presença de inválido/ilegal /incorreto em mensagem de erro · exclamação e emoji em qualquer string de UI · OK/Sim/Não em botão de confirmação · template com placeholder seguido de substantivo (o padrão da MC17). O que não é verificável por máquina e fica no gate humano: se o "por quê" do erro ajuda a agir, se o critério do estado vazio é o critério certo, e se o registro verbal casa com o elemento.