Um ERP de gestão clínica com base instalada de médicos de múltiplas especialidades. O produto opera em um ecossistema regulado, onde a padronização de dados é condição para a emissão de documentos legais — incluindo a receita digital. [Placeholder: adicione o contexto completo da empresa e do cenário aqui.]

No nosso ERP, a base de usuários estava fracionada: enquanto 64% utilizavam a base estruturada, 36% prescreviam exclusivamente em texto livre. O impacto dessa quebra de padronização era profundo: a ausência de dados estruturados em mais de um terço dos atendimentos inviabilizava nossa engine de recomendação baseada em CID e travava a emissão da receita digital, quebrando a jornada do paciente.

Ao investigar a fundo, descobrimos que o problema não era a interface, mas a confiança. Parte dos médicos desconfiava das sugestões do sistema, fazendo o texto livre parecer a opção mais segura e sob controle.

O desafio não era apenas "consertar" o fluxo dos 36%, mas fazer isso sem gerar atrito para os 64% que já usavam o modelo estruturado. Desenhamos um componente único e híbrido que abraça ambos os comportamentos. O profissional começa a digitar livremente e recebe sugestões contextuais em tempo real (baseadas em CID, histórico e especialidade).

O resultado é uma interface fluida: quem prefere a digitação livre ganha o respaldo seguro do sistema com apenas um clique, e quem já buscava dados estruturados ganha um fluxo de busca infinitamente mais rápido.

A validação com os 16 usuários provou o sucesso dessa unificação. Sem forçar uma mudança brusca de comportamento, o modelo híbrido eliminou a fricção cognitiva dos dois perfis de médicos. Conseguimos destravar o fluxo de emissão da receita digital e garantir a integridade dos dados, transformando esse componente no novo padrão de prescrição do produto e otimizando o handoff com a engenharia.

Resolver a fricção da prescrição clínica foi apenas a primeira etapa. O ecossistema de saúde ainda esbarrava em um gargalo crítico na ponta final: a dependência do papel. O trânsito de receitas físicas limitava a liberdade do paciente, dificultava a auditoria das farmácias e abria brechas graves de segurança para fraudes e exposição de dados sensíveis de saúde.

A jornada estava fragmentada e ineficiente para todos os atores envolvidos. Médicos geravam prescrições digitais no sistema, mas o fluxo quebrava na saída: o papel voltava como intermediário obrigatório entre o consultório e a farmácia.

Esse modelo criava três problemas críticos: limitava a liberdade do paciente a redes credenciadas específicas, dificultava a rastreabilidade e auditoria pelas farmácias, e abria brechas sérias de segurança — receitas podiam ser adulteradas, perdidas ou expostas, comprometendo dados sensíveis de saúde.

Projetamos um fluxo descentralizado e seguro. Assim que a prescrição estruturada é gerada pelo médico, o paciente recebe um acesso criptografado e rastreável diretamente via WhatsApp — canal que já faz parte da rotina de todos os perfis de usuário.

O grande trunfo técnico da solução é a interoperabilidade: o sistema não prende o usuário a uma rede específica. O paciente tem total autonomia e conveniência para dispensar sua medicação na farmácia de sua preferência, usando apenas o dispositivo móvel.

A digitalização integral do fluxo eliminou a necessidade de impressão, reduzindo drasticamente custos operacionais e o impacto ambiental da operação. Para os pacientes, entregamos uma experiência de saúde sem atrito e de alta conveniência. Para o negócio, construímos uma arquitetura de tráfego de dados de saúde robusta, auditável e alinhada com as melhores práticas globais de segurança e privacidade.

O DOCA é o design system central da Amigo Tech, construído para suportar um ecossistema B2B de produtos integrados. Ele abrange plataformas de gestão financeira (ERP) e CRM corporativo que convivem com uma alta densidade de regras de negócio — um ambiente onde consistência não é apenas estética, mas condição para que os times consigam escalar com previsibilidade.

A principal dor que o DOCA buscou resolver foi o "design por exceção" descontrolado e a inconsistência generalizada na interface. Sem uma fonte única de verdade, os times de engenharia recorriam a valores primitivos arbitrários hardcoded diretamente nas aplicações.

O resultado era uma lacuna crescente entre o que o design especificava e o que o código entregava — sem uma ponte confiável entre os dois lados. Faltava disciplina estrutural que impedisse as exceções de se tornarem a regra.

A meta principal era garantir consistência visual e semântica em múltiplas verticais de produto através de uma governança sólida de atomic design e design tokens. Em paralelo, o projeto visava estruturar as operações de DesignOps para reduzir drasticamente o atrito no handoff técnico entre as squads de produto e a engenharia.

Estruturei o fluxo de evolução do sistema em seis etapas macro: Submissão → Design → Handoff → Desenvolvimento → Documentação → Publicação. Cada etapa possui critérios de entrada e saída definidos, garantindo que nenhuma mudança avance sem validação.

Para organizar a entrada de demandas, implementei uma Árvore de Decisão técnica que guia a criação de novos componentes, estabelecendo um processo de triagem onde cada nova necessidade passa por um checklist rigoroso antes de ser incorporada ao sistema — evitando que padrões de produto único contaminem a biblioteca compartilhada.

O sistema adota uma estrutura em duas camadas. Os primitivos atuam como base estrutural para a discriminação semântica — idealmente opacos para consumo direto, priorizando amplitude estrutural e organização lógica. Os semânticos traduzem decisões de design em tokens funcionais: se o estado de hover de um elemento interativo exige uma cor específica, há razão estrutural para um token semântico dedicado àquele propósito exato.

Essa separação viabiliza temas como dark mode apenas remapeando os tokens semânticos para novos primitivos, sem alterar os componentes estruturalmente. Também facilita o gerenciamento global de contraste e acessibilidade — incluindo tokens específicos para sobreposições (overlays) configurados para garantir contraste seguro em múltiplos cenários.

A convenção de nomenclatura segue a estrutura: category / property / intention / semantic / prominence / state

Category define a tipologia fundamental (color, font, spacing). Property especifica a propriedade de aplicação (background, content, border). Intention define o propósito macro (interactive, display). Semantic agrupa variações visuais (accent, info, danger). Prominence estabelece hierarquia (subtle, strong, sm). State mapeia estados interativos diretos (hover, pressed).

Alguns tokens omitem naturalmente determinados níveis quando não são necessários. A premissa é separar claramente elementos de ação de elementos estáticos e decorativos — garantindo discriminação precisa do propósito e encontrabilidade eficiente tanto no Figma quanto nas IDEs de desenvolvimento.

Do ponto de vista arquitetural, padronizei as propriedades dos componentes em cinco grupos lógicos: Semantic, Hierarchy, Style, State e Boolean. Isso garantiu que o modelo de design fosse 100% espelhado com a estrutura esperada pela tecnologia.

A regra fundamental: componentes consomem exclusivamente tokens semânticos — nunca primitivos. Essa restrição funciona como o ponto de articulação entre o "que" o elemento é e o "como" ele se parece. Ela encapsula as decisões, previne o design por exceção e impede a utilização de espaçamentos ou valores arbitrários pela engenharia.

Para manter o sincronismo entre design e código, automatizei a exportação das variáveis do Figma para JSON via plugin Tokens Export by Bololō. O ecossistema conta com uma Biblioteca de Referência Foundations no Figma como fonte central de verdade.

O processo também identificou oportunidades de refinamento: há uma recomendação ativa de reavaliação da paleta primitiva de cor, com foco em acessibilidade — especificamente nas quebras indesejadas de luminosidade entre os steps 100 e 200 e nos desvios de matiz na escala de cinzas.

O resultado mais concreto foi uma otimização real no fluxo Figma-to-code, que efetivamente reduziu o atrito no handoff técnico e acelerou o ciclo de entrega das squads multidisciplinares. A ausência de valores hardcoded nas aplicações começou a se tornar uma realidade estrutural — e não apenas uma recomendação.