Meu primeiro projeto trabalhando como UX Designer
Backoffice Klivo: Monitoramento de pacientes crônicos
A Klivo é uma Healthtech que tem como objetivo oferecer cuidados de maneira remota e personalizada para pessoas que convivem com doenças crônicas como: diabetes, hipertensão, colesterol alto e obesidade, visando reeducá-las para que alcancem a tão sonhada melhora clínica.
Meu papel: Para este projeto realizei pesquisas, defini fluxos, fiz entrevistas com usuários, criei Wireframes e desenhei a interface do usuário.
Processo de desenvolvimento:
1- Definição e escopo do projeto
O objetivo do projeto era construir uma plataforma do zero para o time clínico da Klivo, em que fosse possível armazenar e monitorar, em tempo real, informações sobre a saúde dos membros (pacientes), a partir de 4 pilares-base: Clínico; Físico; Nutrição e Mente. Os dados poderiam ser imputados manualmente pelo próprio time ou vir por meio do aplicativo Klivo, criado pelo Muhammad Umm, que seria vinculado à plataforma mais tarde, a partir de devices integrados como smartband e balança.
A plataforma auxiliaria o time clínico nos teleatendimentos, que aconteceriam a cada 15 dias com os membros, e seria um espaço de criação e acompanhamento da jornada clínica deles. Assim, nasceu o “BACKOFFICE KLIVO”.
…
2- Conversa com Stakeholders
O primeiro passo foi reunir o CEO, CPO, time clínico e os demais stakeholders para entender a visão, objetivos, qual valor queríamos entregar aos nossos usuários e o que iríamos priorizar. Levantamos pontos como: “qual será nosso público-alvo?”; “Como os atendimentos irão acontecer?”; “Quais dados serão necessários para o time clínico?; “Qual será o volume de atendimentos?”.
…
3. Persona
Depois de conversar com o time clínico consegui definir a persona e foquei em como centralizar todas as suas tarefas em um único local, e depender o mínimo possível de programas externos, dando mais agilidade para o time.
…
4- Pesquisa
(Documentação, entrevista com usuários, mind map e Benchmark)
O objetivo da pesquisa era descobrir como criar uma plataforma para construir a jornada clínica do membro, gerando dados suficientes para que o time clínico pudesse não só guiá-lo, proporcionando cuidado individualizado, como também visualizar a evolução dele. Então, criamos uma pesquisa de profundidade e contexto que tinha como objetivo:
- Entender o que é necessário para realizar um atendimento e acompanhamento à distância;
- Comparar com os principais competidores do mercado.
…
…
Mindmap — Backoffice: Depois de coletar o máximo de informações com as entrevistas e Benchmark, seguimos para um mapeamento mais detalhado das informações que traríamos para V1.
…
5. Wireframe
Começamos os primeiros rascunhos da estrutura da plataforma, sempre levando em consideração uma visualização rápida e objetiva, já que o time clínico precisaria de uma visão geral dos dados dos membros antes de realizar o atendimento.
Exploramos a ideia de criar um perfil para o membro exibindo todos os dados no mesmo lugar, separados por contexto, de maneira resumida e com a possibilidade de visualização mais detalhada. Dessa forma, o time clínico teria acesso apenas ao que é essencial para realizar o atendimento e, quando necessário, poderia também acessar dados mais detalhados, antigos ou de menor relevância.
Tudo isso foi pensado de forma que pudesse ser escalável com a entrada de novos features no futuro.
Definimos trazer para a V1:
- Dados pessoais; Dados de contato; Perfil de saúde; Medicamentos; Medições Glicêmicas; Diabetes (tipo 1 e 2); Dados evolutivos; Plano de saúde e observações gerais (campo para armazenar informações que pudessem ser necessárias, mas que ainda não tinham um campo específico. Basicamente, íamos “fisgar” as que poderiam ser novas).
…
6. Protótipo de média fidelidade
Seguimos para um protótipo de média fidelidade, focando em como padronizar cards que continham dados tão diferentes, mas que, ainda assim, precisavam exibir a informação de forma rápida e objetiva.
Depois de alguns testes, percebemos que poderíamos manter o padrão de exibir os 5 inputs mais recentes de cada dado, o que seria ideal para o time clínico. Dessa forma, conseguiríamos ter acesso ao histórico das informações, além da opção de novos inputs, edição e consulta detalhada.
Apresentamos para todo o time clínico e stakeholders e depois da validação de todos os times e testes de usabilidade, partimos para um protótipo de alta fidelidade.
…
7- Protótipo de alta fidelidade
Aqui temos o modelo do perfil do membro mais próximo da realidade. Foi desenvolvido no XD enquanto ainda não usávamos Figma na Klivo.
…
Com o tempo fomos implementando mais informações do nosso backlog no Backoffice, criando principalmente nossa agenda interna. Dessa forma, chegamos neste resultado, que ficou em teste por 1 ano:
…
Visão detalhada das informações:
Dados evolutivos:
- Cadastro manual e upload de exames com dois tipos de visualização: gráfico e tabela.
- Visualização espelhada facilitando a comparação de diferentes exames ao mesmo tempo.
…
Glicemia
Medições separadas por dias da semana, exibindo: Valor, horário, contexto (jejum, pré ou pós prandial).
…
Agenda geral Klivo
Sem dúvida alguma, a Agenda geral Klivo foi uma das implementações mais importantes para o time clínico, possibilitando não só criar e controlar os atendimentos, mas, também, categorizá-los, transferi-los entre os operadores, registrar a conduta do próximo atendimento no momento do cadastro e filtrar entre status e tipos de atendimentos: “fixos” ,“flexíveis” e “fila”.
…
Anotações
É um histórico contextual dos atendimentos, onde o time clínico registra tudo o que foi dito em linha.
…
Depois de um ano de testes, precisávamos evoluir o Backoffice, que já tinha uma base de 14 mil membros. O time Clínico já nos trazia feedbacks importantes para correções, junto com outros insights que havíamos coletado.
Notamos que lançar novas features estava demorando muito e o motivo era a complexidade em que o Backoffice havia sido construído tecnicamente e, pensando a longo prazo, fazia mais sentido investirmos esse tempo de solução de problemas em uma plataforma mais funcional, sem nos prendermos tanto à engenharia.
Já tínhamos muito bem definido o que e como evoluir. Então, demos início à segunda versão do “BACKOFFICE KLIVO”, que passou a se chamar: “KOCKPIT”.
Aqui eu explico o que e como migramos o Backoffice Klivo para o KOCKPIT
…
Obrigada! :)