Um terminal compacto em fase de certificação.

Eu poderia ter posto screenshot, render, foto de casing. Optei por não pôr. Um projeto antes do lançamento é território da empresa, não meu — e portfolio público é o lugar errado pra adiantar uma narrativa que o time de marketing ainda não escreveu.

O que sobra aqui é o que é meu: a forma de pensar. Decisões de hierarquia. Critério escrito. Restrição como matéria-prima. Isso eu posso defender em qualquer mesa, sem precisar mostrar o produto.

Em produto puramente digital o designer começa pela tela e desce até o sistema. Em produto físico-digital a ordem inverte: o chassi chega antes da decisão de design. Largura, profundidade, posição da impressora térmica, da câmera, do leitor, da bateria — vêm da engenharia. Display nessa categoria não é uma escolha de layout; é o que sobra depois de tudo o que não pode mudar.

Meu trabalho não é redesenhar o chassi. É tratar a restrição como matéria-prima. Cada milímetro de tela é caro; cada toque na borda é um toque a menos no centro. A hierarquia da UI nasce da geometria do dispositivo, não de uma grid de Figma.

A primeira decisão escrita do projeto foi essa: a tela carrega menos do que uma tela equivalente no app. Não porque o usuário é diferente, mas porque o tempo de uso é. Lojista em pico de fila tem dois segundos por interação. Tudo que não couber em dois segundos vai pro app, que ele consulta depois.

Time de hardware desenha em um software. Time de app desenha em outro. Os dois conversam por reunião — e a reunião nunca cobre o caso onde a câmera olha pra um lado e a UI presume o outro. A integração precisava virar artefato, não pauta.

O que fiz: trouxe a planta do chassi pro mesmo arquivo de Figma do app, em escala 1:1. Toda decisão de hierarquia digital passou a conviver com a forma física no mesmo canvas. Isso parece bobo. Não é. Quando o eng. firmware precisa entender por que um botão de 44px tá colado na quina, ele vê a quina. Quando eu preciso explicar por que a hierarquia muda de orientação, eu mostro a câmera no lado.

O critério: se a decisão é só software, decide software. Se toca o físico, decide os dois juntos. Isso reduziu o número de retrabalho de UI por incompatibilidade de hardware no piloto. Quanto exatamente, não posso dizer aqui.

O projeto não terminou. Tudo aqui é provisório por natureza. Mas três coisas já são suficientemente verdadeiras pra escrever:

1. Restrição é o briefing real. Briefing escrito vem em texto; o briefing de verdade vem da geometria do dispositivo e da curva de bateria. Em hardware, esse briefing escrito quase sempre subestima o real.

2. Decisão escrita pesa mais quando o produto demora. Em fluxo de app eu defendo uma decisão e ela está em produção em duas semanas. Em hardware, ela demora um ano. O que sustenta uma escolha por um ano não é convicção — é registro.

3. Discrição é parte do trabalho. Eu sei o que esse case mostra escondendo. Quem vai me contratar pra trabalhar com hardware precisa ver que eu sei essa diferença. Esta página inteira é parte do portfolio.