NFX

Regula.Já

Product DesignBackofficeSaúdeGovTechB2G
PapelProduct Designer (End-to-End)
Duração12 meses
PlataformasMobile • Desktop
FerramentasFigma, Google Workspace
Prévia da Solução - Regula.Já V5

Resumo

O Problema

A Secretaria Municipal de Saúde de Roteiro operava em caos operacional. O processo dependia de planilhas desconectadas e armazenamento de dados sensíveis em celulares pessoais (Shadow IT), violando a LGPD. Esse fluxo manual gerava 40 horas semanais de retrabalho e colocava em risco 6.000 vidas, com solicitações extraviadas por erros de sintaxe e falta de rastreabilidade.

O Desafio

Como único responsável técnico, sem orçamento e sem equipe de desenvolvimento, precisei traduzir demandas abstratas em uma solução viável. O desafio era duplo:

  • Manter a operação funcionando hoje (tático)
  • Desenhar a arquitetura do software definitivo (estratégico)

A Solução (Entrega Dupla)

Operação Tática (MVP Google Sheets) — REALIZADO: Reestruturei imediatamente os processos usando ferramentas no-code, centralizando dados e sustentando a operação por 12 meses. Resultado: Centralizou os dados, organizou o fluxo e mitigou o risco de perda de informações, sustentando a operação por 12 meses, embora não tenha resolvido o gargalo de tempo no processamento de imagens.

Especificação Técnica (Regula.Já V5): O desenho técnico e funcional de um sistema end-to-end, validado via protótipos de alta fidelidade e pronto para desenvolvimento, projetado para eliminar definitivamente os 18 problemas críticos de infraestrutura através de:

  • Estratégia de Continuidade Operacional para estabilizar a operação crítica antes do desenvolvimento final.
  • Automação de Processos projetada para eliminar 40 horas semanais de trabalho manual (foco em imagens e documentos).
  • Segregação de Dados (App Storage) para eliminar o armazenamento em celulares pessoais.
  • Validação de Input (Travas) para erradicar erros de digitação e rejeições técnicas.
  • Design System Gov.BR para garantir familiaridade imediata e legitimidade institucional.
  • Arquitetura de Informação para transformar dados desestruturados em inteligência de negócio.

O Resultado

A entrega de um pacote de especificação técnica e processo validado. Transformei o caos em um fluxo organizado via MVP e entreguei a Documentação Técnica de Referência incontestável do software V5. Isso garantiu que a Secretaria saísse da paralisia operacional e agora possua um projeto auditável, especificado e tecnicamente pronto para contratação de desenvolvimento, blindado contra riscos de escopo.

Contexto

O Contexto Político e Social

Roteiro é um município do interior de Alagoas com 6.664 habitantes. Em 2025, uma nova gestão assumiu a Secretaria de Saúde encontrando o setor sem qualquer estrutura para a regulação de exames médicos. Como único funcionário designado para a função, recebi uma diretriz puramente operacional:

"Seu cargo é Assistente Administrativo. Protocole os exames e gere listas semanais para enviar ao prefeito."

Não havia sistema, processos, treinamento ou equipe. Apenas a demanda urgente de centenas de cidadãos que dependiam desses exames para diagnóstico e tratamento.

Meu Papel

  • Product Manager (Estratégia): Gerenciar o roadmap de crise, definindo o que era crítico para o MVP (Google Sheets) funcionar imediatamente.
  • Liderança Técnica (Resourcefulness): Diante da falta de verba, recrutei e gerenciei um desenvolvedor parceiro em modelo colaborativo (voluntário), viabilizando as Provas de Conceito (PoC) técnicas nas fases iniciais.
  • Service Designer: Mapear e otimizar a jornada completa (do papel físico ao digital), eliminando gargalos operacionais.
  • UX Researcher: Conduzir imersão etnográfica e entrevistas para entender as dores reais dos servidores e cidadãos.
  • Compliance (LGPD): Definir políticas de restrição de acesso para mitigar o risco de dados expostos.
  • Information Architect: Estruturar a taxonomia de dados (SIA/SUS) para transformar informações soltas em bancos de dados organizados.
  • UX Designer: Desenhar fluxos de tarefas, wireframes e a arquitetura de interação focada em uso mobile.
  • UI Designer: Adaptar o Design System Gov.BR para interfaces de alta fidelidade, garantindo consistência visual.
  • Accessibility: Garantir contraste, áreas de toque adequadas e legibilidade para usuários com baixa visão.

Discovery: Pesquisa e Identificação de Problemas

Metodologia de Pesquisa

Para garantir que a solução atacasse as causas-raiz e não apenas os sintomas, conduzi uma investigação qualitativa e quantitativa utilizando:

  • Imersão Operacional: Atuei como operador do sistema in loco, vivenciando a rotina de trabalho para mapear fricções e nuances que não aparecem em relatórios gerenciais.
  • Entrevistas com Stakeholders: Conversei com a Secretária de Saúde, coordenadores, equipe operacional e pacientes para contrastar a "visão da gestão" com a "realidade da linha de frente".
  • Análise de Artefatos e Legado: Auditei planilhas antigas, documentos físicos e históricos de conversas para entender a lógica (e a falta dela) dos dados da gestão anterior.
  • Avaliação Heurística: Analisei a usabilidade das ferramentas improvisadas (Google Sheets e WhatsApp) para identificar violações de princípios de design e riscos de erro cognitivo.
Registro visual da metodologia de pesquisa 1
Registro visual da metodologia de pesquisa 2
Registro visual da metodologia de pesquisa 3
Registro visual da metodologia de pesquisa 4

Os 18 Problemas Críticos Identificados

Essa investigação profunda no fluxo de trabalho revelou um cenário de Alta Complexidade e Dívida Técnica Sistêmica, onde cada tentativa de solução manual criava novos bloqueios. Categorizei os 18 problemas identificados em 4 pilares:

Trabalhos Manuais e Lento

O processo dependia de montar arquivos "na mão" (copiar e colar fotos no Word), gerando demora, erros de digitação e rejeição dos exames pelo Estado.

Risco Jurídico e Dados

Armazenamento de documentos sensíveis em celulares pessoais violava LGPD, enquanto ausência de validação e inconsistência taxonômica geravam erros e duplicidades.

Falta de Controle e Métricas

A prefeitura operava sem dados para tomar decisões (não sabia a demanda real) e a equipe sofria com sobrecarga e mistura de vida pessoal com trabalho.

Dificuldade para o Cidadão

Para marcar um exame, o paciente precisava perder dia de trabalho e enfrentar filas, o que aumentava a desistência. A falta de avisos fazia muitos pacientes faltarem (No-Show), desperdiçando vagas.

Estratégia e Definição do Problema

Definição do Problema (HMW)

Após meses de imersão, reformulei o desafio central:

"Como poderíamos criar um sistema de regulação que elimine erro humano e retrabalho manual, garantindo segurança jurídica e rapidez, mesmo sendo operado por equipe com pouco conhecimento digital e infraestrutura limitada?"

Priorização de Funcionalidades (MoSCoW)

Must Have (Crítico):

  • Validação de Input (travas lógicas CNS/CPF)
  • Captura Segura (App Storage, sem salvar na galeria)
  • Automação Documental (geração automática de PDFs)
  • Listagem Otimizada (tabelas com paginação e filtros)

Should Have (Importante):

  • Módulo de Relatórios Gerenciais e BI
  • Envio automático via WhatsApp Web
  • Histórico e rastreabilidade de lotes

Could Have (Futuro):

  • App para ACS protocolarem na rua
  • Portal do Cidadão para autoatendimento

Won't Have (Fora do Escopo):

  • Integração API direta com sistema do Estado
  • Módulo de Telemedicina
Prévia de Funcionalidade - Tela 2
Prévia de Funcionalidade - Tela 33
Prévia de Funcionalidade - Tela 13
Prévia de Funcionalidade - Tela 17
Prévia de Funcionalidade - Tela 19
Prévia de Funcionalidade - Tela 21

Design e Prototipagem: (V1 → V5)

Minha trajetória com o Regula.Já não foi linear. Ela evoluiu conforme minha maturidade técnica crescia, apoiada por parcerias estratégicas, testes de campo e a necessidade de adaptação ao cenário de escassez.

Evolução do Regula.Já

V1 — O Protótipo (SaaS Cross-Platform)

Inicialmente, idealizei um ecossistema unificado que cobriria toda a jornada, incluindo features para o paciente protocolar exames de casa.

  • Status: Estrategicamente congelada. O escopo era vasto demais para a infraestrutura política imediata, mas as funcionalidades foram documentadas para implementação futura.
Mockup 1 da versão V1
Mockup 2 da versão V1
Mockup 3 da versão V1
Mockup 4 da versão V1
Mockup 5 da versão V1
Mockup 6 da versão V1
Mockup 7 da versão V1
Mockup 8 da versão V1
Mockup 9 da versão V1
Componentes da V1

V2 — Foco na Secretaria

Pivotamos para focar exclusivamente nas dores da Secretaria. Nasceu uma versão de "Design Funcional", focada em resolver o problema real.

  • A Prova de Conceito (Código): Graças à colaboração com um desenvolvedor voluntário, a V2 ultrapassou a fase de Figma e ganhou um protótipo físico mobile funcional.
  • Entrega Técnica: Implementamos banco de dados real, sistema de anexos e sincronização em nuvem. Essa versão foi para produção em testes de campo e provou que a lógica do sistema funcionava, mas a interface ainda carecia de familiaridade para os usuários.
Mockup 1 da versão V2
Mockup 2 da versão V2
Mockup 3 da versão V2
Mockup 4 da versão V2
Mockup 5 da versão V2
Mockup 6 da versão V2
Mockup 7 da versão V2
Mockup 8 da versão V2
Componentes da V2

V3 — Redesign com Gov.BR e a Solução Tática

Realizei um redesign completo integrando o Design System do Gov.BR.

  • Decisão Estratégica: Como os funcionários já operam sistemas do SUS (CADSUS/SIA), alinhar o Regula.Já a esse padrão visual reduziu a curva de aprendizado.
  • Validação: Assim como a V2, esta versão também contou com um protótipo físico funcional desenvolvido pelo parceiro, sendo elogiada unanimemente nos testes.
Mockup 1 da versão V3
Mockup 2 da versão V3
Mockup 3 da versão V3
Mockup 4 da versão V3
Mockup 5 da versão V3
Mockup 6 da versão V3
Mockup 7 da versão V3
Mockup 8 da versão V3
Componentes da V3

O Pivô Necessário: A Solução Tática (Google Sheets)

Apesar do sucesso dos protótipos V2/V3, ao pesquisar, descobri que enfrentaríamos impedimentos de Compliance e Contratação Pública: a Prefeitura exigiria uma contratação formal de uma empresa e com a falta de orçamento para contratação oficial do desenvolvimento, precisei criar uma solução intermediária de forma imediata.

  • A Decisão Estratégica: Para não deixar a secretaria parar enquanto eu perderia tempo com burocracias e licitações (o que poderia levar anos), migrei a lógica para o Google Sheets. Era uma ferramenta "permitida", estável e que eu podia controlar.
  • O Problema da LGPD: Embora não fosse a solução ideal de segurança, restringi o acesso da planilha a apenas duas contas (eu e a funcionária chave), centralizando dados que antes ficavam dispersos no Excel e WhatsApp.
  • O Problema Operacional: Convenci a gestão estadual a aceitar dados em formato de colunas (Planilha) em vez de cards visuais. Isso resolveu a organização e contagem de dados, mas o processamento de imagens (fotos dos exames) e a criação dos PDFs continuaram manuais (Word), consumindo horas da equipe.
Tela do MVP desenvolvido na V3

V4 — Refinamento Visual e Conformidade Gov.BR

Embora a estrutura funcional da V3 estivesse correta, os testes revelaram problemas sutis de contraste e inconsistência nos tokens de cor, além da persistência do layout em Cards (herança da visão original dos stakeholders).

Reconheci que, na primeira aplicação do Design System, falhei em manter a fidelidade aos tokens. Voltei à documentação técnica não apenas para corrigir o contraste, mas também realizei ajustes significativos nos componentes, reconstruindo-os para garantir conformidade estrita com o padrão Gov.BR e acessibilidade.

  • Resultado: Implementei consistência visual e padrões semânticos claros. Isso reduziu o esforço cognitivo, mas a estrutura de listagem (Cards) ainda se mostrava ineficiente para a densidade de dados.
Mockup 1 da versão V4
Mockup 2 da versão V4
Mockup 3 da versão V4
Mockup 4 da versão V4
Mockup 5 da versão V4
Mockup 6 da versão V4
Mockup 7 da versão V4
Mockup 8 da versão V4
Mockup 9 da versão V4
Mockup 10 da versão V4
Mockup 11 da versão V4
Componentes da V4

V5 — A Maturidade do Produto (Especificação Final)

Com a iminência da contratação externa e o colapso de performance dos computadores antigos em 2026, desenvolvi a V5 para servir como a Documentação Técnica Definitiva e provar que a inteligência do sistema pertence ao Design, independentemente de quem vá codificar.

Esta versão representa uma reconstrução baseada em usabilidade de alta densidade para solucionar os gargalos que o Google Sheets e a V4 não resolveram:

  • Mudança Estrutural (Cards vs. Tabelas): Identifiquei que a listagem em Cards (V4), embora bonita, gerava poluição visual, scroll infinito e baixa performance no mobile.
  • Decisão de Design: Substituí por Tabelas de Alta Densidade com paginação controlada (10/15/30/50/100 itens). Isso eliminou o ruído visual e otimizou a leitura vertical (escaneabilidade).
  • Otimização de Interação (Ações em Massa): Implementei padrões nativos mobile para agilizar a rotina.
  • Modo de Seleção: O uso de Long Press (pressionar e segurar) na linha do paciente ativa a seleção múltipla (Checkboxes), permitindo executar comandos em lote (Imprimir, Confirmar, Enviar) via menu flutuante.
  • Automação Documental: Redesenhei o fluxo crítico. O sistema agora compila os pacientes selecionados e gera o PDF do lote em segundos.
  • Inteligência de Dados (BI): Projetei dashboards automáticos (Visão Quantitativa) para substituir a contagem manual, permitindo à gestão justificar pedidos de verba com dados reais.

Resultado da V5: Um protótipo em Figma de altíssima fidelidade, que simula todas as interações e permite cronometrar fluxos complexos como a automação de mensagens em massa, dispensando a necessidade imediata de código para validação de usabilidade.

Mockup 1 da versão V5
Mockup 2 da versão V5
Mockup 3 da versão V5
Mockup 4 da versão V5
Mockup 5 da versão V5
Mockup 6 da versão V5
Mockup 7 da versão V5
Mockup 8 da versão V5
Mockup 9 da versão V5
Mockup 10 da versão V5
Mockup 11 da versão V5
Mockup 12 da versão V5
Mockup 13 da versão V5
Mockup 14 da versão V5
Mockup 15 da versão V5
Mockup 16 da versão V5
Mockup 17 da versão V5
Mockup 18 da versão V5
Mockup 19 da versão V5
Mockup 20 da versão V5
Mockup 21 da versão V5
Mockup 22 da versão V5
Mockup 23 da versão V5
Mockup 24 da versão V5
Mockup 25 da versão V5
Mockup 26 da versão V5
Mockup 27 da versão V5
Mockup 28 da versão V5
Mockup 29 da versão V5
Mockup 30 da versão V5
Mockup 31 da versão V5
Mockup 32 da versão V5
Mockup 33 da versão V5
Componentes 1 da V5
Componentes 2 da V5
Componentes 3 da V5
Componentes 4 da V5
Componentes 5 da V5

Desktop: Eficiência e Uso Prolongado

Com a versão mobile finalizada e documentada, iniciei a transição do sistema para o ambiente Desktop. Esta versão foi projetada especificamente para quem gerencia o grande volume diário de exames. Ela herda todas as funcionalidades originais, mas traz como diferencial o feedback visual em tempo real das ações, reduzindo a carga cognitiva durante cadastros em lote. Outro grande destaque é a flexibilidade na captura de documentos: além da integração direta com scanners dedicados e impressoras multifuncionais, o sistema conta com o Handoff de Câmera (Cross-Device). Assim, o operador pode usar os equipamentos da mesa ou sincronizar o celular instantaneamente para usá-lo como scanner portátil, enviando a imagem direto para o Desktop sem nenhuma transferência manual de arquivos.

Mockup Desktop 1 da versão V5
Mockup Desktop 2 da versão V5
Mockup Desktop 3 da versão V5
Mockup Desktop 4 da versão V5
Mockup Desktop 5 da versão V5
Mockup Desktop 6 da versão V5
Mockup Desktop 7 da versão V5

Validação e Testes de Usabilidade

Para validar a solução V5 antes do desenvolvimento, conduzi testes de Benchmarking Comparativo com Linha de Base Tripla: Processo Manual (Caos) vs. MVP (Sheets) vs. Protótipo Regula.Já (V5).

Metodologia de Testes

Abaixo, evidencio como o MVP resolveu a organização, mas a V5 é necessária para resolver o gargalo de tempo (Imagens e PDFs).

Organização de Dados

Caos ManualCards no Excel
MVP Google Sheets (Realizado)Colunas e Filtros centralizados
Regula.Já - V5 (Projetado)

Banco de Dados Relacional

Tempo de Lote (Imagens)

Caos Manual~3 horas (Word)
MVP Google Sheets (Realizado)~2 horas (ainda manual)
Regula.Já - V5 (Projetado)

~3 minutos (automação)

Segurança (LGPD)

Caos ManualCrítica (WhatsApp/Galeria)
MVP Google Sheets (Realizado)Acesso restrito. Ainda com WhatsApp + Galeria
Regula.Já - V5 (Projetado)

Protegido (App Storage + bloqueio de screenshot)

Comunicação (No-Show)

Caos ManualLigações um-a-um
MVP Google Sheets (Realizado)Ligações um-a-um
Regula.Já - V5 (Projetado)

Disparo em massa (WhatsApp API)

Nota: O tempo da V5 (3 min) refere-se ao tempo de interação de UI mensurado no protótipo (1min 45s) somado a uma estimativa técnica de latência de servidor para processamento de imagens.

Impacto Projetado

Impacto Operacional (Eficiência)

  • ROI de Tempo: Redução projetada de 40+ horas semanais de trabalho manual

  • Proteção de Dados: Validação automática de CNS/CPF garante integridade da base

  • Saneamento Financeiro: Sistema impede duplicidade de solicitações

Impacto Jurídico

  • Mitigação LGPD: Captura in-app com App Storage privado + bloqueio de screenshot

  • Auditabilidade: Logs completos criam defesa contra acusações de favorecimento

Impacto Social (Acesso e Cidadania)

  • Democratização: Remove barreira econômica do deslocamento físico

  • Segurança Sanitária: Digitalização reduz aglomerações e risco de transmissão

Impacto em Saúde Pública

  • Planejamento Baseado em Evidências: Dashboards eliminam gestão por "chute"

  • Redução de Absenteísmo: Automação de notificações visa reduzir esquecimento de datas

Impacto de Negócio e Métricas (Framework HEART)

Para traduzir as decisões de design em valor real para a gestão municipal, projetei os impactos operacionais utilizando o framework Google HEART, adaptado para o contexto de produtos internos (B2E/GovTech):

H - Happiness (Satisfação & Saúde)

  • O Problema: A equipe sofre com processos manuais repetitivos, gerando alta carga cognitiva e risco de burnout.

  • Impacto: A automação da "Geração de Lotes" elimina a tarefa mais estressante da operação.

  • Métrica: Manutenção do System Usability Scale (SUS) acima de 85 pontos e redução qualitativa nos relatos de fadiga operacional.

E - Engagement (Padronização)

  • O Problema: Uso de processos não oficiais, como planilhas paralelas e WhatsApp ("Shadow IT").

  • Impacto: O sistema centraliza a operação e torna as soluções improvisadas obsoletas pela facilidade de uso.

  • Métrica: 100% dos protocolos realizados exclusivamente dentro da plataforma nos primeiros 30 dias.

A - Adoption (Expansão)

  • O Problema: Agentes Comunitários de Saúde (ACS) não possuem ferramentas digitais em campo.

  • Impacto: Inclusão digital dos ACS, permitindo que protocolem exames diretamente das visitas domiciliares.

  • Métrica: Cadastro ativo e utilização por 60% da força de trabalho de ACS no primeiro mês do módulo mobile.

R - Retention (Retenção Voluntária)

  • Contexto: Sendo um sistema corporativo obrigatório, a retenção é "forçada". O foco aqui é medir a preferência do usuário.

  • Métrica de Sucesso: Zero solicitações para retornar ao método legado (Google Sheets/Word) após o período de adaptação.

T - Task Success (Eficiência Operacional)

  • A Grande Vitória: O ROI do projeto está no tempo economizado com burocracia.

  • Métrica: Otimização de 98% na tarefa principal (economia de 2h58min por lote). O sistema devolve dezenas de horas produtivas mensais.

Entregáveis Técnicos (Handoff)

Preparei pacote completo de especificação técnica para garantir fidelidade durante desenvolvimento externo:

  • Protótipo Navegável (Figma) com fluxos completos (Mobile/Desktop)
  • User Stories & Critérios de Aceite
  • Documentação de Regras de Negócio e Lógica (ex: algoritmos de validação CNS/CPF)
  • Design System & Tokens (baseado em Gov.BR)
  • Guia de Acessibilidade (ordem de tabulação, etiquetas ARIA)
  • Assets Otimizados (ícones e ilustrações em múltiplas resoluções)

Aprendizados

Imersão Operacional: Trabalhar dentro do sistema me deu insights invisíveis a consultores externos. Nenhum relatório substituiria vivenciar a rotina operacional.

Design como Processo Vivo: A evolução V1 (SaaS) → V3 (MVP Tático) → V5 (Produto Maduro) provou que resolver o problema do usuário (mesmo com planilhas) vem antes do código.

Força do Padrão (Gov.BR): Adotar Design System consolidado acelerou decisões e garantiu confiança institucional.

Inovação sob Restrição Extrema: Falta de orçamento exigiu criatividade (uso de voluntários e ferramentas gratuitas) para manter serviço funcionando enquanto projetava solução final.

Gestão de Resistência: Descobri que a melhor forma de vender mudança é com protótipos funcionais que mostram benefício imediato.

Conclusão

O Regula.Já é a materialização de 12 meses de atuação em ecossistema complexo.

Este case demonstra minha capacidade de entregar:

  • Investigação Profunda: Identificação de 18 problemas estruturais
  • Visão Estratégica: Alinhamento de design com eficiência operacional e impacto social
  • Rigor Técnico: Especificação completa (Handoff) baseada em conformidade normativa (WCAG, LGPD)
  • Validação Baseada em Dados: Uso de métricas (SUS, ROI de tempo) para guiar decisões

Mais importante: este projeto prova que Design é infraestrutura. É sobre transformar caos em ordem e ineficiência em impacto. O Regula.Já é a Documentação Técnica de Referência aprovada e validada para mudar a vida de 6.664 cidadãos de Roteiro.