Conteúdo e voz
Como a SEED escreve
Grafia da marca, slogans e tom de voz, linguagem editorial e microcópia de interface — os trechos abaixo são o canon, byte a byte, cada um com a procedência e o link para o lugar de origem. Nada foi reescrito para esta página.
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."
"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.)
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.
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.
- Verbo + objeto, sentence case: "Solicitar diagnóstico", "Enviar proposta", "Baixar relatório". Nunca "CLIQUE AQUI", nunca "Submeter".
- 1 a 3 palavras. Se precisa de mais, o problema é o contexto, não o botão.
- Destrutivo nomeia a consequência: "Excluir proposta" (não "Confirmar", não "Sim"). Em diálogo de confirmação, o par é "Cancelar" + "Excluir proposta".
- Loading mantém o rótulo — sem trocar para "Aguarde..." (o spinner já diz isso).
- Sem exclamação, sem urgência falsa ("Aproveite JÁ!") — o tom SEED é direto e sincero.
- Exemplos calibrados: ✅ "Ver proposta" · "Falar com engenheiro" · "Calcular economia" | ❌ "Saiba mais!!" · "Clique e descubra" · "OK".
- Rótulo: substantivo curto, sentence case, sem dois-pontos. "Unidade consumidora", "E-mail", "CNPJ". Nunca instrução no rótulo.
- 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).
- 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").
- 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.
(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).