O documento é uma carta de agradecimento por um cartão de aniversário. A pessoa agradece o gesto de enviar o cartão e deseja um feliz aniversário para a outra pessoa.
Aí eu parei para pensar em algum exemplo em que a experiência não funcionou como esperado - sempre vale aprender com os erros - sejam nossos ou dos outros. E numa olhada rápida pro jornal, vi o grande fail de um projeto tecnológico recente, o site eSocial.
Bem, para quem não sabe o eSocial é um site / sistema feito pelo governo para centralizar a cobrança de tributos de empregadores domésticos depois dos novos benefícios aprovados com a PEC das domésticas.
O problema é que a lei foi aprovada, estabeleceu um prazo para o início da cobrança dos impostos e o projeto… Bem, não ficou exatamente pronto. Quem acompanha o noticiário deve ter visto as diversas falhas técnicas que impediram as pessoas de completar o cadastro ou emitir as guias para o pagamento do imposto. O prazo inicial para a cobrança - que era sexta passada - foi prorrogado até o fim do mês para tentar resolver essas questões.
[Aqui vale um disclaimer - eu sou totalmente a favor da lei e da ampliação dos direitos trabalhistas de funcionários domésticos. A crítica que eu farei aqui é sobre o projeto do site, que, claramente, apresentou problemas.]
Um projeto muito bem intencionado - e que tem um impacto positivo para a sociedade, acabou sendo visto de forma bastante negativa pelo público geral por não funcionar de forma adequada.
Nesse momento você deve estar pensando, mas esse problema é de tecnologia… UX é outra coisa.
1. UX não é um cargo.
Ux é responsabilidade de toda equipe.
[Se a equipe de desenvolvimento não consegue entregar o que foi planejado, de nada adianta ter o formulário mais eficiente do mundo]
Se TI não entrega, sua experiência está quebrada.
Mostrar para a equipe de TI o que não é possível fazer.
Acompanhei algumas pessoas tentando o usar o site e as questões técnicas estão longe de ser as únicas barreiras de usabilidade encontradas ali - os passos necessários para se realizar algumas tarefas não são claros, estamos em 2015 e os formulários ainda têm um botão cancelar, há problemas de instruções sobre o preenchimento dos campos… A lista poderia seguir elencando observações pontuais sobre a usabilidade do sistema que têm um impacto muito negativo sobre a experiência de uso.
Mas eu queria usar esse exemplo hoje para falar da importância da UX na estratégia do seu produto.
Como uma visão de UX poderia ter mudado o destino desse projeto?
Construir o eSocial foi, sem dúvida, um projeto complicado:
- Escopo extenso e complexo;
- Público alvo extremamente heterogêneo;
- Prazo curto;
- Muita visibilidade;
Se você tem um escopo grande e um prazo limitado, não tente construir tudo de uma só vez.
Defina o que é seu produto mínimo viável - qual é o menor subconjunto de funcionalidades que você pode construir para garantir uma versão funcional do seu produto no tempo dado?
Mais vale um projeto pequeno com alto padrão de qualidade do que um grande sistema cheio de bugs.
Itere e continue incluindo novas funcionalidade em versões posteriores.
Agora, em um universo em que tudo parece importante, como definir no que realmente focar?
Converse e entenda seu usuário.
Seu escopo inicial já tem a visão da empresa ou instituição que demandou o projeto. E nem sempre a lista de requisitos formulada internamente condiz com o que o usuário final realmente quer ou precisa do seu produto.
A visão do usuário é um grande balizador da prioridade dos recursos no plano de futuro de um projeto.
Acompanhei algumas pessoas preenchendo o formulário e todas esbarraram em um mesmo problema: não tinham todos os dados necessários sobre os funcionários. Meu primeiro questionamento é para que tanta informação. Vamos supor que todas as informações sejam realmente necessárias: não seria bom informar o empregador, antes mesmo de iniciar o processo, a lista completa de informações necessárias, como um check list simples? Esse um recurso simples e de fácil implementação, mas que gera um grande valor para quem usa o sistema.
Voltando ao nosso exemplo - e simplificando um pouco as coisas - temos 3 grandes públicos:
Governo - quer receber impostos - secundário: mapear quem são os empregados domésticos
Empregadores - pagar de forma rápida os impostos devidos
Empregados - verificar se os tributos devidos foram devidamente pagos
Voltando ao nosso exemplo - e simplificando um pouco as coisas - temos 3 grandes públicos:
Governo - quer receber impostos - secundário: mapear quem são os empregados domésticos
Empregadores - pagar de forma rápida os impostos devidos
Empregados - verificar se os tributos devidos foram devidamente pagos
- esses dois últimos, como sociedade, também têm interesse em entender dados mais profundos sobre as relações de trabalho doméstico no país.
O eSocial se propõe a ser muito mais do que um site para se gerar uma guia de impostos. Porém, não dá para negar que, nesse primeiro momento de transição essa é sua função principal.
Uma abordagem melhor teria sido priorizar um cadastro simples, com a menor quantidade de dados possível para o funcionamento do sistema (CPF de empregador, PIS do empregado) que evoluísse para um sistema mais amplo. O registro completo de dados - como escolaridade e dependentes do empregado, poderia ficar para um momento posterior.
Um exemplo típico de falta de priorização é a tela para cadastro da carga horária semanal. O sistema pede a escala de horas diária - e permite o cadastro dessa informação de diversas formas - da simplificada e a completa.
Em um primeiro momento, não bastava perguntar a quantidade de horas em uma semana?
Quanto tempo foi gasto no desenvolvimento de uma funcionalidade que não é essencial para o produto final?
custo de desenvolvimento x valor para o usuário
4. UX te ajuda a definir uma visão do produto.
Será que quem estava no dia a dia do projeto tinha a consciência de que as prioridades poderiam se outras?
Como você pode evitar gastar meses desenvolvendo uma funcionalidade que entrega pouco valor?
A visão de que o projeto precisa ter um fim - uma data de entrega em que a chave é virada e ninguém mais se preocupa com ele - é outro mito que colabora com a criação de escopos impossíveis de serem executados.
5. Produtos digitais nunca estão prontos
Um site, aplicativo ou sistema precisa evoluir continuamente
As necessidades mudam, a tecnologia evolui, o contexto de uso se modifica. Não dá para acreditar que o investimento é pontual. Se isso vale para um sistema do governo, em um site ou aplicativo de mercado a necessidade de evolução constante é ainda maior.
6. UX não é uma linha no cronograma.
Assim como o projeto precisa ter uma evolução constante, a experiência de uso do seu produto precisa ser validada continuamente.
Incluir uma etapa de pesquisa - seja entrevistas de entendimento no início ou um teste de usabilidade no final - não vai fazer com que seu produto tenha uma boa experiência. É preciso criar uma cultura de melhoria da experiência, que monitore continuamente a percepção do cliente, pontos de dificuldade e necessidades não atendidas.
Imagino que o eSocial seja bem diferente dos projetos que vocês tocam no dia a dia. E, é claro que minha análise é topo do iceberg dos problemas e limitações encontrados no decorrer do projeto. Mas esse exemplo mostra bem como você pode começar a pensar em UX como algo maior do que um rótulo ou o formato de um campo de input.
Para conseguir criar experiências incríveis UX tem que ser a prioridade do time como um todo.