O SEO dos sites Responsivos

O SEO dos sites Responsivos
 

Nos últimos dias começaram a pipocar na web uma série de notícias dizendo que o novo algoritmo do Google pode dificultar a vida das pequenas empresas, o que não passa de uma grande besteira sensacionalista. O Google está apenas privilegiando em seu algoritmo de busca os sites que proporcionam uma boa experiência mobile para os seus usuários, principalmente aqueles que possuem uma estrutura responsiva.

Já faz um certo tempo que o Google age dessa maneira. Há pelo menos um ano e meio eu digo para os meus alunos do curso de Design Responsivo que o “gigante das buscas” deixa muito claro o padrão de design que ele recomenda:

Sites que usam Web Design Responsivo, isto é, sites que funcionam em todos os dispositivos com o mesmo conjunto de URLs, com cada URL fornecendo o mesmo HTML a todos os dispositivos e usando apenas CSS para alterar como a página é processada no dispositivo. Essa é a configuração recomendada pelo Google.

Desde que o Google existe, muitos profissionais do chamado “marketing de busca” estão sempre tentando encontrar formas de burlar o funcionamento de seu algoritmo (sim, é isso que o SEO faz) para privilegiar suas páginas nos resultados de busca. O que o Google vem fazendo em contra-partida é priorizando como critério de indexação os sites que proporcionam uma boa experiência para os usuários. Dessa forma, questões como validação social e bounce rate ganham cada vez mais importância do que a quantidade de palavras-chave.

A cada dia, são vendidos mais iPhones do que nascem bebês. Fonte: http://www.lukew.com/ff/entry.asp?1506

A cada dia, são vendidos mais iPhones do que nascem bebês. Fonte: http://www.lukew.com/ff/entry.asp?1506

A verdade é que não são apenas as pequenas empresas que correm o risco de verem os seus sites afundando no mar de resultados de busca. Hoje, a grande maioria dos sites, independente do porte da empresa, não proporcionam uma boa experiência mobile (uma fatia significativa é ruim inclusive no desktop). O que está sendo decretado não é o fim de qualquer empresa, mas sim de profissionais que insistem em técnicas arcaicas de web design e SEO, e colocam o marketing acima da experiência do usuário.

Adotar uma abordagem Mobile First não é mais uma questão de pensar no futuro, e sim de estar antenado com o presente.

Be Quick Or Be Dead!

UX no E-commerce: a importância dos testes de usabilidade

UX no E-commerce: a importância dos testes de usabilidade
 

A maioria dos e-commerces atualmente utilizam em sua estrutura as mesmas convenções de interface (disposição dos menus, formatos dos destaques, campo de busca e call-to-action, por exemplo), o que traz uma certa segurança em relação à curva de aprendizado para os usuários, já que não existem grandes novidades entre um e outro. Porém, isso faz com que tenhamos muitos sites idênticos, que proporcionam experiências parecidas.

Já vi algumas lojas tentarem inovar no modelo e formato da interface (e toda experimentação é digna de aplausos). O problema é fazer experiências seguindo a própria intuição ou suposições, sem qualquer teste com usuários que possam validar a interface. O resultado dessa falta de testes pode ser, em muitos casos, uma considerável queda nas vendas.

A maioria dos sites de e-commerce utilizam as mesmas convenções de interface.

A maioria dos sites de e-commerce utilizam as mesmas convenções de interface.

É importante que todo e-commerce procure proporcionar aos usuários experiências diferenciadas dos seus concorrentes, mas toda estrutura visual e funcional de uma interface deve ser criada com base em pesquisas com usuários, e validada com os mesmos através de testes de usabilidade. É essencial proporcionar interações fluidas de acordo com o modelo mental de seus clientes, com um número mínimo de tarefas para atingir o objetivo final (a compra), fornecendo diferentes filtros de pesquisa para se chegar ao produto ideal, disponibilizando informações detalhadas de maneira organizada para cada item, assim como maneiras eficientes de comparar esses produtos. Mas, se nada disso for testado e validado com usuários, será apenas um tiro no escuro. Meras suposições e achismos.

No Congresso de Marketing & Vendas organizado pelo E-commerce Brasil no último dia 13 de março, Horácio Soares perguntou para uma plateia de mais de 1000 profissionais de e-commerce “quem costuma aplicar testes de usabilidade em suas lojas?”, e não foi surpresa (infelizmente) ver que apenas uma meia dúzia de gatos-pingados levantaram a mão. Também costumo comprovar essa triste realidade durante o workshop UX Weekend, onde na maioria das vezes utilizamos sites de e-commerce para aplicar Testes de Usabilidade ou Card Sorting com os alunos, e é impressionante a quantidade de problemas de interface e navegação que encontramos nesses sites somente nesses pequenos testes simulados. Isso tudo só comprova que a grande maioria das lojas brasileiras não têm investido como deveriam em UX e Usabilidade, e com certeza estão perdendo dinheiro com isso, até porque muitas pesquisas já nos mostram que a experiência dos usuários em breve será mais importante que o preço, como diferencial competitivo.

Teste de Usabilidade em E-commerce, durante o workshop UX Weekend em Florianópolis

Teste de Usabilidade em E-commerce, durante o workshop UX Weekend em Florianópolis

A verdade é que os e-commerces que mais aumentam suas taxas de conversão são aqueles que realizam testes com usuários em suas interfaces. Mesmo os pequenos detalhes nas interações podem otimizar a experiência dos usuários e proporcionar grandes resultados. Um ótimo exemplo disso é a famosa história do pequeno ajuste em um botão feito após a aplicação de testes de usabilidade, que fez com que um e-commerce aumentasse as vendas em 45%, o que proporcionou um faturamento adicional de U$S 300 milhões no primeiro ano. Outro bom exemplo é o que faz a Amazon, que mesmo não possuindo um site atrativo esteticamente, possui uma interface muito funcional, por se preocupar com detalhes que fazem toda a diferença para uma interação fluida e prazerosa, como é o caso do trabalho feito no seu menu dropdown.

Sei que os E-commerces hoje preferem se agarrar ao Marketing, e enxergam a Usabilidade somente como um plus, um adendo em que poderão investir quando tiverem mais tempo e dinheiro. Alias, a falta de tempo de dinheiro para contratar uma consultoria costuma ser a desculpa mais usada pelas empresas para não se dedicarem a usabilidade. Mas não caiam nessa. Como já nos mostrou Steve Krug em seu livro Simplificando coisas que parecem complicadas, não precisamos de tanto tempo e dinheiro assim para testar a usabilidade com usuários.

Não se esqueçam de que não basta apenas trazer novos usuários para a sua loja, pois é a boa experiência de uso que poderá reter de fato esses clientes ;)


Leia também: UX no E-commerce: mapeando a jornada do consumidor

Design Responsivo: as Media Queries são só um detalhe

Design-Responsivo--as-Media-Queries-são-só-um-detalhe
 

É com muita frequência que vejo pessoas que querem aprender a criar sites responsivos publicarem em grupos e listas de discussão algo como “quero aprender design responsivo… como uso as Media Queries?” ou então “O que é melhor para começar a aprender Design Responsivo: Bootstrap ou Foundation?”. Também é comum encontrar designers dizendo que a responsabilidade de fazer com que um layout torne-se responsivo é do Front-Ender, e que eles não precisam se preocupar com isso.

Tudo errado!

Associar os esforços para o desenvolvimento de uma interface responsiva a etapa de Front-End é um dos maiores equívocos atuais do desenvolvimento web.

Ethan Marcotte, o cara que cunhou o termo Responsive Web Design, publicou o primeiro texto sobre o assunto no A List Apart em maio de 2010. O que eu acho mais interessante nesse texto são as “categorias” na qual o Ethan classificou esse texto: CSS, Layout & Grids, Mobile/Multidevice, Responsive Design, Interaction Design. Isso mostra por si só a multidiciplinaridade de conhecimentos necessários para desenvolver um site responsivo. Para criar o conceito, Ethan se inspirou em uma ideia mais antiga, a Arquitetura Responsiva, aonde os espaços e ambientes podem se adaptar a condições pre-definidas ou desejáveis, por meio de sensores, de acordo com os diferentes contextos.

Contexto! Essa é a palavra chave.

O Design Responsivo não é apenas uma questão tecnológica de adaptação para diferentes dispositivos, mas sim uma adaptação para diferentes contextos. Desenvolver interfaces com layouts e conteúdos flexíveis e adaptáveis a uma ampla variedade de resoluções de tela, dispositivos e, principalmente, contextos de uso.

As pessoas consomem conteúdo e interagem com os dispositivos de maneiras diferentes de acordo com o contexto em que se encontram. A forma que uma pessoa navega por um site sentada em uma mesa de escritório em um computador com teclado e mouse, com uma tela espaçosa, boa conexão e um ambiente razoavelmente controlado é bem diferente da forma que essa mesma pessoa faria se estivesse no metrô com um smartphone de tela pequena e sem luz adequada, conexão instável e ambiente caótico, segurando o dispositivo com uma única mão e interagindo sem precisão com um dedo gordo e engordurado. Nesses diferentes contextos, as pessoas têm disposições diferentes para consumir conteúdo. O tempo e o ritmo são diferentes, e a forma e quantidade de informação que estamos dispostos a consumir são proporcionalmente opostas.

Criar um site responsivo não consiste simplesmente em aplicar Media Queries ao código para espremer os conteúdos de forma um pouco mais amigável em telas menores. Aquilo que o usuário irá visualizar em um smartphone precisa ter mais foco e ser mais enxuto. Não temos espaço nem tempo disponíveis para conteúdos de relevância duvidosa, e por isso precisamos projetar uma interface mais específica e adequada, o que nos obriga a dar mais atenção à áreas como Arquitetura de Informação, Usabilidade e Acessibilidade. Entre o Desktop e o Mobile, precisamos estabelecer uma escala hierárquica de importância das informações textuais e gráficas do site, e com isso repensar a pertinência de apresentação dessas informações em diferentes contextos e dispositivos. Não se trata apenas do tamanho da tela, mas sim do contexto em que o usuário se encontra.

Para que essa adaptação a diferentes contextos e dispositivos aconteça de forma adequada, precisamos de uma interface com caracteristicas bem específicas como um Layout Fluido com um Design Adaptativo. A estrutura fluida, onde todas as medidas utilizadas são relativas (porcentagem ao invés de pixels, por exemplo) permitirá que o site se adapte em pequenas variações de tamanhos de tela, como por exemplo a diferença entre um iPhone 6 e um iPhone 6 Plus. Por outro lado, em variações de telas maiores, como a diferença entre um iPad e um iPhone, provavelmente a interface fluida se quebraria, e uma parte do conteúdo se tornaria irrelevante. Nessa situação, precisamos de um layout adaptativo, ou seja, quando o site encontrar um desses pontos de quebra (Break Points), o layout e o conteúdo irão se recompor para serem exibidos de uma maneira mais adequada e adaptada.

Exemplo de metodologia de Design feito diretamente no navegador. Fonte: https://medium.com/@astralwave/designing-for-outcomes-a6484e1682cc

Exemplo de metodologia de Design feito diretamente no navegador. Fonte: https://medium.com/@astralwave/designing-for-outcomes-a6484e1682cc

A questão chave é que para implementar todo esse dinamismo no código, além de conhecer bem os usuários e os diferentes contextos de uso, é preciso ter um projeto de design muito bem definido. E, para projetar o design dessas interfaces, um meio estático como o Photoshop não nos ajuda da maneira adequada. Nessas horas é que Designers e Front-Enders precisam dar as mãos, desde a concepção até a implementação dessas interfaces. No projeto de Design Responsivo é onde começam a fazer mais sentido as metodologias de Designing in the Browser, onde a partir de Sketchs, wireframes e um guia de estilo, o layout é desenvolvido diretamente no navegador com a ajuda de um inspetor de código como o Firebug. É uma maneira ágil e consistente e projetar e testar possibilidades e limitações reais simultaneamente.

Para que um site responsivo proporcione uma boa experiência para os usuários, além de layout fluido e design adaptativo, é necessária uma boa otimização de desempenho, o que pode ser feito muito bem por um designer que entende minimamente de código, e um front-ender que entenda minimamente de design.

Designer e Front-enders, sejam amiguinhos. Cada vez mais vocês vão precisar um do outro ;)

Google e o mito da garagem

Google e o mito da garagem
 

Lendo o artigo “A verdade oculta das ‘empresas de garagem’ do Vale do Silício” no El País, dois trechos me chamaram a atenção:

Há ainda a do número 232 da Santa Margarida Avenue, em Menlo Park. Essa foi alugada em 1998 por dois jovens, Larry Page e Sergei Brin, para desenvolver uma jovem empresa chamada Google. A garagem continua surpreendentemente intacta hoje. Com o tapete azul que a então proprietária da casa, Susan Wojcicki, hoje executiva-chefe do YouTube, instalou para que os inquilinos se sentissem mais à vontade. A mesa de pingue-pongue onde se distraíam.

Tudo disposto para que o mito pareça real e nada relembre que, na realidade, o Google foi fundado dois anos antes; já havia arrecadado mais de um milhão de dólares de vários investidores; e a economia que representava alugar uma garagem em vez de um escritório era risível. E mais, em janeiro de 1999, depois de apenas cinco meses pisando no tapete azul, os nove empregados do Google se mudaram para escritórios convencionais. Mas a garagem está ali, é propriedade da empresa desde 2006, e os lucros que gera em seu mito institucional são incalculáveis.

Céus! E quando eles descobrirem que as banquinhas de limonadas que as crianças americanas montam na porta de casa são subsidiadas pelas fundos familiares dos empreendedores?

Dei um bizu no pai dos burros da internet para procurar a quantidade de patentes de dois países, comparativamente, a título de curiosidade:

Pedidos de patentes em 2012:
EUA: 542815
Brasil: 30116

O que isto tem a ver com a carocha da garagem? Ela é conceitual.

Quando o Steve Jobs, lá de sua garagem criou os ícones do iOS, nenhuma reportagem veio dizer que aquela câmera não era uma câmera de verdade, mas meramente uma representação que ativava as rotinas para o celular fotografar. O ícone era conceitual. Ele contava uma história (o termo correto é “esqueomorfismo”). Seu cérebro via o ícone de câmera e imediatamente, sem precisar tirar um MBA em interfaces, sabia o que aconteceria ao clicá-lo.

É engraçado tratar um cérebro como um ente, mas ele muitas vezes funciona assim mesmo. Você não se detém numa análise detalhada que aquele ícone é de uma câmera, e não procura em todos os registros visuais de uma vida um matching de imagem para julgar que se trata de uma câmera fotográfica, nem faz alusões aos Daguerreótipos para finalmente concluir que aquilo ali é para fotografar. Seu cérebro faz isto sem você ter consciência de todos estes processos. São processos subconscientes acionados por conceitos.

Steve Jobs na juventude.

Steve Jobs na juventude.

E vejam só, o país aonde o conceito da garagem é ecoado, fez 18 pedidos de patentes, enquanto o país aonde implantam o conceito no subconsciente de que precisamos perseguir a segurança de um cargo público concursado, registrou uma patente.

A questão pode evoluir para outros conceitos arragaidos. Há tempos se questiona que a colonização protestante dos EUA determina hoje seu sucesso industrial. Embora seja tão cristão quanto a colonização brasileira, os protestantes tem uma diferença: sua conduta valoriza o trabalho como meio de aprimoramento do caráter. Já a tradição cristã ibérica passou a tradição da efemeridade da vida e que o trabalho árduo que os pobres tem que suportar será recompensado… depois de morrerem.

Não lembro de o El País trazendo reportagens dizendo que passagens cristãs (concepção imaculada, assunção de Maria ou com quem Caim teve filhos para formar a humanidade) não tem correlação com passagens bíblicas, ou mesmo passagens bíblicas não batem com registros naturais (o dia que Terra parou, o dilúvio, ou o tal do Apocalipse), mas ainda assim, as estórias inspiraram o empreendedorismo nos EUA.

Nossos cérebros tem uma linguagem poderosa de conexão: são metáforas, conceitos e estórias. Ninguém nunca disse que eles precisavam ter reflexo na realidade. Elas só precisavam acionar nossos cérebros para implantar uma ideia.

Novamente: o país que implantou a ideia do empreendedorismo de garagem pediu o registro de 18 patentes enquanto o país aonde trabalhar é fardo de pobres, pediu um registro.

Naturalmente, os EUA não registra mais patentes só por causa do mito da garagem (a China não o tem até aonde eu saiba, e registram muito mais). Mas eu só estava plantando uma ideia sobre a importância de cultura que estimula ideias empreendedoras.

The Grid: Web Designers ficando obsoletos?

The Grid
 

É, se a tecnologia anda roubando um monte de empregos por aí (felizmente as máquinas ainda não conseguem fazer trocadilhos, assegurando meu emprego), com web designers não seria diferente:

Este é o The Grid. Basicamente é um serviço que analisa seu conteúdo e define automagicamente até as cores num web design responsivo. Tudo usando aqueles minúsculos sul-coreanos que moram dentro de softwares de inteligência artificial.

Funciona assim: ao invés de ter um editor que você arrasta o conteúdo, estica e encolhe até caber na tela, este Server vai fazer uma parada de inteligência artificial para pegar o conteúdo e manjar até as cores que nele vai entrar. Como são computadores e eles são bons em tarefas repetidas, a coisa já vai com design responsivo. O problema é que é possível que os sites usando a inteligência artificial, em algum momento, fiquem com a mesma cara. Mas vamos ser honestos: todos os sites feitos pelos humanos tem a mesma cara. Chamam isso de “tendência”.

Tá em beta, e lançam a parada por roubados $25 no ano que vem. Dá tempo para vocês, web designers, aprenderem alguma profissão que não tem chance das máquinas fazerem melhor. Cobrar para fazer cafuné, por exemplo.

Projetando com Lean UX

Projetando com Lean UX
 

No dia 04 de fevereiro de 2015 aconteceu na 8º edição da Campus Party Brasil a palestra “Projetando com Lean UX”. Nela, eu e a minha amiga Diana Fournier procuramos apresentar como a abordagem Lean pode nos ajudar a encontrar a verdadeira natureza do nosso trabalho.

Abaixo, disponibilizo o vídeo e os slides da palestra.

A área da Experiência do Usuário é muito baseada em entregáveis, e quando somamos a isso a herança de abordagem cascata que a maioria das empresas ainda trabalha, temos como efeito uma área departamental e burocrática. A ideia de projetar para a Experiência do Usuário deve ser compreendida como uma cultura, e não como uma disciplina ou departamento. Precisamos fazer com que todos aqueles cujo trabalho geram de alguma forma impacto na Experiência do Usuário mantenham foco nas pessoas durante todo o projeto, e aprendam a trabalhar de forma colaborativa.

Lean UX: Edu Agni e Diana Fournier

Quando somamos ao nosso processo a visão do Design Thinking, temos a possibilidade de lidar com os nossos projetos com base na empatia, colaboração e experimentação, agrupando todos os envolvidos dentro de uma mesma finalidade comum. Incluir nessa abordagem colaborativa uma metodologia ágil vai nos permitir simplificar o desenvolvimento de produtos/serviços, nos livrando do excesso de entregáveis e trabalhando apenas com documentos rápidos, colaborativos e facilmente editáveis, com menos ênfase nos resultados e maior foco na experiência real do usuário.

Assim, o nosso objetivo passa a ser colocar o quanto antes um protótipo funcional na mão do usuário final, testando e corrigindo os possíveis erros, trabalhando com a ideia de um mínimo produto viável em constante evolução, e avançando para uma próxima versão. Afinal, a tentativa e erro colaborativa tem mais sucesso que o planejamento do gênio solitário :)

Mínimo produto viável

Acessibilidade vs Navegadores Antigos: uma escolha que pode custar caro

Acessibilidade vs Navegadores Antigos
 

Vou te propor uma experiência. Procure os desenvolvedores front-end que você conhece, desde novatos até os ninjas, e faça três perguntas:

  1. Na sua opinião, o que gera mais acessos para um site: pessoas com deficiência ou pessoas com navegadores antigos?
  2. No seu trabalho, qual é a maior exigência: fazer sites acessíveis ou sites que funcionem em navegadores antigos?
  3. Você testa, ou possui alguém na sua equipe que teste o nível de acessibilidade dos sites desenvolvidos?

Infelizmente, esse tipo de experiência nos leva a triste conclusão de que [1] os desenvolvedores não testam a acessibilidade dos projetos que codificam, [2] não se preocupam em desenvolver um site acessível da mesma forma que se preocupam em desenvolver um site que funcione nos navegadores antigos, e [3] sequer sabem que existem mais pessoas com deficiência do que usuários de versões antigas do Internet Explorer.

Uma em cada cinco pessoas possuem alguma deficiência

O número pode parecer um exagero, mas não é. Mesmo que algumas deficiências como as auditivas ou uma miopia que exija o uso de óculos possam “quase” não dificultar o uso da web, tornar um site acessível fará com que essas pessoas tenham uma experiência mais consistente, e trará benefícios que vão além de simplesmente atender essa faixa de usuários.

23,9% dos brasileiros declaram ter alguma deficiência. A deficiência visual foi a que mais apareceu entre as respostas dos entrevistados e chegou a 35,7 milhões de pessoas. Pelo estudo, 18,8% dos entrevistados afirmaram ter dificuldade para enxergar, mesmo com óculos ou lentes de contato. – IBGE, no Censo Demográfico 2010

Se nos atentarmos ao fato de que usuários de versões antigas de certos navegadores normalmente representam algo em torno de 1% ou 2% dos acessos aos sites, podemos facilmente perceber que algo está muito errado na prioridade que os desenvolvedores e Stakeholders dão as necessidades dos usuários que precisam ser atendidas.

O retorno sobre investimento dos sites acessíveis

Profissionais que primam por boas práticas de desenvolvimento, quando argumentam sobre a necessidade de cuidados e prazo adicional para melhorias de acessibilidade, eventualmente barram em gestores com uma visão de negócio retrograda, e justificativas do tipo “cegos não compram”. Os mesmos gestores costumam afirmar que é indispensável manter suporte a navegadores anciões, pois na visão deles existem muitas pessoas que ainda utilizam versões antigas do Internet Explorer.

Trabalho com soluções em e-commerce há anos e nós continuamos tendo maior renda com investimento em acessibilidade do que se importando com Internet Explorer 6/7/8- Christophe Porteneuve (@porteneuve)

Afinal, o que está errado? Será que o diretor de algum e-commerce ou portal de notícias (ou pessoas em seu nome) intencionalmente tomaria uma decisão estratégica ruim?

Na verdade, o mais provável é que essas pessoas acabem priorizando requisitos de forma errada por desconhecimento dos dados. A falta de informação faz com que stakeholders e desenvolvedores deem mais importância em manter a compatibilidade dos sites com o Internet Explorer 7 ou 8 do que fazê-los mais acessíveis.

É importante que todos os envolvidos em um projeto web tenham em mente que, caso tenham que decidir entre um e outro, manter o suporte a navegadores antigos proporciona um menor impacto na qualidade e acaba custando mais caro do que zelar por acessibilidade.

Acessibilidade não é apenas para cegos

Um contra-argumento extremo, que geralmente é utilizado para desqualificar quem defende a implementação de acessibilidade, é que ela faria diferença apenas para cegos, e que, por existirem poucos cegos, não vale o custo de investimento. Essa afirmação é extremamente parcial.

Saiba que implementar a acessibilidade melhora o acesso a informação também de pessoas sem qualquer deficiência. Vários de seus princípios, que já eram pregados há décadas, hoje são populares como recomendações de usabilidade, e claro, também ajudam nos processos de conversão, como as vendas de um e-commerce. Isso explica porque, mesmo que o percentual de pessoas utilizando navegadores antigos fosse o mesmo que o das pessoas com alguma deficiência, ainda assim investir em acessibilidade abrangeria mais usuários. Praticamente 100% dos usuários são beneficiados.

Testar e melhorar seus sites para leitores de tela também melhora indexação feita pelos sistemas de busca. Leitores de tela, que são os sistemas usados por pessoas cegas ou com baixa visão, requerem que o código HTML esteja no mínimo escrito de forma semântica, contendo significado suficiente para que as máquinas também o compreendam. Um erro comum é a estrutura de títulos inadequada: mesmo que visualmente um título esteja com tamanho e cor em destaque em uma página, ele pode ter sido implementado usando uma marcação com hierarquia incorreta no HTML. Ao testar seu site com leitores de tela, você pode identificar mais facilmente alguns erros de estrutura, como os que fariam os atributos de um produto vendido ser confundido com os de outro produto na mesma página, ou mesmo com um espaço para publicidade de terceiros, o que poderia gerar vantagens em segmentos bem concorridos para buscas orgânicas no Google.

Como melhorar a situação geral

Conscientização é a chave do negócio. Ao trabalhar em equipe, sempre que você notar essas escolhas técnicas não ideais por parte de outras pessoas, mesmo que não sejam de sua área, questione e mostre uma referência técnica, ou mesmo uma ferramenta de validação automática. Designers costumam aceitar bem a ideia de um design universal. Desenvolvedores front-end também costumam aceitar sugestões de melhoria.

Acessibilidade não é um tema novo, mas para muitos ainda é uma novidade quando vai além do atributo “alt” nas imagem. Dar importância a isso não é algo apenas sobre ajudar cegos. Sites acessíveis possuem melhor alcance dos resultados. E a cada pequena ação nessa direção, você estará tornando a web um lugar melhor.

Acessibilidade não é um mero custo a mais. Acessibilidade é investimento.

Outline: até mesmo os grandes portais estão fazendo errado

Outline: até mesmo os grandes portais estão fazendo errado
 

Vá agora em https://gsnedders.html5.org/outliner/ e submeta um site seu. O sumário de tópicos faz sentido com o conteúdo que a página apresenta visualmente? Se este não for o caso, você não está sozinho: 8 dos 10 sites de brasileiros mais acessados na época em que este artigo foi publicado também estão fazendo errado.

Verificação do outline de grandes portais brasileiros em 28 de setembro de 2014

Verificação da estrutura Outline da página inicial de grandes portais brasileiros, em 28 de setembro de 2014. “Contextos nomeados” significa que não existem alertas do tipo “Untitled Section”, e “Estrutura não pobre” significa que a página possui ao menos os cabeçalhos básicos.

Para ter acesso ao código fonte e o Outline gerado por cada um dos sites analisados, visite https://github.com/alligo/outline-sites-brasileiros.

Problemas em páginas com cabeçalhos mal estruturados

Sites com uma estrutura de títulos malfeita geram dois tipos de problemas distintos: de acessibilidade para humanos, de interoperabilidade para máquinas. A intensidade do problema gerado é proporcional aos erros observados. Títulos ausentes, redundantes ou mesmo não suficientemente descritivos são um problema.

Algumas técnicas de navegação através de páginas que pessoas com problemas visuais — que usam leitores de tela — utilizam se baseiam em atalhos de teclado e comandos de voz que se valem destes cabeçalhos. Assim, páginas mal-estruturadas limitam esse tipo de navegação.

Mecanismos de busca também dependem de títulos para saberem ao que se referem os blocos de texto presentes em uma página. Páginas pobres podem não só perder relevância como também fazer mecanismos de busca associarem textos de um bloco ao último cabeçalho encontrado. Um título “Sobre o produto XPTO” pode agrupar textos relacionado a propagandas de terceiros por erro de implementação. Todos os grandes e-commerces brasileiros hoje são péssimos exemplos de que, aparentemente, no Brasil a única coisa que é levada em conta é o título da página. E isso é ruim, além de custar caro em termos de relevância e ranqueamento no Google e demais buscadores.

Estrutura de documentos

É provável que arquitetos da informação, antes mesmo de fazerem protótipos de tela, façam um esboço dos tópicos que as telas deverão ter. Tais esboços podem não ser um entregável formal, mas ainda assim costumam ser feitos, mesmo que mentalmente. Esses esboços estão para uma página em HTML como um sumário está para um livro.

O ponto importante é que, geralmente, um wireframe ou um design não é suficientemente claro para desenvolvedores implementarem a estrutura que o arquiteto imaginou. E a julgar pela frequência com que esse tipo de erro ocorre no resultado final de projetos grandes, não são apenas erros de profissionais individuais, mas da forma como todo ciclo de desenvolvimento é realizado.

Implementação HTML de estrutura e validação de outline

Compare um livro a uma página da web. O equivalente em HTML ao título que aparece na capa do livro é implementado com a tag <title>. Sem isso, sua página não possui nem mesmo um HTML válido. Por aparecer em destaque nos mecanismos de busca e na barra de título de navegadores, essa tag costuma ser bem cuidada. Porém o que a maioria absoluta das implementações erra é a estrutura do documento, o equivalente ao sumário de um livro. E a forma de verificar isso não é com validadores de sintaxe HTML como o http://validator.w3.org, mas sim com ferramentas que verificam a estrutura Outline como o https://gsnedders.html5.org/outliner.

Documentos HTML descrevem implicitamente o sumário através de tags de cabeçalho (h1, h2, h3, h4, h5, h6). Cada vez que usamos uma delas, nós criamos um contexto, que é uma espécie de agrupamento onde há uma relação forte entre os elementos contidos. Se os cabeçalhos seguintes são de nível menor, ainda estaremos dentro do mesmo contexto, porém se forem de nível igual ou maior, criamos um novo contexto, onde todas as informações daquele agrupamento tem forte relação. Alguns elementos do HTML5 também forçam criação de um contexto – por exemplo as tags nav, article, aside e section – e por isso é fortemente recomendável que contenham ao menos um cabeçalho, ou a validação da estrutura Outline irá acusar erros do tipo “Untitled Section”, mesmo que um validador de sintaxe HTML não dê qualquer alerta, da mesma forma que não daria para um site feito unicamente com um JPEG.

Você pode ler mais a respeito deste assunto em https://developer.mozilla.org/pt-BR/docs/Sections_and_Outlines_of_an_HTML5_document.

Por que tantos sites, mesmo famosos, estão com estrutura errada?

Isso ocorre provavelmente pelo desconhecimento de ferramentas que verificam a estrutura Outline das páginas e, claro, usá-las para validar (re-)implementações. Desenvolvedores conhecem o validador de sintaxe HTML, mas não o de estrutura de tópicos. Em uma enquete informal feita na Conferência Web.br 2014, os únicos que conheciam tais ferramentas eram os profissionais que trabalhavam com acessibilidade para web. Mesmo os palestrantes da maior conferência sobre padrões web no Brasil desconheciam o validador de estrutura Outline.

Muitas vezes podemos nos deparar com sites mais amadores que os nossos, que ainda assim possuem uma estrutura Outline melhor. Isso é muito comum em boa parte dos sites que usam temas prontos, aonde algum desenvolvedor estrangeiro já entregou pronta uma boa estrutura de tópicos.

Quem é responsável por garantir outline correto de páginas?

Independente da situação, o desenvolvedor que codifica o HTML deve ser responsável por garantir que a estrutura de cabeçalhos esteja condizente com design ou qualquer outro documento que receba. Na falta de documentos que não são suficientemente claros – situação extremamente comum na implementação das tags nav ou aside - mesmo para designs ou wireframes bem descritos, é necessário o suporte do arquiteto de informação.

É polêmico dizer que um Arquiteto de Informação deva saber HTML, porém é extremamente coerente que seja sua responsabilidade definir a estrutura de documentos. Aqui recomendamos que, ao menos ao final do processo de desenvolvimento do HTML, o responsável pela Arquitetura de Informação utilize um validador de estrutura Outline ou, como recurso menos confiável, extensões para Chrome e Firefox, garantindo que a informação passada de forma visual também esteja semanticamente coerente.

Autores

Este artigo aborda 1 dos 10 tópicos da palestra “Considerações técnicas para atlas temáticos digitais e interfaces para dados abertos”, realizada na Conferência Web.br 2014 em 25 de setembro de 2014 e disponível em http://pt.slideshare.net/alligoweb/webbr2014-atlas-e-interfaces-para-dados-abertos. Os autores são:

  • Emerson Rocha Luiz, Full stack developer & coacher @ Alligo – @fititnt
  • Juliana Fernandes, UX Designer @ DUX Coworking – @julianafrost
  • Tasso Evangelista, Desenvolvedor de sistemas de informação @ Alligo – @tassoevan

UX no E-commerce: mapeando a jornada do consumidor

UX no E-commerce: mapeando a jornada do consumidor
 

Quando eu falo em experiência do usuário, não me refiro somente à experiência de uso que uma pessoa possa ter com a interface de um site. A experiência do usuário deve ser entendida como o ciclo de relacionamento de um cliente com a marca, ou seja, precisamos entender todos os pontos de interação que esse usuário terá com o e-commerce, desde a ativação que leva o consumidor até ele, a avaliação dos produtos e das condições de compra, a tarefa da compra, a experiência pós-compra, o atendimento e a lealdade conquistada para que ele volte a comprar.

A Jornada do Consumidor (Consumer Journey) é um método para conceitualizar e estruturar o conteúdo de um serviço e suas funcionalidades. Explora o modelo mental do usuário e  seus padrões comportamentais, processos e caminhos vividos, traduzindo essa bagagem em experiência. Este método pode ser  utilizado em conjunto com métodos correlatos como: personas, cenários e fluxogramas de interação. Via Corais.

Caso um usuário encontre em suas interações com a marca algum ponto falho, ou mesmo uma barreira como um problema na interface no momento da compra, a demora na entrega de um produto ou um e-mail não respondido, além da possibilidade de se perder um cliente, isso pode gerar um depoimento negativo que influenciará um grande número de usuários na sua decisão de compra. Em uma situação utópica, supondo que o seu cliente não encontre nenhuma barreira nas interações com a sua marca, devemos ainda levar em consideração que em todos os pontos de contato com um produto ou serviço o cliente busca uma motivação que o leve a continuar dentro deste ciclo, ou seja, se não tivermos recursos para motivar os usuários a todo o momento, podemos facilmente perder uma venda para um concorrente mais interessante.

Tanto para evitar barreiras como para renovar motivações, precisamos entender quais são as necessidades, desejos e limitações dos usuários. E para isso é necessário inserir nossos clientes no centro da concepção de nossos projetos. Esses usuários precisam participar do processo de desenvolvimento da interface e validar os rumos do nosso projeto. Com o usuário próximo, devemos pesquisar sobre seus hábitos de consumo, seus comportamentos, realizar entrevistas qualitativas e testes de usabilidade. Então, a partir de personas e/ou usuários reais, devemos mapear todas as diferentes jornadas dos clientes com nossa marca, produto ou serviço. Somente assim poderemos entender melhor todo esse ciclo de relacionamento para atendê-los da melhor maneira possível.

Alunos do curso UX Weekend em Brasília, mapeando a jornada do consumidor.

Alunos do curso UX Weekend em Brasília, mapeando a jornada do consumidor de um e-commerce a partir de Personas.

Pense nas necessidades do usuário e do conteúdo associado em uma linha do tempo. Ou seja, você precisa ter um começo, meio e fim. Após isso, coloque-se no modelo mental de seu usuário e imagine como as necessidades e prioridades mudam através de todo o andamento do processo. Via Corais.

Com um número cada vez maior de ferramentas sociais disponíveis, as pessoas vêm levando muito em conta a “validação social” na hora de comprar um produto. Os usuários deixaram de ser passivos na frente de uma TV, assistindo um intervalo comercial, e passaram a compartilhar as suas experiências com produtos e serviços com outras pessoas através de ferramentas como Facebook e Twitter. Hoje, muita gente já não realiza uma compra sem antes ler os comentários dos usuários sobre o produto ou os depoimentos naquele site de reclamações, por exemplo. Muitas pessoas ficam mais ansiosas para postar fotos e comentários sobre os produtos adquiridos do que para utilizá-los de fato. Elas querem compartilhar com as outras pessoas a experiência que têm com o objeto em questão e aguardar os comentários. Boas experiências compartilhadas levam outros usuários a buscar a mesma experiência bem sucedida.

Mapear a jornada do consumidor nos ajuda a entender todo o ciclo de relacionamento de um cliente com uma marca, produto ou serviço, para que possamos renovar motivações e remover barreiras em todas as interações, proporcionando assim a melhor experiência possível. Afinal, clientes felizes e satisfeitos são leais, compartilham as suas experiências positivas, influenciam as decisões de compra de outras pessoas, compram mais, e compram sempre :)


Leia também: UX no E-commerce: a importância dos testes de usabilidade

Percebendo usuários: erros, de quem é a culpa?

Percebendo usuários: erros, de quem é a culpa?
 

Sempre que estou testando algo, aguardo até o final do teste para questionar o usuário sobre os “erros” durante a experimentação: “Maria, percebi que você se atrapalhou um pouco quanto pedi que realizasse a tarefa. O que você acha que aconteceu?”. Na maioria das vezes, Maria responde que ficou perdida e por isto não conseguiu concluir a tarefa. Da mesma forma, questiono de quem ela acredita ser a culpa pelo erro, e, mais uma vez, Maria diz que é culpada, pois, acredita não ter habilidades e/ou precisar melhorar sua fluência com o mundo digital.

Já pensou como o design pode impactar a vida de um usuário? Interfaces confusas podem ser desastrosas e colocar a vida das pessoas em risco.

Este exemplo é simples e objetivo. Ele não colocou a vida de ninguém em risco, mas, revelou um usuário angustiado, frustrado, desacreditado de suas habilidades e capacidades cognitivas e que sem dúvida está arrasado por não conseguir executar tal tarefa com “virtude e precisão”. Logo, a culpa virou um sentimento de inferioridade. Este sentimento é frequentemente inconsciente e pode levar os indivíduos ao desapontamento e ao estresse, pois, a maioria dos usuários acreditam que são responsáveis por não conseguir navegar ou alcançar seu objetivo durante a navegação de um website.

“As doenças mentais podem estar bastante ligadas a esse sentimento de inferioridade se o indivíduo passa a ser cobrado e questionado a respeito da sua performance.” VIA

O verdadeiro problema

Negligenciar o sentimento dos sujeitos em relação a erros, contribuirá para o mau humor da pessoa que está realizando o teste; deixará insatisfeita, triste e com sentimentos de inferioridade. É eminente analisar e conversar com os usuários para melhorar nossas ferramentas, mas, é importante considerar a analise da sensação e da frustração em relação ao erro como parte do processo.

Freud propôs que quanto mais angustiado estivermos, mais fortes os mecanismos de defesa ficam ativados. Isto quer dizer que, quando o usuário “está” errado, o ego entende que está em perigo e irá considerar a situação como ameaçadora, ativando assim, seus mecanismos de defesa.

“Mecanismos de defesa são processos subconscientes que procuram soluções para conflitos não resolvidos ao nível da consciência.” VIA 

Racionalização é um mecanismo de defesa, parte consciente e parte inconsciente, no qual as falhas e os erros são perdoados e desculpados, tanto para o próprio sujeito como perante os outros, de modo a que seja preservada a autoestima do sujeito. O ego ajusta-se à realidade não só tendo em conta a realidade das coisas, mas também as necessidades narcisistas e instintivas do indivíduo. O sujeito apoia-se num raciocínio lógico para explicar os seus sentimentos e emoções que não controla. Torna racionais e coerentes pensamentos e ações inaceitáveis cujos mecanismos inconscientes lhe escapam, e com esta atitude tenta disfarçar os seus conflitos internos perante si e perante os outros.

É uma forma de aceitar a pressão do superego, de disfarçar os verdadeiros motivos e de tornar o inaceitável mais aceitável. Enquanto obstáculo ao crescimento, a racionalização impede a pessoa de aceitar e de trabalhar com as forças motivadoras genuínas, apesar de menos recomendáveis” VIA

Sendo assim, é indispensável observar a pessoa como um todo! Conflitos geram angustias. Se fizer com que o usuário se sinta mal, ele tentará racionalizar a fim de atender as nossas expectativas em relação a experimentação, buscando assim, ajustar-se com as perspectivas esperadas.

É importante lembrar que a empatia faz parte do método e isto essencial; só assim podemos entender a experiência do outro.