HealthTech
Sistemas para saúde com dados sensíveis, rastreabilidade e regulação: gestão da qualidade farmacêutica, prontuário longitudinal e envio seguro de documentos clínicos.
Sou Adrielly Nascimento, desenvolvedora full stack com 4 anos de experiência em produtos digitais para saúde e educação. Atuo de ponta a ponta, da pesquisa com usuários e análise de produto à arquitetura, interface, API e dados, com React, TypeScript, Node.js, Python e Java, e integro IA generativa (LLMs e agentes) a sistemas clínicos e educacionais.

Como eu trabalho
Transformo regras complexas de saúde e educação em interfaces claras, acessíveis e prontas para implementação — do entendimento do problema à interface, à API e aos dados.
Áreas de atuação
Sistemas para saúde com dados sensíveis, rastreabilidade e regulação: gestão da qualidade farmacêutica, prontuário longitudinal e envio seguro de documentos clínicos.
Plataformas acadêmicas com muitos perfis e regras: monitoramento contra a evasão escolar, acompanhamento de alunos entre escola, família e apoio e um filme interativo de segurança digital para alunos de 12 a 14 anos.
Formação em saúde com tecnologia: simulação clínica com pacientes virtuais por IA (SIMARIS) e supervisão e cursos para psicólogos em formação (SOMOS Psicologia).
Projetos selecionados




Filme interativo vertical para alunos de 12 a 14 anos, usado depois da aula do e-book PROTEGER do Instituto Gabriel Gastal. O aluno decide pela Bia com tempo, vive a consequência e, no Mural, vê o que cada escolha revelou — sem gabarito, sem cadastro e sem backend.


Sistema de Garantia da Qualidade farmacêutica (eQMS) para o LAFEPE. O objetivo foi reunir em um só lugar documentos, revisões, treinamentos e processos da Qualidade que antes viviam espalhados em arquivos, planilhas e e-mails — com rastreabilidade em cada decisão.

Sistema de educação personalizada, prototipado para apresentação ao Liberty Group, que transforma as evidências e os objetivos de cada aluno em um plano de estudos próprio, acompanhado pela escola e por uma equipe de apoio e reajustado conforme a evolução.


Plataforma de simulação clínica por IA conversacional para a formação em saúde no SUS, pensada para ser fácil de usar por pessoas com baixo letramento digital. Estudantes conversam com pacientes virtuais, registram o atendimento e recebem feedback por competências — e o preceptor acompanha as lacunas da turma.


SaaS de psicologia que reúne atendimento, prontuário, supervisão clínica e formação contínua para psicólogos, pacientes, estudantes e supervisores.


SIMA é uma plataforma de educação para acompanhar estudantes e prevenir a evasão escolar. Ela reúne frequência, notas e engajamento em um só lugar e mostra, com regras explicáveis, quais alunos precisam de atenção — antes que seja tarde.


Plataforma com cara de chat para o envio seguro de documentos clínicos — laudos, guias e contratos — que substitui o WhatsApp e o e-mail por um fluxo rastreável, auditável e alinhado à LGPD.


Plataforma de saúde integral em que a história de saúde acompanha a pessoa: prontuário longitudinal, consentimento por seção e espaços para pessoas, profissionais e instituições.

Interfaces para treinar agentes de IA em simulações e operar o atendimento de uma clínica em dois modos: copiloto, em que a pessoa aprova cada resposta, e autopiloto, em que um agente orquestrador faz a triagem e passa a conversa a um especialista, com o raciocínio do agente visível para a equipe.


Plataforma para redes de farmácias hospitalares: estoque por lote e validade, previsão de demanda com incerteza, pareamento entre excesso e necessidade e transferências auditáveis entre hospitais. Pesquisa, mapeamento e design das telas em 2023.

Protótipo para apresentação de um sistema para redes de farmácias: vendas no balcão, estoque com reposição, cadastro de medicações controladas e os relatórios exigidos pela Anvisa. Um dos meus primeiros projetos na saúde, em que fiz o design de produto.
Stack
Experiência
Saúde + Educação
produtos Rede SOMOS e SOMOS Psicologia HealthTech
Instituto Gabriel Gastal (IGG) · protótipo para apresentação EdTech
PapéisDesigner de ProdutoGame DesignerDesenvolvedora Full Stack
gestão da qualidade (eQMS) · protótipo para apresentação ao LAFEPE HealthTech
PapéisDesigner de Produto
Liberty Group · protótipo para apresentação EdTech
PapéisDesigner de ProdutoDesenvolvedora Front-end
prevenção da evasão escolar · produto próprio EdTech
PapéisDesigner de ProdutoDesenvolvedora Full Stack
projeto de extensão da UFPE HealthTech
PapéisCofundadora e CDOCoordenadora de Design de ProdutoDesenvolvedora Front-end
agentes de IA para clínicas · produto próprio HealthTech
PapéisDesigner de Produto
farmácia hospitalar em rede · produto próprio HealthTech
PapéisDesigner de Produto
gestão para redes de farmácias · protótipo para apresentação HealthTech
PapéisDesigner de Produto
Formação
Universidade Federal de Pernambuco · 2023 — 2028
Idiomas
Certificações

Filme interativo · EdTech



O PROTEGER forma educadores para a segurança digital de crianças e adolescentes, mas saber o que fazer não garante decidir bem na hora. A SEQUÊNCIA leva a metodologia para a prática do aluno: cada episódio é uma letra do P.R.O.T.E.G.E.R., numa semana da vida da Bia, e a escolha gera consequência, não nota. O Episódio 1 (Perceber) está completo; o Episódio 2 (Refletir) está em produção.


Protótipo desenvolvido para apresentação ao Instituto Gabriel Gastal (IGG). Personagens, escola, app e perfis são fictícios; imagens e vozes foram geradas com IA sob direção de arte. Episódio 1 completo; Episódio 2 em produção.
Como transformar uma metodologia pedagógica em um filme interativo que ensine antes de testar, meça percepção sem transformar a escolha do aluno em nota e rode no celular da escola sem coletar dados pessoais?
Todo episódio segue o ciclo Sonda → Modelo → Ferramenta → Ensaio → Prova → Eco → Mural. O story:check percorre os caminhos do grafo e reprova qualquer evidência medida sem andaime que não tenha modelo, ferramenta e ensaio do mesmo conceito antes dela, em todos os caminhos.
Estado da história e modelo do aprendiz são separados: a opção escolhida só move a história; a avaliação lê apenas o que foi percebido — Lente antes de decidir, rastros tocados e editados, andaime ativo. Uma regra estática impede a avaliação de ler a opção escolhida em nós de prova e eco.
Roda no navegador, sem backend, login, nome ou data de nascimento: o progresso fica no IndexedDB do aparelho, e a mascote do app fictício mostra ao aluno o que o próprio filme registrou, com opção de apagar. Há modo sem pressa, legendas P/M/G, menos movimento, descrição de imagens e modo turma.



Palco vertical de 1080 × 1920 unidades (1u = largura ÷ 1080): textos, rastros e áreas de toque são posicionados em u e escalam com a tela. Escolhas, celular e Lente ficam fora do Player, como HTML real — foco, teclado e leitor de tela —, e só transform e opacity são animados.



O cold open começa no sábado, 23:47, e volta cinco dias. Antes de qualquer ensino, a sonda — as permissões do app fictício, com “Aceitar tudo e brilhar” em destaque — registra a linha de base: nunca vira nível, só aparece no “antes e depois” do Mural e deixa um rastro que pode ser corrigido mais tarde.



A professora mostra a foto dela aos 13 anos, com o carimbo de data da câmera; o Theo, a live com a localização que o app colocou sozinho. A Lente desacelera o Player para 0,35x — timer, áudio e mensagens no mesmo relógio escalado — e dessatura a cena por camadas, sem filter em tempo real. Com andaime, o rastro tocado ganha etiqueta; na prova, só um giz neutro.



O guia GG anuncia o treino e o jogador monta o perfil da Bia com chips. A Ficha do Estranho se preenche ao vivo e separa identificadores (escola, bairro, aniversário) de interesses (desenho, fotografia), com a origem de cada fato. Desfazer é livre e nada do ensaio vira ponto fraco.



Situação nova, pressão do grupo e nenhuma dica. A foto é composta em código — cenário, sprites e placas —, então recortar, borrar, figurinha, legenda, localização e plateia são edições de props. O editor não sugere nada: o que não for editado continua na foto. A evidência é o que foi percebido, nunca a opção escolhida.



A mãe posta uma foto da Bia: o jogador inspeciona o post de um adulto, e cada rastro tocado vira uma fala explicando o efeito combinado. Em todos os caminhos, quem fecha o post é um adulto. Depois vêm a revisão das configurações com a mãe e o perfil do desconhecido, um avatar comum cuja estranheza só aparece nos dados que a Lente revela.



Cinco finais saem do estado acumulado, nunca de uma escolha isolada, e o final vira cartão para compartilhar. O Mural reconstrói o que um estranho sabia e de onde cada fato vazou, compara antes e depois e distribui a responsabilidade entre pessoas, plataforma e adultos — sem ✓/✗, porcentagem ou vermelho/verde.






Episódios liberados em sequência, ajustes de acessibilidade — sem pressa, legendas P/M/G e lentas, menos movimento, descrever imagens e modo turma — e um cartão de cuidado com canais de ajuda antes do final, acessível também pelo botão Ajuda em qualquer ponto.

Web App · Gestão da Qualidade


O LAFEPE (Laboratório Farmacêutico do Estado de Pernambuco) precisava de um sistema de gestão da qualidade que tornasse auditável todo o ciclo de vida de um documento — da elaboração à vigência — e que interligasse treinamentos, desvios, CAPAs, mudanças e riscos.

Deslize para ver a tela inteira →

Protótipo conceitual desenvolvido para apresentação ao LAFEPE; dados fictícios.
Como modelar processos regulados de Garantia da Qualidade — documentos, treinamentos, desvios e CAPAs — em fluxos em que cada perfil veja apenas a próxima ação que lhe cabe, sem perder a rastreabilidade exigida em auditoria?
A aprovação de um documento abre a convocação de treinamento; um desvio pode originar uma CAPA; uma mudança exige avaliação de risco. Essas dependências ficam visíveis no próprio registro, não em telas isoladas.
O assistente gera propostas de texto e revisão em uma prévia separada do rascunho. Nada é gravado sem a ação “Aplicar ao rascunho”, e cada evento entra na trilha de auditoria com hash SHA-256 encadeado ao anterior.
A regra “quem elabora não aprova” é aplicada pelas permissões de perfil, inclusive para gestores. A ação bloqueada continua visível, com o motivo da restrição, em vez de simplesmente desaparecer.

Cabeçalho branco de 90px e menu azul de 60px. Layout validado em QA visual nos três tamanhos.


Lucide · traço 2px
Limpeza de equipamentos
Revisão 03Registro de desvios
Revisão 02| Documento | Responsável | Situação | Prazo |
|---|---|---|---|
| LFP-IT-006 Conferência de materiais | OP OP-001 | Aguardando treinamento | 26/10/2026 |
| LFP-POP-018 Boas práticas de fabricação | GQ GQ-001 | Em aprovação | 28/10/2026 |
| LFP-POP-003 Controle de documentos | GQ GQ-002 | Vigente | 12/01/2027 |

O gestor da qualidade vê os documentos organizados por etapa (em revisão, em aprovação e aguardando treinamento). Ao selecionar um card, o inspetor à direita mostra prazo, área e em que ponto do fluxo o documento está.

Editor em página, no estilo de um processador de texto, com faixa de ferramentas fixa. A assistência de IA abre ao lado: a proposta aparece em prévia e só entra no documento com "Aplicar ao rascunho".


Quando um documento é aprovado, o sistema convoca os colaboradores por função. A tela acompanha leitura, avaliação, aptidão e certificados de cada pessoa.

Desvios geram CAPAs, e mudanças exigem avaliação de risco. As listas mostram etapa, criticidade e responsável, e cada ação fica registrada na trilha de auditoria.


Quem elabora um documento não pode aprová-lo. Quando alguém tenta, o sistema recusa a ação e explica o motivo, em vez de simplesmente esconder o botão.
Web App · EdTech


Cada aluno chega com um ponto de partida e um objetivo diferentes, mas o acompanhamento escolar costuma seguir o mesmo roteiro para todos. A Trilha é um sistema de educação personalizada: reúne as evidências do aluno (notas, frequência, tarefas e observações) e o objetivo declarado por ele para montar um plano de estudos individual, com metas observáveis, rotina, encontros e um responsável humano. O plano é medido e reajustado a cada semana, tanto para superar uma dificuldade quanto para conquistar um objetivo. A IA prepara o contexto, a equipe decide e cada envio compartilha só os dados necessários.

Deslize para ver a tela inteira →

Protótipo criado para apresentação ao Liberty Group. Todos os dados exibidos são fictícios.
Como oferecer educação personalizada de verdade: transformar o histórico, as dificuldades e os objetivos de cada aluno em um plano de estudos próprio, acompanhado por pessoas e reajustado conforme a evolução?
O plano parte do diagnóstico pedagógico e do objetivo do aluno e se desdobra em metas observáveis, rotina semanal, listas graduadas, encontros e um responsável humano. Produtividade, aprendizagem e carga percebida são medidas toda semana para reajustar o plano.
O plano pode nascer de uma necessidade identificada nos dados (superar uma dificuldade) ou de um objetivo declarado pelo aluno, como um curso ou vestibular. Os dois caminhos usam a mesma jornada 360º e reúnem organizadora, professores e especialistas.
O Copiloto organiza as evidências e sugere ajustes ao plano citando as fontes; a equipe revisa, edita e decide. Sinais não viram diagnóstico nem rótulo, e cada envio compartilha só os dados necessários, com trilha de auditoria.

Sidebar de 248px, conteúdo de 640 a 1280px, gap de 24px e espaçamento em escala 4/8/12/16/24/32px. Alvos interativos de no mínimo 44px.



O sistema usa conteúdo fluido, limites previsíveis e redução progressiva de colunas. Nenhuma ação persistente pode desaparecer por causa do viewport.
As mudanças acontecem pela necessidade do conteúdo, não por modelos específicos de dispositivo.
≥ 1120 px≥ 880 px≤ 620 pxGrids colapsam de quatro para duas e depois uma coluna, preservando leitura e ordem do DOM.
content-sm640 px · leituracontent-md880 px · formulárioscontent-lg1120 px · produtogrid-gap24 pxA escala impede conflitos entre conteúdo, navegação persistente, menus, overlays e mensagens.
20Dropdown 40Overlay 60Toast 80Controles visuais podem ser compactos; a área interativa mínima continua sendo 44 × 44 px em ações isoladas.
control-sm34 pxcontrol-md42 pxcontrol-lg50 pxtarget-min44 pxOpacidade é reservada a elementos indisponíveis e scrims; texto secundário usa cor própria.
disabled44%muted68%scrim56%A operação usa tema claro com superfícies de marca escuras. Um modo escuro global não faz parte da versão 2.1 e não deve ser inferido automaticamente.
| Faixa | Estrutura | Navegação | Densidade |
|---|---|---|---|
| Wide · ≥ 1120 px | Até 4 colunas e sidebar fixa | Completa e persistente | Padrão |
| Medium · 880–1119 px | Até 2 colunas | Compacta, sem perder rótulos essenciais | Confortável |
| Compact · ≤ 879 px | Uma coluna e ordem linear | Menu acessível por botão | Alvos mínimos de 44 px |
Material Symbols Rounded
Regra de uso. O asterisco radial é decorativo e institucional. Nunca substitui texto, estado, seta ou confirmação.
Somente os grupos marcados entram na prévia.
Uma pessoa confirma a leitura antes do envio.
A nota privada permanece no espaço profissional.
2 acadêmicos · 1 de rotina
7 em dia · 1 pede revisão
9 presenciais · 5 on-line
2 para hoje · 3 acompanhamentos
Uma direção construída com a voz da estudante, metas revisáveis e uma rotina que respeita seus limites.
Preserva a estrutura para evitar saltos de layout.
Explica o filtro aplicado e oferece um jeito de ampliar a busca.
Confirma o que aconteceu, quem terá acesso e o próximo passo.
Mantém os dados preenchidos e permite tentar novamente.
Mostra o que está salvo no aparelho e o que aguarda sincronização.
Mostra autoria, horário e diferenças antes de substituir o conteúdo.
A interface mostra fatos, fontes, janela e limite antes de oferecer qualquer decisão.
A coordenação pode confirmar, editar ou descartar a leitura.
Resumo preparado para a tutora do Apoio Parceiro, com acesso pelo período definido.
Lívia mantém frequência estável, mas apresentou um padrão recente e concentrado em Álgebra. A recomendação é um rascunho, não uma decisão.
Professor · Escola Parceira · visível para a coordenação
Decisão humana · justificativa registrada
Resumo compartilhável · escola, estudante e família
Botões e campos usam 10px; cards, 18px; pílulas, 999px. Alvo mínimo de toque: 44px.

A coordenação começa o dia com sinais para revisar, planos ativos, monitorias e ações das próximas 24 horas. Um painel mostra o caminho da informação: da rotina da Escola à devolutiva do Apoio Parceiro.

Um sinal é um convite à revisão, não um diagnóstico. Cada um mostra fatos, fonte, janela, confiança, a regra que o gerou e o limite do que afirma. A coordenação confirma, edita ou descarta, e a Jornada 360º registra tudo com autoria, origem e visibilidade.


Não existe “compartilhar tudo”. A escola define finalidade, destinatário, prazo de acesso e grupos de dados, revisa a prévia exata do resumo e confirma a revisão humana antes de enviar. O Apoio recebe só esse contexto e monta, com uma profissional responsável, um plano de seis semanas.


O segundo fluxo começa por uma ambição, não por um alerta. O objetivo pertence à aluna e é tratado como direção revisável, nunca como promessa de aprovação. O time do Apoio transforma Medicina em uma rota de 18 meses, ciclos de 12 semanas e semanas com até cinco atividades.


A anotação privada da profissional fica separada do resumo compartilhável, e a devolutiva só é publicada para os públicos escolhidos. A Evolução compara linha de base, estado atual e objetivo, com uma visão própria para a família.


Web App · HealthTech · IA



A formação clínica depende do acaso: dos casos que aparecem no plantão. O SIMARIS cria pacientes virtuais a partir de casos compostos e permite que o aprendiz pratique com segurança — em português e no contexto do SUS. A interface foi desenhada para pessoas com baixo letramento digital: linguagem simples, poucos passos por tela, botões grandes e a opção de perguntar por voz.

Deslize para ver a tela inteira →
Como calibrar objetivos pedagógicos, realismo clínico e limites de comportamento da IA em um simulador de atendimento que gere evidência avaliável para o preceptor, sem substituir a sua mediação?
O paciente virtual responde apenas com dados previstos no roteiro do caso: não sugere diagnóstico nem conduta, não inventa resultados de exame e sinaliza perguntas fora do escopo. Os casos são compostos e fictícios.
Cada caso é publicado com uma rubrica definida pelo preceptor ou pela curadoria, com pesos por competência — acolhimento, investigação de risco, orientação e registro SOAP. O feedback sai por competência, não como nota única.
O painel da turma agrega lacunas individuais e coletivas por competência, para que o tempo presencial do preceptor seja usado na discussão dos casos, e não na triagem de dúvidas básicas.

Sidebar de 252px com gradiente navy, que vira 220px no tablet e um menu no celular.




Ícones lineares em SVG
Refere cefaleia occipital desde ontem, progressiva, com tontura leve e visão embaçada ao levantar. Nega dor torácica e déficit de força.
Consciente e orientada. PA informada no acolhimento: 160/100 mmHg
Pressão arterial elevada com cefaleia e interrupção recente do anti-hipertensivo.
Cite os sinais de alarme investigadosDescreva quem será acionado, com qual prioridade e justificativa.
Comunicação acolhedora e registro coerente. Torne o encaminhamento mais explícito.
Validou a queixa e fez perguntas claras sem induzir respostas.
Confirme a duração da alteração visual mais cedo.
Registre quem será acionado e com qual prioridade.
Acolhimento, risco e registro SOAP.
68%Reconhecimento de sinais de alerta e priorização.
0%Conferência do cartão e qualidade do registro.
100%| Estudante | Caso | Nota | Situação |
|---|---|---|---|
AB Ana BeatrizEnfermagem · 6º período | Hipertensão com sinais de alerta | 8,7 | Concluído |
RL Rafael LimaEnfermagem · 6º período | Pré-natal com cefaleia e edema | 6,4 | Revisão pendente |
JS Joana SouzaACS · turma B | Visita domiciliar e vulnerabilidade | 4,8 | Em andamento |

A atividade recomendada vem da maior lacuna do aluno. O painel mostra progresso da trilha, última nota e o mapa de competências.

O aprendiz conversa com a paciente virtual, com etapas sempre visíveis. Ao encerrar, registra o atendimento no prontuário SOAP, inspirado no e-SUS APS.


A nota vem desdobrada em acolhimento, investigação de risco, conduta, registro e autonomia, com destaque e ponto de atenção.

O preceptor vê as lacunas da turma, os alunos prioritários e publica casos de reforço pela curadoria.


SaaS · HealthTech + Educação



Psicólogos dividem o dia entre agenda, prontuários, supervisão e estudo, em ferramentas separadas. A plataforma junta essas rotinas num só lugar, com um tom acolhedor que respeita quem cuida e quem é cuidado.

Deslize para ver a tela inteira →


Projeto da SOMOS Healthtech. Dados fictícios.
Como devolver ao psicólogo o tempo que hoje vai para a burocracia, reunindo atendimento, prontuário, formação e supervisão num só lugar, com paciente e estudante na mesma jornada?
Cada perfil começa pela agenda e pelas pendências do dia; a lista de módulos fica como navegação secundária.
O rascunho fica salvo até a finalização, que bloqueia a versão. Uma correção vira complemento com motivo, e o histórico continua completo e auditável.
Estudantes e supervisores compartilham casos, ciclos e materiais no mesmo produto, com acesso definido por perfil.

Títulos em serifa (Fraunces) e textos em PT Sans, cards com raio de 20px e paleta natural de musgo, sálvia e terracota.




Atendimentos e registros
Histórico dos atendimentos e dos registros de evolução do paciente.
Rascunhos não fazem parte do prontuário até a finalização.
A pontuação apoia oportunidades profissionais, mas não substitui a avaliação clínica.
Atualizado · 31/05Psicólogos em início de carreira · Encontro 4 de 8
Supervisão educacional · Discussão de casos
Módulo 6 de 10 · Reestruturação cognitiva
Antes de seguir, registre um sinal breve sobre você.
Faltam 8 pontos para alcançar o nível Sênior 2.
Checklist diário
2 de 5 concluídos.
Sessões documentadas e prontuário ao vivo.
Ver agendaRegistros por paciente, histórico de evoluções e modelos de prontuário em um só lugar.
Abrir prontuáriosTrilhas, casos clínicos e certificados.
Continuar estudandoNível profissional e evolução da sua presença clínica.
Ver carreiraRepasses, planos, split e pagamentos organizados.
Ver financeiroConsulte os dados do dia, encontre materiais da sua biblioteca e acesse seus atalhos.
Bem-vindo de volta
Fraunces · T1 · 42 / 500Prontuários
Fraunces · T3 · 22 / 600Histórico e registros
PT Sans · Corpo · 16 / 400Formação continuada
Source Code Pro · Rótulo · 13 / 700
O dia começa com atendimentos, ocupação da agenda, cursos em andamento e atalhos para cada área da prática.

A agenda reúne sessões, supervisões e grupos. Na lista de pacientes, cada pessoa mostra o próximo encontro e pontos de atenção.


Registros clínicos organizados por paciente e supervisões com ciclos, casos e checklist de preparação.


Cursos recomendados para a prática e um painel de desempenho que mostra o que favorece a evolução profissional.


SaaS · EdTech




A evasão dá sinais: queda de frequência, notas baixas, menos engajamento. Mas esses dados ficam espalhados em papel, planilhas e WhatsApp. O SIMA conecta essas informações e orienta cada perfil da escola sobre onde agir — acompanhamento formativo, não vigilância.

Deslize para ver a tela inteira →



Como desenhar um sistema de acompanhamento para cinco perfis institucionais, com níveis de letramento digital distintos, em que permissões por escopo e alertas explicáveis orientem a intervenção pedagógica — e não a fiscalização hierárquica?
No piloto, o nível de risco (baixo, médio, alto) vem de regras determinísticas e configuráveis, não de modelo preditivo. Cada alerta expõe os fatores que o dispararam, a fonte do dado e a janela de tempo considerada.
Frequência, notas e entregas alteram o nível de risco; observações pedagógicas, saúde e situação familiar entram apenas como contexto, sem reclassificar o aluno automaticamente. O acesso segue escopo e menor privilégio, não hierarquia.
Turma, horário e carga horária vêm preenchidos pela agenda: o professor marca presença para todos, registra as exceções e publica. Lançamento não realizado no prazo vira pendência para professor e coordenação — nunca falta do aluno.

Sidebar de 282px, topbar de 76px e conteúdo até 1320px. Espaçamento em base 4px.






Material Symbols Outlined · peso 300
Nenhuma regra crítica acionada
Frequência abaixo de 75% no mês
5 faltas consecutivas em 2 disciplinas
| Turma 2026.1 B | S10 | S11 | S12 | S13 | S14 | S15 | S16 | S17 | Média |
|---|---|---|---|---|---|---|---|---|---|
| Matheus O. | 58% | ||||||||
| Ana Luíza C. | 61% | ||||||||
| Rafael F. | 72% | ||||||||
| Júlia S. | 91% | ||||||||
| Pedro L. | 88% | ||||||||
| Larissa M. | 76% | ||||||||
| Caio R. | 93% | ||||||||
| Beatriz T. | 63% |
Vale conversar com a turma antes da próxima avaliação.
Ver os alunosCompara unidades e acompanha metas da rede.
5 unidadesVê a escola por turma, turno e curso.
Meta atingidaPrioriza alunos e registra intervenções.
3 críticosImporta dados e corrige inconsistências.
12 para revisarLança frequência e notas em poucos toques.
4 lançamentosMantém o contexto e diz o que está sendo atualizado.
Não há dados para os filtros selecionados.
Limpar filtrosExplica o problema sem expor dados técnicos ou pessoais.
Tentar novamenteMostra o limite do perfil sem revelar registros protegidos.
Voltar ao painelEstados obrigatórios em toda tela, com texto específico ao contexto e foco levado à ação de recuperação.
Cards usam 12px; botões e campos, 8px; o hero do painel, 24px.

O gestor vê as quatro unidades de uma vez: alunos ativos, vagas, frequência e evasão, sempre comparados à meta. Um resumo no topo diz em linguagem simples onde está o problema.


O risco nunca aparece sozinho: o card "Resumo para decisão" mostra o motivo, a evidência e a janela de tempo. A coordenação decide e registra o acompanhamento.

A próxima aula abre o diário com turma e disciplina já definidas. No primeiro acesso, o professor é guiado em três passos até a primeira chamada.


A equipe administrativa acompanha pendências de dados, ocupação de vagas e importações. A nova matrícula mostra o impacto na turma antes de confirmar.

O SIMI é o guia acadêmico do SIMA: um assistente supervisionado que aparece em momentos pertinentes, explica regras e sugere próximos passos, sem decidir pela equipe.


Bom dia, Carla. Encontrei 3 sinais novos na turma SI‑2026.1·B, todos gerados por regras institucionais. Quer revisar os motivos?
Por que o Matheus está com prioridade alta?
Três critérios da regra de atenção foram atingidos nas últimas 8 semanas:
Fonte: diário de classe · regra v1.1 · confiança alta
O SIMI explica e sugere; a decisão é sempre da equipe.

Web App · HealthTech · Segurança

O sistema institucional é lento, então o profissional manda o laudo pelo WhatsApp — e o dado sai do fluxo oficial. O VitaTrace acaba com a escolha entre segurança e usabilidade: “Você não precisa trocar nada. Só precisa parar de perder controle.”

Deslize para ver a tela inteira →
Equipes de saúde mandam laudos pelo WhatsApp porque o sistema oficial é lento. Como tornar o envio de documentos clínicos rastreável e compatível com a LGPD, mas tão simples quanto mandar uma mensagem?
Ao anexar, o arquivo passa por antivírus, detecção de dados pessoais (CPF, nome de paciente) e classificação automática de sensibilidade, com hash SHA-256 — sem formulário extra para quem envia.
O envio só é liberado após a confirmação explícita do destinatário. A permissão é definida por arquivo — por exemplo, visualização com marca-d’água e sem download — e o acesso expira em 7 dias por padrão.
O evento “visualizou às 09:34” confirma a entrega para a remetente e alimenta a trilha de auditoria da instituição, junto com acessos negados, expirações e revogações.

Grid de 12 colunas organizando 3 áreas: sidebar, conversas e painel de contexto. Raios de 8 a 36px e sombras suaves.
Ícones lineares arredondados · Lucide
Hospital Esperança → Operadora Vida+ Saúde · aberto hoje, 08:20
Tentativa de acesso fora do padrão detectada.
exame_maria_costa.pdf expira em 24 h.
Arquivo compartilhado com usuário de outra instituição.
Juliana Silva enviou exame_maria_costa.pdf
SHA-256 · 9f2c…a71eDados sensíveis · criptografia aplicada
Dr. João Almeida visualizou o arquivo · dispositivo verificado
Dispositivo não verificado · política aplicada
Recebimento confirmado pelo destinatário
Só o destinatário consegue abrir este arquivo.

Parece um chat, mas tem a governança de um MFT (Managed File Transfer): cada anexo ganha um card com antivírus, detecção de dados sensíveis e expiração, e a composição é cifrada de ponta a ponta. À direita, o painel do caso mostra SLA e linha do tempo.

Antes de enviar, o pré-envio anti-engano confirma destinatário, permissão e prazo: "Apenas visualizar" abre o PDF num viewer com marca d’água e sem download, e baixar exige justificativa. Depois, o acesso pede uma credencial única por biometria, e o status "Visualizado" vira recompensa para Juliana e auditoria para a instituição.


O painel de segurança mostra a sessão com SSO institucional e MFA (TOTP), IP e dispositivo, as políticas em vigor (hash SHA-256 em todo envio, expiração de 7 dias, compartilhamento externo bloqueado) e os eventos auditáveis. Em Arquivos, cada documento mostra quem acessou, quando expira e pode ser revogado.


Plataforma · HealthTech



A jornada de cuidado é fragmentada: cada serviço registra um episódio e a informação fica presa na instituição. Quem cuida de crianças, idosos ou pessoas com condições crônicas sente isso todos os dias. A plataforma coloca a pessoa como dona dos seus dados.

Deslize para ver a tela inteira →


Projeto da SOMOS Healthtech. Parceiros institucionais anonimizados; dados fictícios.
Como fazer a história de saúde acompanhar a pessoa, e não a instituição, conectando família, profissionais e grupos de cuidado em torno dela, com a pessoa no controle do que compartilha?
No modelo de dados, a pessoa é a titular do prontuário e a conta apenas opera o acesso: uma pessoa pode existir sem login e ser acompanhada por um responsável vinculado.
Cada autorização define seção do prontuário, finalidade e prazo, é versionada, revogável a qualquer momento e registrada em auditoria.
Dependentes e “pessoas que eu cuido” são modelados como vínculos com escopo de acesso próprio e ficam na navegação principal, com troca de contexto entre a própria conta e cada pessoa cuidada.

Fonte única PT Sans, raio de 12px nos cards e espaçamento em base 4px. Busca testada em 320, 768 e 1024px.


Escala de espaço — base 4px
4px8px12px16px20px24px32px48pxBorder radius
Elevação
Material Symbols Outlined
SAEnviamos 6 dígitos para (81) •••••-4120
Hoje
Endocrinologia e Metabologia
Hoje, 28 de julho · 10:30 Anexar arquivos e examesExame laboratorial
12 de agosto · 08:00ConfirmadaSaúde cardiovascular e cuidado preventivo
Envie exames e receitas para tê-los à mão nas consultas.
Enviar arquivoOlá, Sofia
Título · 30 / 700Minha agenda
Seção · 20 / 700Acompanhe suas consultas
Corpo · 15 / 400
A pessoa vê consultas do dia, próximos exames e programas de saúde. No primeiro acesso, a mesma tela guia o preenchimento do perfil.


Atendimentos e especialidades ficam numa só linha do tempo que acompanha a pessoa entre serviços. Em Meus consentimentos, ela decide quem acompanha cada parte do histórico.


O profissional vê a agenda do dia, tarefas e o feed de acompanhamento dos pacientes. As mensagens conectam profissional e paciente dentro da rede.


Filtros por especialidade e local e cards com disponibilidade. No perfil, a pessoa conhece o profissional e agenda a consulta.

Interfaces de IA · Atendimento em clínicas

Clínicas recebem a maior parte dos contatos pelo WhatsApp, e a mesma dúvida sobre preço, preparo ou agenda chega dezenas de vezes por dia. Colocar um agente de IA para responder sozinho, sem preparo, é arriscado. O projeto desenha o ciclo completo: o agente especialista treina contra personas sintéticas numa arena; no atendimento real, começa como copiloto, sugerindo respostas que a equipe aprova ou edita; e, quando pronto, opera em autopiloto, com um agente orquestrador que identifica a intenção e transfere para o especialista certo. Em todos os modos, o raciocínio e o objetivo do agente ficam visíveis para quem supervisiona.

Deslize para ver a tela inteira →
Protótipo de interface. Nome da clínica e do produto anonimizados; pacientes, valores e conversas são fictícios. Os agentes não estão ligados a um modelo de linguagem nesta versão.
Como dar a uma clínica confiança para deixar agentes de IA conversarem com pacientes: treinar antes de expor, manter a equipe no controle enquanto o agente aprende e tornar visível por que ele respondeu o que respondeu?
Na arena, o agente especialista conversa com uma persona sintética de dificuldade definida, como a paciente indecisa com objeção de custo. A equipe assiste em modo espectador e acompanha objetivo, estratégia escolhida e padrões detectados, que podem ser salvos.
O mesmo atendimento alterna entre copiloto e autopiloto. No copiloto, o agente propõe a resposta com raciocínio e próximo passo, e nada sai sem “Aprovar e enviar” ou edição. No autopiloto, o agente orquestrador faz a triagem e transfere a conversa ao especialista, avisando a mudança no próprio chat.
Um painel lateral mostra o histórico do orquestrador, a análise de contexto, a decisão estratégica e o progresso do objetivo. Quando surge um padrão novo, o agente propõe adicioná-lo a um bloco da base de conhecimento, e a equipe confirma ou ignora.

Três regiões: navegação e caixa de mensagens, conversa e painel do agente. A operação foi desenhada para a estação de trabalho da equipe; telas de tablet e celular não fizeram parte do escopo.
Material Symbols Outlined · peso 400
Recomendar Protocolo e Converter em Avaliação
Contornar Objeção de Preço
Histórico do Maestro
Interesse em Cirurgia Bariátrica / Tratamentos
Solicitado informações de perfil
Perfil Paciente Nova identificado
Raciocínio Atual
Detectada objeção de preço. Paciente identificou-se como novo caso. A estratégia 'Vida Leve' é a mais adequada para contornar a objeção sem desvalorizar o protocolo clínico.
Entendi! Com R$ 900/mês e parcelamento estendido, tenho um protocolo personalizado que cabe no seu bolso. Podemos fechar no pacote anual com 15% de desconto na avaliação inicial?
Raciocínio: A paciente demonstrou alto interesse mas possui barreira financeira clara (R$ 900/mês).
Próximo Passo: Apresentar o pacote anual para atingir o valor-alvo e facilitar o agendamento da avaliação.
Extraído da conversa atual
Detectamos um novo conhecimento na análise desta conversa. Deseja adicionar este conhecimento a um bloco na sua Base de Conhecimento?
Obrigada! Meu orçamento atual é de até...
Confirmamos a reavaliação para terça?
O recibo já foi emitido, obrigada.
Prontuário #99482 atualizado.
Responda aqui ou peça algo ao Copiloto...

O agente especialista conversa com uma persona sintética (paciente indecisa, dificuldade alta, cenário numerado). A equipe assiste em modo espectador e acompanha, à direita, o objetivo da simulação, a análise da objeção, a estratégia escolhida e o padrão detectado, que pode ser salvo.

Na conversa real, o agente propõe a resposta com base no que a paciente disse e mostra o raciocínio e o próximo passo. A atendente aprova e envia, edita ou ignora; o objetivo do atendimento avança conforme a conversa.

O agente orquestrador detecta a intenção da paciente e faz perguntas de perfilamento antes de decidir para quem encaminhar. O painel mostra a lógica em passos: detecção, aguardando resposta, perfil e intenção identificados.


Com o perfil definido, a conversa é transferida ao especialista e o aviso aparece no próprio chat. O especialista conduz a objeção de preço com a estratégia exposta, e o conhecimento novo vira proposta para a base, que a equipe confirma ou ignora.


Web App · Farmácia hospitalar em rede



Na mesma rede, um hospital vê um lote de alto custo vencer na prateleira enquanto outro abre uma compra emergencial do mesmo medicamento. O FarmaNexo junta estoque por lote e validade, previsão de consumo e um fluxo governado de transferência: o algoritmo encontra o par e reserva por tempo limitado, os dois hospitais decidem, e o lote é rastreado da coleta à conciliação. Em 2023 fiz a pesquisa, o mapeamento do domínio e o design das telas de pareamento, transferência, rastreabilidade e auditoria. Todos os dados exibidos são sintéticos.

Deslize para ver a tela inteira →


Produto próprio. Dados hospitalares inteiramente sintéticos; sem homologação sanitária ou contrato de operação.
Como fazer hospitais diferentes compartilharem medicamentos antes do vencimento ou da ruptura sem que a sugestão do algoritmo vire autorização, sem expor o estoque que cada um não quer mostrar e sem perder a cadeia de custódia do lote?
O pareamento cria só uma reserva temporária, com prazo, para impedir dupla alocação enquanto os hospitais analisam. Aceite, liberação e transferência dependem de decisão humana bilateral, registrada na auditoria com ator e motivo.
A transferência percorre estados definidos (em aprovação, aprovada, reservada, em separação, em transporte, recebida, conciliada, concluída) e o servidor recusa saltos antes de gravar. Quarentena é um estado próprio, alcançável no transporte ou no recebimento, e não uma observação solta.
O Índice de Impacto reconhece quem cedeu medicamento, mas não é saldo: não gera débito para quem recebe e nunca entra no ranking do pareamento. Valor público preservado é registrado à parte.

Barra lateral de 244px e conteúdo em grid de 12 colunas. Abaixo de 1024px a navegação vira gaveta e a barra superior fica fixa; textos secundários foram revistos num estudo de tipografia feito em 1024 e 1366px.




Lucide · traço 2px
Transportadora VidaLog recebeu 12 frascos lacrados no Hospital Oncológico Central.
Responsável: Marcos Lima · farmacêutico RTSensor VL-8812 associado. Temperatura inicial de 4,2 °C.
Evidência: registro IoT assinadoÚltima leitura em Recife: 4,6 °C, dentro da faixa de 2–8 °C.
Previsão de chegada: 15:20Dupla conferência de lote, quantidade, integridade e temperatura.
Hospital MetropolitanoPontos simbólicos serão gerados para o hospital que contribuiu após o recebimento aceito.
Valor público potencial: R$ 204 milLote PBL240881 · combinação calculada há 4 minutos
Coleta registrada às 09:42 · chegada prevista 15:20
Avançar etapaExemplo: 93 pontos em uma transferência concluída. Divergências não geram pontos até a resolução; nunca existem pontos negativos.

O farmacêutico vê necessidades publicadas, reservas em análise, valor de estoque em risco por horizonte de validade e os pareamentos que pedem decisão. Em Estoques, o hospital escolhe quais lotes disponibilizar; o restante continua privado.


Consumo realizado e demanda prevista com faixa de confiança, excedente projetado e prazo para decidir. A versão do modelo e os fatores considerados ficam visíveis ao lado da sugestão, que nunca movimenta estoque sozinha.

Cada pareamento mostra aderência, lote, validade, hospital cedente e solicitante, valor público potencial e o prazo da reserva temporária. A necessidade segue um fluxo em quatro passos: publicar, busca automática, reserva e decisão dos dois hospitais.


A transferência avança por estados definidos, com rota, progresso e a autorização dos dois hospitais. Na rastreabilidade, o lote é consultado por código e mostra coleta, cadeia fria, deslocamento e recebimento, com evidências e condições monitoradas.


Saúde dos conectores com o sistema hospitalar, latência e qualidade dos dados enviados; trilha de auditoria das decisões e transições; e o Índice de Impacto, que reconhece colaboração sem criar dívida entre hospitais.


Web App · Gestão para redes de farmácias




Uma rede de farmácias de bairro vendia, controlava estoque e prestava contas à Anvisa em ferramentas separadas. Desenhei um sistema único para as unidades, apresentado como protótipo navegável: painel gerencial com vendas, comissões, entregas, estoque, serviços e registro de receitas; ponto de venda com leitura de código de barras; controle e renovação de estoque com importação por CSV ou XML da nota fiscal; cadastros de medicações, produtos, clientes, usuários e serviços farmacêuticos. A interface tem um sistema visual próprio, com cores que indicam a situação do estoque e marcam os medicamentos controlados, pensado para leitura rápida no balcão. O nome do produto, as pessoas e os laboratórios são fictícios.

Deslize para ver a tela inteira →



Protótipo para apresentação (2022) para uma rede de farmácias. O nome da rede não é divulgado; nome do produto, pessoas, laboratórios e números são fictícios.
Como colocar no mesmo sistema a pressa do balcão e a rotina regulatória da farmácia, de modo que a venda de um antimicrobiano ou de um controlado já alimente o registro de receitas e os relatórios para a Anvisa, sem criar uma segunda digitação para a equipe?
Quando o carrinho tem antimicrobiano ou medicamento da Portaria 344/98, o ponto de venda pede prescritor, CRM e data da receita ali mesmo. O lançamento vai para o Registro de Receitas e para a escrituração de controlados, em vez de ser copiado depois.
Cada produto tem quantidade mínima e uma barra de nível com a marca desse mínimo. A Renovação de Estoque lista o que está abaixo dele, sugere a quantidade e gera a lista de reposição para o fornecedor.
Verde, âmbar e vermelho só aparecem para a situação do estoque; roxo marca os controlados e azul-céu, os antimicrobianos. O balconista reconhece um item que exige receita antes de ler o nome.

Barra lateral grafite de 256px (236px abaixo de 1366px), com os módulos em quatro grupos, e conteúdo em 12 colunas. Abaixo de 1024px a navegação vira gaveta e a barra superior fica fixa; abaixo de 640px entram a navegação inferior e as tabelas em cards.





Lucide · ícones de traço em SVG (ISC)
Cápsula diagonal e cruz em quadrado com o gradiente céu → índigo da navegação
Módulos agrupados · ativo com barra · hover em “Clientes”
Unidade Piedade · última atualização em 14 de out., 2022
| Produto | Classificação | Preço | Estoque | Situação | |
|---|---|---|---|---|---|
| Losartana Potássica 50 mg30 comp. · cód. 100101 | Genérico | R$ 12,90 | 184 / mín. 60 | Em estoque | |
| Amoxicilina 500 mg21 cáps. · cód. 100125 | Antimicrobiano | R$ 18,40 | 22 / mín. 40 | Estoque baixo | |
| Alprazolam 0,5 mg30 comp. · cód. 100231 | Lista B1 | R$ 13,40 | 7 / mín. 15 | Crítico |
Como a medicação aparece no balcão, nos relatórios e no SNGPC.
| Nome genérico | Dosagem | Pedir |
|---|---|---|
| Amoxicilina | 500 mg · 21 cáps. | 58 CX |
| Loratadina | 10 mg · 12 comp. | 51 CX |
| Alprazolam | 0,5 mg · 30 comp. | 23 CX |

Quatro indicadores com tendência dos últimos 12 meses, um aviso de itens abaixo do mínimo e oito gráficos com a mesma paleta: vendas por categoria (barras, linhas ou pizza), comissões, entregas por trimestre, estoque por categoria, vendas por vendedor, serviços, renovação de estoque e registro de receitas por classe.



Catálogo com busca, filtros por categoria e cartões de produto com preço e estoque baixo; ao lado, o caixa: leitura de código, vendedor, carrinho com quantidade editável, convênio, entrega, forma de pagamento, total e troco. Se o carrinho tem antimicrobiano ou controlado, o registro da receita é pedido na própria venda.







Tabela com miniatura, classificação, preço, barra de nível com a marca do mínimo e selo de situação; ações por ícone em cada linha. Importar e Exportar ficam em menus. Na aba Renovação ficam só os itens abaixo do mínimo, com sugestão de compra, e a lista de reposição abre num modal pronto para imprimir.


Cadastro em seções (identificação, fornecimento, estoque e validade, imagem) com campos obrigatórios marcados, textos de ajuda e validação, incluindo a classificação da Portaria 344/98. A importação lê CSV ou XML da nota fiscal, preenche o formulário e destaca o que veio do arquivo para revisão antes de salvar.



Catálogo de relatórios da rede com filtros de período, unidade e formato, histórico de gerações e destaque para os documentos regulatórios: registro de receitas retidas, arquivo XML de escrituração para o SNGPC e livro de registro de controlados para assinatura do farmacêutico responsável.


Usuários por unidade, função e permissão, com o farmacêutico responsável liberando controlados; serviços farmacêuticos como injetáveis, testes rápidos e vacinas; e cadastro de clientes com validação de CPF e CEP que preenche endereço e bairro.



Documentação do processo
Produto, game design e desenvolvimento do filme interativo: do estudo do e-book PROTEGER e do desenho do ciclo de ensino ao roteiro, à direção de arte, ao software em React e TypeScript e ao pitch para a diretoria do IGG.
Proposta desenvolvida para o Instituto Gabriel Gastal (IGG). Personagens, escola, app e perfis são fictícios; imagens e vozes foram geradas com IA sob direção de arte. A validação pedagógica pelo IGG e o teste com alunos são próximos passos.
01Papéis
Como atuei no produto, no game design e no desenvolvimento, e o que cada papel entregou.
Transformei uma metodologia para educadores em uma experiência do aluno, com regras verificáveis e próximos passos claros para o cliente.
Desenhei um filme que ensina por mecânica e consequência, não por quiz, com uma linguagem visual coerente do cenário à interface.
Desenvolvi o software do protótipo: o filme roda no navegador a partir do grafo do episódio, sem backend nem cadastro.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Primeiro plano e estudo do e-book PROTEGER
PMPlano v2.1 após três críticas independentes
PMRevisão de ritmo: duração por caminho recalculada a partir do texto
DesignGuia GG, pistas antes de cada decisão e cinco finais reequilibrados
DesignEp. 1 jogável: cenas, vozes, efeitos, Mural e story:check verde
DesignRoteiro e storyboard do pitch em vídeo para a diretoria
PMPitch em vídeo finalizado e contrato de produção do Ep. 2
DesignRevisão pedagógica do IGG e teste com alunos de uma escola parceira
PM03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
Nenhuma prova acontece sem modelo, ferramenta e ensaio do mesmo conceito antes dela, em todos os caminhos. A sonda é só linha de base.
A opção move só o estado da história; a percepção gera evidência. Os finais saem do estado acumulado, nunca de uma escolha isolada.
O Director monta o próximo nó enquanto o atual toca; cada entrada de nó grava um snapshot local que permite retomar e rebobinar.
05Arquitetura
Aplicação estática no navegador: o mesmo núcleo puro roda no app, na verificação da história e no render dos vídeos.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêQuem percebeu todos os rastros e publicou mesmo assim não é “reprovado”: recebe a consequência. Pontuar a opção mediria obediência ao caminho do professor.
Por quêCom Lente, editor e perfil, as combinações chegam a milhares. Só a simulação garante modelo, ferramenta e ensaio antes de cada evidência sem andaime.
Por quêBotões reais têm foco, teclado e leitor de tela, e o timer em CSS não força renderização por quadro. A troca entre cena e interação fica invisível.
Por quêPúblico de 12 a 14 anos: nada de nome nem data de nascimento. A própria mascote mostra o que foi registrado na sessão e o “Apagar agora” apaga de fato.
Por quêCinco finais saem do que o desconhecido vê, da porta dele e de quem soube; nenhum culpa a Bia e todos terminam com caminho de ajuda.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Grafo do Ep. 1
47/47 nós visitadosCobertura da simulação: 127 de 128 planos e 21 de 21 ramos condicionais.Simulação
semente fixaCaminhos reproduzíveis a cada execução, sem faltas.Finais
5 alcançáveisNenhum final abaixo de 11% dos caminhos simulados.Linguagem
lint sem certo/erradoRótulos e retornos sem “acertou”, “errou” ou “perigoso”, com lista de exceções do e-book.Privacidade
0 requisições a terceirosSem backend, login, analytics ou CDN; progresso só no aparelho.Acessibilidade
teclado e leitor de telaAtalhos 1·2·3, L e Esc; aria-live nas falas; alvos de ≈ 44px; descrever imagens.Testes
VitestMotor, história, finais, avaliação, áudio e palco.Fim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto
Documentação do processo
Responsável pelo design do software: arquitetura de informação, fluxos, interface e padrões de interação, do mapeamento das normas ao protótipo funcional validado com o LAFEPE.
Protótipo conceitual desenvolvido para apresentação ao LAFEPE; todos os dados exibidos são fictícios.
01Papéis
O que fiz como designer de produto, do problema às telas.
Desenhei a arquitetura de informação, os fluxos e a interface, com regras visíveis em cada tela.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Estudo das normas, da documentação técnica e dos processos da Qualidade
DesignPerfis de acesso, mapa do site e ciclo documental em sete etapas
DesignReferência visual escolhida: menu azul, quadro por etapa e inspetor
DesignModelo de dados e comandos auditados definidos
DesignQA visual em 1280, 768 e 390 px, sem divergências críticas, altas ou médias
DesignCriação e edição explícitas na ficha e editor em página
DesignAssistência guiada e assistente de IA com prévia obrigatória
DesignProtótipo versionado em repositório
DesignManual ilustrado e 25 defeitos de fluxo corrigidos
DesignValidação com o LAFEPE e vídeos de apresentação
Design03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
Do rascunho à vigência. A revisão anterior continua valendo até o último passo, e quem elabora nunca aprova.
A IA trabalha sobre a seleção ou o cursor e devolve uma proposta. Nada entra no documento sem conferência humana.
Os processos da Qualidade se ligam: o desvio gera CAPA, a correção pode exigir mudança, e a mudança crítica exige risco.
05Arquitetura
Aplicação React que roda localmente no navegador, com domínio próprio e um servidor mínimo apenas para a IA.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêEm ambiente regulado, entender por que algo é bloqueado ensina a regra e evita pedidos informais por fora do sistema.
Por quêA responsabilidade pelo conteúdo é de quem elabora. A IA alimenta só o rascunho e nunca aprova, assina ou coloca em vigência.
Por quêÉ o gesto que quem usa processador de texto já conhece. O sistema amplia a seleção aos parágrafos, listas e tabelas inteiros.
Por quêSem infraestrutura qualificada, rodar localmente permitiu demonstrar tudo sem expor dados e sem depender de rede.
Por quêCada painel diz que usa cenários predefinidos. Não há confiança inventada nem ganho de produtividade alegado.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
QA visual
0 divergências relevantesNenhuma divergência crítica, alta ou média em desktop, tablet e celularTestes automatizados
165 casosDomínio, editor, IA e regras do manual, em 10 arquivosDefeitos de fluxo
25 corrigidos10 com teste automatizado por envolver regra do sistemaConsole
0 errosNavegação e exportações na versão preparadaRede
0 chamadas externas46 solicitações observadas, todas locaisFim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projetoDocumentação do processo
Product designer e front-end: conduzi pesquisa e estratégia, criei o design system, prototipei as 11 telas e traduzi requisitos de privacidade em decisões de interface.
Protótipo criado para apresentação ao Liberty Group. Todos os dados exibidos são fictícios.
01Papéis
Como atuei como Product Designer e Desenvolvedora Front-end, e o que cada papel entregou.
Transformei princípios de cuidado e de privacidade em fluxos, estados e componentes visíveis.
Implementei o protótipo em código para provar a continuidade dos estados entre telas, não só a aparência.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Pesquisa documental concluída e problema reformulado
DesignTese, sete princípios e arquitetura em cinco camadas
DesignPlano de telas priorizado e especificação com critérios de aceite
DesignRequisitos de privacidade e governança a partir da LGPD
DesignDesign system 1.0: princípios, cores, tipografia e padrões do domínio
DesignDeck de demonstração em 18 cenas, com notas do apresentador
DesignDesign system 1.1: identidade própria aplicada à Central
DesignDesign system 2.0: tokens, layout responsivo, estados e governança
DesignQA visual da Central em duas iterações
DesignDesign system 2.1: fundamentos alinhados à Central
DesignProtótipo final: 11 telas, estados propagados e cenas por URL
DevValidar papéis, campos e regras com as instituições antes do piloto
Design03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
A rotina da escola gera um sinal explicável; a IA só prepara o contexto; pessoas decidem, encaminham, cuidam e devolvem.
Nada é compartilhado por padrão: cada envio exige finalidade, destinatário, grupos de dados, prazo e revisão humana.
O ponto de partida é a voz do aluno, não um alerta. O plano mede execução semanal e é reajustado por pessoas.
05Arquitetura
O protótipo implementado (telas, estado e design system) e as cinco camadas conceituais que ele representa.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêAlerta não é diagnóstico. O nome convida a uma decisão humana (confirmar, editar ou descartar) e evita rotular o aluno.
Por quêA IA prepara, a pessoa decide: o rascunho cita fontes e só produz efeito quando alguém confirma. O painel abre e fecha sem dominar a tela.
Por quêA LGPD pede necessidade e minimização, com cuidado redobrado para adolescentes. “Compartilhar tudo” nunca é oferecido como padrão.
Por quêA metodologia do Apoio começa pela história e pelo objetivo do aluno. Um plano de conquista evita reduzir o produto a um painel de déficits.
Por quêEra outro produto, para outra parceria. A versão 1.1 separou a identidade e a 2.1 consolidou a Central como referência de paleta, tipo e escala.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
QA visual
2 iterações · aprovadoNenhuma divergência crítica, alta ou média restante na comparação com a referência.Console
0 erros e 0 avisosNas interações principais verificadas no navegador.Contraste do deck
19/19 WCAG AAVerificações automáticas aprovadas na validação final.Validação do deck
0 errosLint, runtime e motion; 18 cenas e 40 alvos de clique consistentes.Alvo de toque
mínimo de 44pxDefinido como token do design system.Acessibilidade
teclado e leitor de telaFoco visível, Escape em modais, aria-live; cor nunca é o único indicador.Privacidade
0 dados reaisSelo “Dados fictícios” sempre visível no protótipo.Fim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto
Documentação do processo
Pesquisadora e desenvolvedora full stack no Hospital das Clínicas da UFPE. Defino a arquitetura funcional e os fluxos, desenvolvo as interfaces e trabalho na integração com modelos de linguagem.
01Papéis
Como atuei como pesquisadora e desenvolvedora full stack, e o que cada papel entregou.
Organizo requisitos, fases e documentação para que a pesquisa e o software avancem juntos.
Implemento o protótipo em código e construo a integração com modelos de linguagem.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Problema estruturado e comparação com soluções existentes
PesquisaJornadas do aprendiz e do preceptor
DevMódulos, requisitos funcionais e não funcionais e arquitetura proposta
PesquisaPlano de trabalho técnico em três fases com sprints de duas semanas
PesquisaProtótipo navegável de alta fidelidade e design system
DevTelas autossuficientes com verificação automática de renderização
DevPitch institucional e conceito de simulação por voz
DevResumo expandido submetido ao CBEB 2026, depois aceito
PesquisaIntegração com modelo de linguagem e casos roteirizados
DevAPI, modelo de dados e banco de casos compostos
DevEntrevistas e ciclos de usabilidade com meta SUS ≥ 70
Pesquisa03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
O aprendiz conversa em linguagem natural; a IA responde dentro do roteiro do caso; o feedback vira conversa com o preceptor.
O sistema sugere; o preceptor decide o reforço e publica casos só depois da validação clínica, pedagógica e jurídica.
Casos compostos combinam elementos de vários atendimentos para que nenhum paciente seja identificável.
05Arquitetura
Do protótipo atual à plataforma com IA: a camada de roteiro fica entre o aprendiz e o modelo de linguagem.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêReduz o risco de alucinação clínica e permite mapear o feedback por competência. A IA conduz a conversa; o conteúdo vem dos preceptores.
Por quêNenhum paciente é identificável e a pesquisa não acessa prontuários. É privacidade desde a concepção, com realismo pedagógico.
Por quêA formação por competências pede saber o que melhorar. Trechos da conversa viram pauta concreta para a preceptoria.
Por quêO raciocínio clínico é do aprendiz. A interface diz isso na tela: “o sistema não sugere conduta”.
Por quêPreceptores acompanham turmas grandes. O sistema devolve tempo com sugestões e lacunas, mas quem decide o reforço é o preceptor.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Produção científica
1 resumo aceitoCBEB 2026, em coautoria com a equipe do projeto.Renderização
0 erros por telaVerificação automatizada de fonte, imagens e estilos em cada tela do protótipo atual.Privacidade
0 dados reaisPacientes, alunos e casos são fictícios; casos compostos por desenho.Aviso educacional
em todas as telas“Não substitui protocolos ou prontuários oficiais.”Meta de usabilidade
SUS ≥ 70Planejada para o teste formal; ainda não aplicada.Fim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto
Documentação do processo
Design de produto, QA e desenvolvimento full stack na SOMOS Healthtech: telas em React para quatro perfis, a partir de reuniões com especialistas.
Projeto da SOMOS Healthtech. Os dados exibidos são fictícios.
01Papéis
Como atuei como Product Manager, Product Designer (com QA) e Desenvolvedora Full Stack, e o que cada papel entregou.
Transformei conversas com especialistas em regras de negócio, tarefas e prioridades.
Desenhei uma rotina clínica acolhedora para quatro perfis, sem transformar cuidado em burocracia.
Construí o protótipo em código e troquei comportamento simulado por regras reais.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Proposta técnica com personas, princípios e roadmap
PMDesign system, login e primeiras telas
DesignPrimeira publicação na Vercel; agenda e comunicação
DevPacientes, cursos, prontuários, documentos e supervisão
DevAtendimentos e financeiro
DevReunião com especialistas e plano do prontuário
PMAvaliação heurística da agenda e correções no dia seguinte
DesignDossiês de descoberta e nova escala tipográfica
DesignRegras de sessões, pacotes, reembolsos e planos modulares
PMProntuário em lista e detalhe, com complemento rastreável
DevRevisão com o fundador e retirada da IA do MVP
PM03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
O registro finalizado não muda: qualquer correção vira um complemento rastreável. A revisão por IA foi planejada e retirada do MVP.
Nenhum atendimento particular entra na agenda sem o aceite do termo de consentimento.
Uma conta pode ter vários perfis; os dados clínicos do perfil paciente nunca aparecem nos outros.
05Arquitetura
Front-end em React com estado local por módulo, pensado para trocar o armazenamento por uma API sem refazer telas.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêAs três colunas foram rejeitadas na validação. Lista e detalhe priorizam a escrita, o caminho principal, com densidade calma.
Por quêDecisão da liderança para a primeira versão. O princípio continua: IA como copiloto, nunca autora, e sempre com revisão humana.
Por quêO documento clínico precisa ser íntegro. O complemento preserva o original e mostra quem mudou, quando e por quê.
Por quêAgenda, atendimento e registro formam uma rotina só e compartilham os mesmos dados do acompanhamento.
Por quêPersonalizar a forma de registrar sem perder a documentação mínima nem os direitos do paciente.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Testes automatizados
104Incluem o carregamento de todas as rotas; mais 26 testes de fluxo.Avaliação da agenda
11 + 9Problemas de usabilidade e bugs, cada um com severidade.QA visual
4 larguras1440, 1024, 768 e 390px.Regras de negócio
26Sessões, pacotes e reembolsos validados com especialistas.Descoberta
59 tarefasOrganizadas em dossiês com perguntas de validação.Fim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto
Documentação do processo
Responsável por pesquisa, produto, design e desenvolvimento do produto, trabalhando com especialistas em tecnologia e em pedagogia.
01Papéis
Como atuei como Product Manager, Product Designer e Desenvolvedora Full Stack, e o que cada papel entregou.
Defini o que o produto faz, o que ele nunca deve fazer e como provar que funciona.
Desenhei 35 telas para cinco perfis com linguagem de cuidado e risco sempre explicado.
Implementei todo o protótipo e o MVP em React e TypeScript, acompanhei a validação e os testes e modelei o domínio para o back-end futuro.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Documentação funcional e design system 2.0
DesignMapa de requisitos, modelo de domínio, registro de decisões e plano de validação
PMDesign system 3.0
DesignTelas dos perfis no repositório e contrato de 35 telas
DevDesign system 3.1 com comparação em desktop e celular
DesignAvaliação do protótipo com especialistas em educação
PMRegras de produto v0.9 e documento de ajustes da reunião
PMAuditoria do app do Professor com 17 problemas priorizados
DesignApp do Professor em React com TypeScript
DevTestes de domínio, interface e acessibilidade no app
DevEntrevistas em campo com direção, gestão e equipe
PMBase de descoberta e cronograma de validação até dezembro
PM03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
O sistema aponta e explica; pessoas decidem e registram. O alerta só fecha com motivo.
Tudo em até três interações a partir do painel. Pendente nunca é falta: cada aluno precisa de estado explícito.
O assistente só sugere. Ele responde dentro do escopo do perfil e admite quando faltam dados.
05Arquitetura
O que existe hoje é front-end com dados fictícios; o back-end está modelado como arquitetura de referência.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêNão havia base de dados validada. Regras simples mostram o motivo de cada alerta e não prometem prever evasão.
Por quêClassificar um aluno automaticamente por dado sensível é injusto e arriscado. Esses dados ajudam a interpretar, não a rotular.
Por quêO assistente não altera notas, não encerra intervenções e não determina evasão. Quando faltam dados, ele diz o que falta.
Por quêSem frequência e notas lançadas na origem, os painéis dos outros perfis ficam sem dado confiável.
Por quêFoi o principal risco apontado pelos especialistas. Diagnósticos coletivos aparecem como hipóteses a investigar, nunca como causa.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Acessibilidade
0 violações axeVerificação estrutural em 10 telas; não substitui teste com usuáriosTestes automatizados
101 aprovadosDomínio, interface e acessibilidade, com typecheck e lintResponsividade
10 rotas em 320 pxSem rolagem horizontal; desktop de 1440 px revisadoTeclado
Foco contido em modaisEscape fecha e devolve o foco ao botão de origemAuditoria
17 de 17 tratadosProblemas de design, regra e fluxo do app do ProfessorFim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto
Documentação do processo
Cofundadora em um projeto de extensão: pesquisa, identidade e design system, e desenvolvimento do front-end do app em React.
01Papéis
Como atuei como Product Manager, Product Designer e Desenvolvedora Front-end, e o que cada papel entregou.
Transformei um problema de comportamento em um MVP com escopo, métrica e plano de validação.
Desenhei um envio que parece chat e se comporta como um MFT.
Levei o protótipo para um app real em React, com o design system em código e as telas ligadas à API do produto.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Estruturação do problema e da oportunidade
PMEvento HOPE – Conexão Saúde e entrevista com um consultor de gestão de TI e dados em saúde: prontuários circulam por WhatsApp e o risco se concentra na recepção e nos cargos de entrada
PMEntrevistas com um especialista em gestão de dados clínicos, com atuação em hospitais, operadoras e healthtechs, e com um especialista em cibersegurança
PMSíntese das entrevistas: o ponto em comum é o dado sensível por WhatsApp e e-mail, sem rastreabilidade nem controle institucional
PMDecisão a partir das entrevistas: clientes são hospitais, clínicas e operadoras; usuário é o funcionário da ponta que compartilha dados sensíveis
PMPersona Juliana, analista de autorização em operadora, composta de relatos reais das entrevistas
DesignRevisão do escopo após a mentoria
PMEntrevista com profissional de uma operadora de saúde do Nordeste: na expansão, 5 mil novos cadastros passaram por canais informais
PMLean Canvas revisado com o que ouvimos: hospitais privados e operadoras como segmentos, e instituições que já sofreram incidentes como early adopters
PMDocumentação de produto e jornada do usuário
DesignDesign system e primeiras telas
DesignProtótipo das 5 telas do fluxo crítico publicado
DevPlano de validação e formulário estruturado
PMProtótipo transformado em app React
DevTelas de grupos, permissão por arquivo e painel de segurança
DevConversa em tempo real e telas de recuperação de senha
DevMelhor Projeto, Melhor Pitch e Maior Potencial de Mercado no Projetão (CIn/UFPE)
PM03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
Do upload ao “Visualizado”: as verificações acontecem por baixo e só pedem decisão quando importa.
Cada transição gera um evento na trilha. Expirar é o padrão; manter acesso é exceção.
05Arquitetura
O front-end em React conversa com a API do produto por REST e WebSocket; a camada de interface é o foco deste case.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêMFTs têm segurança, mas baixa adoção na ponta. Se a tela parecer formulário, a usuária volta ao WhatsApp.
Por quêA mentoria mostrou que “certificação de conformidade” soa como garantia jurídica. O MVP mede adoção segura; o selo vem do uso.
Por quêPermissão mínima por padrão: abrir acesso é uma ação consciente e baixar exige justificativa.
Por quêNo mesmo app ficam colegas, família e fornecedores: o envio acidental é esperado. Uma confirmação curta custa segundos.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Validação do problema
4 entrevistasGestão de dados clínicos, operadora de saúde, TI em saúde e cibersegurança.Fluxo crítico
5 telasConversa, pré-envio, pós-envio, arquivos e segurança.Meta de uso
3 minutosTempo-alvo do envio urgente sem sair do canal seguro.Front-end
6 áreas em ReactConversas, contatos, casos, grupos, arquivos e segurança.Layout
3 regiõesNavegação, conversa e painel de contexto recolhível em 1280px.Reconhecimento
3 prêmiosProjetão 2026.1 do CIn/UFPE.Fim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto
Documentação do processo
Design de produto, QA e desenvolvimento full stack na SOMOS Healthtech: do entendimento do problema às telas em código.
Projeto da SOMOS Healthtech. Parceiros institucionais foram anonimizados; os dados exibidos são fictícios.
01Papéis
Como atuei como Product Manager, Product Designer (com QA) e Desenvolvedora Full Stack, e o que cada papel entregou.
Traduzi conceitos de saúde e governança de dados em regras que o time consegue construir.
Desenhei mais de 200 telas para pessoa, profissional e grupo, sempre em código.
Levo o protótipo para o MVP desktop, com rotas, formulários validados e integração com a API.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Login, cadastro, validação por código e nova senha
DesignInício do protótipo em código e primeiro pull request
DevInício do app web do MVP em Next.js
DevMeus consentimentos e permissões da agenda
DesignConsentimentos e agenda do profissional
DesignPágina pública de grupos, início do profissional e testes da busca
DevGrade de 12 colunas, permissões de membros e início dos grupos
DesignDesign system, mensagens e registro de humor
DesignEspecificações funcionais aprovadas como base oficial
PMQuality gate de lint, build e testes nos pull requests
DevQA da busca de 320 a 2561px e comunidades na busca
Design03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
Do login ao início: o código confirma o contato e o cadastro já pergunta por quem a pessoa cuida.
A pessoa decide quem acompanha cada parte do histórico. Revogar tem efeito imediato e o histórico é preservado.
Laço não dá acesso: quem cuida pede participação e o gestor aprova ou recusa.
05Arquitetura
O protótipo em código define a tela; o MVP em Next.js consome a API REST do back-end.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêCrianças, idosos e pessoas sob tutela precisam de histórico próprio, mesmo sem conta, e podem assumi-lo depois.
Por quêAceite parcial libera só o que a pessoa escolheu; uma nova versão pede novo aceite apenas da seção alterada.
Por quêSer parente não autoriza ver o prontuário. Cada acesso precisa de uma decisão explícita e auditável.
Por quêCom mais de 200 telas, o código mantém componentes consistentes e aproxima a decisão de design da implementação.
Por quêFoi a direção recomendada no estudo de produto, com um plano de validação com usuários antes de fechar o padrão.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Telas prototipadas
200+Em código, entre pessoa, profissional e grupo.Responsividade
0 rolagem horizontalBusca verificada de 320 a 2561px.Contraste
5,25:1Botão principal da busca; texto secundário em 4,55:1.Testes automatizados
~50 casosBusca de profissionais e página pública de grupos.Histórico
500+ commitsUm ano de evolução contínua do protótipo.Fim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projetoDocumentação do processo
Responsável pelo design de produto: defini os modos de operação dos agentes, desenhei as conversas e os painéis de supervisão e prototipei as telas em React e Tailwind CSS.
ClinIA, produto próprio: protótipo de interface para o atendimento de clínicas médicas. Clínica anonimizada; pacientes, valores e conversas são fictícios.
01Papéis
O que fiz como designer de produto, do problema às telas.
Desenhei conversas e painéis em que o raciocínio do agente fica à vista de quem supervisiona.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Problema do atendimento por WhatsApp em clínicas e definição dos três modos de operação
DesignPrimeira tela do copiloto
DesignCopiloto com resposta recomendada, estratégia e objetivo
DesignArena de simulação com persona sintética e primeira tela do autopiloto
DesignDecisão de roteamento do orquestrador e ajustes nas telas de copiloto e autopiloto
DesignGaleria de telas por modo para apresentação
DesignLigar os agentes a um modelo de linguagem e ao canal de mensagens
DesignMétricas de qualidade das respostas antes de liberar o autopiloto
Design03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
O orquestrador descobre a intenção e o perfil; o especialista conduz; a equipe vê cada passo.
O agente só ganha autonomia depois de treinar e de ter respostas aprovadas no copiloto.
05Arquitetura
Desenho funcional que as telas representam; nesta versão, as conversas são roteiros fixos.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêEm saúde, uma resposta errada sobre preço ou preparo vira problema com o paciente. O copiloto gera confiança e exemplos aprovados antes de liberar o autopiloto.
Por quêA equipe precisa entender por que o agente respondeu algo para corrigir a estratégia, não só o texto.
Por quêEscopo menor por agente facilita treinar, avaliar e trocar um especialista sem mexer nos outros.
Por quêEvita que uma conversa atípica altere o comportamento do agente sem revisão.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Controle humano
3 pontosaprovar resposta, confirmar conhecimento e supervisionar o autopilotoTransparência
4 camadashistórico, análise de contexto, decisão estratégica e objetivoDados
100% fictíciosclínica e produto anonimizadosFim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto
Documentação do processo
Concebi o produto e conduzi o design: pesquisa, mapeamento do domínio e design das telas do portal, com base de conhecimento, fluxos, telas responsivas e estudo de tipografia.
Produto próprio. Não há homologação sanitária nem contrato de operação, e todos os dados são sintéticos.
01Papéis
O que fiz como designer de produto, do problema às telas.
Desenhei uma operação regulada em que o algoritmo sugere e o hospital decide, sempre com o motivo à vista.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Pesquisa e mapeamento do domínio: estoque, necessidades e transferências
DesignMapa do problema: lote vencendo em um hospital e compra emergencial em outro
DesignBase de conhecimento do produto: produto, domínio, regulação, dados, IA, segurança e riscos
DesignTelas independentes e estudo de tipografia para telas compactas
DesignPiloto restrito após os gates jurídico, sanitário e patrimonial
Design03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
O algoritmo encontra o par e reserva por tempo limitado; quem autoriza são os dois hospitais.
Só transições adjacentes são aceitas; o servidor recusa saltos antes de gravar.
05Arquitetura
Leitura e escrita separadas: consultas vêm de um snapshot; comandos autenticados passam pelos serviços de domínio.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêMover medicamento entre instituições exige responsabilidade técnica e instrumento jurídico. A reserva evita dupla alocação sem antecipar uma autorização que o software não pode dar.
Por quêCrédito criaria dívida entre hospitais públicos, e pontos no ranking fariam o acesso depender de reputação. O índice reconhece sem interferir em quem recebe.
Por quêO hospital decide o que compartilhar; o restante do estoque continua privado e só alimenta as previsões dele.
Por quêDemanda hospitalar é intermitente. Mostrar a faixa e os fatores evita confiança falsa e deixa claro que a previsão apoia a decisão, não a substitui.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Testes
19 testesdomínio, renderização, interações e tipografia (node:test)Contrato
OpenAPI7 rotas e esquema versionado de eventoLegibilidade
1024 e 1366pxtextos de 7 a 10px substituídos por escala legívelDados
100% sintéticosnenhum dado pessoal real no seedFim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projetoDocumentação do processo
Fiz o design de produto: do mapa de módulos e do sistema visual às telas de login, painel, ponto de venda, estoque e cadastros, responsivas do desktop ao celular.
Protótipo para apresentação (2022) para uma rede de farmácias, cujo nome não é divulgado. Nome do produto, pessoas, laboratórios e números são fictícios.
01Papéis
Como atuei como Designer de Produto no sistema Fórmula, e o que entreguei.
Desenhei um sistema único para o balcão, o estoque e a gerência de uma rede de farmácias de bairro.
02Linha do tempo
Marcos do projeto e o papel que cada um exigiu.
Mapa de módulos da rede, grupos do menu e fluxos de venda e reposição
DesignSistema visual: cores com significado, tipografia e componentes
DesignPainel gerencial, ponto de venda, estoque, renovação e lista de reposição
DesignFormulários em seções e importação por CSV ou XML da nota fiscal
DesignProtótipo navegável para apresentação: rotas, componentes e gráficos
DesignLayouts responsivos em 1440, 1180, 820 e 390px e design system
Design03Fases
O que eu fiz em cada etapa e o que ficou de entregável.
04Fluxos
Jornadas e regras de negócio desenhadas antes das telas.
Quando o carrinho tem antimicrobiano ou controlado, a receita é registrada na própria venda e alimenta os relatórios.
Do alerta de mínimo à entrada do produto, com importação do XML da nota para não digitar de novo.
05Arquitetura
App de página única: rotas por módulo, componentes compartilhados e dados fictícios locais, prontos para trocar por uma API.
06Decisões
Dilemas de produto, as opções avaliadas e o porquê de cada escolha.
Por quêRegistrar depois cria uma segunda digitação e abre espaço para esquecimento. No balcão, com a receita na mão, o dado entra uma vez e alimenta o Registro de Receitas e os relatórios.
Por quêA gerente bate o olho na lista e vê o que está baixo ou crítico sem comparar números. Verde, âmbar e vermelho ficam reservados para a situação; roxo e azul-céu marcam controlados e antimicrobianos.
Por quêQuatro ou cinco botões do mesmo peso competem com a ação principal. Nos menus, cada formato ganha uma linha de explicação e a tela fica com uma única ação primária.
Por quêA gerente precisa de uma lista para o fornecedor, não só de um aviso. A Renovação filtra o que está abaixo do mínimo, sugere a quantidade e gera a relação em um clique.
Por quêNo balcão o celular é usado em pé e com pressa. Cards com rótulos e quatro atalhos fixos evitam rolagem lateral e alvos pequenos.
07Qualidade
Números agregados do processo. Dados de usuários, clientes e regras de negócio não são expostos.
Telas
17 telasem 19 rotas navegáveisResponsividade
4 larguras1440, 1180, 820 e 390px, sem rolagem horizontalAcessibilidade
Contraste AAfoco visível e rótulos em todos os camposDados
100% fictíciospessoas, laboratórios e números inventadosFim da documentação
Volte para a apresentação do design: interface, design system e fluxos de cada tela.
← Voltar para a apresentação do projeto