O Smush.it é um otimizador de imagens desenvolvido pelo Yahoo! que remove bytes desnecessários e que não afetam a aparência ou a qualidade da imagem. Ele otimiza PNG, GIF e JPG. As imagens são submetidas a vários algoritmos para terem seus tamanhos reduzidos.

Funciona assim: você faz o upload de todas suas imagens para o Smushi.it — ele aceita múltiplos uploads — e ele te devolver um arquivo compactado em .zip com todas suas imagens otimizadas. Para cada imagem que você subir ele te informa o tamanho original e o tamanho final depois da otimização, além de exibir os ganhos totais ao submeter várias imagens juntas. Uma observação importante é que ao subir as imagens em GIF elas serão automaticamente convertidas para PNG quanto a conversão for responsável por gerar uma imagem de tamanho físico menor do que o GIF.

A otimização de imagens no meu fluxo de trabalho com o Smush.it é a última coisa a ser feita, no final do projeto e antes de publicar o site. Não precisa se preocupar com isso antes. Legal né?Artigos relacionados:

• Princípio de pareto: A teoria 80/20 aplicada ao desenvolvimento de web
• Yahoo! Search por uma web cada vez mais semântica
• Yahoo!, Google e Microsoft em esforço conjunto no protocolo sitemaps

• Imagens gratuitas é com a Stock.XCHNG
• Geotagging, meta informações de geoposicionamento cada vez mais populares!
• swfir – SWF Image Replacement
• Novas features de mapas estáticos no Google Maps e futuras adaptações no Geopress
• ROI – Retorno de investimento com web standards

Formato

O livro Formato (ISBN: 9788577802739, 176 páginas) foca na relação ergonômica e utilitária dos objetos de design, como o livro, o pôster, a revista, o objeto, a tela do monitor, etc. Trata-se da reflexão de como o uso de diferentes formatos com objetivos diferentes é fator importante na concepção do design.

O foco deste livro está muito mais nos materiais impressos do que em outros tipos de produtos, preocupando-se com tipos de papel, tipos de dobras, escala, encadernação, cortes, brochuras, relevos, acabamentos e vários outros detalhes do universo do design gráfico e publicitário. Apesar de ter um capítulo sobre “A tela do monitor“, trata-se apenas de 6 páginas sobre o assunto e muito bem ilustrado.

Layout

O livro Layout (ISBN: 9788577803088, 176 páginas) é um compilado de exemplos de como a disposição e o arranjo dos elementos de texto e imagem influencia na percepção do design e do espaço que eles ocupam, considerando-se aspectos emocionais, estéticos, clareza, concisão, etc.

Aborda a introdução aos Grids (que possui um livro dedicado sobre o assunto como você verá a seguir) além de alinhamento dos elementos, forma e função, escala, estrutura. Apesar deste livro também conter a maioria dos exemplos focados no impresso, a reflexão de posicionamento e layout é universal. Os conceitos e exemplos são claramente transferíveis para web.

Impressão e Acabamento

O livro Impressão e Acabamento (ISBN: 9788577803071, 176 páginas), junto com o livro "Formato" são os dois livros basicamente focados em mídia impressa, onde o aproveitamento no universo do design para web é mínimo. Como eu vim da mídia impressa há mais de 10 anos atrás adorei rever conceitos e materiais usados na impressão e acabamento de impressos.

Tipos de impressão como offset, serigrafia, termografia, além de tipos de papeis, acabamentos, encadernação, texturas, aplicações de cores, etc são o conjunto de assuntos abordados neste livro. Esta edição possui várias páginas com tipos de acabamento e impressões diferentes. Tudo muito impecável.

Cor

O livro Cor (ISBN: 9788577804993, 176 páginas) junto com o de "Grid" são os dois livros da coleção que eu acho fundamentais para todos os designers. O livro introduz os vários elementos essenciais do estudo de cores como sistemas e círculos cromáticos, simbolismo das cores, percepção, combinações, técnicas de aplicações, etc.

Assim como nos outros livros há também certa atenção para os impressos mas não limitando-se a isso. Achei também que, devido a complexidade do assunto, poderia ter dado mais atenção a parte teórica. Isso torna essa edição, na minha opinião, mais interessante pra quem já estudou teoria das cores e quer um belo livro de referência do que para os não iniciados.

Imagem

O livro Imagem (ISBN: 9788577805006, 176 páginas) é um emaranhado de conceitos e relações com a aplicação de imagens. De todos os livros da coleção, eu achei que esse foi o que mais explorou o assunto com variadas aplicações do uso de imagens.

Este livro traz conceitos como resolução, cores, canais de cores, técnicas de impressão, ilustração, fotografia, significados da imagem como processos cognitivos, semiótica, tipografia, sinédoque, metáfora, analogia, metonímia, além de usos de imagens, fotojornalismo, manipulação, montagem, enquadramento, marcação, etc. São vários os relacionamentos criados na aplicação de imagem. Possui também vários exemplos de impressos mas também em contextos onde o conceito é transponível para outras disciplinas de design.

Grids

O livro Grids (ISBN: 9788577805228, 176 páginas) foi o meu preferido da coleção. Sou suspeito por ser apaixonado por Grids. Se você é designer de interfaces para web, pelo menos este você precisa comprar. O grid é a base sobre a qual um design é construído e organizado. O foco do livro está muito mais nos princípios e diferentes abordagens da utilização de grids do que impor um caminho prescritivo.

O livro começa com a defesa do por que usar grids e percorre os diferentes aspectos como formato, medidas, proporções, regra dos terços, simetria, grids compostos, e vários exemplos de aplicações e modelos já estabelecidos principalmente na mídia impressa.

Pontos negativos

Esta coleção da Bookman de Design Básico foi publicada incompleta. A coleção original é da editora suíça AVA Publishing e ficaram de fora o Design Thinking e o Typography, que são dois temas muito fundamentais para o design. Não sei as razões da não publicação, mas os dois temas são muito importantes na reflexão do design do que os livros Impressão e Acabamento e Formato, que são mais característicos dos profissionais focados em impressos. Se refletirmos do ponto de vista do Design como disciplina, os dois livros fazem muita falta e os outros dois citados acima, nem tanto. Estou inclusive considerando a possibilidade de comprá-los em inglês mesmo.

Outro ponto negativo para quem trabalha com web é a pegada no mundo dos impressos que a coleção possui. Apesar de ser uma reflexão sobre design, os elementos típicos da impressão estão presentes em todos os livros. Não necessariamente isso torna os livros interessantes somente para designers gráficos, mas para os profissionais de web, nem todos são importantes.

Considerações finais

O acabamento de todos os livros é muito bonito e impecável. Papel especial, principalmente no livro de impressão e acabamento onde algumas páginas estão com o tipo de papel e impressão indicado no contexto. Nenhum destes livros é um compêndio completo e esgotado sobre os assuntos propostos. Todos eles são compilações de conceitos e boas práticas que abrem a sua cabeça pra ir explorar esses assuntos em outras fontes.

Se você trabalha com web e desenvolvimento e precisa focar ou está sem grana pra comprar a coleção inteira, minha sugestão é que você compre na seguinte ordem de importância (minha opinião): Grids, Cor, Imagem, Layout, Formato e por último Impressão e Acabamento. Os livros podem ser adquiridos no site da própria editora Bookman. Em breve tem mais reviews dos livros que etsou lendo!Artigos relacionados:

• Book Review: Manual de Tipografia – a história, a técnica e a arte
• Book Review: Ansiedade de Informação 2 de Richard Saul Wurman
• Book Review: 250 segredos para web designers de Molly Holzschlag
• Book Review: O Design do dia a dia de Donald A. Norman
• Book Review: Projetando Web Sites Compatíveis de Jeffrey Zeldman
• Book Review: Refatorando HTML – Como melhorar o projeto de aplicações web existentes
• Book Review: Web Standards Solutions de Dan Cerderholm

• Até que enfim, Sandman, Entes queridos
• Book Review: Design de Navegação Web
• Book Review: Manual de Tipografia – a história, a técnica e a arte
• Despertar: Sandman chega ao fim, pela segunda vez no Brasil
• Book Review: Ansiedade de Informação 2 de Richard Saul Wurman

Se você se preocupa com a indexação do seu site pelos mecanismos de busca você também precisa se preocupar em deixar seu site livre dos links quebrados. A internet é interligada por hyperlinks. Mecanismos de busca são estruturados em torno de links. Quanto mais links apontando pra um endereço mais relevante ele é. Se você possui muitos links quebrados ou páginas com erro 404, o Google pode não encontrar razão em dar alguma relevância para seu site, visto que o mesmo não oferece uma boa experiência de usuário. E isso é razão mais do que suficiente pra você se preocupar em manter seu site sempre atualizado e livre de links quebrados.

Erro 404 e como minimizar uma péssima experiência de usuário

Erro 404 é a denominação da famosa mensagem de “Página não encontrada” que todo mundo já se deparou alguma vez. Trata-se de uma resposta enviada pelo servidor informando que o endereço que você está tentando acessar não existe. E sabe quando essa tela aparece? Quando você deixou algum link interno quebrado ou removeu alguma página e não fez nenhum redirect para um novo endereço.

Geralmente a mensagem enviada pelo servidor, por padrão, não é muito útil como você pode ver na imagem acima. O correto é você personalizar essa página de erro 404 com uma mensagem mais amigável e mais explicativa para o usuário. Infelizmente a maioria dos sites não a personalizam deixando o usuário perdido e sem qualquer possibilidade de encontrar algum conteúdo similar no seu site. A Smashing Magazine publicou um texto sobre várias boas práticas relacionadas com páginas de erro 404 que vale a pena dar uma olhada antes de construir a sua. O Google também publicou algumas observações importantes sobre o assunto.

Evite round-trip times desnecessários

Round-trip Times (tempo de ida e volta em português), também abreviado por RTT é o tempo gasto para que uma aplicação client side (um browser por exemplo) gasta para enviar uma requisição ao servidor somado ao tempo que o servidor vai gastar para responder esse pedido. O RTT não inclui o tempo de transferência desses dados, trata-se apenas do tempo de comunicação entre cliente e servidor.

Vamos supor que na sua folha de estilos de CSS você chama uma imagem de background que não existe. Vamos supor que você nem notou que essa imagem não existe mas a regra de CSS que “linka” essa imagem continua lá. Toda vez que alguém acessa o seu site ou blog, sua folha de estilos vai enviar uma requisição ao seu servidor desnecessariamente. Pode parecer pequeno, mas em sites com grande audiência isso é um grande desperdício de recursos do servidor, consequentemente menos grana no seu bolso. Uma boa prática em desenvolvimento web para deixar sites mais rápidos é minimizar a quantidade round-trip times. Principalmente os desnecessários como aqueles originados dos maditos links quebrados.

Detectando e combatendo links quebrados

Depois de identificado 2 grandes problemas relacionados com broken links, o que você precisa fazer agora é colocar a mão na massa. Se seu site possui muitos links quebrados, ela passa uma impressão amadora e descuidada. Quanto mais importante — financeiramente falando — seu site representar pra você, mais cuidadoso com ele você deve ser. E combater links quebrados é uma tarefa que você não deveria esquivar-se nunca. Não há outra forma de combatê-los senão verificando link por link. Como fazer isso manualmente seria um tanto desumano, existem ferramentas que fazem isso por você.

Há várias soluções de ferramentas que checam links quebrados, mas neste artigo vou indicar apenas algumas que eu já utilizei.

W3C Link Checker: O W3C Link Checker é um verificar de links quebrados online parte de um grupo de ferramentas de qualidade da W3C. A vantagem desse verificador é que você não precisa instalar nada no seu computador.

Xenu’s Link Sleuth: O Xenu trata-se de um aplicativo desktop (roda somente em plataforma Windows) muito popular entre os desenvolvedores. Ele verifica imagens, JavScripts e CSS. Possui algumas informações em relatórios interessantes.

Firefox extension: LinkChecker: O LinkChecker é bem popular e fácil de usar. Basta instalá-lo como uma extension no Mozilla Firefox.

WordPress: Broken Link Checker Plugin para o WordPress que estará sempre monitorando seu blog atrás de links quebrados, te poupando muito esforço.

Além dessas ferramentas é sempre bom nunca tirar os olhos do Google Webmasters Tools e do Yahoo! Site Explorer atrás de problemas de indexação e report de erros. Nada substitui essas duas ferramentas.

P.S.: Sim, eu tenho alguns links quebrados por aqui e pretendo exterminá-los em breve. Eu disse que é algo que precisa ser feito e não que era um trabalho fácil.Artigos relacionados:

• Declarando encodings em XHTML
• Configurando encodings em ferramentas de desenvolvimento
• Acessibilidade, Validações e Mecanismos de Busca
• Hacks hack hacks!
• Algumas questões em torno do desenvolvimento de sites para dispositivos móveis
• Validação e Semântica
• Rubens de Freitas

• A "usabilidade" de informar ao usuário que um link é externo ao seu site
• Smart Start, e-book sobre Links Patrocinados gratuito
• Gmail: Lockdown in sector 6
• Google Insights for Search, mais uma ferramenta para facilitar a vida dos analistas e anunciantes de Links Patrocinados
• Design acessível, Daltonismo e a cegueira das cores

O Manual de Tipografia cobre a história desde os antigos sistemas de escrita até a revolução tecnológica dos computadores, incluindo a evolução das formas de aplicação tipográfica, anatomia dos caracteres, características, classificação, composição tipográfica, etc. Quase que do meio do livro em diante você encontra um apêndice com amostras de várias fontes famosas, contendo uma breve história delas além de exemplos da aplicação da fonte em diferentes tamanhos.

Pontos negativos: O livro é para iniciantes no estudo de tipografia e poderá frustrar os mais experientes. Praticamente cada capítulo do livro esta com uma tipografia diferente e um modelo interno de grid variável (hora em 2, 3, 4 ou 5 colunas) e em outros trechos o modelo de grid parece inexistir. Pesquisei antes de escrever esse texto e esse estranho modelo de organização é uma herança da edição americana.

Pontos positivos: Para o iniciante alguns capítulos são uma mão cheia de informações preciosas compartilhadas de uma forma muito didática. Os capítulos de características (anatomia) dos caracteres e composição de textos tipográficos são muito bem escritos, claros e trazem informações preciosas que todo mundo que trabalha com web deveria saber, como alinhamento, peso de fonte, contraste, serifada ou não serifada, uso de kernel negativo, etc.

Se você nunca parou para estudar tipografia de forma mais organizada recomendo que compre o livro. Mas se você já estudou um pouco ou tem boas noções, recomendo procurar livros mais elaborados com foco em composição, aplicação, etc. Você pode comprar o livro no Submarino ou no próprio site da Editora Bookman.Artigos relacionados:

• Book Review: Não me faça pensar de Steve Krug
• Book Review: O Design do dia a dia de Donald A. Norman
• Book Review: Refatorando HTML – Como melhorar o projeto de aplicações web existentes
• Book Review: Coleção Design Básico – Formato, Layout, Impressão e Acabamento, Cor, Imagem e Grids
• Book Review: CSS Mastery de Andy Budd
• Book Review: Bulletproof Web Design de Dan Cederholm
• Review do livro: Estratégias de e-mail marketing

• Book Review: Não me faça pensar de Steve Krug
• Book Review: O Design do dia a dia de Donald A. Norman
• Book Review: Refatorando HTML – Como melhorar o projeto de aplicações web existentes
• Gadget de Natal: Monitor Widescreen 19” LCD AOC 193FW
• Book Review: Coleção Design Básico – Formato, Layout, Impressão e Acabamento, Cor, Imagem e Grids

“Finalmente entendi a diferença entre sites ruins e bons: a integração entre equipe de UX e desenvolvedores.”

Eu retuitei e em seguida a Aline Couto (@alineideias) fez algumas considerações direcionadas a mim, o que foi o suficiente pra começarmos uma discussão interessante sobre os problemas relacionados com a integração de equipes de experiência de usuário e desenvolvedores. E como as frases jogadas no Twitter me fizeram conectar alguns pontos interessantes, eu não gostaria de deixar que isso morresse por lá.

O problema

Desenvolvimento de projetos para web envolve pessoas com formação e especialidades diferentes. Desde o planejamento até a publicação no servidor, um projeto passa por várias fases nas mãos de diferentes profissionais. Podemos dividir estes profissionais em 2 grandes grupos. De um lado temos profissionais de design, experiência de usuário (UX) e arquitetos da informação. De outro temos os programadores de interface e os desenvolvedores server side. Geralmente os profissionais de experiência do usuário não entendem de tecnologia e desenvolvimento como deveriam e de igual modo os desenvolvedores não entendem de usabilidade, acessibilidade e design centrado no usuário como deveriam entender. Cada grupo com suas especialidades e cada grupo com, digamos, “objetivos” diferentes. Os profissionais de UX querem que o projeto seja fácil de navegar, de encontrar informações e intuitivo. Os desenvolvedores querem que a aplicação funcione sem erros e que cumpra os requisitos que receberam no início do projeto. O que faz com que esses dois grupos tenham tantas divergências no desenvolvimento do projeto?

Eu atribuo esse dilema a um problema característico de cada grupo. Geralmente os profissionais de experiência do usuário não entendem de tecnologia e desenvolvimento como deveriam e de igual modo os desenvolvedores não entendem de usabilidade, acessibilidade e design centrado no usuário como deveriam entender. Estou sendo simplista? Talvez, mas eu acredito que este seja a raiz dos principais problemas de divergência entre equipes.

Eu comecei a trabalhar com internet focado em desenvolvimento, design e programação de interfaces e só depois de muito tempo é que migrei para arquitetura da informação e design centrado no usuário. Até hoje eu perambulo pelos dois mundos. Este texto é uma reflexão de problemas que observei cumprindo os diferentes papeis e eu adoraria muito saber a opinião de vocês sobre eles. Vamos lá:

Não entender nada de tecnologia e de desenvolvimento

Essa é a principal acusação que os desenvolvedores fazem aos designers de interface, planejadores, arquitetos da informação e outros profissionais de UX. Muitas vezes os desenvolvedores estão certos. Vejamos alguns problemas:

Falta de alinhamento com escopo: Os profissionais de UX acham que sempre é possível alterar a interface sem mexer em banco de dados, etc. Nem sempre. Se o projeto, por exemplo, for uma manutenção em um sistema legado, onde apenas a camada de apresentação será alterada, nem sempre dá para tratar as informações de forma diferente como implementada na versão anterior. Tudo depende de como o banco foi estruturado. As vezes dá e as vezes não dá. As vezes o profissional de UX cria uma interface fantástica, muito útil ao usuário, muito fácil de navegar e de encontrar mas não existe tempo hábil para alterar toda a estrutura de banco de dados só para sustentar a tal interface foda. Ou seja, por mais que o profissional de planejamento esteja bem intencionado, ele também precisa seguir o escopo do projeto. Porque os gerentes de projetos e líderes vão cobrar exatamente isso dos desenvolvedores: seguir os requisitos conforme foram definidos. Quer alterar alguma parte do escopo? Então chame os gerentes e o representante dos desenvolvedores para solicitar alterações de escopo e deixar claro pra todos as justificativas de alteração.

Demonstrar na cara do desenvolvedor que você acha que tudo é fácil de ser feito: Profisisonais de experiência de usuário muitas vezes acham que alterar uma interface no meio do projeto é algo “fácil”. Banco de dados são estruturados para serem otimizados de acordo com o que foi planejado. Se um projeto está no meio, muito provavelmente todo o banco já foi modelado e estruturado. É possível alterá-lo? Claro que sim, mas tudo depende do prazo e do tempo hábil para fazer. Não considere e não fique aborrecido se algo não der para ser feito (sempre considerando, prazo, cobrança e tempo hábil). Nem tudo é fácil de ser implementado.

Desconhecer contextos de desenvolvimento: Eu sei o valor que uma busca bem desenvolvida agrega a um projeto. Mas alguns tratamentos finos são muito, muito complexos de serem colocados em prática. Um dicionário de sinônimos (ou tesauro), por exemplo, é uma funcionalidade “linda”. Desenvolvedores precisam lidar com mensuração de carga no servidor, quantidade de consultas, precisam definir se buscas serão pré-indexadas ou não, quantos usuários o servidor aguenta se buscas forem realizadas no mesmo segundo sem derrubar o site, onde ele ficará hospedado etc. Implementar uma funcionalidade “fina” em um site com uma infra-estrutura muito pequena, poderá acarretar em um site muito lento devido a toda carga gerada no servidor. Nestes casos, se aquilo que o profissional de UX planejou for implementado, poderá acarretar em uma experiência de usuário lenta e desestimulante. Em resumo, conhecer o contexto de desenvolvimento é fundamental. E uma boa experiência de usuário no resultado final de um projeto, depende de alinhamento do contexto do projeto.

Desenhar telas sem consultar os analistas: Essa é clássica. Nunca mostre uma interface, wireframe ou o que for ao cliente sem ter certeza que dá pra ser feito, se a informação vai existir em banco, etc. Estamos falando de projetos já fechados. Se você está em fase de planejamento do projeto, apenas certifique que o analista entendeu como será o funcionamento e a natureza do tipo de informação que você pretende printar na tela. Tudo dá para ser feito e não custa nada perguntar e definir com quem vai desenvolver. Não estamos falando em “pedir bença” pro desenvolvedor, estamos falando apenas de alinhar com o que você está em mente. Consultar o desenvolvedor sobre certa implementação não deve fazer você se sentir inferior, com o tempo, você verá que você vai aprender muito sobre como as coisas são desenvolvidas e certas dúvidas que você tem hoje, não as terá no futuro.

Não entender nada de design e experiência de usuário

Esta é a principal acusação dos profissionais de experiência de usuário, arquitetura da informação, etc. Desenvolvedores na maioria das vezes não sabem o que é design centrado no usuário. E sabe o que é curioso? Eles também estão certos. Muitos desenvolvedores são hábeis e excelentes em programação mas desconsideram boas práticas de interface, funcionalidade, etc. Vejamos alguns problemas:

Não seguir boas práticas de desenvolvimento: Muitos desenvolvedores acham que o sucesso de um projeto está no fato de ele “não dar pau”. Ou seja, se tudo “funciona”, se o site não cai, o projeto foi um sucesso. Estes são os piores tipos de desenvolvedores que eu conheço. São capazes de ignorar qualquer outro requisito que não seja os “explícitos”. Deixar de seguir boas práticas de desenvolvimento é deixar de pensar no usuário. SEO, acessibilidade, separar conteúdo da apresentação e outros detalhes do desenvolvimento melhoram a experiência de usuário e nem sempre são requisitos que chegam documentados. Depende do “bom senso” do desenvolvedor. Deixar de seguir boas práticas de desenvolvimento é deixar de pensar no usuário. E muitas vezes os desenvolvedores poderiam fazer algo a respeito mas preferem colocar a culpa na falta de documentação.

Achar que design é apenas deixar uma tela bonitinha: Se você pensa assim, precisa se informar melhor do que é design. Se tivesse um pouco mais de conhecimento saberia que desenvolvimento de software e aplicações web também é uma disciplina de design. E design é feito para usuários. Existem milhares de boas práticas relacionadas a interação do usuário, comunicação de erros, agrupamentos de informação, organização, feedback ao usuário, etc. Design é um conjunto de definições que deve ser centrado no usuário. A tela nem precisa ser “bonitinha” mas precisa ser fácil de usar.

Achar que a atenção a detalhes é frescura: Uma vez ocorreu o seguinte caso: um sistema possuía um grid de resultado de busca com paginação. Se você estava em um intervalo x da paginação (página 15 de 40, por exemplo) e acessasse um dos registros, ao dar backspace ou usar o voltar do browser ou salvar o registro, o usuário era sempre levado a página 1 do resultado de busca. Eu disse que, ao “voltar”, o usuário deveria ser levado exatamente para a página da paginação em que ele estava anteriormente. Um dos desenvolvedores achou aquilo uma “frescura”. Mas são detalhes assim que tornam a vida do usuário útil. Estes detalhes poupam tempo quando pensamos que o usuário do tal sistema faz isso várias vezes ao dia. Imagine que toda vez que o usuário volta para a página 1 da paginação, ele precisa dar pelo menos 1 clique (no mínimo) a mais para voltar na página 15. Pense em quantos cliques e carregamentos de página eu não conseguiria economizar em 15 usuários que trabalham no sistema 6 horas por dia. Entendeu o porque eu preciso pensar no usuário?

Como essa relação pode ser melhor?

Em todos os projetos de sucesso que eu trabalhei, os projetos só foram um sucesso por causa do alinhamento entre os profissionais sobre qual é o objetivo do projeto, e não o objetivo individual de cada um como profissional. E para isso é fundamental todo mundo entender qual será a contribuição de cada um. O desenvolvedor só odeia os profissionais de UX quando estes se acham superiores aos desenvolvedores. Acham que por eles não “entenderem” de design centrado no usuário, não deveriam participar do planejamento. Se você deixar o desenvolvedor entender a importância do trabalho de UX, se mostrar sobre quais bases seu trabalho está fundamentado é bem possível que ele se interesse por boas práticas de desenvolvimento para alcançar seus objetivos.

Já os profissionais de UX odeiam os desenvolvedores quando os mesmos os tratam como ignorantes em TI. Tratam os profisisonais como se não fossem profissionais de “web”, quando na verdade os dois grupos lidam com tecnologia o tempo inteiro. Acham que tudo o que vem dos caras de UX é frescura e tudo o que eles planejam só serve para tornar o projeto mais caro. Profisisonais de UX não precisam ser especialistas em desenvolvimento como você, e eles são muito capazes de compreender como as coisas são gravadas e recuperadas em banco, assim como você. O que é necessário é treiná-los para entender mais sobre desenvolvimento e fugir das pequenas armadilhas do dia a dia.

Não estou falando que todo profisisonal de experiência de usuário precisa estudar programação e nem que todo desenvolvedor precisa ser especialista em arquitetura da informação. Mas eu defendo que os dois lados precisam conhecer melhor a especialidade do outro. Cursos e workshops de tecnologia, desenvolvimento e experiência de usuário irá agregar muito em todos os times. Um não é mais importante que o outro, porque um trabalho excelente nunca vai existir sem um desenvolvimento decente e uma boa usabilidade.

TI influencia na experiência final

Veja abaixo apenas 3 exemplos de como a forma com que um site é desenvolvido pode contribuir ou atrapalhar a experiência que o usuário terá:

• Site lento: Implemente cache, etags, expire header, reduza o número de consultas o quanto for possível. Isso é tão sério do ponto de vista do usuário que o Google resolver atualizar o algoritmo do pagerank e colocou o tempo de carregamento como um fator importante para a relevância de um site. Sites mais lentos faz com que os usuários permaneçam menos tempo navegando dentro deles.
• Acessibilidade: Desde atribuir o pseudo elemento :focus no CSS até fazer com que um formulário funcione sem javascript, são implementações que melhoram a acessibilidade para os usuários. Já navegou com a tecla tab em um site que não possui o :focus definido? Acessibilidade não é só para cegos.
• SEO: SEO não são macetes para trapacear com os mecanismos de busca. SEO trata-se de fazer com que seu site seja mais amigável para os mecanismos de busca, para que consequentemente seja também mais fácil de ser encontrado pelos usuários que precisam da informação que o site que você está desenvolvendo possui. Isso chama-se “encontrabilidade”. A forma com que o conteúdo do site é tratada (semanticamente falando) pode facilitar (código semântico) ou dificultar (código porco dependente de JavaScript) o acesso ao mesmo.

Pronto, desabafei! Até a próxima!Artigos relacionados:

• O que diabos um web designer faz?
• Começando a desenvolver para a web à partir do usuário e não da máquina
• Qual o papel dos web standards na arquitetura da informação?
• Foco na experiência do usuário é para todos
• Tutorial de arquitetura da informação em português
• Top 7 paradigmas de um projeto para web
• Book Review: O Design do dia a dia de Donald A. Norman

• Book Review: Design de Navegação Web
• WaSP Interact – Curso gratuito de desenvolvimento para web
• 3º Encontro brasileiro de Arquitetura de Informação – EBAI
• Diferença entre “Design Centrado no Usuário” e “Design Centrado no Designer”
• O que diabos um web designer faz?