Medicloud
Arquitetura da informação · Healthcare · SaaS · 2025
5 min
Problema
Um mercado de soluções robustas
Entre os softwares voltados para o setor médico, existem soluções bastante robustas, de alto custo e repletas de funcionalidades. Para clínicas e consultórios menores e independentes, algumas destas soluções extrapolam suas necessidades operacionais e orçamentos. Em busca de um serviço mais objetivo, surgiu a Medicloud: produto voltado ao compartilhamento de laudos e exames médicos online.
A ideia da plataforma surgiu da dor vivida por um profissional da saúde a partir da sua própria prática clínica, que não encontrou no mercado um serviço que o atendesse de forma pontual e com custo mais baixo.
Recebi a missão de desenhar todo o sistema, desde a definição do conceito, passando pela estruturação da arquitetura de informação, do sistema de tokens e da biblioteca de componentes, amarrando isso em um design de interfaces e protótipo operacional. Por se tratar de um cliente sem uma marca ou outros produtos existentes, tive que começar o projeto do zero, apenas com as seguintes informações: necessidades técnicas do produto, motivo de sua criação e a atuação limitada a um cronograma apertado, priorizando usabilidade e clareza visual.
Requisitos mapeados em épicos e histórias de usuário.
Estrutura
Hierarquia de acessos construída em torno da privacidade
Diante dos dados apresentados pelo cliente, compreendi o sigilo médico como um ponto importante na definição da estrutura do produto, tratando-se inclusive de uma exigência legal para o nicho. Considerando este fato e os diferentes perfis potenciais de usuários, foram trabalhadas três diferentes visões: do(a) Médico(a), com controle administrativo total; do(a) Operador(a) (Recepção), que pode cadastrar pacientes e criar consultas, mas não tem permissão para visualizar os resultados de exames e laudos; e do(a) Paciente, que acessa apenas seus próprios arquivos através de um fluxo simplificado.
Arquitetura de informação definindo a estrutura de navegação do produto e os limites de acesso por entidade de usuário.
Consulta como pasta, não como evento na agenda
Outro ponto importante no desenho estrutural foi a compreensão da consulta como unidade de armazenamento de laudos e exames médicos, não tendo destaque como elemento para organização de agenda ou criação de lembretes. Em sua versão inicial, a MediCloud não se propunha a oferecer um calendário elaborado para acompanhamento e agendamento de consultas médicas, tratando assim a consulta principalmente como uma pasta e uma referencia para localização de arquivos através do sistema.
Menores elementos de decisão visual
Mapeadas as limitações e desenhada a estrutura base da plataforma, segui para as primeiras decisões visuais a partir de design tokens. Iniciei o projeto desta forma por acreditar que, dada a complexidade do sistema e o cronograma apertado, o trabalho com tokens e componentes bem estruturados desde o início me proporcionaria ganho de agilidade na construção, consistência sistêmica e com isso, melhor usabilidade.
Estruturei os tokens em duas camadas: primitiva (paleta bruta) e semântica (atribuições com significado funcional); de forma que ajustes fossem refletidos em todo o sistema e componentes instantaneamente. A linguagem visual se apoia em padrões comuns do mercado de saúde, priorizando a redução de carga cognitiva e a transmissão de confiança como valor primário da mensagem.
Apesar de decidir pela construção do sistema de tokens de forma antecipada, neste momento nem as nomenclaturas dos tokens, tampouco as paletas e escalas foram absolutamente definidas, estando tudo passível de testes e mudanças posteriores.
Tokens primitivos definindo a paleta bruta — a camada de fundação antes das atribuições semânticas.
Tokens semânticos mapeando valores primitivos para papéis funcionais em toda a interface.
Uma tipografia sóbria, digital e acessível
A tipografia é o elemento mais importante em um projeto, estando presente em todas as partes do sistema e guiando boa parte da hierarquia e ritmo das páginas. E a escolha da Work Sans não foi apenas estética. Em um ambiente clínico, onde a leitura de dados densos é constante, a legibilidade em diferentes tamanhos, pesos, devices e displays é uma exigência funcional. O tom sóbrio e profissional da família tipográfica também reforça os valores de confiança e precisão que o produto precisa transmitir.
Sistema tipográfico construído com Work Sans — escolhida pela legibilidade e pelo tom profissional adequado a ambientes clínicos.
Execução
Componentes que documentam decisões, não apenas padrões visuais
Mantendo a abordagem de construir os "blocos" antes de montar as interfaces finais, a criação dos componentes básicos foi o próximo passo. Foram aplicados aos componentes: estilos tipográficos e tokens de cor e espaçamentos estabelecidos; além de diretrizes visuais, como o uso de bastante espaço em branco para facilitar o consumo de conteúdo denso e a valorização da estética limpa para garantir maior destaque às ações chave da plataforma.
Conforme o projeto avançou, naturalmente surgiram novos componentes e adaptações em componentes existentes, no sistema de cores, na escala tipográfica e nas nomenclaturas.
Biblioteca de componentes construída para consistência e precisão no handoff — cada estado documentado e pronto para implementação.
Montando os "blocos"
Alguns rascunhos foram feitos em etapas anteriores para mapear necessidades que os tokens e componentes deveriam atender. Comecei a construir as telas aplicando os "blocos" às telas rascunhadas, para transformá-las em interfaces reais e a partir disso criar as outras telas e fluxos do sistema.
O sistema criado ajudou a construir as telas com maior velocidade, mantendo a coerência visual e funcional entre telas, enquanto sofria adaptações para atender da melhor forma a construção das interfaces.
Os fluxos desenhados primariamente foram os de gestão de exames e gestão de laudos, que carregavam o valor central do produto. O primeiro exigia um serviço de upload progressivo de imagens, PDFs e vídeos, além de adição de marca d'água, já o segundo fluxo, deveria exibir um formulário com vários campos e etapas, da forma mais agradável e clara possível.
Fluxo de criação de laudos para o mínimo de fricção — etapas progressivas, rotulagem clara e comportamento consistente entre breakpoints.
Fluxo de upload de imagens diagnósticas com aplicação automática de marca d'água — do estado vazio à confirmação do exame.
Edição de vídeo diagnóstico no navegador: recorte de trecho e aplicação de marca d'água sem dependência de software externo.
Diante do curto cronograma e do requisito de projetar para pelo menos 3 tamanhos de tela (celular, tablet e computador), decidi usar o card como principal elemento de interação e visualização, por oferecer facilidade de uso e reaproveitamento para diversos fins, além de boa adaptação para responsividade.
Diante do tempo limitado e necessidade de responsividade, optei por cards pela facilidade de adaptação entre dispositivos e possibilidade de reutilização em diversos contexto com facilidade.
Com o intuito de tornar melhor a experiência de completar o formulário, me atentei ao preenchimento automático inteligente de campos e ao uso dos inputs corretos para cada tipo de dado. Além disso, considerei no projeto a criação e uso de templates para agilizar a constituição de laudos e a facilitação da revisão, por se tratar de uma etapa crucial em formulários longos.
Demonstração do fluxo de criação de laudos, com pré-preenchimento de campos, prevenção de erros e revisão priorizada.
Detalhes das features de criação e consumo de templates para aceleração durante o preenchimento de laudos médicos.
Resultado
O que funcionou
O sistema entregue cobriu um escopo considerável de complexidade: múltiplos perfis de acesso com permissões distintas, fluxos de upload e edição de arquivos e comportamento consistente em diferentes dispositivos e tamanhos de tela, mesmo se tratando de uma primeira versão. A estrutura de componentes e a documentação de casos de uso sustentaram essa amplitude sem perda de coerência visual ou funcional, entregando o que foi solicitado pelo cliente dentro do prazo acordado.
O sistema de tokens em duas camadas demonstrou seu valor ao longo das iterações: ajustes foram propagados globalmente em minutos, reduzindo a necessidade de alterações locais. A documentação de componentes, tokens e especificações também contribuiu para uma implementação mais eficiente, reduzindo ambiguidades no handoff entre design e desenvolvimento.
O que eu faria diferente
Estruturar o sistema de tokens e a biblioteca de componentes desde o início garantiu consistência e velocidade. Em contrapartida, esse caminho restringiu o processo criativo antes que a identidade do produto estivesse madura. A linguagem visual foi consolidada cedo demais, limitando o espaço para experimentação e gerando uma interface mais conservadora.
Para uma próxima oportunidade, priorizaria deixar a direção visual amadurecer antes de formalizar o sistema. O sistema de design deve registrar o que o processo descobriu, não condicionar o que ele tem permissão para explorar.
