O produto é um ERP de gestão clínica voltado para médicos de múltiplas especialidades, cobrindo a jornada completa do atendimento: agendamento, prontuário e emissão de documentos legais como receitas e atestados. Opera em um ecossistema regulado onde a padronização de dados não é apenas uma boa prática: é um requisito para que o sistema possa emitir documentos com validade jurídica, incluindo a receita digital.

Com uma base instalada diversa, o produto precisava atender simultaneamente diferentes perfis de prescritor: desde clínicos gerais com alta rotatividade de consultas até especialistas com fluxos de prescrição mais complexos. Essa diversidade de uso carregava uma tensão estrutural que só se tornou visível quando começou a travar a evolução de uma feature crítica.

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.

Desde o início, sabíamos que parte da base não adotaria a nova mecânica. A variabilidade etária dos nossos usuários é alta, e isso se traduz diretamente em diferentes graus de familiaridade com interfaces digitais e com padrões de interação que produtos contemporâneos tomam como dados.

A decisão de avançar foi consciente: o movimento era necessário para preparar o sistema para ser progressivamente mais inteligente, abrindo caminho para a próxima geração de usuários. Mas aceitar o atrito sem gerenciá-lo não era uma opção.

A resposta foi um lançamento versionado. Com base em análise comportamental e de uso, a funcionalidade foi liberada gradualmente para subconjuntos de usuários de cada vez, dando ao time de treinamento tempo e dados reais para entender como abordar os perfis com menor aderência digital. O rollout não foi só uma decisão técnica: foi uma estratégia coordenada entre produto, design e capacitação.

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.

A descoberta mais relevante não veio dos dados: não tínhamos como cruzar perfis de pacientes, e as restrições da LGPD impediam qualquer rastreamento direto. Ela veio de um dia observando pessoas chegando ao balcão de uma farmácia para dispensar receitas. Ali ficaram visíveis problemas que o sistema não conseguia enxergar: receitas sem carimbo do profissional, informações divergentes entre a prescrição e o papel, casos de falsificação de assinatura. E um problema de conveniência que ninguém havia mapeado: muitos pacientes precisavam visitar múltiplas farmácias para dispensar os medicamentos de uma única receita.

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.

Estávamos desenhando para uma persona que nunca havia existido formalmente nos nossos processos: o paciente. Não o médico nem o administrador da clínica, mas o cliente do nosso cliente. Sem histórico de pesquisa com esse perfil e com restrições reais de LGPD para cruzamento de dados, a única forma viável de entender o problema foi ir ao campo.

O projeto começou em 2020, em plena pandemia, um contexto que tornava qualquer dependência de papel ainda mais crítica. O que viabilizou a solução foi a Lei 14.064/2020, que permitiu profissionais de saúde assinarem documentos digitalmente. Foi um aprendizado sobre o papel do contexto regulatório no design: nem sempre é um obstáculo. Às vezes é o que torna possível o que antes não era.

Trabalhar sem dados de perfil nos forçou a depender inteiramente de observação direta. Isso foi uma limitação, mas também foi o que produziu os insights mais acionáveis: os problemas de falsificação e divergência de informação nunca teriam aparecido num questionário. Foram descobertos pelo simples ato de estar presente onde o problema acontecia.

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.