O lado negro dos wireframes: criando profissionais de um método só

wireframes

Já falamos por aqui sobre os vários métodos de UX e a função de cada um deles dentro do projeto. Alguns são relacionados a pesquisa com usuário, outros mais dirigidos a estratégia e planejamento de produto, outros mais focados em design – e assim por diante, um para cada etapa do projeto.

Ainda assim, UX Designers são lembrados primariamente pelos bons e velhos wireframes. Não adianta. É a marca registrada do UX Designer e, no fim das contas, é o bottomline do que a gente faz: a forma mais reduzida e tangível de materializar tudo aquilo que aprendemos à medida em que estudamos o usuário ou definimos a estratégia do produto.

Mas será que estamos aprendendo tudo o que devemos saber antes de colocar a mão na massa e produzir esses tais wireframes?

O mercado viciado em wireframes

Conversando com amigos freelancers, ouço com frequência a mesma história: clientes que só resolvem envolver o profissional de UX na jogada de última hora, quando o prazo está apertado e o diretor de arte precisa começar o layout no dia seguinte.

“Oi, meu nome é Fulana e eu estou tocando um projeto para a agência X. Você faz freelas, né? Você consegue fazer uma estimativa e orçamento e me devolver ainda hoje? O ideal é você entregar os wireframes prontos pra gente até amanhã, porque o Diretor de Arte já está parado esperando pra começar.”

Soa familiar?

Continue lendo »

Aceite os erros e desenhe para a imperfeição

“Eu acredito que nós devemos aceitar erros e complexidade. Precisamos nos afastar um pouco e pensar de forma mais ampla. Como é que nossas pequenas decisões estão impactando a forma como os produtos funcionam, e a forma como ele vai se encaixar na vida dos usuários?

Sugiro que os designers sigam as seguintes guidelines nesse caso:

  • Assuma o desconhecido: não importa quantas questões você pergunte ou quanta pesquisa faça, sempre haverá algum tipo de comportamento que você não consegue prever ou entender. Isso vai acontecer sempre. Uma pequena mudança nas tendências fará com que o uso da sua ferramente mude.
  • Pense sistematicamente: todos os dados que coletamos em personas e os conceitos que usamos para desenvolver storyboards não são somente inputs do processo de design, eles são o processo de design. Em cada etapa do projeto, discuta explicitamente quem são os usuários, suas expectativas, comportamento e necessidades, e como eles são supridos de formas diferentes na jornada.
  • Use e construa padrões e guidelines: arte e ciência evoluem quando você constrói usando o que já existe. Use padrões e entenda como eles se aplicam ao seu trabalho. Crie padrões para o seu produto, em vez de layouts.
  • Analise e foque: admita que você não entende tudo sobre as pressões, comportamentos e inputs que vêm do usuário. Mas não é por isso que você pode negligenciar o que você já sabe sobre eles.”

Daqui.

Job stories, personas e distrações semânticas no Design

Alan Klement fala em seu blog sobre o uso de job stories para criar funcionalidades em produtos digitais.

Segundo ele, o uso de user stories (criadas a partir de personas) fez sentido durante muito tempo em times de design na hora de pensar funcionalidades que fossem relevantes para o público-alvo do produto. Mas esse não é mais o caso.

O problema é que “personas são consumidores imaginários definidos por atributos demográficos que não levam em conta as causalidades de suas ações” – ou seja, as motivações que fazem o indivíduo utilizar o produto.

O exemplo citado por ele: personas não explicam porque o consumidor comeu aquela barra de chocolate na beira do caixa da loja de conveniência. Ter somente 30 segundos para comprar algo e saciar a fome por 30 minutos, isso sim explica as motivações do consumidor.

Snickers

Quando uma funcionalidade que foi criada a partir de user stories falha, é muito difícil identificar se o motivo da falha foi um problema de implementação do produto ou se foi um problema que aconteceu lá atrás, na hora de entender se as motivações que levam o consumidor a usar o produto eram legitimamente válidas. O que, a meu ver, faz um certo sentido.

JobStory

O modelo mais comum de user stories tenta “adivinhar” as motivações dos consumidores.

Qual a diferença entre user stories e job stories?

A maior delas é que as job stories incluem a situação no meio da frase. A situação ajuda a testar se a motivação do consumidor é válida e, à medida em que a job story circula entre mais membros do time de design, mais as pessoas podem ajudar a verificar se aquela motivação soa humana o suficiente para justificar a funcionalidade que está sendo criada. E é claro, é um processo que se retroalimenta: a funcionalidade vai tomando forma à medida em que as pessoas vão ajudando a lapidar a job story.

Continue lendo »

UX em agências digitais

Texto enviado por Richard Jesus.

UX_em_Agências

Construir marcas fortes nos dias de hoje é um desafio enorme e que, aparentemente, vai aumentar. Investimentos cada vez mais elevados apostam na comunicação como ferramenta para conseguir diferenciação e valor agregado aos produtos e serviços e isso tem feito com que agências e clientes invistam na criação de serviços para suas marcas.

“Tell me and I forget, teach me and I may remember, involve me and I learn.”
- Benjamin Franklin

O que as pessoas irão se lembrar?

Seja lá qual for a área e o tamanho da agência, conhecemos alguns desafios no cenário atual: do lado do cliente, o prazo, orçamentos apertados e expectativa de retorno. Do lado do mercado, todos os lançamentos, surgimento de novos modelos de negócio e marcas, mudanças de hábito e novas tecnologias.

Continue lendo »

Seu design só é bom se seu desenvolvedor for bom

Designers e Desenvolvedores

Já falamos por aqui sobre a aproximação entre Designers e Desenvolvedores e o quanto essa parceria é importante para agilizar processos, elevar qualidade e evitar esforço desnecessário de alguma das partes.

A apresentação abaixo, criada por Magga Dora e apresentada no BostonCHI 2013, fala um pouco sobre essa colaboração entre os dois lados.

Um ponto importante que ela levanta é que os desenvolvedores que não acreditam na importância de UX já são um obstáculo a mais para o projeto sair com a qualidade esperada. É importante não só que o designer entenda a importância da participação do desenvolvedor, mas também que o desenvolvedor entenda que o designer não está lá apenas para dificultar sua vida.

(Se você estiver lendo este post por RSS ou email e a apresentação acima não abrir, veja-a no blog)

Receita para cozinhar boas experiências do usuário

iA

Em torno de um tema polêmico – e Oliver Reichenstein sabe fazer isso – voltamos ao tema de entregáveis, metodologia e processos.

Bureaucracy - Working with paper, scissors and glue to produce digital interfaces, creating cellulose mountains that no one would ever want to even look at.

A agencia iA – Information Architects se coloca no mercado com “foco na essência”, seja lá o que isso quer dizer. Nesta apresentação eles levantam alguns temas “contra-cultura-ux”. Ok, não é tão pesado assim, mas vale a leitura. É rapidinho.

Link: http://cloudfront6.ia.net/wp-content/uploads/2010/09/IA-on-iA_1-0_ORN.pdf

Lean UX: método de trabalho ágil para User Experience Design

Lean UX

Quem nunca?

Já falei por aqui sobre Lean UX e como muitas equipes de User Experience estão revendo sua metodologia para que os trabalhos sejam produzidos de forma mais ágil.

Ao invés de trabalhar com uma metodologia em cascata (onde o trabalho inicia com UX, depois vai para o time de Visual Design, depois para os desenvolvedores), algumas empresas estão optando por um método Agile, onde o tempo usado para documentação é menor e os protótipos funcionais do produto começam a surgir mais rapidamente.

Dessa forma, fica mais fácil colher feedback e fazer ajustes no produto antes que todo o tempo do projeto tenha se esgotado – já que os ciclos de implementação são menores.

Feedback Loops

A apresentacão abaixo, criada pela Pathfinder, compartilha alguns apredizados de dois de seus profissionais sobre como fazer a tal Lean UX funcionar de uma vez por todas na empresa.

(Se você estiver lendo este post por RSS e a apresentação acima não abrir, veja-a no blog)

Leia também:

Solidifique o conceito primeiro, adicione fidelidade depois

O conceito de “fidelidade” em um documento produzido por designers diz respeito ao nível de detalhamento que tal documento possui em relação à interface que está sendo produzida.

Um sketch feito rapidamente à mão, por exemplo, é o que chamamos de protótipo de baixa fidelidade.

Um layout montado no photoshop e com riqueza de detalhes é o que chamamos de protótipo de alta fidelidade.

Acontece que existem momentos distintos dentro do processo de design. Cada etapa do projeto demanda um nível de detalhamento (fidelidade) diferente.

Ross Popoff-Walker escreveu uma frase em seu blog que fez bastante sentido, tendo em vista tendências que tenho observado nos últimos projetos em que trabalhei.

Solidifique o conceito primeiro, adicione fidelidade depois.

Segundo ele, esse processo de detalhar como funciona a interface pode ser feito em um segundo momento.

O mais importante, no início do projeto, é definir um conceito que funcione bem e um fluxo de interação que faça sentido para o usuário. Feito isso, existe um segundo momento em que o UX Designer e o Visual Designer podem trabalhar juntos para adicionar fidelidade ao documento – seja ele um wireframe detalhado ou um layout com arte final em Photoshop.

O processo, segundo sua teoria, fica mais ou menos assim:

UX Fidelity

Mais importante do que Lean UX, metodologia ágil ou metodologia em cascata, é saber a hora certa de entrar em detalhes.

Gostei da maneira como foi colocado no artigo. Se quiser entender melhor, sugiro que leia o artigo completo.

Veja também: Entregue um cupcake ao invés de um bolo-com-recheio-e-cobertura

O começo do fim dos wireframes

Wireframe tristonho

Eu sei, o título deste post é um pouco polêmico. Mas talvez seja apenas o fim do wireframe como o conhecemos hoje, ou apenas uma mudança na forma de produzi-lo.

O que me motivou a escrever sobre o assunto foi uma mudança na forma de trabalhar nos últimos projetos em que participei – e uma mudança de mentalidade que tenho observado em times de UX com os quais tenho maior contato.

Wireframes são uma ótima ferramenta na hora de demonstrar como uma interface deve funcionar e quais informações estão contidas nela, além de serem muito mais rápidos de serem produzidos (e alterados) do que os layouts em Photoshop.

Até aí, nenhuma novidade.

No entanto, existem outras ferramentas e métodos que conseguem cumprir o mesmo papel em muito menos tempo e com um pensamento mais ágil.

Até alguns anos atrás era muito comum que em um projeto fossem desenvolvidos wireframes, layouts e depois mockups clicáveis de uma determinada interface. Um processo de trabalho em cascata, onde cada entrega é validada com o cliente para que a etapa seguinte se inicie. Essa é uma forma segura de garantir que o visual designer só começará a trabalhar quando o wireframe tiver sido aprovado pelo cliente e pelo restante do time, evitando horas desperdiçadas em refação.

Acontece que no exemplo citado acima, o time acaba desenvolvendo 3 protótipos sequenciais. O wireframe nada mais é do que um protótipo, uma simulação de como a interface deve funcionar. O layout em jpg também é um protótipo, uma segunda simulação da mesma interface. E quando o UX utiliza uma ferramenta de criação de layouts clicáveis ou wireframes clicáveis, ele acaba criando um terceiro protótipo da mesma tela.

O pior: nada disso é aproveitado na hora dos desenvolvedores escreverem o código.

Wireframe e Layout

São três layers diferentes para se chegar ao mesmo resultado. Ou duas, em alguns casos onde a ferramenta de wireframing é a mesma de criação de mockup clicável (o Axure é um bom exemplo disso). O problema é que quase tudo é posto de lado na hora dos desenvolvedores começarem a trabalhar.

Em discussões recentes com o time de Experience Design da R/GA (NY e SP), começamos a listar outras alternativas para agilizar essa etapa do projeto. E também colocamos algumas delas em prática.

UX e post-its

Algumas alternativas que testamos:

  • Wireframes colaborativos entre todos do time. Semana passada montei uma sessão de wireframing com todos os membros da equipe (visual designer, producer, redator, front-end developer, back-end developer e planejamento), onde usamos papel, post-its e caneta para montar as telas juntos – cada um colocando seu ponto de vista em cada decisão que tomávamos. Funcionou muito bem, especialmente porque o projeto tinha poucas telas. Em duas sessões de duas horas conseguimos montar o fluxo principal do site. A parte boa é que, saindo da reunião, todos já sabiam o que o site deveria conter e já puderam começar a trabalhar no mesmo dia, sem precisar esperar um deck de wireframes de 50 páginas para isso.
  • Sketches de UX + styleguides de Visual Design. Em alguns casos específicos, fica mais fácil desenhar em papel o conteúdo da tela e já partir para o Photoshop com o visual designer. A diferença é que, ao invés de layoutar tela a tela, o designer cria apenas os elementos-chave da interface, separadamente, como em um styleguide. O programador front-end junta as duas coisas (o sketch com o styleguide), direto no código. Isso torna a etapa de UX e arquitetura de informação muito mais curta, e também a de visual design. Mas talvez não funcione muito bem caso o site tenha um back-end muito complexo; algumas regras deveriam ser melhor documentadas para o desenvolvedor.
  • Mockups clicáveis. Essa opção pode ser feita usando o clássico Axure ou então uma dessas ferramentas que cria links em jpgs. A parte boa é que fica muito mais fácil para o cliente entender como o produto irá funcionar, sem precisar percorrer extensas páginas de wireframes. A parte ruim é que isso não descarta o trabalho inicial de pensar na AI da página (e layoutar, caso você queira que o mockup tenha o visual final). Outro ponto negativo é que depois que o cliente aprova o mockup, o código não é reaproveitado pelo front-end developer.
  • UX aprendendo a programar. Essa é uma ótima alternativa, para que o próprio UX designer monte o wireframe/protótipo usando HTML e CSS. Muita gente tem falado por aí sobre “desenhar no próprio browser“. A parte boa é que o protótipo fica muito mais realista (pode ser até mesmo responsive) e o desenvolvedor consegue aproveitar uma parte do código no futuro. A parte ruim é o risco do UX Designer ficar muito entretido nas linhas de código e ter pouco tempo para se afastar, ter uma visão geral da experiência e advogar pelo usuário mais do que pela interface – que convenhamos, é o que o UX faz de melhor.
  • UX e front-end developer criando protótipos juntos. Esse me parece o melhor caminho até agora, ou pelo menos o caminho que tem funcionado para mais tipos de projetos. Cria-se uma dupla de UX designer e desenvolvedor e eles desenham e montam juntos o protótipo. Tudo é feito sem muita necessidade de documentação, já que eles sentam lado a lado. Como é o próprio desenvolvedor front-end que está escrevendo o código, 100% dele é reaproveitado no produto final – ele só precisa adicionar o estilo depois que o visual designer tiver definido o styleguide no Photoshop.

Acho que uma das principais motivações nesse processo de reinventar o fluxo de trabalho de um time de Design é a constatação de que wireframes de alta fidelidade não têm tido um bom desempenho em certos tipos de projeto. Entre os principais problemas desse tipo de entregável:

  1. Wireframes estáticos não são muito bons em representar um design responsivo, a não ser que você desenhe umas 5 versões diferentes dele ou mais.
  2. Wireframes muitas vezes tentam simular um comportamento que já é nativo do HTML e do CSS.
  3. Alterações no wireframe de alta fidelidade levam mais tempo para serem feitas do que no código, por mais que você use elementos-mestres e outras táticas.

Antes de prosseguir, penso que seja importante diferenciar dois termos que, apesar de parecidos, são bem diferentes um do outro: protótipos e mockups. Pelo menos essa é uma diferenciação que sempre deixamos claro na agência.

Protótipo é uma primeira versão do produto, criado com a mesma linguagem de programação que será usada no produto final. Isso garante que o comportamento do protótipo seja mais próximo do comportamento final da interface – e também que o código possa ser reaproveitado na hora de construir a versão final. O Axure não gera protótipos, segundo essa definição; o que ele gera são mockups clicáveis.

Mockup é uma simulação de como a interface deve funcionar. Um wireframe em PDF é um mockup. Um layout em JPG é um mockup. Um wireframe clicável que não foi feito na linguagem de programação final que o produto usará também é um mockup.

Outro dia li um artigo que trazia uma lista das vantagens de protótipos em relação aos wireframes segundo Leisa Reichelt:

  • You’re making, not documenting. You can feel the thing you’re making.
  • You’ve got a thing you can start testing, in all kinds of ways, almost immediately. Prototyping is more like experimenting than describing your grand design.
  • It doesn’t have to look good to be effective. It’s easier to keep it rough which helps people give better feedback early on.
  • You start out with the barest structure of an idea and gradually build in the detail as you play with and test out the thing you have made.
  • You’re learning useful things (like how to better translate your ideas into code).
  • Stakeholders and clients get excited about prototypes in a way they never do about wireframes.
  • Prototypes are concrete where wireframes are abstract.
  • Prototypes create the impression of real progress—of something actually happening—in a way that wire framing never does.
  • Prototyping is addictive—you have to pull yourself away from it (rather than forcing yourself to stay in your chair and finish annotating your wireframes).
  • Prototyping encourages cross-disciplinary teams from the earliest stages of design. You get to work with smart people who can make your work better.
  • If you’re on a project where you feel like you have to wireframe extensively, there’s probably a better way to be doing that project.

A essa altura já deu para entender melhor o motivo do título do post.

E se você chegou até o fim desse post pensando que encontraria a resposta definitiva para o método que “substituirá” os wireframes, essa resposta talvez nunca chegará. Existem várias “vertentes” diferentes: a que acredita que designing in the browser é a melhor opção, a que acredita em post-it e caneta, a que acredita em sketches e muitas outras.

Eu prefiro não enxergar como “vertentes”, e sim como diferentes opções, cada uma com seus prós e contras. Cabe ao UX designer entender a ferramenta que funciona melhor para aquele projeto, para aquele prazo, para aquele time e para aquele cliente. That’s where the magic happens.

UX e Desenvolvedor trabalhando juntos, ao mesmo tempo

Esse veio de um infográfico da TargetProcess sobre como funciona o escritório da empresa e sobre como os ciclos de iteração entre UX e Desenvolvedor acontecem simultaneamente e tentam ser o mais breve possível.

UX Design e Desenvolvimento

Algo me diz que não é toda empresa que topa trabalhar assim e não é todo tecnólogo que aceita esse processo tão cheio de “incertezas”.

Alguns desenvolvedores têm receio de começar a programar sem antes receber um deck de wireframes de 50 páginas (no mínimo) aprovado e assinado pelo time e pelo cliente.

Mas quando você encontra espaço para esse tipo de metodologia, os resultados mostram que o tal “método de cascata” se torna cada vez menos produtivo para alguns tipos de projeto.

Google+