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 ScrumJeff 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ê.

Tags: , , , ,

21 Responses to “Agile UX: Como trabalhar com os designers”

  1. “Pense fora da caixa!” Excelente post Guilherme, acho que o caminho é esse mesmo. Sempre chegamos a conclusão que não existem respostas fáceis e é preciso buscar aquilo que funciona melhor para cada situação.

  2. [...] Guilherme Chapiewski Enviar por e-mail  | Hits para esta publicação: [...]

  3. Antonio Carlos Silveira says:

    GC, estou tendo uma experiencia bem diferente da que acontece na Globo.com, na minha equipe no Yahoo!.

    Vou escrever um post a respeito, este é sem duvida um dos assuntos mais “quentes” em termos de desenvolvimento ágil de produtos.

  4. [...] um post resposta bem legal do Alistair Cockburn. E alguns dias atrás o Guilherme Chapiewski fez um excelente post sobre como tem sido a experiência na Globo.com até o momento. Eu passei por este problema lá e [...]

  5. Antonio Carlos Silveira says:

    Tá lá o Post sobre a minha experiência com Design + Desenvolvimento iterativo no Y!

    http://www.acarlos.com.br/blog/2008/12/agile-ux-como-integrar-ux-e-desenvolvimento/

    abs

  6. Luiz Aguiar says:

    Ficou muito bom o post GC, excelente, parabéns!

  7. Andre Brito says:

    BDUF me lembra ICONIX :)

  8. Só to passando aqui para te parabenizar pelo uso correto da expressão “ir de encontro à”. É tão raro que eu fico feliz toda vez que vejo.

  9. [...] como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como [...]

  10. [...] como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como [...]

  11. [...] como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como [...]

  12. Muito bom, enviei automaticamente para os designers aqui da empresa!

  13. Brunno Silva says:

    Ótimo post, Guilherme. Porém, ele me trouxe uma dúvida. Eu confio no trabalho de minha equipe a ponto de não checar por qualquer erro funcional uma vez que eles dizem que concluíram uma tarefa. Caso haja falhas, cedo ou tarde, o Product Owner irá fornecer um rápido feedback a respeito e será criada uma entrada para corrigir este defeito na próxima interação. Porém, algumas “falhas” de interface gráfica não são perceptíveis para o cliente, por se tratarem apenas de uma UX não tão boa quanto o esperado para o nível da equipe, mas ainda razoável para os olhos do cliente. Então, te pergunto: Como garantir o nível da equipe (e talvez até formentar o crescimento deste) em aspectos do software que fogem dos olhos críticos do Product Owner sem apelar para revisões?

  14. @Brunno,

    Não sei a resposta para essa pergunta :)

    Aqui na empresa já tentamos algumas coisas (incluindo revisão pelo UX Master) e até agora não temos respostas satisfatórias. Até agora minha opinião é a seguinte: contrate sempre os melhores profissionais de UX, mais experiêntes e mais sêniors que você conseguir.

    Dificilmente você, o P.O., o time ou o cliente vão perceber problemas de UX, por isso você precisa ter sempre os melhores especialistas de UX por perto para resolver isso para você.

    Fora isso não tenho nenhuma idéia mágica não :)

    [ ]s, gc

  15. Realmente, só quando nos colocamos na “pele” de outro proficional temos consciência das dificuldades de suas tarefas. Se todas pessoa que lidasse com projetos tivesse essa mentalidade, de tentar entender o outro lado, muitos problemas seriam resolvidos de forma mais prática. Muitas vezes o corporativismo, burocracia e o sentimento de onipotência atrapalham demais o projeto.

  16. [...] bem definidas durante o desenvolvimento do software, mas em algum momento será necessário que eles sentem juntos e colaborem para definir os detalhes da [...]

  17. [...] para desenhar belas interfaces dentro de um sprint não se precisa muito esforço. Como o Guilherme Chapiewski já percebeu, qualquer um com conhecimento mínimo de Photoshop ou Fireworks vai produzir algo de alta [...]

  18. [...] para desenhar belas interfaces dentro de um sprint não se precisa muito esforço. Como o Guilherme Chapiewski já percebeu, qualquer um com conhecimento mínimo de Photoshop ou Fireworks vai produzir algo de alta [...]

  19. [...] Agile UX: Como trabalhar com os designers | Guilherme Chapiewski (tags: revisar ux agile) [...]

  20. Ótimo Post. Como disse Antonio Carlos Silveira …. “quente”.

    O velho problema do trabalho em grupo.
    Isoladamente -> geniais. Agrupados -> argh.

    Fico feliz de ver essa discussão em pauta. São vários os problemas entre desenvolvedores e designers.

Leave a Reply