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 :)

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.

A espada não faz o cavaleiro

George R. R. Martin, autor de "Crônicas do Fogo e do Gelo" (que deu origem a Game of Thrones)
 

George R. R. Martin parece um hobbit. Da sua pena saiu o calhamaço “Crônicas do Fogo e do Gelo”, 7 livros (dois ainda a serem publicados), média de 700 páginas cada um. Deve ter por baixo uns 60 personagens. A série é mais conhecida por “Game of Thrones” e pela adaptação para a TV que a HBO (“It’s not porn. It’s HBO“) está passando. Se o seriado é bom? Bom, ele é geralmente a coisa mais pirateada do ano.

Eu disse “sai de sua pena”? Ele não escreve a saga medieval fantástica usando uma pena. Mas quase: Martin escreve seus livros usando Wordstar 4.0, rodando sobre DOS. Isto pode ser considerado medieval em computação. Wordstar era o editor de texto mais editado quando você ligava o PC e aparecia a mensagem “esperando o HD atingir a rotação adequada para funcionamento”. DOS é o sistema operacional antes que o Windows viesse a existir. Na verdade, até o Windows 95 lançado (dãh) em 1995 era um software que rodava dentro do DOS.

Anos atrás, uma dupla de designers brasileiros, Elesbão e Haroldinho, contavam como se cansavam de responder a pergunta “que soft/hard vocês usam?”. Eles defendiam que a melhor máquina ou o mais novo software não deveria interferir na qualidade do trabalho.

Usar o Microsoft Word 2013 não o fará ser um escritor comercial de sucesso. Martin prova que seu método pode usar uma ferramenta que foi lançada há 27 anos… E que os Outros me levem se ele não faz isto bem.

Mostrem o link acima quando alguém vier se gabar que usa Photoshop CSCHY versão 17 beta. Aço valiriano não faz de alguém um cavaleiro. Às vezes, basta uma agulha para fazer o serviço.

Se o sujeito é idiota o suficiente para achar que a melhor ferramenta o faz profissionalmente melhor, ele dará declaração de pós-idiotice se ele sair a procura do Wordstar, achando que isto fará dele um grande escritor.

Inércia tecnológica

Caps Lock
 

Porque o Google é o Google?

Por coisas como essa aqui: slate.com/articles/technology/good_riddance

A próxima geração do Chromebook (que não é um computador de verdade, segundo a Microsoft e o pessoal do Trato Feito, “pois não tem MS Office”) eliminará do teclado a Caps Locks. No lugar, colocarão uma tecla Search.

Faz um tremendo sentido. Eliminar a Caps Locks. Mas, e a Search? Em partes:

No texto, relembram que a Caps Locks é uma tecla herdada das máquinas de escrever (aquele negócio que ficava ao lado do toca-discos e o amuleto contra dinossauros) e quando fabricantes começaram a introduzir computadores no mercado, e o máximo que eles faziam era processamento matemático e texto (sem gráficos), copiaram o recurso das Remingtons e Olivettis para aproveitar a mesma experiência dos datilógrafos.

A tecla foi introduzida no século XIX nas máquinas de escrever. E continuam nos computadores até hoje por… Inércia tecnológica. Vão ficando lá. É como a Sys Rq ou a Scroll Lock, primas que só surgiram num advento não muito posterior à máquinas de escrever, o IBM PC XT.

Interfaces touchscreen já não tem mais a Caps Lock – mantenha o Shift pressionado e VOILÁ. Qual era a dificuldade de habilitar isto num teclado mecânico? Só a do Google vir e mostrar como se faz.

E colocar um Search no lugar, faz sentido? Para o Google, não. Sou usuário de Android deste criancinha. No Android 3.x, os celulares mantinham na interface um atalho para Search. Útil pra burro. No Android 4, declinaram deste atalho (agora tem apenas Home, Voltar e Alternar apps).

Claro, no Android 4 a busca fica a cargo do Google Now, permanente na tela. Mas que faz buscas num escopo amplo. No Android 3.x, se precisasse fazer uma busca, por exemplo, dentro do Evernote, Springpad ou Winamp… Era só clicar na tecla Search. Hoje, no Android 4, este Search fica escondido em algum menu popup. Nem sempre está à vista. No Chrome, por exemplo, o Find está depois que expomos o menu superior e clicamos para abrir o popup.

Mas para o usuário que se aventurar no Chromebook, a tecla Search à mão pode ser muito útil. Afinal, é metade do trabalho de clicar <ctrl + F>, né? Bom, isso no caso de todos softwares, pois no Microsoft Office eu acho que era <ctrl + H>. O Office, aquele conjunto de programas em que <ctrl + A> abre arquivos ao invés de selecionar tudo, <ctrl + T> não abre caixa de diálogo de textos, mas seleciona tudo. E ainda, salva-se um documento clicando <ctrl + B>, que não é negrito, pois negrito é no <ctrl + N>… que outros programas normais usam para abrir um novo documento.

Inércia tecnológica. Fica fácil inovar assim, basta só quebrar esta inércia, correto? Nem tanto. Por que até hoje usamos teclados que foram inventados quando o homem ainda usava cavalos pra voltar para casa no fim do dia? Porque até hoje não surgiu nenhuma tecnologia tão prática quanto as teclinhas.

Reconhecimento de voz? Olha, melhora na toada da Lei de Moore, sem dúvida. Mas pense num andar inteiro de gente teclando seus memorandos e agora pense no mesmo andar, de gente ditando seus emails. Teclado é uma tecnologia barata, funcional e incrivelmente discreta. Exceto por deslizes gramaticais (exceção, essessão, encheção), tem uma baixíssima ocorrência de entradas de dados dúbios.

Imagine preencher uma planilha de dados ditando-os. Assim não dá, Bionicão.

“Ah, tem o Minority Report“, dirá aquele sujeito entusiasta do design, que usa cachecol aos 35 graus Celsius e óculos retrô colorido. De fato, manter os braços erguidos apoiados em… luz, nossa, que ergonômico. Quero passar cinco dias por semana, oito horas por dia assim. Melhor que isto só aquelas telas que a gente enxerga através delas, como vimos em “Os Vingadores”.

É possível que nossos netos ainda tenham lá que lidar com seus teclados, exceto se o processamento conseguir eliminar a dubeidade ao interfaciar os bits. Claro que o avanço tecnológico pode vir a eliminar a própria interface. Computação tão avançada que pesca dados e comandos diretamente do cérebro.

Falta saber se a computação vai ficar tão singular a este ponto e não vai escravizar a humanidade antes disto. Vai ver, são os teclados que ainda nos mantém a salvos.

Página 404: como tirar proveito dela?

404 Page Not Found
 

Uma URL acessada pelo seu usuário e que na verdade não existe não deve – nem pode – ser o final da experiência dele com seu site.

Apesar de ser uma página normalmente odiada pelos usuários (ele teve a experiência bloqueada por uma página), uma página 404 bem pensada pode trazer benefícios para o site e para seus usuários.

O erro 404 acontece quando a URL acessada pelo seu usuário não existe – por erro de digitação, pela página estar indexada mesmo sem existir mais, ou por qualquer outro motivo. Nesse momento, o melhor é pensar no seu negócio e não deixar os usuários sem saída, como diz a segunda e a terceira Heurísticas de Nilsen:

Falar a linguagem do usuário: a terminologia deve ser baseada na linguagem do usuário e não orientada ao sistema. As informações devem ser organizadas conforme o modelo mental do usuário.

Ou seja, nada de deixar páginas de sistema para seu usuário. Linguagem de sistema não é facilmente compreendida pelo usuário, podendo deixa-lo sem direção e quebrando o fluxo de navegação.

404 page not found

Saídas claramente demarcadas: o usuário controla o sistema, ele pode, a qualquer momento, abortar uma tarefa, ou desfazer uma operação e retornar ao estado anterior.

O primeiro passo é conversar com os desenvolvedores do projeto, deixando claro que qualquer URL acessada sem uma página correspondente deve ser direcionada para uma página de erro 404. O segundo passo é aproveitar essa página da maneira apropriada.

A página 404 das Lojas Americanas, por exemplo, mantém o cabeçalho permitindo acesso ao menu e ao campo de busca, além de exibir produtos que estão sendo visualizados por outros clientes.

Página 404 das Lojas Americanas

Outro exemplo é essa campanha de 2011, que traz um simples gesto para ajudar o próximo. A doação consiste em, no lugar de ter sua página 404, você baixa o HTML da página 404 da AACD, e toda vez que uma URL do seu site não for encontrada, uma página sugerindo uma doação será exibida.

Página 404 da AACD

Quando o tema do seu site permite, é possível aproveitar muito bem os recursos gráficos e o lado lúdico para criar empatia com seus usuários, como é o caso da Lego e da DC Comics.

Página 404 da Lego

O site da DC Comics em especial tem um recurso interessante e prático: ele identifica o que está digitado depois da barra na URL e joga direto do campo de busca da página 404 para o usuário fazer a pesquisa apenas com um clique.

Página 404 da DC Comics

Já o Balsamiq, sendo uma ferramenta para criação de mockups, deu uma solução legal: além de permitir a busca, dá a opção para pessoas “mais visuais” navegarem pelo mapa do site para encontrar o que procuram.

Página 404 do Balsamiq

Boas práticas para uma página 404

Na hora de criar a sua página 404, fique atento a algumas dicas importantes:

  • Faça com que o seu sistema informe automaticamente qual URL acessada redirecionou para a página 404, podendo assim reparar caso seja um erro;
  • Informar o porquê aquele erro provavelmente ocorreu, pois nem todos os usuários estão familiarizados com a linguagem;
  • Permitir que o usuário diga de onde estava vindo e o que pretendia ver;
  • Mostrar links relacionados e a opção para voltar à página anterior ou inicial.

Página 404 do MailChimp

Página 404 do Shelfworthy.com

Página 404 do deliciouslycreative.com

Página 404 do odopod.com

E ai, como está a página 404 do seu site?