Problema
Um mercado de soluções que resolvem demais — ou de menos.
Clínicas de diagnóstico independentes se veem diante de uma escolha limitada: aderir a plataformas all-in-one robustas, caras e repletas de funcionalidades que extrapolam suas necessidades operacionais, ou recorrer a alternativas manuais e pouco seguras. Não havia uma solução focada na tarefa que realmente estrutura o dia a dia dessas clínicas: armazenar e entregar laudos médicos com segurança e rastreabilidade.
Requisitos mapeados em épicos e histórias de usuário.
Contexto
Uma oportunidade identificada na prática clínica.
O MediCloud nasceu de uma oportunidade identificada por um médico a partir da sua própria prática clínica. Meu papel foi projetar o produto de ponta a ponta — da arquitetura de informação e sistema de tokens à biblioteca de componentes e protótipo operacional — dentro de um prazo enxuto.
Decisões de design
Hierarquia de acessos construída em torno da privacidade.
O sigilo médico não é uma funcionalidade — é uma exigência ética e legal. Estruturei o produto em torno de três entidades: o Médico, com controle administrativo total; o Operador (Recepção), que pode cadastrar pacientes mas é sistematicamente impedido de visualizar o conteúdo dos exames; e o Paciente, que acessa apenas seus próprios documentos através de um fluxo autenticado por PIN.
Arquitetura de informação definindo a estrutura de navegação do produto e os limites de acesso por entidade de usuário.
"Consulta" como unidade organizacional, não como evento de agenda.
Em softwares convencionais, uma consulta é tratada como um evento de agenda. No MediCloud, redefini esse conceito como a unidade lógica que conecta um paciente, um momento no tempo e seus documentos. Essa decisão eliminou a necessidade de um prontuário eletrônico completo, mantendo a rastreabilidade precisa das informações sem ampliar o escopo do produto.
Um sistema de tokens construído para escalar.
Estruturei os tokens em duas camadas — primitiva (paleta bruta e escalas) e semântica (atribuições com significado funcional, como bg-color-static-primary) — de modo que alterações de identidade visual possam ser aplicadas globalmente em minutos. A linguagem visual se apoia em padrões consolidados do mercado de saúde, priorizando a redução de carga cognitiva e a transmissão de confiança como valores primários da interface.
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 que comunica antes de ser lida.
A escolha da Work Sans como typeface do produto não foi apenas estética. Em um ambiente clínico onde a leitura de dados densos é constante, a legibilidade em diferentes tamanhos e pesos é 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.
Desenvolvi uma biblioteca de componentes modular garantindo consistência na interface e maior precisão no handoff para desenvolvimento. O espaço em branco é aplicado de forma deliberada em toda a interface — em um contexto onde profissionais de saúde lidam com dados diagnósticos densos, o respiro visual cumpre uma função cognitiva, não apenas estética.
Biblioteca de componentes construída para consistência e precisão no handoff — cada estado documentado e pronto para implementação.
Os fluxos que definem o valor do produto.
Dois fluxos concentram o valor central do produto. O fluxo de gestão de exames suporta upload progressivo de PDFs, imagens e vídeos, com etapas reduzidas e estados de erro bem definidos. As ferramentas de edição em nuvem — aplicação automática de marca d'água e corte de vídeo no navegador — eliminam a dependência de softwares externos no fluxo de trabalho da clínica.
Fluxo de upload de exames projetado para o mínimo de fricção — etapas progressivas, rotulagem clara e comportamento consistente entre breakpoints.
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.
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.
Fluxo de criação de laudo em múltiplas etapas — da coleta de informações básicas à revisão e publicação do documento.
Resultado
O que funcionou.
Para uma primeira versão, 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, autenticação em duas etapas e comportamento consistente em diferentes dispositivos e tamanhos de tela. 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 escopo e prazo acordados.
O sistema de tokens em duas camadas demonstrou seu valor ao longo das iterações: ajustes de identidade visual foram propagados globalmente em minutos, dispensando atualizações manuais componente a componente. 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 pareceu a decisão mais adequada para garantir consistência — mas, na prática, esse caminho restringiu o processo criativo antes que a identidade do produto estivesse suficientemente explorada. A linguagem visual foi consolidada cedo demais, o que limitou o espaço para experimentação e pode ter resultado em uma interface mais conservadora do que o projeto permitia.
Na próxima oportunidade, priorizaria deixar a direção visual amadurecer antes de formalizar o sistema. O design system deve registrar o que o processo de design descobriu, não condicionar o que ele tem permissão de explorar.
