Olá mais uma vez. Hoje resolvi falar um pouco sobre um dos maiores dilemas para todos aqueles que querem mudar o mundo mas precisam de alguém para financiar essa mudança. Sim, somos nós, heróis de TI, que com muito esforço utilizamos muitas vezes de recursos que não existem, tempo que nunca é suficiente  e trabalhos que não são sempre reconhecidos.

Um dos maiores dilemas entretanto, é quando nos deparamos com a seguinte situação: Após uma série de estudos, definições e várias sessões de brainstorm, a equipe decidiu adotar a solução A. Entretanto, por algum motivo (que normalmente nem chega ao time) o cliente – que é quem está pagando – decidiu que para todos os envolvidos (usuários finais incluídos) é melhor que seja adotada a solução B. Soou familiar? Como procedemos nesses casos? Por que isso acontece?

Vou tentar responder de trás para frente.

Antigamente, o desenvolvimento de software tinha o foco muito diferente do que temos hoje em dia. Na época em que se alguém quisesse usar um software de planilha eletrônica tinha que recorrer ao Lotus 1-2-3 e, consequentemente, não havia a concorrência que temos hoje, o usuário era por muitas vezes refém de uma situação em que ou ele aprendia a utilizar aquela ferramenta (normalmente lendo um manual extenso e altamente técnico) ou “fazia na mão”. Isso acontecia principalmente porque quem projetava os sistemas eram pessoas que estavam naquele meio comumente (desenvolvedores de software). O que isso quer dizer? Quer dizer exatamente que se o usuário final não tivesse as mesmas habilidades de um programador, não conseguiria usar de forma satisfatória. Isso acontecia porque esse tipo de abordagem – em que o cliente está em foco e o sistema é desenvolvido baseado nos requisitos e desejos do mesmo – se baseia em premissas como:

• Ênfase no funcionamento do sistema
• Especialistas (desenvolvedores, designers, testers) trabalhando de forma isolada
• Não há validação do usuário até o primeiro release
• Visão de qualidade no produto (ex. número de bugs)

Diferentemente, temos hoje uma abordagem em que o sistema é projetado baseado nos interesses dos usuários que irão utilizar o produto que está sendo desenvolvido. Analogamente, temos então que o design centrado no usuário tem como premissas:

• Ênfase na interação com o usuário
• Equipes multidisciplinares trabalhando conjuntamente
• Validação por parte dos usuários antes mesmo de escrever a primeira linha de código
• Visão de qualidade baseada na satisfação do usuário

Vemos então que esse tipo de abordagem – a do design centrado no usuário – tem como foco trazer o usuário para dentro do processo. Mas e quando os usuários querem uma coisa diferente do que o cliente quer? Bom, nesse caso o mais prudente é tentar convencer o cliente da importância e do impacto que é ter um projeto que está alinhado com o desejo dos usuários finais. Um produto que não atende as expectativas não vai ser vendido (ou baixado) e não vai gerar lucros e/ou visibilidade. Contudo, nem sempre o cliente vai querer ceder e é aí que entra toda a experiência do profissional para saber lidar com a situação. Não se preocupe se não conseguir, nem todos querem mudar o mundo. Alguns simplesmente não podem fazê-lo.

Se tudo isso soou familiar, não se preocupe. Isso é sinal de que você está no mundo real.