Se tem um tema dentro da estrutura de Arquitetura de Informação que eu gosto, esse tema é sem dúvida o Sketching, quer seja pelo meu passado desenhista, quer seja pela sua praticidade.

O Processo de arquitetura de informação de forma simplista consiste na propotipagem, é o desenvolvimento de protótipos que se tornam o que chamamos Wireframes. Evidente que cada empresa utiliza um tipo de processo, muitas vezes até suprimindo alguns passos as vezes vitais, mas… de maneira crua, temos: Estudo da Informação, passo em que se separa e hierarquiza o conteúdo, Sketching (Discussão da abordagem), Prototipagem (vulgo Wireframe), Teste de Usabilidade.

Vamos ao que interessa, Sketching é o que podemos chamar de esboço ou rascunho, do projeto em questão. É uma maneira poderosa de discutir idéias. Como funciona? Simples, o arquiteto de informação vai rascunhar suas idéias básicas, baseado no contexto geral do projeto, ele vai fazer as diversas telas principais rapidamente, levar para uma reunião com os envolvidos e então apresentar tal idéia. O objetivo é que seja algo dinâmico, que não consuma muito tempo, e que alinhe o grupo todo sobre o que será desenvolvido.

O Sketching pede do profissional um conhecimento básico de desenho, isso se ele quiser fazer a mão livre, mas… para os mais desajeitados eu recomendo: www.uistencils.com ,não, eu realmente não estou ganhando nada indicando tais réguas, apenas sou também um usuário das mesmas e posso garantir que são muito boas.

Vamos a um exemplo de Skecthing voltado a User Interface.

Perceba que tais desenhos podem ser produzidos rapidamente, o foco é levar isso mesmo para ser discutido. Mas existem outras formas de se fazer isso, utilizando também os Skecthes recortados.

Nas mãos de um arquiteto habilidoso o Skecthing pode se transformar em uma ferramenta extremamente poderosa, isso porque vai direto no ROI (falaremos disso mais a tarde), onde você reduz um re-trabalho e deixa de antemão toda a equipe alinhada com seu pensamento.

Quando discutido entre designers, desenvolvedores e outros, tais rascunhos minimizam o processo de aprovação do wireframe por parte dos seus parceiros de equipe, em resumo, eles antes mesmo de começaram o processo de criação e desenvolvimento poderão enfatizar pontos críticos que deixarão de existir nos Wireframes vide a discussão ter sido realizada.

É comum muitos grupos de UX ignorarem a prática do Sketching, quer seja por dizer que não há tempo hábil de se fazê-lo,  ou mesmo por não haver tal cultura. Mas eu já participei de inúmeros projetos onde utilizei eu mesmo o Sketching, e pude perceber os seus benefícios. Não é incomum inclusive em uma reunião, o responsável pela estrutura navegacional utilizar uma lousa branca de reunião para traçar as primeiras idéias antes de executar uma UI.

Tais discussões são tão benéficas que muitas vezes a solução não sai do próprio especialista e sim do grupo como um todo, da mente coletiva. Onde se agrega as inúmeras impressões ao se olhar para algo que lembra uma UI discorrendo sobre o que vai ser a aplicação em si.

Uma coisa é você discutir o Abstrato, e isso pode ser absurdamente perigoso, a outra é discutir algo visual, que se vê de fato. Não é incomum perceber que o arquiteto pensou em uma solução, o designer visualizou na cabeça uma estrutura de layout, e o desenvolvedor já estava prevendo uma outra user interface… isso porque as palavras por mais maravilhosas que sejam não conseguem ser tão dinâmicas e concretas como um simples rabisco.

O Sketche feito para mobile é ainda mais funcional, pois trata-se de telas mais simples. Ainda no uso do mesmo, alguns arquitetos recortam tais telas e colam com durex/espadrapo na lousa, simbolizando a navegação, discutindo e mexendo na dinâmica do fluxograma do projeto e utilizando o canetão para simular o fluxo.  O Visual ajuda a encontrar falhas, e quanto antes elas forem percebidas menor o custo para o projeto, menor o custo para o desenvolvimento de Wireframes, menor o custo para o desenvolvimento de Layout e do próprio código. Logo, ROI imediato.

Não a toa, o Balsamiq, um sistema criação de wireframes, não pode ser visto como, exatamente um sistema para criar wireframes.. rs. O Balsamiq é um gerador de sketches, ele tem esse estilo rascunho exatamente para simular essa prototipagem rápida.

Como Bill Buxton diz em seu livro “Sketching User Experience”, Sketches (esboços) são rápidos para criar e também é fácil de eliminar, razão pela qual eles são tão poderosos.

_________________________________________

Eduardo Horvath é UX Specialist e Designer na DClick.
Design de Mídia Digital.

Se o tráfego de vídeo nas redes de banda larga é um problema para nove entre 10 engenheiros de redes de telecomunicações, os engenheiros de TV a cabo parecem não estar muito preocupados. “Claro que o vídeo consome capacidade da rede de banda larga. Mas ainda temos muitas coisas que podemos fazer para compensar esse aumento de tráfego. É preciso investir e não é barato, mas aumentar o tráfego é sempre uma coisa boa. Nós adoramos a banda larga”, disse Michael LaJoie, CTO da Time Warner Cable durante debate na Cable 2011, que acontece esta semana em Chicago. Para ele, a questão do aumento de tráfego de vídeo nas redes de dados é a menor das preocupações, disse, ao responder sobre o consumo da capacidade da rede com a proliferação de serviços como o NetFlix. “É fato que o tráfego de dados em nossas redes aumenta entre 35% e 50% a cada ano. É preciso estar atento ao que acontece e ajustar onde é necessário”, disse Tommy Werner, CTO da Comcast, a maior operadora de cabo dos EUA.

Para Lajoie, o desafio dos operadores de TV paga, do ponto de vista de tecnologia, é melhorar a interface do usuário, já que boa parte das plataformas que os usuários estão usando para consumir conteúdo, como Apple TV e tablets, têm interfaces bem mais amigáveis do que as do set-top boxes. “Além disso, temos que pensar em uma interface que seja multiplataforma”. A Time Warner Cable, por exemplo, apostava em uma integração entre o set-top e o iPad para que o conteúdo que chega à casa do assinante pudesse ser assistido pela rede Wi-Fi doméstica (limitada àquele ambiente) em qualquer cômodo. Mas a Apple mandou, a pedido dos programadores, suspender a distribuição do aplicativo sob a alegação de que havia questões de direitos pendentes.

A Comcast, por sua vez, deixou para renomear seus serviços de cabo para Xfinity durante a Cable 2011. Mais do que uma mudança de nome, a troca veio com uma remodelagem das interfaces de usuário, pelo menos nos serviços mais avançados, para dar conta de um ambiente multiplataforma em que todos os dispositivos têm uma identidade visual e uma navegação parecida. A operadora também integrou o serviço Skype aos seus set-tops, com uma pequena caixinha adicional e uma câmera instalada sobre a TV. O serviço permite chamadas de vídeo em HD para qualquer usuário Skype, sem custo.

FONTE: Pay-TV – Samuel Possebon, de Chicago

Texto de Fabrício Teixeira sobre User Experience, achei conveninete colocá-lo aqui pois é muito bom.

São duas discussões diferentes. A primeira é inteiramente semântica, e diz respeito ao argumento que diz que uma experiência não pode ser desenhada. O que se desenha é o recipiente que contém essa experiência. E uma experiência sofre influência de uma porção de fatores subjetivos que não podem ser controlados – apesar de muitas vezes serem manipulados pelo designer que a projetou. Mas discussões puramente semânticas não afetam o jeito que você trabalha, então vamos pular esse assunto.

A segunda é um post muito interessante de Whitney Hess, que traz um checklist para identificar se você realmente atua como UX Designer ou se carrega um título não tão legítimo assim.

A nomenclatura User Experience Designer não é muito clara, e a ausência de uma regulamentação mais forte ajuda a confundir o cargo com outros similares: Arquiteto de Informação, Especialista de Usabilidade, User Interface Designer – entre outros. Mas o User Experience Designer tem um papel um pouco mais amplo em um projeto, e vale a pena percorrer esse checklist para ver se não existe algo que possa ser melhorado na metodologia de sua equipe de UX.

Então vamos à lista (editada e adaptada do post original).

Você não é um User Experience Designer se…

• …você não fala com os usuários. Se você desenha baseado somente em sua própria intuição, sem entender, pesquisar ou entrevistar os usuários reais do produto que você está desenhando, então você não é um User Experience Designer. Você é um Yourself Designer. Mas você não pode desenhar apenas pensando em você mesmo, né?

• …você não consegue identificar o seu público. Se quando alguém te pergunta quem é o público do seu site, você responde “todo mundo”, ou se dá uma resposta genérica como “mulheres de 30 a 40 anos”, você está tratando seu usuário com a mesma profundidade com a qual Rebecca Black escreve a letra de suas músicas. Melhor dar uma pausa e começar a listar as necessidades desses usuários e as motivações que os fazem utilizar o seu site.

• …você não define o problema antes de tentar resolvê-lo. Se o seu chefe pede para você redesenhar um site sem te contar qual é o problema que você precisa resolver, alguma coisa está errada. Na maioria das vezes, entender o problema muda radicalmente a solução proposta.

• …você não conhece os objetivos do usuário. Mesmo que você conheça o problema, ainda é preciso definir o porquê dessas pessoas utilizarem o seu produto. O que você está ajudando essas pessoas a fazerem?

• …você trabalha dentro de uma bolha. O User Experience Designer quase nunca trabalha sozinho. Você precisa conversar com o gerente de projetos, com o planejador, com o designer e com o programador – bem antes de colocar a mão na massa. E claro, receber feedback dos usuários.

• …você faz decisões de design baseado em suas próprias referências pessoais. Toda decisão deve ser baseada em algum argumento racional – seja ele obtido através de pesquisa ou não. Mas se quando alguém pergunta por que você reposicionou algum elemento e sua resposta contém as palavras “prefiro”, “acho” ou “gosto”, então você não é um User Experience Designer.

• …você não considera os objetivos de negócios. Definir os Key Performance Indicators é um dos estágios iniciais do processo. Aumentar as taxas de conversão em 10%? Aumentar o tempo de navegação em 30 segundos? Aumentar a média de page views por usuário de 1,1 para 1,3? Criar formas de medir a taxa de retorno? Fazer as pessoas tuitarem? Algum objetivo o projeto tem que ter. E conversar com o Gerente de Projetos e com o Analista de Métricas vai ajudar bastante a definir e mensurar esses objetivos.

• …você não usa métodos. Entrevistas com usuários, testes de usabilidade, personas, cenários, card sorting, diagrama de afinidades, rabiscoframes, wireframes, fluxos, diagrama de telas, protótipos, testes A/B e muito mais. Se você não utiliza a maioria desses métodos – ou se pelo menos não estabelece um critério claro na hora de decidir utilizar um ou outro – então você não é um User Experience Designer.

• …você não pensa nas exceções. Se você trabalha sempre com os melhores cenários, você está sendo otimista demais para um UX Designer. As notícias do seu site não vão ter foto o tempo todo. As galerias multimídia não terão 30 fotos para compor o seu grid. Não é todo usuário que tem caixas de som ou fones de ouvido. Não é todo celular que roda javascript. Não é todo mundo que começa a navegar pela homepage. Se você não consegue prever esses cenários, então você não é um User Experience Designer.

• …você só pensa no wireframe. Se você só pensa no que o usuário vê em seu site, aplicativo ou quiosque – mas não pensa em como o usuário vai chegar lá, o que ele vai fazer depois, qual sentimento você quer provocar ou quanto tempo você espera que ele permaneça ali – você é um User Interface Designer, e não um User Experience Designer. Tem uma diferença aí.

É claro que se você participa em qualquer etapa do processo de criação de um produto (como Visual Designer, Programador, Redator), você está afetando diretamente a experiência do usuário. E para isso você deveria entender quem é esse usuário, quais são suas necessidades, referências e objetivos ao utilizar o tal produto.

Mas se você, UX Designer, não é a pessoa responsável por disseminar esse conhecimento por toda a equipe, então talvez existem coisas que você possa melhorar no seu processo de trabalho.

Talvez a lista de Whitney Hess pegue um pouco pesado em alguns pontos. Para muita coisa não existe certo ou errado. Mas existe uma série de referências bacanas de metodologias que funcionam e que trazem bons resultados. Então não custa dar uma olhada, filtrar e tentar aplicar uma coisa ou outra no seu dia-a-dia.

FONTE: Arquitetura de Informação

Nós sabemos que diversos produtos revolucionários já foram concebidos em um guardanapo de botequim. Às vezes, usar os bons e velhos recursos do lápis e papel é a melhor forma de garantir grandes idéias e raciocinar livremente sobre elas.

Os kits de estêncil desta loja são projetados para ajudar rapidamente no esboço de interface com o usuário, traçando fluxos e idéias sobre como um novo aplicativo pode funcionar. Assim, as boas idéias podem fluir naturalmente. São réguas e blocos para criar interfaces do Iphone, Android, Ipad e websites.

Eu já comprei o meu e é muito legal.

Abraços.

Link: www.uistencils.com/

Quem trabalha com arquitetura de informação e usabilidade sabe que o aluguel ou compra de um equipamento profissional de eye-tracking pode custar os olhos da cara. (Pausa para reflexão sobre o trocadilho infame.)

Mas essa semana a Tobii Technology lançou, em parceria com a Lenovo, o primeiro laptop equipado com sistema de eye-tracking nativo. O sistema está programado para executar comandos baseado na direção dos olhos dos usuários. Você olha para determinado canto da tela e o menu aparece. Você pisca um dos olhos e dá o play em um vídeo.

Se a tecnologia se popularizar, preparem-se para projetar também interações com os olhos – além dos cliques, toques e recentes gestos. Interessante como o conceito de “interface” tem buscado inspiração em novos sentidos e partes do corpo. E é bom a gente estar preparado :)

Fonte: Arquitetura de Informação

Um nova tecnologia, design, protótipo, processo de trabalho ou patente pode ser criada a partir de uma invenção. Mas é por meio da inovação que as invenções são transformadas em produtos e serviços comerciais.

É mais importante ainda, entender que uma invenção somente tem valor de mercado quando consumidores e usuários compram ou a usam.

É por isso que hoje, muito mais importante do que equipes de criação trabalhando, isoladas do mundo, gerando ideias de novos produtos, vale muito menos do que ir a campo, olhar para o mundo e identificar desejos e necessidades reais e desenvolver produtos que irão atender a demandas reais .

Cada vez mais a pesquisa em design, como a pesquisa em campo e os testes de usabilidade se torna ainda mais importante na corrida pela inovação. Não só para identificar novas demandas e necessidades mas também para validar os novos produtos, ajudando a evoluí-los.

Leia este post do Thomas D. Kuczmarski  na Bussinesswek para entender melhor a diferença entre os dois conceitos.

FONTE: Designing for Humans

Quando o excesso de ícones de redes sociais começa a atrapalhar a interface de seu site, é hora de repensar a vida. Além de poluição visual, muitas vezes acaba distraindo a atenção do usuário daquilo que você tanto quer que ele compartilhe: o conteúdo.

Os ícones de compartilhamento podem até servir como um lembrete, no final de um texto muito extenso, como cita esse artigo.

“The reason behind adding one share widget to the bottom of each article is based on logic and user experience. If a person enjoys your content enough that they read through the entire article, they will be more inclined to share it. So when they get to the very end of the article, what should be there waiting for them to spread information they are interested in? A non-obtrusive share button that does not distract from the rest of your article. You only have a few seconds to grab the reader’s attention, and adding more widgets will create more clutter that users don’t want.”

Tenho a tendência a acreditar que, se o conteúdo é realmente bom, ele será compartilhado mesmo sem nenhum desses botões. Em todo caso, não custa lembrar o usuário que não está acostumado a copiar a colar links da barra de endereços.

Mas será que o The Washington Post não está exagerando?

Mas como é um tipo de lista muito pessoal e muito polêmica, vou listar aqui apenas os meus motivos. Faça o mesmo ali embaixo, nos comentários.

1. Som automático. Não tem coisa mais irritante do que ser surpreendido por uma trilha-sonora mal educada em um site. É como abrir a porta do banheiro logo cedo e se deparar com uma orquestra inteira retumbando clarinetes e pratos no seu ouvido. Se a trilha-sonora for realmente enriquecedora para a experiência de navegação, seja educado: deixe que o usuário a ative, ou comece com uma versão minimalista na homepage.

2. Banner DHTML, o pega-rato. O pop-up clássico não me irrita tanto, porque quem coloca pop-ups em um site o faz por inocência, ou por ignorância, ou whatever. Mas o DHTML é por maldade. É para tentar driblar o bloqueador de pop-ups do browser. E em alguns casos a má fé é ainda maior: o botão fechar é propositalmente pequeno para que a pessoa se engane e clique no banner na hora de fechá-lo. Em alguns sites gringos existem ainda os Interstitials, o primo malvado do DHTML. Veja um exemplo no site da Forbes. Esse não é de Deus.

3. Loading. Eu ainda tolero um pouco de loading porque normalmente estou interessado em explorar o site por motivos profissionais. Mas imagino quem chega no site cheio da boa vontade e se depara com um loading que demora mais do que… 10 segundos. Agravantes: loadings sem indicação de progresso e sites que não armazenam o loading em cache. Um descuido na hora de navegar e pronto: lá está o loading novamente no 0%, firme e forte, rindo da sua cara.

4. Erros de português. Alguns são irrelevantes, mas alguns são imperdoáveis e levam uma vida inteira para cicatrizar.

5. Falta de clareza. Quando eu entro em um site, quero entender do que se trata em menos de 2 segundos. Não quero precisar clicar em “About” e ler dois parágrafos de texto, ou ter que rodar um vídeo-tutorial que não possa ser resumido em uma frase. Objetividade e clareza não fazem mal a ninguém, não é mesmo?

Ilustração de um usuário em dúvida.

E os seus motivos, quais são? O que te faz pegar ódio mortal por um site?

Desabafe, arquiteto de informação. É quase uma terapia :)

FONTE: Arquitetura de Informação

Este texto, fiz questão de colocar aqui no meu site, para provocar todos aqueles que se aventuram em desenvolver sites e portais.

“Websites são funcionalmente confusos porque não são delicados o bastante, porque não foram desenhados com a atenção necessária. Quando os websites precisam se tornar simples, simplicidade não é deixar tudo banalizado ou estúpido. Pelo contrário. Simplicidade é quando alguém toma conta dos detalhes.” – Oliver Reichenstein

A caixa de buscas do Google é um universo à parte no que tange ao comportamento do usuário. Há algum tempo ela deixou de ser apenas um campo texto e passou a representar o ponto de partida de grande parte das tarefas realizadas na web. Com o tempo, passou a corrigir erros ortográficos, sugerir buscas relacionadas e – com o recente Google Instant – inclusive prever o que você está digitando.

Ainda assim, a busca do Google não está isenta de causar frustração nos usuários.

Usuária loucamente frustrada.

Agora imagine um mecanismo de busca que detecte essa frustação em tempo real e já sugira uma solução para o problema. É isso que o time de User Experience do Google vem tentando fazer e compartilha em seu blog.

“We gave users search tasks, some of which we knew to be difficult. The first couple of searches always looked pretty much the same independent of task difficulty: users formulated a query, quickly scanned the results and either clicked on a result or refined the query. However, after a couple of unsuccessful searches, we started noticing interesting changes in behavior. In addition to many of them sighing or starting to bite their nails, users sometimes started to type their searches as natural language questions, they sometimes spent a very long time simply staring at the results page, and they sometimes completely changed their approach to the task.”

Segundo o Google, além de mudanças faciais e corporais nos usuários que estão com dificuldades, ocorrem mudanças também na navegação.

“…those signals were: use of question queries, use of advanced operators, spending more time on the search results page, formulating the longest query in the middle of the session, and spending a larger proportion of the time on the search results page.”

Esses são os primeiros sinais de que sim, é possível que, no futuro, o computador identifique que o usuário está tendo dificuldades. É como se a frustração pudesse ser “catalogada” e identificada por uma inteligência artificial.

Sabemos que esse tipo de pesquisa monitorada (ou teste de usabilidade) é fundamental para que uma empresa tente entender melhor como as pessoas se comportam ao utilizar determinado serviço. Mas para o Google esse tipo de resultado deve ter um sabor especial.

Afinal, como ser inovador em um serviço que já está bem estabelecido e que as pessoas já sabem utilizar? Como evoluir a busca, que já é um processo tão simples, sem torná-lo complicado demais?

Não tem momento melhor para extrair esses insights do que ao observar pessoas.

Vai lá, Google!