# Conteúdo e voz — trechos do canon ## Posicionamento e tom de voz > Sobre a SEED 2026-09-05 · §09 · byte a byte do canon · https://ds.seed.eng.br/canon/sobreaseed/09-posicionamento-e-tom-de-voz/ ## 9. Posicionamento e tom de voz ### Slogans oficiais - **Slogan principal:** *"Onde quer que esteja, conte com a experiência da SEED engenharia. Especialistas em energia há mais de uma década."* - **Tagline curta:** *"Provemos Eficiência Energética"* - **Tagline manuscrita** (assinatura quente): *"Soluções Sustentáveis"* > A especificação tipográfica das taglines (Montserrat Bold para a curta, Indie Flower para a manuscrita) está no `marca-seed.md` — este arquivo é a fonte do **texto**; aquele é a fonte da **aplicação visual**. ### Tom de voz **Acolhedor · Direto · Autêntico · Energético.** - **Use:** frases curtas, verbos de ação, dados concretos, nome do cliente. - **Evite:** jargão corporativo vazio, clichês ("inovador", "futuro melhor", "sinergia", "transformar"), caixa alta excessiva, exclamações em sequência, emojis em excesso. **Exemplos:** - ✓ *"Em fevereiro seu sistema gerou 8% acima do esperado."* - ✗ *"RELATÓRIO MENSAL DISPONÍVEL! Descubra todos os benefícios!"* - ✓ *"Esse e-mail não parece certo. Pode dar uma conferida?"* - ✗ *"ERRO: Endereço de e-mail inválido."* --- ## Grafia da marca > Marca SEED v5.37 · §01 · byte a byte do canon · https://ds.seed.eng.br/canon/marca-seed/01-grafia-da-marca-regra-visual-e-verbal/ ## 1. Grafia da marca (regra visual e verbal) **"SEED engenharia"** — SEED em caixa alta, "engenharia" em minúsculo. Inegociável em qualquer peça. Nunca "SEED Engenharia", "Seed Engenharia" ou "SEEDENGENHARIA". *(Regra duplicada intencionalmente aqui e no `sobreaseed.md` por ser crítica nos dois contextos.)* --- ## Linguagem editorial > Marca SEED v5.37 · §10 · byte a byte do canon · https://ds.seed.eng.br/canon/marca-seed/10-linguagem-editorial-novo-na-v5-0/ ## 10. Linguagem editorial (novo na v5.0) O rigor que diferencia o material SEED de template: - **Eyebrow/label micro** abre seções: CAPTION 11px, UPPERCASE, tracking 2px, cinza-500 — em Montserrat SemiBold ou JetBrains Mono Medium (acento técnico). - **Displays falam frases completas, com ponto final.** "Tudo o que evoluiu, em um só lugar." — não "NOVIDADES!!!". Título é afirmação, não grito. - **Hierarquia por peso e espaço, não por cor.** Cor em título é exceção com função (H3 brand), não regra. - **Respiro generoso:** margens de seção ≥ `sp-12` (48px) em documentos, ≥ `sp-16` (64px) em landing pages. Na dúvida, mais branco. - **Números são protagonistas:** dados da SEED (+1.000 obras, +50.000 painéis) em destaque tipográfico com fonte/contexto — e valores de medição sempre em mono. - Sem emojis em material de marca. Ícones: a biblioteca SVG do DS. --- ## MICROCÓPIA DE INTERFACE > Componentes v1.43 · §89 · byte a byte do canon · https://ds.seed.eng.br/canon/seed-componentes/89-microcopia-de-interface-estavel-2026-08-24-f7-7/ ## 89. 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. --- ## 1.7 Microcopy — regras de rótulo > Componentes v1.43 · §01 · 1.7 · byte a byte do canon · https://ds.seed.eng.br/canon/seed-componentes/01-botao-estavel/#sec-1-7-microcopy-regras-de-rotulo-tom-seed ### 1.7 Microcopy — regras de rótulo (tom SEED) 1. **Verbo + objeto, sentence case:** "Solicitar diagnóstico", "Enviar proposta", "Baixar relatório". Nunca "CLIQUE AQUI", nunca "Submeter". 2. **1 a 3 palavras.** Se precisa de mais, o problema é o contexto, não o botão. 3. **Destrutivo nomeia a consequência:** "Excluir proposta" (não "Confirmar", não "Sim"). Em diálogo de confirmação, o par é "Cancelar" + "Excluir proposta". 4. **Loading mantém o rótulo** — sem trocar para "Aguarde..." (o spinner já diz isso). 5. **Sem exclamação, sem urgência falsa** ("Aproveite JÁ!") — o tom SEED é direto e sincero. 6. Exemplos calibrados: ✅ "Ver proposta" · "Falar com engenheiro" · "Calcular economia" | ❌ "Saiba mais!!" · "Clique e descubra" · "OK". ## 2.8 Microcopy — tom SEED > Componentes v1.43 · §02 · 2.8 · byte a byte do canon · https://ds.seed.eng.br/canon/seed-componentes/02-form-field-campo-de-formulario-estavel-validado/#sec-2-8-microcopy-tom-seed-vocabulario-pt-br-alinhado-ao-gov-br ### 2.8 Microcopy — tom SEED (vocabulário PT-BR alinhado ao gov.br DS: rótulo, texto auxiliar, mensagem) 1. **Rótulo:** substantivo curto, sentence case, sem dois-pontos. "Unidade consumidora", "E-mail", "CNPJ". Nunca instrução no rótulo. 2. **Texto auxiliar:** 1 linha, diz FORMATO ou PORQUÊ. "Somente números." · "Está na sua fatura de energia, no canto superior." **Nunca indica obrigatoriedade** (regra Uber: esse espaço é de formato/erro). 3. **Erro = o que houve + como corrigir, na voz SEED (direto, acolhedor, sem culpar):** ✅ "CPF incompleto — digite os 11 números." · "CEP não encontrado — confira ou preencha o endereço manualmente." | ❌ "Erro no campo." · "Entrada inválida." · "Você digitou errado." Específico > genérico (Baymard: "CEP curto demais" > "Inválido"). 4. **Dado pessoal explica o porquê (LGPD + prática fintech):** texto auxiliar do CPF: "Usamos seu CPF apenas para emitir a proposta." Coleta sem porquê visível é atrito e risco. 5. **`(opcional)` literal em minúsculas** no produto; formulário público de conversão usa `*` + legenda "Campos com * são obrigatórios" no topo (B3).