wensity/wensity-ui-copy

Cópia de Interface Wensity

Palavras são parte do design. Uma cópia vaga ou inflada faz uma interface polida parecer genérica; uma cópia simples e específica faz uma interface simples parecer confiável. O teste para cada string: ela ajuda alguém a entender ou agir?

1. Tom de Voz

• Palavras simples. Escreva como uma pessoa prestativa falaria em voz alta. "Salvar alterações", não "Persistir modificações". "Você ficou sem créditos", não "Saldo de créditos esgotado".
• As palavras do usuário, não as do sistema. "Notificações", não "Configuração de dispatch de webhook". Nomeie as coisas pelo que as pessoas fazem com elas.
• Curto. Corte toda palavra que não mude o significado. Depois corte novamente.
• Maiúscula inicial em tudo: cabeçalhos, botões, itens de menu, abas, rótulos. "Criar novo projeto", não "Criar Novo Projeto".
• Voz ativa, dirigida ao usuário. "Você não tem acesso a este projeto", não "O acesso a este projeto não é permitido". Quando o sistema falhar, diga isso claramente: "Não foi possível salvar seu arquivo", não "O arquivo não pôde ser salvo".
• Calmo. Sem pontos de exclamação, exceto para comemorações genuínas, sem desculpas em erros, sem piadas em estados de erro.

2. Palavras que Fazem o Texto Parecer Gerado

Evite estas. Elas não dizem nada que um leitor possa verificar:

• Verbos: desbloquear, liberar, elevar, capacitar, turbinar, revolucionar, transformar, agilizar, alavancar, aproveitar, reinventar, disparar.
• Adjetivos: perfeito, sem esforço, inovador, de última geração, de classe mundial, robusto, poderoso, intuitivo, inovador, completo.
• Frases: "No mundo acelerado de hoje", "Leve seu X para o próximo nível", "Seja você um X ou um Y", "Diga adeus a", "Não procure mais".
• Formas: três adjetivos em linha ("Rápido. Seguro. Simples."), listas separadas por ponto mediano (Design · Construa · Lance) e travessões em qualquer lugar do texto do produto, incluindo o <title> da página, meta descrição e texto alternativo. Use dois pontos, uma vírgula ou duas frases: "Ledgerline: faturas em qualquer moeda".

Substitua cada um por um fato concreto: o que faz, quão rápido, para quem, com que resultado. "Reduz um relatório de 40 minutos para 2 minutos" é melhor do que "Turbine seu fluxo de trabalho".

3. Cabeçalhos

• Um cabeçalho diz o ponto, não o tópico. "Faturas são pagas 9 dias mais rápido" é melhor do que "Recursos". "Seu espaço de trabalho está vazio" é melhor do que "Espaço de trabalho".
• Sem subtítulos. Não coloque um rótulo em maiúsculas pequenas acima de um cabeçalho ("RECURSOS", "PREÇOS", "COMO FUNCIONA"). Escreva um cabeçalho que se sustente sozinho.
• Os títulos das páginas nomeiam a página para que as pessoas saibam onde estão: "Faturamento", "Membros da equipe".

4. Botões e Links

• Comece com um verbo e nomeie o resultado: "Criar fatura", "Enviar convite", "Exportar CSV". Não "Enviar", "OK", "Sim", "Clique aqui", "Saiba mais" sozinhos.
• Combine o botão com o que acontece depois. Se o botão disser "Publicar", a notificação dirá "Publicado", e a página mostrará o estado publicado.
• Primário e secundário devem ser ações claramente diferentes: "Excluir projeto" e "Cancelar", não "Sim" e "Não".
• Uma a três palavras é o ideal. Um CTA pode ir até cinco se adicionar um benefício concreto ("Comece grátis, sem cartão").
• O texto do link faz sentido sozinho (leitores de tela listam links fora de contexto): "Leia o guia da API", não "aqui".
• Ações destrutivas nomeiam a coisa: "Excluir 3 arquivos", "Remover Sam da equipe".

5. Formulários

• Rótulos acima dos campos, sempre visíveis. O texto do espaço reservado não é um rótulo; ele desaparece quando a digitação começa.
• Espaços reservados mostram formato, não instruções: [email protected], MM / AA. Deixe-os de fora quando o rótulo for suficiente.
• Texto de ajuda abaixo do campo para regras que as pessoas precisam saber antes de digitar: "Pelo menos 12 caracteres".
• Marque campos opcionais, não os obrigatórios, quando a maioria dos campos for obrigatória: "Empresa (opcional)".
• Valide ao perder o foco ou ao enviar, não a cada tecla pressionada. Mostre o erro ao lado do campo a que ele pertence.

6. Erros

Cada erro responde a duas perguntas: o que aconteceu e o que fazer agora.

Ruim	Melhor
Entrada inválida	Digite uma data posterior a hoje
Algo deu errado	Não foi possível acessar o servidor. Verifique sua conexão e tente novamente.
Erro 403	Você não tem acesso a este projeto. Peça a um proprietário para convidá-lo.
Upload falhou	Este arquivo tem 24 MB. O limite é 10 MB.
Pagamento recusado	Seu cartão foi recusado. Tente outro cartão ou entre em contato com seu banco.

• Nunca culpe o usuário ("Você digitou um e-mail inválido"). Descreva a correção ("Digite um e-mail como [email protected]").
• Mantenha códigos e rastreamentos de pilha fora da mensagem. Coloque um ID de referência no final se o suporte precisar de um.
• Mantenha o que o usuário digitou. Nunca limpe um formulário porque um campo falhou.

7. Estados Vazios

Um estado vazio é a primeira coisa que um novo usuário vê. Trate-o como integração:

1. Diga o que aparecerá aqui: "As faturas que você enviar aparecerão aqui."
2. Dê a única ação que o preenche: um botão primário, "Criar fatura".
3. Opcional: um link para importar, um modelo ou um guia rápido.

Para estados vazios de "sem resultados", diga o que foi pesquisado e como ampliar a pesquisa: "Nenhum resultado para 'fatura'. Verifique a ortografia ou limpe os filtros."

8. Carregamento, Sucesso e Notificações

• Carregamento: diga o que está acontecendo quando leva mais de um segundo: "Gerando relatório…". Use o caractere de reticências.
• Notificações de sucesso: passado da ação, mais o objeto: "Convite enviado para [email protected]", "Projeto excluído. Desfazer".
• Ofereça Desfazer em vez de uma caixa de diálogo de confirmação para ações reversíveis. Peça confirmação apenas quando a ação não puder ser desfeita.
• Caixas de diálogo de confirmação: o título faz a pergunta real ("Excluir 'Relatório Q3'?"), o corpo declara a consequência ("Isso o remove para todos. Você não pode desfazer isso."), os botões nomeiam a ação ("Excluir relatório" / "Cancelar").

9. Números, Datas e Unidades

• Use numerais: "3 arquivos", não "três arquivos".
• Formate com a localidade do usuário: Intl.NumberFormat e Intl.DateTimeFormat (ou toLocaleString) em vez de strings construídas manualmente.
• Hora relativa para eventos recentes ("2 min atrás"), datas absolutas para mais antigas ("4 de mar"), e o carimbo de data/hora completo em uma dica de ferramenta.
• Pluralize corretamente: "1 arquivo", "2 arquivos", "0 arquivos". Use Intl.PluralRules ou um auxiliar, nunca "arquivo(s)".
• Mantenha números e unidades juntos com um espaço não separável (10 MB em HTML, "10\u00A0MB" em JavaScript) para que nunca se separem.

10. Conteúdo de Espaço Reservado Realista

Ao construir um design sem conteúdo real, escreva um conteúdo que pareça real:

• Nomes e dados específicos: "Maya Chen, Designer de produto na Northwind", "R$ 12.480,00", "Fatura INV-2041". Não "João Silva", "R$ XX", "Lorem ipsum".
• Comprimentos realistas, incluindo alguns longos, para que o layout seja testado: um nome de 40 caracteres, uma descrição de 3 linhas ao lado de uma de 1 linha.
• Nunca invente provas. Nenhum logotipo de cliente inventado, classificações por estrelas, contagens de usuários ou depoimentos apresentados como reais. Use espaços reservados marcados ([Depoimento de cliente], [Logotipo]) ou peça ao usuário pelos reais.
• Combine com o mundo do produto. Os dados de amostra de uma ferramenta de desenvolvimento são repositórios e implantações; os de um aplicativo de clínica são consultas e pacientes.

11. Acessibilidade na Cópia

• Todo botão com apenas ícone recebe um nome acessível: aria-label="Fechar caixa de diálogo".
• O texto alternativo descreve o que uma imagem mostra quando ela transmite informações ("Gráfico de barras: receita aumentou 24% desde janeiro"). Imagens decorativas recebem alt="".
• Não confie apenas em palavras de cor ("clique no botão verde").
• Expanda abreviações na primeira vez, a menos que o público as use diariamente.

12. Verifique Antes de Finalizar

• Nenhuma palavra de enchimento da seção 2, nenhum slogan de três adjetivos, nenhum travessão em strings de interface.
• Cada cabeçalho declara um ponto; nenhum subtítulo.
• Cada botão começa com um verbo e nomeia seu resultado.
• Cada erro diz o que aconteceu e o que fazer.
• Cada estado vazio se explica e oferece a próxima ação.
• Maiúscula inicial em todo o texto.
• O conteúdo de amostra é específico, variado em comprimento e não contém provas inventadas.
• Controles apenas com ícone e imagens significativas têm texto acessível.