Baixar para ler offline
Carregado porCarolina Leslie
UX como estratégia
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.
UX como estratégia
- 1.
- 36.
Notas do Editor
- #4 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.
- #5 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.
- #7 Nesse momento você deve estar pensando, mas esse problema é de tecnologia… UX é outra coisa.
- #11 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.
- #14 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;
- #20 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?
- #22 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?
- #24 Converse e entenda seu usuário.
- #25 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.
- #26 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
- #27 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
- #28 - 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.
- #30 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?
- #31 custo de desenvolvimento x valor para o usuário
- #34 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.
- #35 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.
- #36 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.