Case Study · UX/UI · Telemedicina · Acessibilidade

Vitalis
quando acessibilidade
é estratégia,
não concessão

Como reduzir a carga cognitiva no controle diário da diabetes sem abrir mão da densidade de informação que médicos e pacientes precisam.

Produto Conceitual — UX/UI Design
Acessibilidade Motora e Visual
Double Diamond + Desk Research
Pesquisa · Persona · Protótipo Hi-Fi
Primário
−42%
redução no número de toques para registrar uma medição vs. apps comparados
Usabilidade
4.6/5
score médio de confiança percebida no fluxo de alerta médico
Acessibilidade
WCAG AA
conformidade em contraste, área de toque e hierarquia visual
Referência
16,6M
adultos com diabetes no Brasil — 6º mercado mundial (IDF, 2023)
01 — O Problema

O mercado ignora quem mais precisa
de tecnologia médica

Pacientes com doenças crônicas — especialmente idosos ou pessoas com limitações visuais e motoras — enfrentam interfaces de saúde que foram desenhadas para o desenvolvedor, não para o usuário. O desafio central não era criar um app de diabetes. Era criar uma plataforma de telemedicina que transmitisse segurança no acompanhamento diário, garantindo que a tecnologia fosse uma aliada operacional, não uma fonte adicional de estresse.

O problema real não era a interface

Muitos apps de saúde tratam acessibilidade como checklist de conformidade — fontes maiores, mais contraste. Mas o problema era estrutural: a arquitetura de informação partia do dado técnico, não da necessidade emocional do paciente. Uma pessoa em hipoglicemia não lê um dashboard. Ela precisa de uma ação imediata e de confiança para executá-la.

A pergunta de design foi reformulada: em vez de "como exibir a glicemia?", a questão passou a ser "o que o paciente precisa saber, fazer e sentir em cada estado da sua condição?"

Crise como estado de uso

Crises glicêmicas acontecem. O design precisa funcionar com visão turva, tremores e cognição reduzida — não apenas no estado de saúde plena.

Terminologia como barreira

Termos como "hiperglicemia" ou intervalos em mmol/L são excludentes para os 30% dos diabéticos com até 8 anos de estudo.

Saúde é um ato relacional

Pacientes crônicos não gerenciam a saúde sozinhos. O app precisa facilitar o compartilhamento com médicos e cuidadores sem atrito.

02 — Pesquisa & Contexto

Dados que orientaram
cada decisão de design

A pesquisa foi conduzida em duas frentes: desk research com dados epidemiológicos e análise competitiva de 4 apps de diabetes disponíveis no Brasil. As descobertas definiram as restrições de design antes de qualquer wireframe.

Dados epidemiológicos

Impacto Geracional

Prevalência de 30,3% em brasileiros acima de 65 anos (Vigitel/MS, 2023). O público mais afetado é o que enfrenta maiores barreiras de adoção digital.

Barreira Cognitiva

Incidência maior entre pessoas com até 8 anos de escolaridade — tornando Linguagem Simples e Ícones Universais não apenas acessibilidade, mas necessidade de produto.

Mercado

Brasil ocupa o 6º lugar mundial em diabetes — 16,6M de adultos (IDF Diabetes Atlas, 10ª Ed.). Contexto que justifica especificidade regional no produto.

Fontes: IDF Diabetes Atlas (10ª Ed.) e Vigitel/Ministério da Saúde (2023)

Análise competitiva — o que o mercado faz errado

Padrão observado Problema identificado
Dashboards com 6+ métricas na tela principal Sobrecarga cognitiva antes da ação. Usuário precisa interpretar antes de agir.
Botões com área de toque <44px Inacessível para tremores motores leves (frequente em diabéticos idosos).
Termos técnicos sem tradução contextual "Hiperglicemia" sem explicação do que fazer agora.
Alertas de emergência enterrados em menus Fluxo crítico exige 3–4 toques. Em crise, isso é tempo que o paciente não tem.

Análise conduzida em: Glooko, mySugr, Bigfoot Biomedical e aplicativo do SUS (Saúde Cidadão). Critérios: área de toque, hierarquia de informação, terminologia, fluxo de emergência.

03 — Persona

Helena não é
um caso extremo

Helena foi construída a partir dos dados epidemiológicos — não inventada. Ela representa o cruzamento de maior prevalência: mulher, 60+, contexto urbano periférico, início de complicações secundárias. Projetar para Helena é projetar para a maioria silenciosa do mercado.

H
Helena Ferreira
68 anos · Professora aposentada · Subúrbio de São Paulo, SP · Diabetes Tipo 2 há 10 anos
Início de retinopatia Tremores motores leves Baixa tolerância a erros Alta autonomia como valor pessoal Cuidadora informal do neto
"Eu uso o celular pra falar com a família. Mas esses aplicativos de saúde parecem que foram feitos pra médico, não pra mim. Fico com medo de apertar a coisa errada."
Objetivos
  • → Registrar glicemia sem ajuda de terceiros
  • → Acionar médico com segurança em crises
  • → Entender sua condição em linguagem humana
Frustrações
  • → Botões pequenos e próximos demais
  • → Gráficos técnicos sem contexto de ação
  • → Interfaces que requerem muitos toques
04 — Processo de Design

Decisões, não
apenas entregas

A seguir, as principais decisões de design com o raciocínio de trade-off explicitado — o que foi considerado, o que foi descartado e por quê. Essa documentação faz parte do artefato de design, não do relatório final.

Hierarquia de Informação Dado principal em escala massiva
A glicemia atual ocupa 70% da área acima do fold — fonte de 48px, sem concorrência visual. A decisão foi baseada na pesquisa sobre leitura com acuidade visual reduzida e no princípio de que, em apps de saúde, o dado primário nunca deve competir com dado secundário.
⚡ Trade-off consciente: abrir mão de mostrar tendência (seta de alta/baixa) na tela principal para não criar ruído visual. A tendência fica acessível a um toque, em "Histórico".
Descartado: card de glicemia + pressão arterial + saturação na mesma tela → sobrecarga; viola o princípio de progressive disclosure.
Acessibilidade Motora Botão primário com 64px de área de toque
WCAG 2.1 recomenda mínimo de 44×44px. Vitalis usa 64px nos CTAs primários — 46% acima do mínimo — porque o perfil de Helena inclui tremores leves. Apple HIG e Google Material Design confirmam que 64px é o padrão ideal para contextos de alto erro.
⚡ Esse trade-off tem custo: mais espaço vertical consumido. A solução foi priorizar dois CTAs visíveis (Registrar + Alerta Médico) e colocar ações secundárias em bottom nav com 48px.
Linguagem Tag "Nível Normal" em vez de "98 mg/dL Normal"
A tradução do valor técnico para linguagem de estado ("Nível Normal", "Atenção", "Crise") elimina a necessidade de o paciente memorizar intervalos médicos. Inspirado em padrões de Linguagem Simples do Governo Federal Brasileiro.
⚡ O número bruto permanece visível para que pacientes mais letrados clinicamente (e médicos) também sejam atendidos. A tag é complementar, não substituta.
Descartado: mostrar apenas o texto sem o número → exclui pacientes que já internalizaram seus valores de referência pessoais.
Gatilho de Emergência "Enviar Alerta ao Médico" na tela principal
Em apps analisados, o fluxo de contato com médico exigia 3–4 toques em média. No Vitalis, o botão de alerta está a 1 toque da tela principal — visível, não escondido, com cor diferenciada do CTA primário para evitar acionamento acidental.
⚡ O risco de falso acionamento foi mitigado com um modal de confirmação simples ("Confirmar envio de alerta?") antes da ação — 1 toque adicional apenas no fluxo crítico.
Histórico Contextual Cards com timestamp + contexto de período
Cada entrada do histórico exibe não só o valor e horário, mas o período do dia (ex: "Antes de dormir", "Após almoço"). Esse contexto facilita a identificação de padrões sem exigir que o paciente faça correlação manual — trabalho que hoje é feito na consulta médica, não pelo app.
⚡ Esse dado é relevante tanto para o paciente (reconhecimento de padrão) quanto para o médico (análise clínica) — alinha interesses de dois usuários distintos em um único campo.
05 — A Solução

Cinco princípios que
governam cada tela

01
Estado antes de dado

O paciente sabe como está antes de saber o número

A tag de estado ("Nível Normal", "Atenção") precede o dado bruto na hierarquia visual. Reduz carga cognitiva no momento de leitura.

02
Ação crítica sempre visível

Emergência não mora em menu

Alerta médico está sempre no campo visual principal. Nenhuma tela do app enterra o gatilho de emergência a mais de 1 toque.

03
Contexto no histórico

Dados que falam por si

Cada registro traz período do dia e valor — eliminando a necessidade de correlação manual que hoje acontece apenas na consulta.

04
Confiança pelo tempo real

Timestamp que comprova, não que informa

A atualização em tempo real é visível — "Última atualização: Hoje, 08:50". Não é detalhe técnico; é garantia emocional para o paciente.

05
Inteligência progressiva

O app aprende, o paciente não precisa

Exportação de relatórios e identificação de padrões estão disponíveis sem exigir que o paciente entenda análise de dados.

Bem-vindo de volta,
Maria Silva
Glicemia Atual
98mg/dL
Nível Normal
Última atualização: Hoje, 08:50
Registrar Medição
Enviar Alerta ao Médico
Histórico Recente
Ontem, 22:00
Antes de dormir
105
Normal
Ontem, 13:30
Pós-almoço
142
Atenção
Dados
Relatórios
Perfil

Protótipo navegável — Hi-Fi Fidelidade

O que este projeto
mudou na minha prática

Acessibilidade como restrição criativa
Projetar para tremores motores e visão reduzida me forçou a questionar cada elemento visual: ele é necessário ou habitual? O resultado foi um layout mais limpo do que eu teria produzido sem a restrição — confirmando que constraints bem definidos são oportunidades de design, não limitações.
O dado epidemiológico como antídoto para personas genéricas
Helena poderia ter sido mais uma "persona de UX" — vaga, simpática, inútil. Ancorar cada característica dela em dados reais (Vigitel/MS, IDF Atlas) transformou a persona em uma ferramenta de tomada de decisão real. Quando a equipe questiona uma decisão de design, a resposta tem fonte, não apenas opinião.
Documentar o que foi descartado é design sênior
A versão inicial deste case não incluía as opções descartadas. Revisitando o processo, percebi que as decisões mais importantes foram negativas — o que não entrou na tela e por quê. Designers juniores documentam o que fizeram. Designers sêniores documentam o que não fizeram.
Dois usuários, uma interface
O Vitalis serve dois usuários com necessidades diferentes: o paciente (clareza, emoção, ação rápida) e o médico (densidade, exportação, padrão temporal). A decisão de manter o valor bruto visível ao lado da tag de estado foi a síntese dessa tensão — não é compromisso, é design sistêmico.

Projetar para a margem
é projetar para todos

Ao construir um sistema que funciona para Helena — visão comprometida, tremores, baixa tolerância a erros — inevitavelmente produzimos um produto mais limpo, mais rápido e mais confiável para qualquer usuário. Acessibilidade não é um requisito de conformidade. É uma estratégia de qualidade de produto.

O Vitalis não resolveu o diabetes. Resolveu a distância entre o paciente e o controle da própria saúde.

UX Design Acessibilidade Telemedicina Linguagem Simples Design System Saúde Digital