Um framework para design de experiência: Why, What, How

RJ Owen, num artigo para o site InsideRIA, define um framework que dividide a visão de um produto interativo em três partes: Why, What, How (Porquê, O Quê, Como).

  • O Porquê se refere ao contexto: modelo mental do usuário, seus objetivos, ambiente de uso;
  • O Quê é o conteúdo, a informação que deve ser transmitida, os dados; e
  • Como é referente à mecânica do processo, os elementos físicos e digitais com os quais a pessoa interage diretamente.

Esses elementos têm uma dependência hierárquica: se você não compreende o Porquê, é impossível definir corretamente O Quê será oferecido como conteúdo ou funcionalidade ao usuário. Da mesma forma, antes de saber O Quê, não se pode estabelecer Como será a interação.

Nessa linha, o autor faz uma crítica pertinente ao conceito estabelecido na web, que diz que “o conteúdo é rei” quando, na realidade, dentro desse framework, o rei seria o Porquê.

Fica evidente a semelhança com os elementos da experiência do usuário, de Garret: Porquê é equivalente ao primeiro nível (necessidades do usuário e objetivos do negócio), O Quê é análogo ao segundo nível (funcionalidades e conteúdo) e Como representa os níveis seguintes (design de interação / AI, design de interface e design visual).

O que percebo é que, muitas vezes, os clientes não têm uma visão clara do Porquê de seu produto ou serviço, mas procuram consultoria profissional com a intenção de melhorar o arranjo e o funcionamento da interface (Como). Mas, claro, isso é compreensível e o nosso dever é esclarecê-los.

Via InfoDesign.

Prazer em ajudar startups

Ano passado, Karine, Leandro e eu, além de outros profissionais, fomos escalados pelo Yuri Gitahy a participar do time de mentores da Aceleradora, uma iniciativa que tem feito o trabalho nobre de “ligar investidores e empreendedores, realizando coaching para transformar startups em negócios viáveis”.

Nossa função, como mentores, é auxiliar as startups a construir e melhorar seus produtos e serviços, doando algumas horas de consultoria sobre os assuntos que dominamos.

A Campus Party 2010 foi uma ótima oportunidade de colocar, num mesmo espaço físico, vários desses mentores e startups. Lá, fizemos os primeiros contatos com os empreendedores apoiados pela Aceleradora e pudemos iniciar o mentoring com três delas: Omnilogic, Ninui e Ignit – todas com potencial inegável em seus produtos.

O foco do nosso mentoring foi em aspectos diretamente relacionados à experiência do usuário: utilidade, usabilidade, estética, estratégia de releases e evolução de produto. Além de dicas pontuais sobre como melhorar cada um dos produtos, tentamos, principalmente, guiar essas startups, passando alguns conceitos e práticas de design centrado no usuário.

É um trabalho que não nos dá retorno financeiro imediato, mas que certamente renderá bons frutos a médio e longo prazo. De qualquer forma, a experiência tem sido muito gratificante, pois percebemos, durante as conversas, o quão bem-vinda e útil tem sido a nossa ajuda.

Revista da pós-graduação em Design de Interação

Terminei a pós-graduação em Design de Interação na PUC Minas em julho do ano passado. Queria ter contado mais coisas aqui no blog sobre o desenrolar do curso e tudo que aprendi, mas outras atribuições me impediram de fazê-lo. Dentre essas atribuições, estavam os próprios trabalhos do curso, que, em algumas das disciplinas, consistiam em escrever um artigo relacionado ao que foi estudado.

No final do curso, foram escolhidos cinco desses artigos escritos pelos alunos. Eu tive a honra de estar entre eles. Meu artigo, intitulado Um modelo de cilco de vida para design de websites com foco no usuário, foi publicado na revista.

Legal também foi ter meus dois sócios, Karine e Leandro —somente meus colegas na época—, também na lista dos autores.

A revista está disponível para download no site do curso.

Mais um Dia Mundial da Usabilidade

Ontem foi o Dia Mundial da Usabilidade. Ou seja, dia de ao ir ao Instituto de Educação Continuada da PUC Minas, desde 2005. Só que dessa vez foi um pouco diferente pra mim, pois participei da organização.

A Latitude14, o IEC/PUC Minas e o curso de Especialização em Design de Interação promoveram o DMU 2008 em Belo Horizonte. No evento deste ano tivemos seis palestras e, em paralelo, a apresentação do Projeto Aqua, da Cúmplice.

As fotos que tirei já estão disponíveis no Flickr. Em breve publicaremos os slides e vídeos das apresentações no site do evento.

Série de entrevistas com designers de interação

Eu sou suspeito pra falar, pois são meus sócios, mas achei excelente a iniciativa do Leandro e da Karine de fazer uma série de entrevistas com outros designers de interação, falando sobre a trajetória profissional e o contexto de trabalho de cada um. Acho importante pra gente ter essa referência, saber como é, na prática, o trabalho em empresas que investem pesado em experiência do usuário.

Por enquanto, eles publicaram uma entrevista em cada blog:

E tem mais vindo por aí.

Ao invés de redesign, uma abordagem estilo Agile

Temos conversado muito aqui na Latitude14 sobre a aplicação dos conceitos de desenvolvimento ágil (ou Agile) no processo de design com foco na experiência do usuário. Tentamos herdar idéias como:

  • começar desenvolvendo somente a essência, a menor unidade de um sistema (sem perder a visão do todo, claro);
  • colocar o produto nas mãos do usuário para se ter feedback o mais cedo possível (iterar cedo para iterar mais); e
  • reduzir a burocracia e a documentação (documentos e relatórios mais “digeríveis”).

Falei um pouco disso num post anterior. A Karine também escreveu um post bem esclarecedor sobre o assunto no blog dela. Vemos que maioria dos projetos pode se beneficiar dessa abordagem, até mesmo produtos que já estão prontos.

Onde quero chegar com isso: existe uma cultura fortíssima de redesign no mercado. Pelo menos é o que constatamos, de forma muito evidente, aqui em Belo Horizonte, principalmente quando se fala em websites.

Não sei dizer se é uma estratégia das produtoras e agências para obter mais lucro, se ainda não pensaram em trabalhar de outra forma, ou se os clientes demandam redesigns sempre e elas não têm argumentos para justificar uma abordagem incremental. Talvez as três coisas.

Quando se faz um redesign completo, não há tempo de aprender o suficiente e acaba-se focando somente nos problemas principais do produto anterior. Fatalmente, numa nova versão, também surgem novos problemas, que serão cobertos muito depois, num novo redesign, já que a verba se foi toda no primeiro.

Como gostam de dizer os gringos, “joga-se fora o bebê junto com a água da banheira”. E aí ficamos nesse ciclo vicioso, no qual nunca se chega a um produto totalmente maduro. Melhoram-se alguns aspectos enquanto surgem novos, os projetos duram vários meses e, quando vão ao ar, já têm problemas congênitos.

Quando foi a última vez que você viu um redesign completo da Amazon ou da Netflix, por exemplo? O mesmo vale para o Google e o Yahoo!, que fazem melhoras constantes e seus produtos, ao invés de jogar tudo no chão e reconstruir do zero. São empresas que têm essa mentalidade, não porquê são grandes, mas porque precisam construir produtos sólidos, com o mínimo de risco possível.

Se é feito inicialmente um estudo mais criteiroso dos problemas que existem na versão atual de um produto, de forma a ordená-los em ordem de criticidade, é possível quebrar o grande redesign em pequenos projetos.

Refazer ou melhorar somente uma pequena parte ou aspecto de uma aplicação ou website faz com que aquele seja um produto melhor num prazo muito mais curto. Além disso, aprende-se sobre o contexto, os usuários e outros stakeholders no processo. E esse aprendizado é reaproveitado nos “mini-projetos” seguintes.

Usabilidade de cupom fiscal

Cupom fiscal com muitas informações e códigos

Será que é tão difícil tornar essas porcarias mais legíveis? Bastaria destacar as informações mais importantes (como data da compra, nome do estabelecimento e valores) e isolar os milhões de códigos e números inúteis.

Leah Buley: a equipe de uma pessoa só

Durante o iA Summit 2008, Leah Buley deu uma palestra sobre como ser uma “equipe de user experience de uma pessoa só”. Tendo passado pela experiência de trabalhar numa empresa onde só ela era responsável por todos os aspectos da experiência do usuário nos produtos — e em seguida ter ido para a Adaptive Path — ela dá dicas de como guiar o processo de geração e posterior filtragem de idéias. Durante a apresentação, enfatiza as vantagens de sempre envolver outras pessoas, mesmo que não sejam especialistas nessa área.

As lições podem ser aplicadas não só no contexto de “equipe de uma pessoa só”, mas também, perfeitamente, em equipes maiores.

Achei bem interessante o fato dos slides serem todos desenhados a mão, o que reforça a prática sugerida de gerar idéias à exaustão, no papel e caneta, antes de pular pra frente do computador.

Os slides, com o áudio da apresentação, estão disponíveis no SlideShare.

Vamos iterar

Desde o início da especialização em design de interação (e acho que desde sempre), tenho o interesse bem voltado ao processo de design — ou seja, o que fazer e quando fazer. Desenvolvi três trabalhos sobre esse assunto durante o curso.

Hoje acordei pensando na 37Signals. Mais exatamente, em seu processo de desenvolvimento de aplicações web e como aplicar alguns dos conceitos do livro Getting Real em outros contextos.

Um dos conceitos do livro é que, no processo de desenvolvimento de uma aplicação, as iterações (não confundir “iteração” com “interação”) devem ser feitas o mais rápido possível, implementando inicialmente só as funcionalidades essenciais e já começar a utilizar o produto, de forma a obter feedback rápido e melhorá-lo logo.

A outra vantagem que eles pregam sobre esta abordagem — que me levou a escrever este post – é de que isso mantém alta a motivação da equipe.

Motivation is local — if you aren’t motivated by what you are working on right now, then chances are it’s not going to be anywhere near as good as it could be. In fact, it’s probably going to suck. — Jason Fried

No contexto da web, onde pode-se modificar o produto imediatamente após o seu lançamento, isso é muito bem aplicado. Mas, em casos onde o produto passa por um processo industrial antes de chegar ao público final, mudar algo depois que já foi lançado é, no mínimo, inviável.

Por outro lado, iterar um protótipo, é plenamente possível. Aliás, este é o propósito da sua existência. E, neste caso, vale uma outra recomendação da 37Signals: “optimize for change”, ou seja, favoreça as mudanças. No caso dos protótipos, utilize técnicas que os torne fáceis de modificar ou de refazer.

Mas o ponto onde eu queria chegar é o seguinte:

Vejo que no processo de alguns trabalhos de conclusão da especialização em design de interação, pelo menos os que eu tenho acompanhado (incluindo o meu), estamos tentando realizar uma etapa de pesquisa muito extensa e bem documentada. Mas o que percebo é que, a partir de certo ponto, o entusiasmo com o projeto acaba.

Afinal de contas, ir a campo, observar, conversar com as pessoas, fazer descobertas, é bem legal, mas convenhamos… somos designers. As idéias começam a borbulhar na cabeça e, principalmente quando há muito material coletado para processar, a pesquisa perde o glamour e as idéias borbulhantes acabam esfriando.

Portanto, acredito de verdade que a prática do design, sempre que possível, deveria favorecer iterações rápidas e, por conseqüência, a motivação do designer. Pelo bem do resultado final (um bom produto), inicialmente pode-se realizar pesquisa de forma mais superficial — proporcionando a geração das primeiras idéias — e aprofundar aos poucos o conhecimento sobre o contexto, testando e refinando os protótipos o máximo possível ou até onde o prazo deixar.

Design "Intuitível"

Estes dois textos sugeridos num post do blog Design de Interação são muito importantes para que eu deixasse de citar. Esclarecem muito bem o conceito de interface “intuitível” (já que um objeto não tem intuição, portanto não pode ser intuitivo) e vão além, explicando outras coisas como a fragilidade das metáforas, a relatividade do “fácil de usar” e como equilibrar conhecimento atual e conhecimento alvo do usuário. Leituras indispensáveis pra quem projeta interfaces: