5 coisas que aprendi em um projeto Mobile-First Responsive Design para o Google

Nos últimos meses trabalhei em um projeto para o Google em que propusemos a construção de um site usando os conceitos de Responsive Design e de Mobile First. Este post foi feito para compartilhar algumas das lições aprendidas durante o processo e incentivar que essa abordagem seja utilizada por mais designers e desenvolvedores brasileiros.

O artigo foi escrito com a ajuda do Diego Tres, que foi o líder técnico do projeto em questão. O Diego trabalha como Senior Front-End Engineer na R/GA, estuda Responsive Design há um bom tempo e é um grande entusiasta de UX.

Google Creative Sandbox: do que trata o projeto?

Quem trabalha em agências de publicidade sabe que as ideias mais disruptivas geradas pelo time de Criação muitas vezes não chegam a ser produzidas. Às vezes são ideias consideradas “arriscadas” pelo time de marketing das empresas parceiras e por isso são mais difíceis de saírem do papel. Outras vezes o problema é simplesmente o timing ou o budget do projeto.

Essas ideias, ao invés de serem produzidas, permanecem guardadas no moleskine do criativo — esperando a hora certa de acontecerem.

Foi então que o Google e a R/GA decidiram criar a Google Box — uma espécie de “urna high-tech” — que está circulando pelas maiores agências digitais do país e coletando as ideias que estão guardadas nos cadernos dos criativos. Uma ideia na rua vale muito mais do que uma ideia no moleskine, certo?

O que essa caixa faz? Ela recebe as ideias escritas à mão pelos criativos e as tritura logo em seguida. Alguns minutos depois, você recebe um email do Google pedindo que vá até o site do projeto e confirme a publicação da ideia triturada recebida.

Acontece que esse público (o profissional de criação de agência) possui algo bem peculiar quanto aos seus hábitos de navegação na web: eles acessam sites a partir de uma grande variedade de dispositivos: celulares, desktops, laptops e tablets.

Pensando nisso, a R/GA optou por um approach Mobile-First na hora de desenvolver o site que hospeda as ideias enviadas pelos criativos. Uma experiência diferente pensada para cada dispositivo.

O que é esse tal de “Mobile-First Responsive Design”?

Uma coisa comum em alguns times de Design é começar o projeto pensando na versão desktop do site. Existe uma certa tradição no jeito que os designers estão acostumados a trabalhar: a web nasceu no computador e só depois começou a popular outros dispositivos como smartphones e tablets. E a cabeça do designer, por inércia, acaba funcionando da mesma maneira.

O problema é que a cabeça dos usuários não funciona assim. Elas querem acessar o “site”; pouco importa se irão acessar a versão “desktop” ou a versão “mobile” do mesmo.

Leia também: O que é Responsive Web Design?

Já participei de muitos outros projetos onde o time de Design de Interação começou pela versão desktop do site. Assim também começa o time de Visual Design e a equipe de Desenvolvedores. O que acontece, muitas vezes, é que em determinado momento o time “magicamente” se lembra de que o site também precisa ser visualizado em celulares. O que o designer faz, então, é tentar adaptar o conteúdo do site desktop que está em desenvolvimento para uma versão mais “estreita” que será lida por smartphones.

É o famoso método “aperta-pra-caber”. E isso não é Mobile-First Responsive Design.

O maior problema desse approach que costumávamos ter é que o designer passava dias tentando “cortar” conteúdo para que ele coubesse em uma tela menor.

Mas essa não é necessariamente a solução que as pessoas precisam quando estão navegando no celular.

Um exemplo prático. Se você entra no site de um restaurante enquanto está em casa, sentado no computador, é provável que você tenha tempo de ver fotos do ambiente, saber quem é o chefe da cozinha e conhecer algumas das opções do cardápio. Mas se você acessa o mesmo site do celular, possivelmente você está dentro do carro, parado em fila dupla, e precisa confirmar o endereço em menos de 5 segundos.

São funções diferentes que o site assume dependendo do contexto de uso.

“Every device does not need to have the same experience. Trying to maintain the same experience in all devices is dated. It is an obsolete approach. People understand different devices provide different experiences.” -Jeffrey Zeldman

Entender esse contexto e pensar qual o conteúdo mais relevante para cada caso é um trabalho que pode/deve ser feito a quatro mãos pelo Desenvolvedor e pelo UX Designer. Sem esse pensamento inicial, o Design Responsivo fica sendo apenas uma “firula tecnológica” — e não se torna relevante para as pessoas.

Então vamos às 5 lições:

1. O mesmo site se adapta para diferentes dispositivos

O endereço do site é sempre o mesmo. Nada de digitar “m.enderecodosite.com” ou “www.enderecodosite.com/mobile”.

Parece um pouco óbvio, mas para o usuário isso é interessante porque ele não precisa pensar se quer navegar na versão mobile, tablet ou desktop. A transição entre um dispositivo e outro também acaba sendo mais suave, já que a URL das páginas é exatamente a mesma cá e lá.

Para os desenvolvedores isso é interessante porque significa que um único site será construído — poupando o problema de lidar com diferentes versões do mesmo site na hora de fazer sua manutenção ou evolução.

[caption id=”attachment_4827" align=”alignnone” width=”826"]

Header do site também se adapta a diferentes resoluções[/caption]

A navegação e a arquitetura da informação do site devem ser pensadas para cada situação. No site do Google Creative Sandbox, a navegação que antes estava recolhida sob o item “Menu” na versão mobile agora já aparece aberta na versão desktop. Outra preocupação é a relação entre header global, header local e footer; foi importante levar em conta que quanto menor o dispositivo, menos tempo as pessoas costumam navegar.

Existem vários padrões que estão sendo criados na hora de reorganizar o layout do site da versão Mobile para a versão Desktop. À capacidade do site de se adaptar automaticamente entre um dispositivo e outro, dá-se o nome de Adaptive Layout. Se você quer dar uma olhada em alguns exemplos de como isso acontece, sugiro visitar o mediaqueri.es, e se quer conhecer mais sobre os padrões de Adaptive Layout recomendo este post do blog do Luke W.

2. O conteúdo varia em cada resolução

Se você está acessando o site do celular, é pouco provável que queira (ou que tenha banda suficiente) para navegar por uma galeria de vídeos e assistir um a um. Se você está acessando o site do seu grandioso iMac, é possível que você seja um designer e se importe bastante com o acabamento visual da interface e com seu próprio conforto na hora de ver o conteúdo do site.

Ao invés de simplesmente “fazer caber” na resolução do usuário, criamos um raciocínio diferente para cada situação de uso. Os elementos e funcionalidades que aparecem na tela variam; o jeito de navegar varia; o tempo que você tem para ler textos varia. E é óbvio que não existe “mouse-over” se você está navegando em um tablet e usando seu próprio dedo como ponteiro.

A imagem abaixo explica melhor o exemplo da homepage do site. O conteúdo usado para explicar a proposta do Creative Sandbox foi diferente na versão Desktop, na versão Tablet e na versão Mobile. Repare que a quantidade de texto também muda de uma versão para outra.

[caption id=”attachment_4824" align=”alignnone” width=”826"]

Conteúdo varia na homepage do site[/caption]

Isso exigiu um trabalho muito próximo entre o UX Designer e o Desenvolvedor. Precisava ficar muito claro para ambos quais conteúdos seriam carregados e exibidos em cada versão do site. E os ciclos de iteração entre os dois profissionais eram curtos e constantes: as mudanças eram acertadas em tempo real durante o desenvolvimento, rabiscadas em papel e documentadas simultaneamente pelo designer. Noções de Visual Design por parte do time também ajudam a agilizar o processo: se tivéssemos feito um arquivo PSD para cada resolução diferente, precisaríamos de um batalhão de Visual Designers trabalhando ao mesmo tempo.

O texto também precisou ser ajustado à medida em que o site ia sendo desenvolvido; a agilidade no processo foi um diferencial importante para que o projeto coubesse no prazo estimado. Se você está acostumado com uma metodologia “em cascata” (onde seu trabalho termina depois da entrega do wireframe), talvez esteja na hora de reorganizar o time e repensar algumas práticas.

Leia também: O que é Lean UX?

As imagens do site também mudam dependendo da resolução. Não faz sentido carregar uma imagem de 640x480 pixels se ela será vista em uma tela muito menor que isso. Mas não se trata apenas de fazer um redimensionamento automático na imagem e deixá-la com o mesmo peso em kilobytes: o html precisa exibir uma versão reduzida da mesma imagem, ou então uma imagem diferente. Ou em muitos casos simplesmente ocultar a imagem se ela não for realmente importante para a experiência mobile.

Para reduzir as imagens, precisamos levar em conta o conteúdo delas. Quando você reduz uma imagem onde o sujeito da foto é dominante, a redução de tamanho funciona sem problemas. Repare no exemplo abaixo que, mesmo no menor tamanho, você ainda percebe que a foto contém “uma mão segurando um iPhone”:

[caption id=”attachment_4857" align=”alignnone” width=”640"]

Imagem responsiva quando o sujeito da foto é dominante[/caption]

Mas quando o conteúdo da foto é menor, reduzir não é a melhor solução. Se você reduz, o sujeito da foto não fica nítido o suficiente.

[caption id=”attachment_4858" align=”alignnone” width=”640"]

Imagem responsiva quando o sujeito da foto é menor[/caption]

Nesses casos é preciso pensar na melhor forma de cortar a foto para que o usuário continue enxergando o que há de mais importante nela. Esse é o tipo de decisão que precisa ser pensada caso a caso, para cada imagem do site.

3. O carregamento deve ser progressivo

Agora olhando um pouco para o código do site: o caminho mais curto seria fazer o navegador carregar a versão desktop do site e depois simplesmente “ocultar” da tela os blocos de conteúdo que não devem ser exibidos se o usuário está navegando no celular. Mas se você faz isso, você força o usuário a carregar um conteúdo que não será visualizado e a gastar um dos recursos mais preciosos que ele tem quando acessa o site de um smartphone: kilobytes de dados transferidos.

Ao trabalhar com carregamento progressivo (progressive enhancement), você carrega apenas os módulos que são essenciais para aquele dispositivo em que o usuário está navegando. A própria ordem de carregamento foi pensada para não onerar uma pessoa que esteja vendo o site em seu celular.

Na prática, o código do site é um só. À medida em que você aumenta a resolução da tela, o html do site faz novas requisições em ajax do conteúdo que ainda não havia sido carregado na versão menor do site. Mas é preciso achar um meio-termo, pois não é todo conteúdo que precisa ser recarregado com novos requests em ajax; alguns deles são mais leves e já podem vir ocultos no próprio html da página.

4. É preciso escolher os melhores breakpoints

“Breakpoints” são as larguras de tela (em pixels) onde o site começa a se transformar e adicionar conteúdo extra dependendo do dispositivo onde você está navegando. Por exemplo: a partir dos 410px de largura, entendemos que o usuário não está mais navegando em um smartphone no modo “retrato”, e sim no modo “paisagem”. E então servimos a ele um conteúdo e uma interface específica para aquele tipo de navegação.

Os breakpoints escolhidos para este projeto foram:

• Mobile
• Mobile Landscape
• Tablet
• Tablet Landscape
• Desktop

Faça um teste: abra o site do Creative Sandbox em uma nova aba e tente redimensionar o browser até que ele fique do tamanho aproximado de uma tela de celular. Você vai perceber que existem alguns “momentos-chave” nesse processo de resize onde o conteúdo é ocultado, reposicionado ou editado para dar mais conforto ao usuário.

Não existe uma fórmula certa para escolher os breakpoints, porque isso depende do público-alvo do projeto e do tipo de dispositivo mais comum entre esses usuários. Nesse ponto, vale um pouco de pesquisa para entender quem é o visitante e quais tipos de aparelhos ele possui.

Uma coisa para ter em mente é que esse processo de escolha de breakpoints não é a solução visual definitiva para o site. Quando você determina a largura da versão “Mobile Landscape” do site (ex: dos 350 aos 640 pixels), você precisa lembrar que alguns usuários possuem iPhone, outros possuem Samsung Galaxy, outros possuem Motorola. E esses gadgets, mesmo quando estão todos no modo paisagem, possuem larguras diferentes em pixels. O layout do site precisa funcionar bem durante todo o range de pixels.

5. O aprendizado também é responsivo

Esse foi só um projeto e tenho certeza que muitos outros virão — cada um deles trazendo novos aprendizados a respeito de Responsive Design e Mobile First. Espero que eu consiga compartilhar mais coisas por aqui.

Abaixo uma lista de perguntas que me foram bastante úteis antes de começar a etapa de Design de Interação do projeto. Ela ajudou a levantar a discussão sobre a versão mobile e tablet do site com o restante do time — e também a reunir argumentos que ajudaram a justificar a importância do Responsive Design no projeto.

• Quem é o público-alvo do projeto e que tipo de dispositivos ele usa no dia-a-dia?
• Em que contexto ou hora do dia ele irá acessar esse website?
• Em que dispositivos ele possivelmente irá acessar esse website?
• Quais as tarefas que ele quer realizar no site?
• Quais dessas tarefas ele fará do celular? E de um tablet? E do computador?
• O projeto possui “saídas sociais”? O conteúdo é compartilhado no Google Plus, no Facebook, no Twitter? Esse usuário acessa essas redes sociais do celular? Sendo assim, o celular se torna um ponto de entrada relevante para o site?
• Existe disparo de emails para o usuário? Esse usuário lerá o email no celular? Sendo assim, o celular se torna um ponto de entrada relevante para o site?
• Qual a audiência esperada para o site? Em linhas gerais, qual a porcentagem de novos usuários e qual a de usuários que retornam?
• Qual o tempo de navegação esperado para o site? Em quanto tempo ele consegue cumprir cada tarefa? E as tarefas que serão feitas pelo celular ou tablet?
• O projeto se trata de um redesign? Se sim, quais as estatísticas de acesso do site antigo em cada tipo de dispositivo?

Ponto e vírgula.

Há alguns dias aconteceu o An Event Apart 2012, em Austin. Mais de metade das palestras falavam de Responsive Design, Mobile Trends, Mobile First, Responsive Typography e assuntos relacionados. Foi interessante acompanhar a cobertura do evento e perceber que está surgindo um movimento natural por parte dos designers e programadores em começar a entender mais e executar projetos Responsive.

Leia também: mais posts do @blogdeai sobre Responsive Design

O fato é: não existe “jeito certo” ou “jeito errado” de se fazer sites adaptáveis a múltiplos dispositivos. Adoraria ouvir depoimentos de pessoas que trabalharam em sites com esse mesmo approach, e também que usam técnicas diferentes.

O que existe é uma comunidade de designers e desenvolvedores quebrando a cabeça e criando soluções para a multiplicidade de dispositivos que temos hoje. E se ajudando, acima de tudo. Learn from the community, give something back to the community.