Do início ao fim: projeto de aplicativo para o curso de UX/UI da EBAC

Introdução

O artigo a seguir descreve o processo de desenvolvimento de um projeto que realizei ao longo de um curso da EBAC. As aulas abordaram os principais conceitos de UX — user experience, do início ao fim do processo de desenvolvimento de produto.

A metodologia utilizada no curso foi a do “Diamante Duplo”, com o intuito de coletarmos o máximo de informações sobre um assunto, convergir os principais problemas encontrados, para então pensar em uma gama de soluções e, novamente, convergir na mais adequada.

Ao longo das matérias haviam atividades práticas na qual devíamos escolher um tema livre, que acabou sendo trabalhado de forma linear. Optei em trabalhar alguma dor de médicos residentes. Assim, o projeto foi se desenvolvendo ao longo das tarefas do curso e seus feedbacks.

O grande desafio de início foi: como realmente identificar um problema, partindo do zero?

Desk Research

O primeiro passo do projeto foi realizar um mergulho sobre o tema, através de troca de ideias com médicos residentes, sites especializados, vlogueiros que compartilham suas jornadas em vídeos, e através de um mini-documentário televisivo.

Encontrei alguns pontos em comum em todos os meios pesquisados:

• Há constante pressão sob os residentes, frequentemente resultando em nervosismo;
• Para muitas tarefas internas, é comum o uso de ferramentas manuais (como escrever em quadros ou pranchetas algumas informações entre os profissionais);
• As agendas não costumam ser fixas, e são constituídas por tarefas que variam de todas as formas (desde estudos a auxílio em cirurgias);
• É comum os profissionais trabalharem em mais de um local.

Mapa de Stakeholders

Ao aprender mais sobre esta ferramenta nas aulas assistidas, apliquei-a para entender melhor quem eram os atores no meu projeto, quais as suas relações e em quais níveis que eles modificam os resultados. O resultado foi sumarizado no mapa abaixo:

Benchmarking

Precisei entender também o que o mercado já oferece para tais profissionais. Através de uma análise, percebi que as principais tarefas ofertadas são:

• prontuários eletrônicos;
• bibliotecas de consulta de doenças (sintomas, remédios, causas);
• relatórios de pacientes;
• agendamentos de consultas;

Analisei também os feedbacks que os clientes escreviam para estes serviços, acessando páginas como as lojas de aplicativos (Google Play e App Store), redes sociais (Facebook) e sites especializados em reclamações de clientes (Reclame Aqui).

Todas essas análises serviram para peneirar possíveis nichos de mercado, já que algumas tarefas eram pouco ofertadas, e outras tiveram reclamações de entendimento de interface, de ações falhas, entre outros problemas apontados.

Matriz CSD

Após levantar informações gerais sobre o projeto, realizei uma matriz CSD para entender melhor o tema estudado, e ajudar a identificar melhor quem são os usuários.

A matriz ajuda a entender quais conteúdos ainda não são totalmente compreendidos, contribuindo assim para direcionar as próximas pesquisas que seriam feitas. As principais dúvidas que surgiram foram quanto ao entendimento maior do dia-a-dia dos residentes.

Proto Persona

Estes resultados iniciais foram compilados em uma proto persona, para guiar o andamento dos próximos passos. Assim, essa persona inicial teve um caráter fictício.

Ela se caracterizou por um médico residente, que mudou de cidade após terminar a faculdade.

A proto persona lida constantemente com insegurança quanto a veracidade dos dados que utiliza no dia-a-dia já que, caso estejam errados, podem acarretar erros irreparáveis. O fato de se mudarem também traz características sociais, pessoais e, principalmente, financeiras.

Pesquisa Quantitativa

A Matriz CSD e a Proto-persona guiaram o passo da pesquisa quantitativa, influenciando os lugares em que busquei os candidatos e as questões a serem perguntadas.

Foquei em entender as características técnicas do dia-a-dia e costumes dos profissionais, utilizando principalmente escalas de valor para não enviesar as perguntas.

Quase todos os entrevistados (médicos residentes), possuem bastante acesso ao celular enquanto trabalham. Como o curso instiga a produção de um produto digital, tendei entender como é o costume do uso de tecnologia pelo público.

Em relação as tarefas — se são mais manuais ou virtuais, constei que a tecnologia aparece mais forte para tarefas que costumam envolver os pacientes, enquanto muitas atividades internas ainda costumam ser realizadas manualmente.

Ainda ligado a uma questão mais interna, os profissionais relatam uma dificuldade de comunicação relativamente alta e, quando perguntados como sentem o trabalho de transferir um paciente de hospital, todos responderam uma dificuldade média a alta (valores 3 a 5).

Pesquisa Qualitativa

Para aprofundar o conhecimento na rotina dos profissionais do estudo, foram realizadas três pesquisas qualitativas, não estruturadas, acontecendo em forma de conversa para extrair o máximo de informações possível, e seguindo o seguinte roteiro:

• Como é o seu dia-a-dia no hospital?
• Como é o seu dia-a-dia no hospital?
• Quais as suas principais tarefas?
• Quais outros profissionais estão envolvidos nessas tarefas?
• Você costuma escrever manualmente durante o trabalho? Se sim, quaisinformações?
• Há um horário específico para se passar informações para o sistema? Oucostuma ser na hora que se atende os pacientes?
• Como é o processo para trocar pacientes do hospital?
• Já ocorreram problemas de comunicação com outros profissionais? Se sim, de quais tipos?

Aqui, os entrevistados moravam em três cidades distintas: Blumenau, Curitiba e Porto Alegre. Uma das entrevistas foi presencial, e as outras duas se deram de forma remota por vídeo conferência.

Os três profissionais são residentes, e em diferentes momentos e áreas (radiologia, obstetrícia e psiquiatria), e trouxeram alguns insights:

• É comum trabalharem em outros hospitais, fazendo plantões “por fora”;
• Embora tenham agendas definidas, elas costumam ter imprevistos frequentemente;
• Percebem muitos problemas de comunicação interna, desde médicos aparecendo no mesmo horário para um plantão, faltando horários, ou profissionais trocando pacientes com o mesmo nome da hora de fazer exames, entre outros;
• As atividades são bem diversificadas, desde consultar pacientes, fazer prontuários, passar informações aos sistemas, visitar pacientes, e até participar de/realizar cirurgias;
• Todos utilizam bastante a ferramenta WhatsApp para se comunicarem com os demais profissionais;
• Suas tarefas sempre passam pela aprovação de profissionais responsáveis (médicos(as) preceptores(as)/ chefes(as)).

Personas e Mapas de Empatia

As informações das pesquisas qualitativas foram separadas em post-its e agrupadas conforme temas similares, encontrando assim dois padrões diferentes que originaram duas personas — desta vez, com peso real.

Estes dois personagens personificam as informações levantadas, e têm como foco projetar um produto mais assertivo, devido à empatia gerada.

A primeira persona (Ana Lúcia), retrata duas questões principais: a mudança de cidade, o que acarreta trabalhos extras em mais hospitais para ter uma renda mais alta, e o esforço realizado sempre que é necessário transferir um paciente (ou receber).

Humberto, a segunda persona, retrata fortemente a questão da organização e o foco no desenvolvimento profissional, mais que o pessoal.

Acrescentei às personas mais dados relacionados às demais informações levantadas nas outras pesquisas, criando um mapa de empatia para cada uma.

Acrescentei às personas mais dados relacionados às demais informações levantadas nas outras pesquisas, criando um mapa de empatia para cada uma.

Jornada do Usuário e Needs Statements

Entendendo bem quem é o meu usuário, chegou a hora de analisar melhor as suas tarefas. Esta ferramenta foi utilizada para identificar cada passo do usuário, e mapear as reações que estas tarefas desencadeiam — e, assim, encontrar pontos a serem melhorados.

Junto com cada jornada, pensei em needs statements: uma ferramenta que sumariza em frases curtas a necessidade do usuário.

Quanto as necessidades da primeira persona, os momentos de mais dificuldade foram encontrados nos primeiros passos da tarefa de receber pacientes de outras instituições, por ser o momento em que recebem diversas informações que devem ser organizadas.

Já a segunda persona possui maiores problemas nas últimas etapas da sua tarefa: depois de receber todas as informações de modificação de plantão, o residente responsável deve alterar uma planilha manualmente, evitando ao máximo confundir informações e errar.

Assim, defini quatro principais needs statements (duas para cada persona), que resumissem as suas necessidades:

• Ana Lúcia precisa de um jeito de ter uma comunicação facilitada para transferir o paciente de forma rápida;
• Ana Lúcia precisa de um jeito de receber informações de forma organizada para não cometer erros;
• Humberto precisa de um jeito de organizar os plantões para ter mais tempo;
• Humberto precisa de um jeito de acessar a planilha de qualquer lugar para não fazer confusão.

Grid de Priorização

Então, tendo as frases como base, cogitei em como poderia resolver os problemas selecionados, fazendo um brainstorm cujas algumas ideias estão listadas na imagem abaixo:

Mas… como definir qual solução trabalhar? Para decidir, coloquei-as em um quadro analisando o esforço de implementação x impacto positivo para o usuário. Assim, a solução escolhida foi uma planilha inteligente, que funcione como um “secretário de escalas de plantão”.

Wireframes

Com uma ideia mais clara da solução surgida no projeto, comecei a destrinchar quais possíveis tarefas fariam parte do produto. Apesar de surgir diversas ideias boas, limitei as tarefas às mais básicas para uma implementação e testagem.

Após escolhidas, comecei os “rabiscoframes”: sketches à caneta para gerar diversas ideias que tornassem a solução representada graficamente.

Definindo as telas a serem trabalhadas, e como elas seriam dispostas, criei os wireframes para definir a hierarquia visual.

Prototipação e Teste de usuário

Os wireframes passaram para uma breve repaginada, deixando o produto um pouco mais humanizado e mais próximo de um produto final. Uma ação principal foi escolhida para reproduzir as telas, com o objetivo de serem testadas.

Assim, reproduzi as telas com uma usuária real (uma residente médica de radiologia), utilizando o serviço MarvelApp, que simula as interações entre telas.

Os objetivos do teste eram:

• Descobrir o quão intuitivo está o layout;
• Analisar o tempo para realizar cada tarefa do teste;
• Coletar insights de possíveis melhorias.

Para iniciar, criai um cenário para ambientalizar a usuária:

“Você é R1 de Clínica Geral no hospital Santo Agostinho e faz plantões por fora para uma renda extra. Um destes hospitais é o Santa Clara. Para ajudar nessa organização, você utiliza o aplicativo à seguir no celular.

Você tem um plantão de 24h no dia 22/08 no Santa Clara. Porém, surgiu um compromisso importante e você não irá poder estar presente.

Assim, você descobriu que o plantonista Roberto poderá cobrir o seu plantão.”

Após informado o cenário e outras diretrizes de pesquisa, foram feitas algumas perguntas como:

• Como você teria certeza que os dados do plantão estão corretos?;
• Você conversou com o Roberto e ele pode cobri-la no dia. Como você procede?
• Existem dois pacientes que precisam de cuidado extra: o João precisa tomar paracetamol e a Dona Alberta precisa acompanhar a glicemia. Como você agiria na troca de plantões em relação a isso?

Tal experimento resultou nas seguintes observações:

• A candidata, percebeu logo no início que não estava na página do hospital que desejava realizar a tarefa (trocar o plantão);
• Porém, ela levou bastante tempo para perceber onde trocava de hospital (nas setas na imagem, que ficam nas laterais do nome);
• Ela tentava, automaticamente, trocar de hospital deslizando o dedo pela tela;
• Depois, conseguiu encontrar a data rapidamente;
• Conferiu as informações sem problema;
• Selecionou o colega para trocar o plantão. Porém, depois, ela não sabia mais o que fazer (como a tela ficou grande, a seta para avançar ficou no fundo e ela não rolou a tela de imediato);
• Após achar o botão em que avança, ela conseguiu finalizar a última tarefa {simular digitar informações sobre o paciente);

Resultado Final

Graças ao teste com a usuária, pude pensar em algumas melhorias. Entre elas:

• Criar um calendário único para a pessoa que acessar, e não um para cada escala de cada hospital em que o médico trabalhar;
• Uma sugestão da usuária: trabalhar com cores contrastantes para cada item da legenda, para agilizar a memorização e aumentar a acessibilidade;
• Trabalhar com botões flutuantes na hora de avançar a tela, para que fiquem fixos e acessíveis em qualquer momento.

Assim, atualizei as telas com as melhorias. As atividades do curso se encerraram por aqui, mas estariam prontas para mais uma rodada de testes, visando novas melhorias — e assim por diante.

Conclusão

O projeto foi extremamente enriquecedor, pelo fato de ver os conceitos aplicados na prática.

Tive um pouco de dificuldades na questão de organização, por estar sozinho, e também um certo bloqueio no início devido ao fato de não ter claro o que seria trabalhado ainda — afinal, como descobrir um problema “do nada”?

Mas todas estas questões foram se ajeitando conforme o trabalho se desenvolvia. Fui conversando com profissionais, entendendo melhor o cenário e coletando insights. Inclusive, ideias iam surgindo aos poucos.

Ideias estas que se modificaram com o tempo. É interessante analisar o poder das pesquisas ao longo de um projeto, e o quanto elas agregam para um resultado mais consistente.

Quanto ao desenvolvimento do produto, gostaria de dar continuidade ao projeto, fazendo mais testes e coletando mais insights, mas devo focar em outras prioridades no momento. O conhecimento adquirido já foi mais que satisfatório.

Obrigado pela leitura!