[UX] Case Study: Saúde Pública no Brasil
A saúde pública no Brasil tem muitos problemas, mas quais podem ser resolvidos ou melhorados com uma abordagem de UX design? E quais seriam mais relevantes para o usuário?
Para trazer uma solução dentro desse tema foi usada a abordagem de wicked problems, que traduzindo para o português poderíamos chamar de problemas cabeludos ou problemas capciosos.
Resumindo, podemos dizer que wicked problems são problemas do mundo real que admitem a complexa interdependência de diversos fatores e stakeholders, ao invés de abstrações simplistas e lineares de causa e efeito que isolam o produto de design do contexto.
É possível lidar com wicked problems combinando o pensamento sistêmico (systems thinking) com metodologias ágeis. O pensamento sistêmico nos ajuda a entender os componentes de um problema e a relação entre eles, enquanto a metodologia ágil ajuda a desenvolver soluções de forma colaborativa e iterativa. Novos problemas exigem um pensamento inovador, e ideias inovadoras surgem através de novas perspectivas.
O primeiro passo foi pesquisar e entrevistar os usuários para entender melhor o problema
Como mostrado no gráfico ao lado, milhões de brasileiros não tem plano de saúde: ou usam o sistema privado de forma pontual ou usam o SUS.
O SUS (Sistema Único de Saúde) é um dos maiores e mais complexos sistemas de saúde pública do mundo, segundo o Ministério da Saúde. Um dos princípios do sistema que podemos destacar é a universalidade: desde que foi criado, há mais de 30 anos, o acesso ao SUS passou a ser um direito de todos os brasileiros. Outro princípio importante é o da integralidade: o que significa que ele oferece desde o atendimento mais básico como avaliação da pressão arterial aos mais complexos, como transplante de órgãos, por exemplo.
Outra pesquisa mostra a incompatibilidade do investimento em relação ao número de pessoas atendidas nos sistemas público e privado. Como podemos ver no gráfico, temos valores de investimento muito parecidos, mas a saúde pública atende o triplo de pessoas.
Entrevistar os usuários foi muito importante, nos ajudou a quebrar alguns paradigmas e gerou empatia.
(questionário online: 45 respostas / entrevistas em profundidade: 10)
O Carlos teve plano de saúde durante muitos anos e há alguns anos usa o SUS. Além dele, vários entrevistados citaram o tempo de espera e também a infraestrutura como principais diferenciais dos planos de saúde em relação ao SUS.
Outra coisa que chamou a atenção foi a longa espera nos pronto-socorros de hospitais citadas por alguns usuários, como o caso da Érika.
Selecionamos os principais insights da pesquisa para começar a delimitar o problema e definir nosso usuário:
Para fazer essa seleção o diagrama de afinidade e o mapa de empatia foram ferramentas que ajudaram a organizar as respostas qualitativas.
Baseado nos dados da pesquisa com usuários reais construímos a persona. A Jackeline nos acompanhou durante todo o processo e ajudou em muitos pontos:
- Focar no conjunto de usuários específicos para o qual estávamos projetando.
- Limitar nossas escolhas, ajudando na tomada de decisões.
- Gerar empatia, envolvendo toda a equipe.
“Criar um produto para um tipo de usuário terá mais sucesso
do que para uma vasta audiência.” Alan Cooper — About Face: The Essentials of Interaction Design
Mapear a jornada da Jackeline nos ajudou a fazer um recorte do problema.
Mapeamos a jornada quando ela precisa ir até o pronto-socorro de um hospital. Incluímos uma camada de tempo vinculada a outra camada de emoções, já que um dos insights mais importantes da pesquisa foi em relação ao tempo de espera. Essa representação visual ajuda a identificar os momentos onde há grande necessidade e oportunidade de melhora, decidimos focar no tempo de espera até a consulta médica. Como estamos lidando com um wicked problem precisamos quebrar o problema em muitas partes e escolher uma delas para solucionar.
Declaração do Problema:
Observamos que o tempo de espera nos prontos-socorros dos hospitais geridos pelo SUS é extremamente longo causando muita insatisfação nos usuários e até desistência.
Para entender melhor o funcionamento de um pronto-socorro e capturar a experiência do usuário de forma mais profunda utilizamos o service blueprint.
O Service Blueprint é uma ferramenta que, assim como a jornada, também parte do ponto de vista do usuário, mas não se limita ao que ele enxerga. Inclui bastidores e outras interações que acontecem além do que está visível a ele, e que são essenciais ao funcionamento do produto ou serviço. Posteriormente, essa ferramenta nos ajudou a mapear as possibilidades de melhoria.
Como podemos melhorar a experiência em utilizar o pronto-socorro para que os usuários passem menos tempo ali até seu atendimento?
Hora de começar a pensar em ideias que poderiam ajudar a responder essa pergunta! Fizemos um brainstorm, organizamos as ideias e votamos nas que acreditamos que levariam as melhores soluções para a Jackeline, considerando todo o contexto:
Como vimos na pesquisa o investimento na área da saúde aparentemente é bem apertado. Por isso, buscamos trabalhar em soluções que dependam o mínimo possível de treinamentos ou estrutura tecnológica, visando baixo ou nenhum custo para os hospitais.
Analisando um cenário análogo, o google maps já fornece informações sobre horário de pico e espera para restaurantes. É possível transpor essa solução para ajudar um grupo de usuários como a Jackeline a fazer escolhas melhores na hora de ir para um pronto-socorro.
Montar um wireframe de papel ajudou a entender como acomodar melhor as informações de acordo com as necessidades do usuário.
Por exemplo, na ferramenta de restaurantes a primeira informação mostrada são as fotos, o que no caso de um pronto-socorro de hospital provavelmente não é tão relevante.
Protótipo
- Ao pesquisar no google por hospital público ou pronto-socorro os pins já indicam o status atual do tempo de atendimento em cada unidade: verde (até 2h de espera), amarelo (entre 2h e 6h de espera) e vermelho (mais de 6h de espera. Também é possível informar o horário de chegada e os pins são atualizados de acordo com a média de espera no horário desejado.
- Ao escolher uma unidade, além das as informações mostradas geralmente, o usuário terá acesso a um gráfico que indica horários de pico mostrando a média de espera por horários e dias da semana. A possibilidade de comparar o tempo de espera torna possível que o usuário tome a melhor decisão de acordo com o que sente naquele momento.
- Além disso a opção antecipar seu atendimento possibilita que o usuário consiga agilizar o cadastro na unidade escolhida: o usuário insere seu número de cartão do SUS e previsão de chegada, permitindo ao hospital agilizar seu cadastro.
Acesse o protótipo navegável no seu smartphone!
Roadmap
PRÓXIMAS FEATURES
- Disponibilizar informação “setorizada” por necessidade do usuário: preferencial, PS ortopédico, etc. (evolução da solução incluindo outros públicos através personas secundárias).
- Pré-triagem por telefone e online.
- Transporte gratuito para unidades ociosas.
VISÃO DE NEGÓCIOS
- Previsão de pico de atendimento (gestão de turnos, sazonalidade)
- Redução do tempo de contato com pacientes infectados
(equipe e outros pacientes)
Pitch
Quem estava assistindo a apresentação recebeu uma senha de atendimento e um sintoma que supostamente levou aquela pessoa até o pronto-socorro. Iniciamos a apresentação com uma foto de sala de espera de hospital e durante a apresentação colocamos um painel eletrônico chamando algumas senhas (bem distante das que entregamos pela sala). Dessa forma, colocamos as pessoas no lugar do nosso usuário desde o início da apresentação e no final cada um pôde acessar o protótipo navegável e acessar a solução no seu próprio smartphone. Imagina se soubessem o tempo de espera antes de vir e pudessem ter escolhido ir para outro hospital ou deixado a visita para outro horário?
Aprendizados
O resultado do projeto — uma solução simples e relevante para um problema complexo — comprova a importância do processo de design thinking centrado no usuário: a solução não onera o SUS e o google já é uma tecnologia familiar para o usuário.
Confiar no processo é desafiador, foram três semanas de trabalho e só começamos a pensar em solução lá pelo meio da última semana. O tempo limitado para cada etapa do processo foi importante para que não gastássemos mais energia que o necessário, para que não tentássemos resolver todo o wicked problem de uma vez só e para que não tivéssemos tempo de pensar em solução antes da hora.
Bibliografia
Facing Complexity: Wicked Design Problems — Daniel Christian Wahl
Dilemmas in a General Theory of Planning — Rittel and Webber
How to write a great UX case study — Karina Daukaeva
About Face — Alan Cooper
Equipe
O projeto foi desenvolvido em conjunto com Daniela Castro, Eris Fernandes, Fulvio Irente e Nathalia Sacks. A montagem do case para o medium é individual e a forma de apresentar varia de acordo com a visão de cada integrante do grupo. :)
Jun/2019 ˙ Ironhack São Paulo ˙ UX/UI Design
Orientação: Isabela Abrantes e Mayra Sasso
