Design de serviços governamentais baseado em eventos de vida

Uma mãe sai da maternidade com o bebê nos braços e uma lista de tarefas que nenhuma lei obriga a existir: registrar o nascimento em um cartório, solicitar o cartão de saúde em outro balcão, atualizar o imposto de renda, pedir o auxílio-natalidade em um terceiro sistema, trocar o endereço no cadastro escolar futuro. Nenhum desses passos nasce da vida da família. Todos nascem do organograma do Estado.

É esse o problema que o desenho de serviços por eventos de vida tenta resolver. A tese é simples de enunciar e difícil de executar: o governo deveria organizar seus serviços em torno dos acontecimentos que as pessoas realmente vivem — nascer, casar, perder o emprego, abrir uma empresa, se aposentar — e não em torno das secretarias e ministérios que os administram. Quando essa inversão não acontece, o custo da fragmentação recai inteiramente sobre o cidadão, no momento em que ele tem menos energia cognitiva para pagá-lo.

O que é desenho de serviços por eventos de vida?

Desenho de serviços por eventos de vida (life-event based service design) é a prática de agrupar e sequenciar serviços públicos de acordo com um acontecimento significativo na vida do cidadão — e não de acordo com a estrutura administrativa que os produz. Em vez de "Formulário 27-B da Secretaria de Registro Civil" e "Formulário 14-A da Secretaria de Saúde", o cidadão encontra um único fluxo: "Tive um filho". Por trás da interface, os sistemas continuam separados; na frente, a experiência é uma só.

A definição importa porque ela desloca a pergunta de design. A pergunta deixa de ser "como digitalizamos este formulário?" e passa a ser "o que essa pessoa está realmente tentando resolver esta semana, e quantas dessas etapas podemos eliminar, unificar ou automatizar?". É a diferença entre digitalizar a burocracia e redesenhar o serviço.

Por que a lógica do organograma trai o cidadão?

Porque nenhum cidadão vive dentro de uma secretaria. A estrutura funcional do Estado — um ministério para saúde, outro para trabalho, outro para fazenda — existe para organizar orçamento, competência técnica e prestação de contas. É uma lógica de produção, feita para quem opera o sistema. O cidadão, por outro lado, vive em eventos: tem um filho, muda de cidade, fica desempregado, herda um imóvel. Cada evento atravessa cinco, dez, quinze órgãos diferentes, e cada órgão pede provas que outro órgão já possui.

Essa dissonância tem nome em desenho de serviços: é a diferença entre a jornada organizada pela oferta e a jornada organizada pela demanda. Um mapeamento de jornadas do cidadão feito a partir do evento de vida — e não a partir do processo interno — costuma revelar que metade das etapas de um trâmite existe apenas para que um órgão confirme uma informação que outro órgão já validou. Isso não é rigor administrativo. É fricção que sobrevive porque nunca foi medida do ponto de vista de quem a atravessa.

A Recomendação sobre Estratégias de Governo Digital da OCDE, adotada pelo Conselho da organização em 2014, já apontava esse mesmo diagnóstico: governos digitais eficazes são aqueles desenhados a partir das necessidades do usuário, e não a partir da estrutura interna das agências que prestam o serviço. Mais de dez anos depois, a maioria das plataformas de governo digital ainda espelha o organograma, não a vida das pessoas.

Como isso funciona na prática: três exemplos reais

A teoria convence pouco sem exemplo operacional. Três casos mostram como o princípio se traduz em sistema.

• Registro automático de nascimento na Estônia. Segundo a iniciativa oficial de governo digital do país, descrita em e-Estonia, quando uma criança nasce em um hospital estoniano, o próprio hospital registra o nascimento eletronicamente e os dados alimentam automaticamente os sistemas de saúde e de benefícios familiares — os pais não precisam abrir um processo à parte para que o Estado saiba que uma criança nasceu. O evento de vida dispara o serviço; o cidadão não precisa solicitá-lo.
• Organização por "situações de vida" no portal dinamarquês. O borger.dk, portal oficial de serviços ao cidadão da Dinamarca, estrutura seu conteúdo em torno de situações como ter um filho, se mudar ou ficar desempregado, em vez de listar serviços por ministério. A navegação segue a pergunta do cidadão, não a competência do órgão.
• "Tell Us Once" no Reino Unido. Lançado nacionalmente em 2011 pelo governo britânico e descrito nas páginas oficiais do GOV.UK, o serviço permite que uma família, após um falecimento, informe o óbito uma única vez — e essa informação é distribuída automaticamente para os órgãos de previdência, tributação, carteira de motorista e outros cadastros relevantes. Antes do serviço, o mesmo dado precisava ser repetido a até 44 organizações diferentes.

Os três casos compartilham o mesmo mecanismo: o Estado assume o custo de coordenação interna para que o cidadão, no momento mais vulnerável do evento — nascimento, luto, desemprego —, não precise carregá-lo.

Qual o papel da arquitetura de escolha e do "sludge" nesse desenho?

Aqui entra a economia comportamental, e ela não é decoração — é o mecanismo que explica por que tantos trâmites sobrevivem sem necessidade. O economista Richard Thaler cunhou o termo sludge para descrever a fricção administrativa desnecessária: etapas, formulários e esperas que não protegem ninguém, apenas desgastam quem precisa do serviço. O jurista Cass Sunstein desenvolveu o conceito em profundidade no livro Sludge: What Stops Us from Getting Things Done and What to Do about It (MIT Press, 2021), argumentando que reduzir sludge deveria ser tratado com o mesmo rigor com que se reduz um imposto — porque, para quem o enfrenta, o efeito é equivalente.

Um trâmite que exige que o cidadão comprove, em três repartições diferentes, um dado que o próprio Estado já possui é sludge puro. Cada campo de formulário repetido, cada carimbo redundante, cada visita presencial evitável é fricção com custo real e sem benefício correspondente — a definição de sludge que qualquer equipe de desenho de serviço deveria usar como filtro. Isso é diferente da fricção que Thaler chama de "boa fricção": um período de reflexão antes de assinar um contrato de crédito imobiliário protege o cidadão. Pedir a mesma certidão de nascimento pela quinta vez não protege nada.

A arquitetura de escolha entra na decisão do que é padrão. Se, por padrão, o sistema pré-preenche o formulário de auxílio-natalidade com os dados que a maternidade já enviou, a decisão racional e de menor esforço para o cidadão é aceitar o padrão — e ele o fará, porque a maior parte do comportamento humano segue o caminho de menor resistência, o que Kahneman descreveria como pensamento de Sistema 1 operando sobre uma opção já pronta. Desenhar o padrão certo, no evento de vida certo, vale mais do que qualquer campanha de conscientização para aumentar a adesão a um benefício.

Como mapear um evento de vida do zero: um método em seis passos

Redesenhar um serviço público em torno de um evento de vida não é um exercício de branding de portal. É um trabalho de mapeamento, negociação interinstitucional e priorização. Um roteiro que funciona na prática segue esta sequência:

1. Escolha o evento, não o serviço. Comece por "perder o emprego" ou "abrir um pequeno negócio", nunca por "modernizar o sistema de seguro-desemprego". O evento força a visão de ponta a ponta; o serviço isolado reforça o silo.
2. Reconstrua a jornada real, com dados e não com suposições. Entreviste cidadãos que passaram pelo evento nos últimos meses, levante os registros de atendimento presencial e digital, e monte um blueprint de serviço que mostre cada etapa, cada órgão envolvido e cada documento exigido.
3. Marque os pontos de repetição de dados. Toda vez que um dado pedido em uma etapa já existe em um sistema visitado numa etapa anterior, marque como candidato à eliminação. Essa lista é o mapa do sludge a remover.
4. Identifique os momentos de maior carga emocional. Em eventos como luto, desemprego ou doença grave, há um ou dois momentos em que a decisão do cidadão está mais vulnerável ao desgaste — são os momentos de verdade do evento, e é ali que a regra do pico-fim de Kahneman deve orientar o desenho: a etapa mais difícil e a etapa final determinam como toda a experiência será lembrada, então proteja essas duas antes de qualquer outra.
5. Negocie a integração de dados entre órgãos antes de desenhar a interface. Uma tela bonita sobre sistemas que não conversam entre si só transfere a fricção do papel para a tela. A integração de backend é o verdadeiro projeto; o portal é a vitrine.
6. Lance com um piloto mensurável e publique os números. Meça tempo médio de conclusão, número de visitas presenciais evitadas e taxa de abandono antes e depois. Sem esse contraste, não há como defender o investimento perante quem controla o orçamento seguinte.

Esse método se apoia em uma ferramenta que já existe na caixa do desenho de serviços tradicional — o blueprint —, mas aplicada com uma disciplina que a maioria das repartições públicas ainda não pratica: medir o custo de cada etapa do ponto de vista de quem a atravessa, não de quem a exige. É o mesmo raciocínio por trás de uma boa estratégia de desenho de serviço: separar o que é essencial do que é herança institucional.

Quais armadilhas destroem projetos de eventos de vida?

A maioria dos projetos de governo digital que tentam adotar essa lógica falha nos mesmos pontos, e vale a pena nomeá-los antes de começar:

• Digitalizar o formulário em vez de eliminar a etapa. Transformar um processo em PDF em um processo em app não remove o sludge — apenas o torna mais rápido de repetir.
• Ignorar quem não tem acesso digital. Um evento de vida como perda de emprego afeta desproporcionalmente pessoas com menos recursos e, muitas vezes, menos familiaridade digital. Um desenho que assume conectividade universal exclui exatamente quem mais precisa do serviço.
• Tratar a integração de dados como um problema de TI, e não de governança. A barreira raramente é técnica. É o órgão A que não quer perder controle sobre "seu" dado para o órgão B. Sem patrocínio político explícito, a integração nunca sai do papel.
• Medir sucesso pelo número de serviços "disponíveis online" em vez de pelo tempo e esforço reais do cidadão. Um portal pode ter cem serviços digitalizados e ainda exigir que o cidadão visite três repartições físicas para completar um único evento de vida.
• Lançar sem canal de escalonamento humano. Todo evento de vida tem uma cauda de casos excepcionais — famílias monoparentais, documentos perdidos, situações jurídicas atípicas. Sem uma estratégia de escalonamento clara, esses casos ficam presos em um fluxo automatizado que não foi desenhado para eles.

Como medir se o redesenho por evento de vida está funcionando?

A métrica mais honesta não é satisfação declarada — é esforço observado. Tempo total para concluir o evento, número de vezes que o cidadão precisou repetir o mesmo dado, número de visitas presenciais eliminadas, e taxa de conclusão sem abandono no meio do caminho. Essas quatro métricas juntas contam mais sobre a qualidade do redesenho do que qualquer pesquisa de satisfação pós-atendimento, porque capturam a fricção estrutural, não apenas a impressão do momento.

Vale também acompanhar o indicador que a maioria dos governos ignora: quantos órgãos diferentes o cidadão precisou contatar para resolver o evento do início ao fim. Um evento de vida bem desenhado tende a esse número para um — mesmo que, por trás da interface, continuem existindo cinco sistemas distintos trabalhando em conjunto. Ferramentas de diagnóstico de maturidade, como a avaliação de maturidade de CX, ajudam a situar em que estágio dessa integração o órgão realmente se encontra, antes de prometer prazos que a estrutura interna não sustenta.

Vale lembrar, ainda, que confiança institucional não se recupera com uma campanha de comunicação — ela se constrói exatamente nos pontos de atrito que o desenho por evento de vida se propõe a eliminar, como já argumentamos ao tratar da confiança que se constrói no balcão, não na campanha. O mesmo raciocínio vale para a primeira experiência de qualquer serviço público, um momento tão decisivo quanto o onboarding de linha de frente no setor privado.

O evento de vida como unidade de planejamento, não como campanha de portal

O erro mais caro que um governo pode cometer aqui é tratar o evento de vida como uma camada de apresentação — um menu bonito sobre a mesma burocracia de sempre. O evento de vida só funciona como princípio organizador quando se torna a unidade de planejamento orçamentário e de governança, o critério pelo qual se decide o que integrar primeiro e quem responde por quê. Isso exige patrocínio de alto nível, uma estratégia de governança de CX que atravesse secretarias, e a disposição de medir o serviço pela experiência de quem o vive, não pela conveniência de quem o administra.

Nenhum órgão público redesenha cem eventos de vida ao mesmo tempo. O caminho realista é escolher um, o de maior volume ou maior vulnerabilidade — nascimento, desemprego, luto —, provar que a integração funciona, publicar os números, e usar esse piloto como mandato político para o próximo. É assim que a lógica do cidadão, e não a lógica do organograma, deixa de ser um slogan de discurso de posse e passa a ser a arquitetura real do Estado.