E-mail marketing e automaçãoVídeos de marketing e vendas

Entendendo os desafios (e frustrações) do design de email HTML

Se você abrir um sistema de gerenciamento de conteúdo para criar páginas da web, será um processo bastante simples. Suporte a navegadores modernos HTML, APFe JavaScript de acordo com padrões rígidos da web. E são apenas alguns navegadores com os quais os designers precisam se preocupar. Existem exceções, é claro… e algumas soluções simples ou funções específicas para esses navegadores.

Devido aos padrões gerais, é simples desenvolver construtores de páginas em sistemas de gerenciamento de conteúdo. Os navegadores estão em conformidade com HTML5, CSS e JavaScript... e os desenvolvedores podem criar soluções incrivelmente robustas para criar páginas da Web que respondam aos dispositivos e sejam consistentes em todos os navegadores. Há duas décadas, praticamente todos os web designers usavam software de desktop para desenvolver páginas da web. Agora, é bastante incomum para um web designer desenvolver uma página web – na maioria das vezes, eles estão desenvolvendo modelos e usando editores em sistemas de conteúdo para preencher o conteúdo. Os editores de sites são fantásticos.

Mas os editores de e-mail estão lamentavelmente atrasados. Aqui está o porquê…

Projetar e-mails em HTML é muito mais complexo do que para um site

Se sua empresa deseja um belo e-mail em HTML, o processo é exponencialmente mais complexo do que construir uma página da web por vários motivos:

  • Sem padrões – NÃO há adesão estrita aos padrões da web por parte dos clientes de e-mail que exibem e-mail em HTML. Praticamente todos os clientes de e-mail e todas as versões de cada cliente de e-mail agem de maneira diferente. Alguns honrarão CSS, fontes externas e HTML moderno. Outros respeitam alguns estilos embutidos, exibem apenas uma coleção de fontes e ignoram tudo, exceto estruturas baseadas em tabelas. É bastante ridículo que ninguém esteja trabalhando nesta questão. Como resultado, projetar modelos que sejam renderizados consistentemente em clientes e dispositivos tornou-se um grande negócio e pode ser bastante caro.
  • Segurança do cliente de e-mail – Recentemente, o Apple Mail foi atualizado para bloquear por padrão todas as imagens em e-mails HTML que não estão incorporadas no e-mail. Você dá permissão para carregar um e-mail por vez ou precisa ativar as configurações para desativar essa configuração. Junto com as configurações de segurança do cliente de e-mail, também existem configurações corporativas.
  • Segurança de TI – Sua equipe de TI pode implantar conjuntos de regras estritos sobre quais objetos podem realmente ser renderizados em um email. Se suas imagens, por exemplo, vierem de um domínio específico que não está na lista de permissões de um firewall corporativo, as imagens simplesmente não aparecerão em seu e-mail. Às vezes, tivemos que desenvolver e-mails e hospedar todas as imagens no servidor da corporação para que seus próprios funcionários pudessem ver as imagens.
  • Provedores de serviços de e-mail – Para piorar as coisas, os construtores de e-mail que fornecem serviços de e-mail (ESPs) realmente introduzem problemas em vez de restringi-los. Embora eles promovam seu editor como What You See Is What You Get (WYSIWYG), o oposto costuma ser verdadeiro com o design de e-mail. Você visualizará o e-mail em sua plataforma e o destinatário verá todos os problemas de design. Muitas vezes, as empresas optam, sem saber, por um editor rico em recursos em vez de um editor bloqueado, pensando que ele tem mais recursos. O oposto é verdadeiro… se você deseja e-mails que sejam renderizados de forma consistente em todos os clientes de e-mail, quanto mais simples, melhor, porque menos pode dar errado.
  • Renderização do cliente de e-mail – Centenas de clientes de email renderizam HTML de maneira diferente em desktops, aplicativos, dispositivos móveis e clientes de webmail. Embora o editor de texto bacana do seu provedor de serviços de e-mail possa ter uma configuração para colocar um cabeçalho no seu e-mail, o preenchimento, as margens, a altura da linha e o tamanho da fonte podem ser diferentes para cada cliente de e-mail. Como resultado, você precisa simplificar o HTML e codificar cada elemento de maneira diferente (veja o exemplo abaixo) – e muitas vezes escrever exceções específicas do cliente de e-mail – para que um e-mail seja renderizado de forma consistente. Não existem tipos de blocos simples, você precisa criar layouts baseados em tabelas que sejam equivalentes à construção para a web de trinta anos atrás. É por isso que qualquer novo layout requer desenvolvimento e teste de cliente e dispositivo de e-mail cruzado. O que você vê na sua caixa de entrada pode ser totalmente diferente do que vejo na minha caixa de entrada. É por isso que ferramentas de renderização como E-mail sobre ácido or Tornassol são essenciais para garantir que seus novos designs funcionem em todos os clientes de e-mail. Aqui está uma pequena lista de clientes de e-mail populares e seus mecanismos de renderização:
    • Uso do Apple Mail, Outlook para Mac, Android Mail e iOS Mail WebKit.
    • Uso do Outlook 2000, 2002 e 2003 Internet Explorer.
    • Uso do Outlook 2007, 2010 e 2013 Microsoft Word (sim, palavra!).
    • Os clientes de webmail usam o respectivo mecanismo do navegador (por exemplo, o Safari usa o WebKit e o Chrome usa o Blink).

Um exemplo de HTML para Web vs. E-mail

Se você quiser um exemplo que ilustre a complexidade do design no e-mail versus a web, aqui está um exemplo perfeito do artigo do Mailbakery 19 grandes diferenças entre e-mail e HTML da Web:

HTML do e-mail

Devemos construir uma série de tabelas incorporando todo o estilo embutido necessário para posicionar o botão corretamente e garantir que ele tenha uma boa aparência nos clientes de e-mail. Uma tag de estilo acompanhante também estará no topo deste e-mail para incorporar as aulas.

<table width="100%" border="0" cellspacing="0" cellpadding="0">
   <tr>
      <td align="left">
         <table border="0" cellspacing="0" cellpadding="0" bgcolor="#43756e">
            <tr>
               <td class="text-button"  style="padding: 5px 20px; color:#ffffff; font-family: 'Oswald', Arial, sans-serif; font-size:14px; line-height:20px; text-align:center; text-transform:uppercase;">
                  <a href="#" target="_blank" class="link-white" style="color:#ffffff; text-decoration:none"><span class="link-white" style="color:#ffffff; text-decoration:none">Find Out More</a>
               </td>
            </tr>
         </table>
      </td>
   </tr>
</table>

HTML Web

Podemos utilizar uma folha de estilo externa com classes para definir o caso, alinhamento, cor e tamanho de uma marca âncora que aparece como um botão.

<div class="center">
   <a href="#" class="button">Find Out More</a>
</div>

Como evitar problemas de design de e-mail

Problemas de design de email podem ser evitados seguindo um processo decente:

  1. Teste de modelo – Compreender os clientes de e-mail que seus assinantes utilizam e garantir que seu e-mail HTML seja totalmente testado em dispositivos móveis e desktops é fundamental antes de implantar qualquer modelo. Podemos criar um e-mail literalmente a partir de um layout do Photoshop... mas dividi-lo em um cliente de e-mail cruzado baseado em tabela é essencial para implantar designs de e-mail que sejam ideais e consistentes.
  2. Testes internos – Depois que seu modelo for projetado e testado, ele deve ser enviado para uma lista interna de sementes dentro da organização para revisão e aprovação. Você pode até querer começar com um subconjunto muito limitado de indivíduos para primeiro garantir que não haja problemas de firewall ou segurança associados à renderização do email internamente. Se isso estiver criando uma instância em um novo provedor de serviços de e-mail, você pode até encontrar alguns problemas de filtragem ou bloqueio associados ao envio de seu e-mail para a caixa de entrada.
  3. Versão do modelo – Não altere seus layouts ou designs sem trabalhar em uma nova versão do seu modelo que possa ser projetada, testada adequadamente e implantada. Muitas empresas adoram designs únicos para cada campanha... mas isso exige que cada email seja projetado, desenvolvido e implantado para cada campanha. Isso adiciona muito tempo ao processo de email marketing interno. E você corre o risco de não entender quais elementos em seu email estão tendo um bom desempenho em relação a quais elementos não estão. A consistência não é apenas uma maneira de facilitar o processo, também é importante para o comportamento de seus assinantes.
  4. Exceções do provedor de serviços de e-mail – Praticamente todo provedor de serviços de e-mail tem um meio de contornar os problemas que seu construtor de e-mail apresenta. Muitas vezes, podemos adicionar CSS bruto a uma conta – ou até mesmo ter um bloco de conteúdo que deve ser incluído em todos os e-mails – para que a empresa utilize o editor de e-mail integrado e não quebre o design do seu e-mail. Claro, isso pode exigir algum treinamento e controle de processo para implantar essas etapas para garantir que sejam cumpridas. Ou – você pode literalmente querer apenas desenvolver seu design de e-mail em uma solução que comprovadamente funciona em clientes e dispositivos e colá-la novamente em seu provedor de serviços de e-mail.

Plataformas de design de e-mail

Como as plataformas de serviço de e-mail fizeram um trabalho ruim na criação e manutenção de construtores consistentemente renderizados entre clientes e dispositivos, várias plataformas excelentes chegaram ao mercado. Um que usamos extensivamente é Stripo.

Stripo não é apenas um construtor de e-mail, eles também possuem uma biblioteca de mais de 900 modelos que podem ser facilmente importados. Depois de criar o e-mail, você pode enviar e-mail para mais de 60 ESPs e clientes de e-mail, incluindo Intuit MailchimpName, HubSpot, Campaign Monitor, AWeber, eSputnik, Outlook e Gmail. O melhor de tudo é que os modelos Stripo vêm com testes de renderização de e-mail incluídos para que você possa garantir que foram testados e funcionam de forma consistente em mais de 40 clientes de e-mail.

Faça login na demonstração do editor Stripo

Douglas Karr

Douglas Karr é CMO de AbrirINSIGHTS e o fundador da Martech Zone. Douglas ajudou dezenas de startups de MarTech bem-sucedidas, auxiliou na due diligence de mais de US$ 5 bilhões em aquisições e investimentos da Martech e continua a auxiliar empresas na implementação e automatização de suas estratégias de vendas e marketing. Douglas é um especialista e palestrante em transformação digital e MarTech reconhecido internacionalmente. Douglas também é autor publicado de um guia para leigos e de um livro sobre liderança empresarial.

Artigos Relacionados

Voltar ao topo botão
Fechar

Adblock detectado

Martech Zone é capaz de fornecer a você esse conteúdo sem nenhum custo porque monetizamos nosso site por meio de receita de anúncios, links de afiliados e patrocínios. Agradeceríamos se você removesse seu bloqueador de anúncios ao visualizar nosso site.