Firmware é UX

Existe um tipo de projeto de hardware que engana: eletronicamente é maturidade, e humanamente é protótipo. O NeuroPulse viveu nesse estado por um ano. A segunda revisão da placa fazia tudo que eu queria — corrente controlada, bifásica, limitador de carga por fase com cut analógico — e nenhum terapeuta conseguia usar sem mim do lado.

O diagnóstico foi humilhante na medida certa. O dispositivo tinha um menu com 11 níveis. Eu tinha projetado o menu para mim: cada parâmetro de estimulação (frequência, largura de pulso, rampa, limite de carga) acessível, com display e navegação por botão. Tecnicamente impecável. Do ponto de vista de um fisioterapeuta com paciente na maca, era um formulário de imposto de renda com corrente elétrica no final.

A lição que ficou: em instrumentação embarcada, UX não é a capa do firmware — é a decisão de o que o usuário precisa decidir. Um terapeuta não quer ajustar 11 parâmetros; quer protocolos nomeados (“fortalecimento de deltóide”, “prevenção de subluxação”) que ele confia e, no máximo, escala de intensidade. O especialista mora na receita, não no knob. A terceira revisão do NeuroPulse saiu com três controles físicos (intensidade, início/pausa, seleção de protocolo) e um cartão SD onde os protocolos moram como arquivos texto editáveis.

Isso mudou a hierarquia do projeto inteiro. O firmware perdeu o menu e ganhou um parser de arquivo de protocolo — que é muito mais fácil de testar. A segurança melhorou de graça: com três knobs, é possível fazer o dispositivo se recusar a rodar qualquer protocolo com limite de carga acima do calculado pela área do eletrodo, sem que ninguém precise saber da regra. A regra mora no arquivo; o dispositivo apenas se recusa a violar.

O que eu escreveria para o eu de um ano atrás: o firmware não serve a placa — serve a mão que aperta o botão. As 1.900 linhas de C que sobraram são mais fáceis de manter que as 3.400 de antes, e a interface melhorou porque ficou menor. Toda vez que um recurso de dispositivo exige manual, o manual é o bug.