User Experience – Guilherme Chapiewski

Porquê eu não gosto de desenvolver sites usando Flash

Uma vez estava no carro com minha esposa procurando um lugar para jantar (porque o primeiro lugar que fomos estava lotado). Um amigo me recomendou uma pizzaria que é bem popular aqui em São Paulo e decidimos ir para lá, mas primeiro queria ver se eles não estavam com fila de espera também. Quando entrei no site do restaurante para pegar o telefone e ligar… não funcionou porque o site é feito em Flash – que não funciona no iPhone.

Quem me acompanha no Twitter já deve ter percebido há tempos que eu não sou muito fã de Flash, mas quando eu faço os meus “rants” fica parecendo que eu não gosto pura e simplesmente porque sou fã de carteirinha do iPhone.

Se fôssemos discutir esse episódio do ponto de vista do usuário, a primeira coisa que alguém falaria seria “ah, você deveria ter um Android porque ele roda Flash”. Mas eu não quero entrar nesse mérito. Na verdade quero discutir esse problema de outro ponto de vista, o do dono do negócio (o cara que paga para alguém fazer o seu site).

Se você tem um negócio – seja uma pizzaria, um mercado, uma empresa de desenvolvimento de software e por aí vai – você possivelmente vai querer estar na Internet, afinal, alguns dos 67,5 milhões* de Brasileiros que são usuários de Internet podem acabar “esbarrando” no seu site e comprando algum produto ou ao menos conhecendo sua empresa (*dados do Ibope/Nielsen de dezembro de 2009).

Uma pessoa da minha família passou por essa experiência recentemente. Ele contratou uma empresa para desenvolver um site para a sua empresa justamente porque queria ser encontrado na Internet e queria vender seus produtos para mais pessoas. Acontece que a empresa que ele contratou desenvolveu o site em Flash, que obviamente não funciona no iPhone. Mas mais do que isso, o site bloqueia alguns comportamentos padrão do navegador (barra de rolagem e o botão de voltar/avançar), além de não ser indexado nos mecanismos de busca. Obviamente ele não percebeu nada disso por ser leigo no assunto, mas eu fiz uma brincadeira bem rápida procurando por alguns dos produtos da empresa dele em ferramentas de busca e vários sites de concorrentes apareçeram nos resultados, mas o dele não. Não preciso nem dizer que ele ficou decepcionado (e com razão).

Pensando como o dono do negócio, eu diria: “Ora bolas, se eu invisto dinheiro para ter um site, eu quero que ele seja acessível para o maior número de pessoas possível!” E como profissional de Internet, não gosto de desenvolver usando Flash pelos mesmos motivos a não ser que eu não tenha escolha (mas geralmente há uma saída). Para ser um pouco mais claro, meus motivos são os seguintes:

1) Sites em Flash não são indexados direito em mecanismos de busca

A maioria das informações dos sites em Flash ficam dentro de um arquivo compilado que não é lido pelos “crawlers“. Se o conteúdo não pode ser indexado ele dificilmente será encontrado por possíveis usuários/compradores/etc. em ferramentas de busca. Até existem formas de contornar esse problema, mas uma rápida análise em alguns sites em Flash conhecidos me mostraram que em mais de 90% dos casos os desenvolvedores não se preocupam em fazer com que o site seja buscável. Ferramentas de busca hoje em dia são fundamentais para ajudarem os usuários a acharem o que precisam na Internet. O site que não aparece bem em buscas certamente está deixando de ter uma boa quantidade de usuários a mais.

2) Sites em Flash não são acessíveis para pessoas com deficiência

Pessoas com deficiência visual utilizam “screen readers” para navegarem na Internet. A navegação nesses leitores de tela é feita com base nas tags HTML da página. Por exemplo, as tags <h*> ajudam o cego a navegar pelos tópicos principais que a página cita. O alt (da tag <img>) ajuda-o a saber qual o conteúdo das imagens, e por aí vai. Se o site é feito em Flash, nada disso vai funcionar. É possível contornar esses casos (assim como no tópico anterior), mas é trabalhoso e ninguém faz. Dos 20 sites populares que analisei antes de escrever esse post nenhum se preocupou com isso. Se você faz o seu site em HTML, isso tudo já funciona praticamente “de graça”.

É claro que pessoas cegas são uma minoria da população, mas nós temos sorte de não fazer parte dela. Justamente por serem minoria eles acabam muitas vezes sendo excluídos, e como se a cegueira já não fosse sofrimento suficiente eles sofrem ainda mais. É uma questão humana que, pelo menos para mim, conta bastante.

3) Flash atrapalha algumas funções nativas dos navegadores

Sites em Flash muitas vezes atrapalham o funcionamento padrão dos navegadores. Um exemplo clássico é que eles fazem com que o botão de Avançar/Voltar parem de funcionar ou funcionem errado. Esse mesmo problema impede que um usuário consiga gravar nos seus “Favoritos” uma página específica (porque o endereço é o mesmo para o site inteiro, e quando ele acessar vai cair na página principal do site ao invés da página que ele queria). Muitos sites já corrigem isso atualizando as URLs ao longo da navegação, mas vários não funcionam direito. Um outro exemplo pior ainda é quando sites em Flash substituem a barra de rolagem nativa do navegador por uma específica do Flash. Esse sim é um problema terrível, porque até o scroll do mouse para de funcionar. Quer ver como é perturbador? Então veja este site. Por favor, será que dá para me deixar usar o navegador direito?

4) Flash é pesado, especialmente se você está em redes 3G/Edge ou conexões lentas

Tudo bem, os sites em Flash funcionam em Android. Mas o que você acha de ter que esperar um Flash de 2MB carregar para você poder começar a usar o site? E olha que nem estou contando as famosas introduções animadas, das quais vou falar daqui a pouco. As aplicações em Flash ficam gigantescas e lentas, especialmente para quem está acessando de dispositivos móveis ou de conexões mais lentas.

5) Muitos designers de sites em Flash esquecem da usabilidade

Veja este site. Eu que não sou nenhum especialista em UX sei há anos que rolagem horizontal é abominável. Neste exemplo eles anda fizeram com que o trackpad do meu notebook não funcione corretamente, proporcionando assim a maneira mais lenta e tediosa possível de rolar para achar a informação que eu preciso. Agora veja este outro site. Fiz um teste rápido em casa e minha mãe não foi capaz de usá-lo, tem animações demais e objetividade “de menos”. Aposto que muitas outras pessoas também não conseguiriam. Você não constrói sites somente para pessoas que entendem de Internet ou são capazes de “fuçar” e descobrir como funcionam as coisas. A Internet é aberta e todo tipo de gente usará o seu site, por isso é preciso que ele seja tão fácil e direto quanto possível. Não adianta se preocupar somente em fazer sites bonitinhos, eles precisam ser funcionais também.

6) Flash não funciona em todos os dispositivos móveis

Sites em Flash não funcionam em iPhones e iPads, por exemplo. O iPhone – especialmente o 4 – é um fenômeno de vendas. No primeiro dia de venda foram vendidas 300.000 unidades do iPhone 4. No Brasil, várias pessoas foram para a porta da loja à meia noite para poderem ser os primeiros a comprarem o aparelho. Até hoje as lojas das maiores operadoras ainda estão com o aparelho em falta (porque todas as unidades que chegam são vendidas num piscar de olhos). Isso sem contar o iPad, que estima-se que serão vendidas 10 milhões de unidades até o fim de 2010. Ou seja, estamos falando de uma quantidade expressiva de aparelhos. Assim como você se preocupa em desenvolver sites compatíveis com vários navegadores, você precisa se preocupar com dispositivos móveis. Seria muito mais fácil desenvolver para Firefox somente, mas infelizmente há um grande número de usuários que usam Internet Explorer (incluindo IE6, infelizmente) e você não pode deixar de levar isso em consideração, senão eles não conseguirão usar seu produto. O mesmo vale para iPhone – seria muito mais fácil se você não precisasse se preocupar com ele, mas um grande número de pessoas estão usando e você não vai querer deixar essas pessoas de fora do seu site. Se você realmente precisar usar Flash, preocupe-se em ao menos desenvolver uma versão compatível com outros dispositivos (como fizemos na época que eu trabalhava na Globo.com, por exemplo).

7) Introduções em Flash são pouco úteis

Qual é o objetivo funcional de uma introdução em Flash em um site? Pense. Não há nenhum! Sites em Flash muitas vezes tem aquelas introduções gigantes e tediosas que são uma maneira super eficiente de impedir os usuários de fazerem o que eles precisam. Pode ser que isso tenha sido legal há alguns anos quando era novidade, mas isso já passou há muito tempo.

Concluindo…

Como falei no início, minha análise é do ponto de vista dos nossos clientes, ou seja, das pessoas que nos pagam para fazermos bons projetos de websites. Tenho certeza que você que é profissional de Internet como eu não quer fazer projetos ruins (ou não tão bons quanto poderiam ser).

Existem um monte de ferramentas que te permitem criar sites funcionais, rápidos, acessíveis e eficientes. Mais recentemente com o HTML5, muitas das coisas que antes só eram possíveis com Flash (ou Silverlight) agora são nativas dos navegadores.

Da próxima vez que você for usar Flash, pense duas vezes. E se não tiver jeito e você for usar mesmo, por favor faça direito. 🙂

Agile UX: Como trabalhar com os designers

Seguindo com a série de posts-resposta, vou aproveitar mais um e-mail que recebi para falar de um assunto que é campeão em dúvidas e discussões: como trabalhar com os designers. A questão é a seguinte:

Gostaria de tirar uma dúvida (ou mesmo sugestão) sobre como vcs estão trabalhando ai na Globo.com com os designers, arquitetos de informação, etc, inseridos nos times ágeis.

A empresa onde trabalho tem um “setor” de criação artística muito forte, alias, excelentes profissionais, e eles trabalham independentes praticamente do desenvolvimento.

Devido a maneira da empresa gerir seus projetos – waterfall – eles fazem toda a parte de criação e entregam um wireframe+layout de telas prontos pras equipes de desenvolvimento, ai é cada um por si.

Como estamos fazendo um processo de migração de waterfall pra desenvolvimento ágil, esse ponto específico do pessoal de criação inseridos nas equipes ágeis ainda deixa muitas dúvidas, na maneira que eles podem fazer parte dos times.

Talvez esse tenha sido um dos maiores problemas que tivemos na adoção de Scrum aqui na Globo.com, ou pelo menos é um dos problemas que têm durado mais tempo. Novamente, não acho que exista uma receita de bolo, cada time ou empresa precisa encontrar a melhor forma de trabalhar. Vou me limitar a dar algumas idéias e falar do que temos tentado fazer aqui para integrar desenvolvimento e design.

Por último, vou falar especificamente de Scrum porque é o que usamos aqui (apesar de usarmos também práticas e conceitos de XP e Lean), mas as mesmas idéias servem para outros processos similares.

O ponto de vista do processo

Do ponto de vista do Scrum, o correto seria desenhar a cada história que fosse feita somente as partes da tela necessárias para a conclusão da história.

Fazer todo o design antes nos mínimos detalhes não é o mais indicado porque para isso é preciso fazer um levantamento de requisitos para entender as necessidades e é exatamente assim que funciona a fase de análise e levantamento de requisitos do waterfall (ou seja, o que não queremos fazer).

Outro problema é que se no início de um projeto você só trabalha telas, o que você irá entregar no fim de um Sprint? Com certeza não será software funcionando e toda aquela história de antecipação do ROI vai por água a baixo.

Por fim, um dos objetivos do desenvolvimento com Scrum é produzir software de maneira iterativa e incremental. A cada Sprint deveria ser entregue uma pequena parte do produto funcionando e quando isso é feito, o Product Owner pode chegar em qualquer ponto do projeto e perceber que o investimento em mais um Sprint já não vale mais a pena como valia no início – porque as histórias que sobraram darão um retorno bem menor do que o valor investido em um Sprint – e ele pode decidir que é necessário encerrar o projeto por razões econômicas óbvias e partir para outro.

O ponto de vista do desenvolvedor

Os princípios de desenvolvimento ágil também não deixam dúvidas. Big Design Up Front (BDUF) é coisa de cascateiro, e as práticas de desenvolvimento como Test-Driven Development (TDD) fomentam justamente o desenvolvimento incremental.

Do ponto de vista do desenvolvedor ágil também é um erro desenvolver todo o design antecipadamente.

O ponto de vista do designer

Só depois de muitas conversas com o Cainã Nunes e o André Braz – dois dos melhores “criativos” que temos aqui na Globo.com – é que eu consegui entender o problema de verdade. Eu não sou nem de perto um especialista no assunto (e nem pretendo ser), mas vou tentar explicar o pouco que eu entendo.

Para entendê-los, precisamos entender a diferença entre “design de interface” e “design de UX”.

Desenhar uma tela qualquer é muito fácil. No início da minha carreira quando eu trabalhava em uma agência de desenvolvimento de sites cansei de mudar e algumas vezes até fazer layouts. Depois que você aprende a usar direitinho o Photoshop e o Fireworks é realmente muito muito muito fácil desenhar uma tela, desenhar objetos diversos e entregar qualquer coisa. Não que todos os designers façam isso, mas que é fácil fazer uma tela qualquer é.

O problema é que aqui na Globo.com nós não queremos fazer somente telas. Além do design e beleza em sí, estamos preocupados com a experiência do usuário (a famosa UX). Ao contrário de desenhar uma simples tela, projetar a UX é muito muito muito difícil. Em UX, não basta ter uma tela, ela precisa ser fácil de usar, os usuários precisam querer usá-la e a experiência de uso tem que ser memorável – porque isso fará com que os usuários queiram voltar. Isso é tão difícil de fazer que muitas vezes falhamos, mas essa é a nossa mentalidade e como queremos desenvolver nossos produtos.

Quando falamos de projetar a UX, vários fatores além do Photoshop ou Fireworks estão envolvidos (veja o experience design manifesto para ter uma idéia). Aspectos como ergonomia, sentimento e psicologia entram em cena. Alguns projetos que fazemos são testados exaustivamente com usuários comuns no laboratório de usabilidade, e mesmo assim continua difícil de alcançar o resultado que queremos.

Pense friamente e veja como todas essas “loucuras” fazem muito sentido. Independente do processo que usamos, não é isso que queremos dar para os nossos usuários nos produtos que desenvolvemos?

O problema

O problema é que para projetar a experiência do usuário, os designers acreditam que é difícil (ou impossível) pensar em pequenas partes do site e que é preciso pensar na experiência como um todo. Isso vai totalmente de encontro com a forma que o processo funciona e que os desenvolvedores trabalham…

Para ser muito sincero, eu não entendia porque eles não gostavam da idéia de ir refatorando o design e ir adaptando conforme as partes fossem sendo desenvolvidas. O que eu sempre entendi é que indivíduos e interações devem estar acima do processo, então ao invés de ficar procurando respostas no processo precisamos confiar nessas pessoas – que são especialistas no que fazem – e junto com elas encontrar uma saída.

Isso não nos exime da responsabilidade de fazê-los entender claramente como funcionam os processos e princípios de desenvolvimento ágil para que eles saibam o impacto das suas decisões e ajudem a encontrar uma forma de trabalhar que seja compatível com essa realidade.

Harmonia entre desenvolvimento e criação

Depois de muitas tentativas e erros, a forma de trabalhar mais próxima do ideal que eu consigo enxergar é uma mistura dessas três visões.

Os projetistas de UX podem e devem sempre pensar na visão do todo mas não necessariamente precisam entrar em todos os detalhes de cada uma das telas. Com a visão inicial do projeto os designers já têm muitas informações que precisam para começar a trabalhar na experiência do usuário e devem desde já pensar no produto como um todo, mas mais uma vez, isso não quer dizer que tudo precisa ser feito e pensado nos mínimos detalhes antes do projeto. Abaixo ao BDUF!

Na nossa equipe os designers têm feito sketches, wireframes e desenhos à mão para discutir funcionalidades e usabilidade. Muitas vezes isso é feito durante as discussões do Sprint planning e re-pensado algumas vezes durante o Sprint. Depois, durante o desenvolvimento, a cada história que vai sendo desenvolvida o time vai implementando junto com os designers, que vão fazendo as pequenas partes necessárias para aquela funcionalidade específica e ao mesmo tempo o design da experiência como um todo é continuamente revisto e refatorado para atender à visão do projeto.

A idéia é mais ou menos como a do cone da incerteza: no início do projeto você têm uma vaga idéia de como será na prática a experiência do usuário, e essa certeza vai continuamente aumentando até que depois de algum tempo (mais próximo do fim) você tem certeza absoluta de como ela será.

Ainda não estamos craques em fazer isso mas promete funcionar bem melhor do que tudo que já tentamos.

Concluindo

Você é realmente ágil quando não existe algum processo burocrático que te impede de fazer alguma coisa com mais eficiência. Criar um processo ou ambiente que impeça as pessoas de trabalhar ao invés de facilitá-las vai totalmente de encontro à agilidade.

Para citar um exemplo, o próprio criador do Scrum – Jeff Sutherland – achou melhor adaptar o processo na sua empresa para fazer o design das telas antes do desenvolvimento. Nessa empresa os sistemas são feitos para serem usados por médicos e eles vêem o sistema como algo que dificulta o trabalho (torna menos ágil), portanto, a usabilidade do software tem que ser perfeita. Sendo o design tão crítico e tão importante para o sucesso do projeto, eles decidiram se organizar para trabalhar com definição de telas e criação de protótipos antes do desenvolvimento. E não adianta achar que todos os projetos devem ser assim; cada caso é um caso!

As pessoas precisam conversar mais e entender as motivações das outras e o que as levam à tomada de decisão. Quando você consegue entender de verdade o lado do outro (dos designers no meu caso) você começa a entender quais são as reais motivações para o que ele está fazendo. O designer no meu time não queria atrapalhar o processo fazendo todas as telas antes, ele simplesmente queria fazer um trabalho espetacular de usabilidade e essa era a melhor forma que ele conhecia. Fazer um trabalho excelente de UX foi exatamente o que o gerente de UX pediu para ele e é essa a direção que a empresa quer seguir. Só depois que eu me dispus a entender como funciona a cabeça dele (e de todos os outros de UX) é que eu estou conseguindo pensar de outra forma. Agora existem muito mais chances que a adaptação que estamos fazendo no processo funcione melhor.

Então, respondendo a pergunta do post: como trabalhar com os designers? Pense fora da caixa! Aqui estão algumas idéias e opiniões, mas que eu aconselho é que cada time experimente e encontre a sua resposta.

Se você ficou decepcionado com a resposta e achava que eu ia te dar uma regra para ser seguida sem precisar pensar, talvez você esteja procurando nas metodologias ágeis a resposta errada e precise de alguma outra coisa que dê isso para você.