Norius
O Norius é a plataforma de monitoramento IoT da NETZSCH do Brasil: sensores, reservatórios, bombas, alarmes, operação remota, hospedada no Thingsboard. Redesenhei dois tenants do zero com uma descoberta estruturada, um design system e um protótipo navegável pra validação com o cliente.
- 33
- Famílias de componentes no Storybook
- 179
- Stories documentadas
- 81
- Tokens de cor
Desafio
Dois tenants (Pomerwasser e Capixaba Energia) rodavam em doze telas divergentes, cada uma resolvendo a mesma coisa de um jeito diferente. Pressão, nível de tanque e severidade de alarme apareciam em lugares diferentes com padrões incompatíveis. Não havia design system nem nada reutilizável. O ponto de partida era o Thingsboard cru: funcionalmente correto, visualmente datado e carente da acessibilidade e da consistência que um ambiente industrial precisa.
O cliente precisava de uma interface que um operador de campo pudesse usar num tablet sob 4G fraco, sem retreinamento por tenant.
Abordagem
Comecei com uma descoberta estruturada: inventariei as doze telas na mão, cataloguei 42 componentes pequenos que já estavam na UI e escrevi 15 problemas de usabilidade ordenados por prioridade. Isso alimentou as decisões: colapsar doze telas em seis templates, usar Atomic Design pra montar tudo a partir de peças pequenas reutilizáveis, e servir os dois tenants a partir de um conjunto compartilhado de tokens e chaves simples de liga/desliga em vez de duplicar tela por tela.
Em vez de só desenhar no Figma, construí o design system em código ao mesmo tempo. Storybook com React e Tailwind 4, uma story por componente, e docs com orientação de faça e não faça. No fim da fase de design, 30 componentes tinham implementações reais, 155 stories e 115 testes passando. Também construí um protótipo clicável separado pra que o cliente pudesse percorrer o fluxo antes de uma linha de código de produção.
Resultado
O cliente tem um design system funcional com um Storybook hospedado, 51 páginas de Figma espelhando os componentes, e um protótipo navegável que cresceu pra um pequeno produto: dashboard com sparklines de reservatório ao vivo, mapa de equipamentos completo com painel de dispositivos filtrado por status, telas de ETA por reator com gráficos em tempo real, um inventário de dispositivos, filas de alarme, e um registro de eventos que audita cada ação do operador. Tudo em inglês, pronto pra validação com o cliente.
Três princípios atravessam tudo: a severidade do alarme se lê por forma e cor, não só por cor; os gráficos de série temporal usam segmentos retos, não curvas suavizadas; ações destrutivas como parar uma bomba exigem um motivo digitado.
Pra quem eu desenhei
Três pessoas com relações diferentes com o mesmo dado.
O operador de campo trabalha de um tablet, às vezes sob 4G fraco, e precisa confirmar se uma bomba está rodando ou qual alarme disparou. Sem tempo pra explorar, então a resposta tem que estar visível.
O supervisor de operações lê o site inteiro pelo mapa antes de mergulhar num ponto. O engenheiro de manutenção precisa de horímetros, histórico de partidas e configuração de limiares pra diagnóstico, uma profundidade que não deve ficar no caminho do operador.
Os dois tenants complicam: a Pomerwasser monitora reservatórios e química da água, a Capixaba monitora pressão e potência de bomba. Dados diferentes, interface compartilhada.
A decisão-chave: um sistema, não dois produtos
O caminho tentador eram dois produtos, um por tenant. Escolhi um design system com as diferenças controladas por tokens e feature flags.
A Pomerwasser não precisa de um medidor de pressão; a Capixaba não precisa de indicadores de flúor. Mas as duas precisam que o card de alarme, o header de dispositivo, a sidebar, o mapa e o card de KPI se comportem de forma idêntica. Dividir os produtos dobraria a manutenção sem benefício nenhum pro usuário. Então os componentes em cada tela dos dois tenants viraram a base inegociável, e as peças específicas de cada tenant se encaixam via flags sem tocar no resto.
O design system vive no código
O design system do Norius não é uma biblioteca de Figma com boas intenções sobre implementação. É um Storybook rodando: 33 famílias de componentes, 179 stories documentadas, cada story com controles, checagens de acessibilidade e docs em MDX que dizem quando usar o componente e quando não.
A peça de vitrine é o RealtimeAreaChart, o gráfico de eixo duplo por trás das telas de ETA: nível e pressão em eixos opostos, marcadores de limiar, um navegador de intervalo, onze props configuráveis. Ele existe de forma idêntica no Figma (como componente que o cliente revisa) e no código (como a coisa que o dev entrega). Os componentes de domínio carregam o peso industrial: cards de tanque com dez estados documentados, fileiras de medidores pra pressão e vazão, cards de alarme em sete variantes de severidade e estado.
O que não foi bem
A descoberta me mostrou que parte da UX estranha da plataforma original era, na verdade, racional quando você entendia o contexto operacional. Redesenhei dois padrões de interação antes de perceber que o problema não era o padrão, era o contexto visual ausente que o deixava confuso. Isso custou alguns dias.
O protótipo também cresceu pra além do briefing. Começou como cinco telas pro cliente clicar e virou um pequeno produto: mapa de equipamentos, inventário de dispositivos, registro de eventos, telas de ETA por reator, controles de operação remota. Valeu a pena (o cliente deu feedback específico em vez de aprovar frames estáticos), mas o escopo passou do que o contrato cobria.
Telas selecionadas
" Construir o design system em código junto com o Figma é a decisão que eu tomaria de novo sem hesitar. Escrever as docs em MDX forçou respostas pra perguntas que o Figma nunca faz, tipo quando um componente não deve ser usado, ou qual é o comportamento dele no erro. Essas respostas são exatamente o que o handoff pro dev precisa. "
TechCo.lab
→Stack inteira nas mãos do designer. Do conceito à URL no ar com Figma Make + vibe coding.