Trazendo um processo de design melhor para sua organização

Como designers e pesquisadores de experiência do usuário (UX), a reclamação mais comum que ouvimos dos usuários é:

“Por que eles não pensam sobre o que eu preciso?”

Na verdade, muitas organizações têm equipes dedicadas a fornecer o que os usuários e clientes precisam. Cada vez mais desenvolvedores de software estão ansiosos para trabalhar com designers de UX para codificar interfaces que os clientes usarão e entenderão. O problema é que projetos de software complexos podem facilmente ficar atolados em prioridades concorrentes e confusão sobre o que fazer a seguir.

O resultado é um design ruim que impede a produtividade. Por exemplo, a eficiência nos cuidados de saúde é prejudicada pelos registros médicos eletrônicos (EMRs). As reclamações sobre esses sistemas de software são inúmeras. Dr. Steven Ugent, dermatologista de Boston e ex-aluno da Yale Medical School, não é exceção.

Desde 2010, o Dr. Ugent usa dois sistemas EMR: Antes de 2010, ele terminava o trabalho pontualmente às 5h15 todos os dias. Desde que ele e seus colegas começaram a usar EMRs, ele normalmente trabalha de meia hora extra a 1,5 hora à noite. “Não conheço nenhum médico que esteja satisfeito com seu sistema de registros médicos. O louco é que eu era muito mais eficiente quando usava caneta e papel.”

Os sistemas EMR são desajeitados, inflexíveis e difíceis de personalizar. Ugent, por exemplo, não pode incorporar fotos diretamente em suas notas de gráfico. Em vez disso, ele deve abrir a pasta com a foto da toupeira e depois abrir uma pasta diferente para ver o texto. Essa configuração é particularmente complicada para dermatologistas que dependem muito de fotos ao tratar pacientes.

Ugent resume sucintamente o problema com os EMRs:

“As pessoas que o projetam [o sistema EMR] não entendem meu fluxo de trabalho. Se o fizessem, eles projetariam um sistema diferente.”

Os médicos não estão sozinhos em sua frustração com softwares desajeitados. Consumidores e profissionais de todo o mundo fazem reclamações semelhantes:

“Por que não consigo encontrar o que preciso?”

“Por que eles tornam isso tão difícil?”

“Por que tenho que criar um login quando simplesmente quero comprar este produto. Estou dando dinheiro a eles. Não é o suficiente?”

Um dos principais contribuintes para softwares desajeitados são os processos de design falhos. Neste artigo, descreveremos quatro problemas do processo de design e explicaremos como resolvê-los.

1. Complexidade
2. Síndrome do próximo lançamento
3. Tempo insuficiente para iterações de design
4. Entregando o controle a fornecedores externos

1. Complexidade

Escala, múltiplas partes interessadas e a necessidade de código sofisticado estão entre os muitos fatores que contribuem para a complexidade de grandes projetos de software.

Às vezes, no entanto, são negligenciadas leis e regulamentos complexos. Por exemplo, o seguro é fortemente regulamentado em nível estadual, adicionando uma camada de complexidade para as companhias de seguros que operam em vários estados. Bancos e cooperativas de crédito estão sujeitos a regulamentação, enquanto as concessionárias devem cumprir as leis ambientais estaduais e federais.

Produtos de saúde e softwares sujeitos às regulamentações da FDA oferecem um desafio ainda maior. O problema não é que os regulamentos são irracionais. A segurança é primordial. As questões são tempo, orçamento e o planejamento necessário para atender aos requisitos da FDA.

Como Jeff Horvath, Ph.D., consultor de UX com vasta experiência em saúde, explica: “Esses requisitos adicionam algumas ordens de magnitude ao rigor para escrever protocolos de teste, configuração de teste, coleta de dados, análise, controles de qualidade e obter aprovação para conduzir a pesquisa em primeiro lugar.” Por exemplo, uma única rodada de testes de usabilidade salta de seis semanas (um prazo razoável para um teste de usabilidade padrão) para seis meses. E isso com uma única rodada de testes de usabilidade . Muitas vezes, são necessárias duas ou mais rodadas de testes.

Esse nível de rigor é um alerta para as empresas que estão começando a trabalhar com a FDA. Mais de uma vez, Horvath enfrentou conversas difíceis com clientes que não estavam preparados para os prazos estendidos e o orçamento adicional necessário para atender aos requisitos da FDA. É difícil, mas necessário. “Vale a pena ser minucioso”, diz Horvath. Em 2018, a FDA aprovou apenas 11% das submissões de pré-mercado.

As demandas de pesquisadores, designers e desenvolvedores são maiores para softwares de saúde que exigem conformidade com a FDA do que para produtos de software tradicionais. Por exemplo:

• Um pesquisador de UX pode realizar apenas uma ou duas sessões de teste de usabilidade por dia, em oposição às cinco a seis sessões mais comuns por dia para software padrão.
• Os designers de UX devem permanecer hiperatentos a todos os aspectos da interação do usuário com o software. Mesmo uma interação confusa pode fazer com que um médico cometa um erro que pode comprometer a saúde de um paciente. Pela mesma razão, os designers de interface do usuário devem desenhar interfaces que permaneçam fiéis a cada interação.
• Um prazo mais longo para testes de design e usabilidade significa que os esforços de codificação do desenvolvedor devem ser planejados com cuidado. Desenvolvedores habilidosos e bem-intencionados geralmente estão ansiosos para modificar o código assim que novas informações estiverem disponíveis. Embora essa abordagem possa funcionar em organizações bem praticadas em iteração rápida, ela traz riscos ao projetar e codificar sistemas complexos.

A falha em gerenciar a complexidade pode ter consequências fatais, como aconteceu quando Danielle McCray foi internada no Tallahassee Memorial Hospital quando estava prestes a dar à luz. Para aliviar seu desconforto, os profissionais de saúde a conectaram a uma máquina de analgesia controlada pelo paciente, uma bomba de infusão programável.

Oito horas depois, McCray foi declarado morto por overdose de morfina. Um fator importante nessa tragédia foi o projeto falho da bomba de infusão usada para administrar medicamentos. A bomba exigiu 27 etapas de programação. A falha em lidar com essa complexidade projetando uma interface de usuário mais intuitiva contribuiu para a morte desnecessária.

Solução

A solução é reconhecer e abordar a complexidade Este ponto parece lógico. No entanto, como explicado acima, regulamentações complicadas da FDA geralmente surpreendem os líderes das empresas. A negação não funciona. Não planejar significa que sua organização provavelmente cairá nos 89% dos envios de pré-mercado que o FDA rejeitou em 2018.

Ao realizar testes de usabilidade, os pesquisadores de experiência do usuário devem seguir três etapas para gerenciar a complexidade associada aos regulamentos da FDA:

1. O moderador (a pessoa que executa o teste de usabilidade) deve ser hiperatencioso. Por exemplo, se uma ressonância magnética exigir que um técnico siga uma sequência estrita de etapas ao usar o software associado, o moderador deve observar cuidadosamente para determinar se o participante segue as instruções ao pé da letra. Caso contrário, a tarefa é classificada como falha, o que significa que tanto o design da interface quanto a documentação associada exigirão modificação;
2. O moderador também deve acompanhar as chamadas fechadas. Por exemplo, um participante pode inicialmente executar as etapas fora de ordem, descobrir o erro e se recuperar seguindo a sequência correta. A FDA considera isso um erro, e o moderador deve denunciá-lo como tal;
3. O moderador também deve avaliar o conhecimento do participante. Ela acredita que seguiu a sequência correta? Essa crença é correta?

2. Síndrome da próxima versão

Um fator na falha em reconhecer a complexidade é uma mentalidade de consertar depois que chamamos de síndrome do próximo lançamento. Bugs de software não são um problema porque “vamos corrigir isso na próxima versão”. A ênfase na velocidade em detrimento da qualidade e segurança torna muito fácil adiar a resolução dos problemas difíceis.

Qualquer pessoa envolvida no design e desenvolvimento de produtos deve enfrentar a síndrome do próximo lançamento. Dois exemplos chamam a atenção:

• Descobrimos sérias falhas de projeto com o software de rastreamento de saúde de um cliente. A empresa optou por lançar o software sem resolver esses problemas. Não surpreendentemente, os clientes estavam insatisfeitos.
• Realizamos testes de usabilidade para uma grande cooperativa de crédito com sede nos EUA. Os participantes eram consultores financeiros experientes. Os testes revelaram sérias falhas de design, incluindo ícones de status confusos, botões com uma finalidade pouco clara e um link quase oculto que impedia os participantes de exibir dados importantes. Lembre-se, se o usuário não vê, não está lá. Quando relatamos as descobertas, a resposta foi: “Vamos corrigir isso na próxima versão”. Como esperado, a aplicação web não foi bem recebida. As respostas dos usuários incluíram: “Por que você nos pediu para revisar o aplicativo se você não tinha intenção de fazer alterações?”

Solução: Rejeite a mentalidade de consertar da próxima vez

A solução é resolver problemas sérios de design agora. Parece direto. Mas, como você convence os tomadores de decisão a mudar a mentalidade arraigada de “consertar depois”?

A chave é mudar a conversa sobre realização da entrega do produto para o valor criado. Por exemplo, as equipes que dedicam tempo para revisar um design com base na pesquisa do usuário provavelmente verão melhores reações do cliente e, com o tempo, maior fidelidade do cliente.

Fortaleça o caso usando dados quantitativos para mostrar aos tomadores de decisão a conexão direta entre a pesquisa do usuário e o aumento da receita e uma experiência positiva do cliente.

Redefinir valor é, na verdade, uma melhoria de processo porque estabelece um novo conjunto de prioridades que atendem melhor aos clientes e aos interesses de longo prazo de sua empresa. Como a McKinsey relata em The Business Value of Design: “As empresas do primeiro quartil adotam a experiência completa do usuário; eles quebram as barreiras internas entre o design físico, digital e de serviço.”

3. Tempo insuficiente para iterações de design

Relacionado com a síndrome do próximo lançamento, há tempo insuficiente para iterar o design com base nas descobertas da pesquisa ou nos requisitos de negócios em mudança. “Não temos tempo para isso”, é o refrão comum de desenvolvedores e proprietários de produtos. Designers que trabalham em ambientes ágeis são frequentemente pressionados a evitar “atrasar” a equipe de desenvolvimento.

O desenvolvimento acelera e o software é lançado. Todos nós já vimos os resultados de aplicativos de telefone confusos, software de registros médicos desajeitado, até a interface de usuário complicada para consultores financeiros mencionados acima.

Solução: picos de design

Uma solução vem do mundo da codificação. Em seu artigo “Fitting Big-Picture UX Into Agile Development”, Damon Dimmick oferece a ideia de picos de design, “bolhas de tempo que permitem que os designers se concentrem em questões complexas de UX”. Eles se encaixam no framework Scrum tomando temporariamente o lugar de um sprint regular.

Os picos de design oferecem várias vantagens:

• Eles permitem que as equipes de UX se concentrem em questões holísticas e evitem ficar atoladas em problemas de design granular que às vezes são enfatizados em um único sprint;
• Eles oferecem a oportunidade de explorar questões complexas de UX de alto nível. Se necessário, a equipe de design de UX também pode se envolver em pensamento centrado em design a qualquer momento para resolver desafios maiores de UX;
• Ao adotar picos de design, as equipes de UX podem aproveitar a mesma flexibilidade que as equipes de desenvolvimento usam no processo ágil e dedicar o tempo necessário para se concentrar em problemas de design que nem sempre se encaixam bem em um sprint scrum padrão;
• O desenvolvimento que provavelmente não será afetado por decisões de design pode prosseguir.

Naturalmente, as iterações de design geralmente afetam certas partes do código de um site, aplicativo ou produto de software. Por esse motivo, durante os picos de design, qualquer código que provavelmente será afetado pelo pico de design não pode avançar. Mas, como Dimmick afirma claramente, esse “atraso” provavelmente economizará tempo, evitando o retrabalho. Simplesmente não faz sentido escrever código agora e reescrevê-lo algumas semanas depois, depois que a equipe concordou com um projeto revisado. Em suma, adiar alguma codificação realmente economiza tempo e orçamento.

4. Confiar demais nos fornecedores

Abordar a complexidade, resistir à síndrome do próximo lançamento e dar tempo para a iteração são essenciais para um processo de design eficaz. Para muitas empresas, outra consideração é seu relacionamento com os fornecedores de software. Esses fornecedores desempenham um papel importante, até mesmo crítico, no desenvolvimento. No entanto, conceder a eles muita alavancagem dificulta o controle de seu próprio produto.

Certamente, devemos tratar colegas e fornecedores com respeito e fazer solicitações razoáveis. Isso não significa, no entanto, que seja necessário abrir mão de toda a alavancagem, como aconteceu durante meu mandato em uma grande empresa financeira.

Enquanto trabalhava nesta empresa como designer de UX, frequentemente encontrei essa dinâmica:

Gerente : “Ei, Eric, você pode avaliar este software de sinistros que estamos planejando comprar? Nós só queremos ter certeza de que funciona como pretendido.”

Eu : “Claro, enviarei minhas descobertas preliminares até o final da semana.”

Gerente : “Ótimo”

Na semana seguinte:

Gerente : “Obrigado pela avaliação. Vejo que você encontrou três problemas sérios: dificuldade de encontrar o número de uma reclamação existente, telas com muito texto de difícil leitura e dificuldade de retornar a uma tela anterior ao processar uma nova reclamação. Isso é preocupante. Você acha que esses problemas prejudicarão a produtividade?”

Eu : “Sim, acho que esses problemas aumentarão o estresse e o tempo de processamento na Central de Reclamações. Estou bastante preocupado porque meu trabalho anterior com a equipe de Janet demonstrou que os representantes do Centro de Reclamações já estão muito estressados.”

Gerente : “Muito bom saber. Acabei de enviar o cheque. Vou pedir ao fornecedor para corrigir os problemas antes de enviar.”

Eu (gritando por dentro): “Nãooooooooooooo!”

Esse gerente bem-intencionado fez exatamente a coisa errada. Ele pediu alterações depois de enviar o cheque. Não é surpresa que o fornecedor nunca tenha feito as alterações solicitadas. Por que eles iriam? Eles tinham seu dinheiro.

Não apenas esse cenário se repetiu repetidamente naquela empresa, mas eu testemunhei isso ao longo da minha carreira de UX.

Solução

A solução é clara. Se o produto do fornecedor não atender às necessidades do cliente e da empresa e as alterações solicitadas estiverem dentro do escopo, não pague até que o fornecedor faça as alterações. É realmente muito simples.

Conclusão

Neste artigo, identificamos quatro barreiras comuns ao design de qualidade e soluções correspondentes:

1. Regulamentos e padrões complexos
   A solução é reconhecer e abordar a complexidade criando cronogramas realistas e orçamento suficiente para pesquisa e design iterativo.
2. Software de envio com bugs com a promessa de corrigi-los mais tarde
   A solução é evitar a síndrome do próximo lançamento e resolver problemas sérios agora. Persuadir os tomadores de decisão redefinindo o significado de valor dentro de sua organização.
3. Tempo insuficiente para iterações de design
   A solução é incluir picos de design no processo de desenvolvimento ágil. Essas bolhas de tempo substituem temporariamente um sprint e permitem que os designers se concentrem em problemas complexos de UX.
4. Confiar demais nos fornecedores
   A solução é manter a alavancagem retendo o pagamento final até que o fornecedor faça as alterações solicitadas, desde que essas alterações estejam dentro do escopo original do projeto.

A quarta solução é simples. Embora os três primeiros não sejam fáceis, eles são concretos porque podem ser aplicados diretamente aos processos de projeto existentes. Sua implementação não requer uma reorganização massiva ou milhões de dólares. Requer simplesmente o compromisso de oferecer uma experiência melhor.