Produto de gestão de ordens de serviço e site

Produto de operações em oito módulos, mais o site em Next.js.

Site do upOS, com o painel do produto em destaque

Desenhei um produto de operações com oito módulos para uma assistência técnica — atendimento, orçamento, kanban de ordens de serviço, catálogos, clientes e financeiro — e depois desenhei e programei o site em Next.js. O produto está em produção, e um time posterior refez o app em outra stack mantendo o design.

Função
Sole designer of an 8-module operations product, and designer + front-end developer of the landing page
Período
jul. de 2025 – ago. de 2025
Stack
TypeScriptTailwindFigma
Evidência
  • No ar
  • Design + código
  • Código
  • Stack de produto

Ver o build (cópia própria)Código-fonte

Uma assistência técnica precisava do sistema que faz suas ordens de serviço andarem de ponta a ponta — do momento em que o cliente entra com algo quebrado até o momento em que a conta é quitada. Oito módulos no desktop, uma superfície mobile propositalmente pequena, e o site que vende tudo isso.

Trabalho de agência na Spaceapps; a relação com o cliente era da agência e eu entreguei como funcionário. A discovery foi conduzida pelo líder técnico, que me entregou o quadro pronto. Dali em diante o design do produto foi meu, sozinho — e a landing page foi minha para desenhar e para construir.

O site do upOS rolando e, em seguida, o produto atrás dele: atendimento, o kanban de ordens de serviço, o controle financeiro e o módulo de permissões.
Trinta segundos, sem som e em loop — a landing page que desenhei e programei, e o produto de oito módulos que desenhei atrás dela.

Do balcão até o dinheiro

O problema real de uma assistência técnica não é nenhuma tela isolada; é que um aparelho, uma promessa e um valor circulam pelo negócio em velocidades diferentes e na cabeça de pessoas diferentes. O balcão recebe o aparelho. Alguém orça. Outra pessoa conserta. E alguém precisa saber, três dias depois, onde ele está e o que foi combinado. O sistema tinha que segurar tudo isso num lugar só sem transformar o balcão num posto de digitação.

  • Autenticação — a porta de entrada, e o único módulo que existe em todas as superfícies.
  • Atendimento — recepção e orçamento, onde a promessa ao cliente é feita.
  • Assistência — o trabalho em si, com um kanban de ordens de serviço para a oficina enxergar a fila em vez de lembrar dela.
  • Serviços e Produtos — os catálogos que tornam um orçamento repetível em vez de improvisado.
  • Clientes — o histórico que faz a segunda visita ser mais fácil que a primeira.
  • Financeiro — do orçamento até a quitação.
  • Configurações — os ajustes que permitem um mesmo design servir oficinas que não trabalham igual.
8
módulos desenhados no desktop
2
deles no mobile, de propósito
26
permissões ver/editar, 8 áreas
59
arquivos no repositório da landing

A superfície mobile tem dois módulos, e essa é a decisão de design

O celular recebe autenticação e recepção de serviço. Nada além disso. Não porque o resto foi cortado por prazo, mas porque a recepção é a parte que acontece longe da mesa — alguém em pé no balcão ou em campo, com um cliente na frente — e o back office não é. Financeiro no celular seria uma funcionalidade que ninguém abre. Isto é o oposto de uma alegação de cobertura responsiva: dois de oito é a resposta, e espelhar os oito numa tela pequena teria sido a decisão mais fácil e pior.

Recepção de serviço na superfície mobileRecepção de serviço na superfície mobile
Placeholder — recepção de serviço no mobile, um dos dois únicos módulos que existem ali.

O caminho do dinheiro é faturamento, não checkout

Vale nomear com precisão, porque a palavra errada aqui embelezaria o trabalho e o descreveria mal. Não existe carrinho, nem checkout, nem comércio recorrente neste produto. O que existe: um orçamento que vira um acordo, e um controle financeiro que o acompanha até a quitação. Isso é faturamento entre empresas, e desenhar isso bem é um problema diferente de desenhar uma loja — a parte difícil não é o pagamento, é que o valor pode mudar entre a promessa e o conserto.

Permissão é um módulo, não três telas fixas

A discovery modelava três atores, e o caminho óbvio para atendê-los é desenhar três versões de cada tela. Eu fiz o contrário. O acesso mora nas Configurações como módulo próprio: uma tabela de perfis — Admin master, Técnico, Vendedor — cada um mostrando quantos usuários estão nele e se está ativo, e um construtor de perfil com cerca de vinte e seis permissões individuais em oito áreas do produto, todas divididas entre ver e editar. Ver financeiro e Editar financeiro são chaves separadas, e o mesmo vale para o kanban, as ordens de serviço, os pedidos de peças e os relatórios. Assim a oficina consegue definir um perfil que eu nunca imaginei, que uma oficina com técnico do turno da noite vai precisar e que eu não teria como adivinhar.

A landing page

O site era meu para desenhar e para construir, em Next.js: hero, banner, uma seção de como funciona, duas seções de imagem de funcionalidade, depoimentos, FAQ e uma chamada final, mais o conjunto de cookies, privacidade e termos e um 404 próprio. Com cinquenta e nove arquivos, é o repositório mais enxuto daquele período, e enxuto era o ponto — a página de um produto de operações precisa carregar na hora na pior conexão da oficina.

A seção de como funciona do siteA seção de como funciona do site
Placeholder — a seção de como funciona da landing page.

O que isto não é

  • Não é a minha construção do produto. Eu desenhei; um desenvolvedor Bubble construiu e outro depois refez em Next.js.
  • Não é evidência da minha engenharia. A aplicação no ar evidencia o meu design, e o fato de o design ter sobrevivido a uma reconstrução. O código atrás daquela tela de login nunca foi meu.
  • Não é a discovery. O líder técnico conduziu e entregou o quadro.
  • Não é alegação de cobertura responsiva. Dois de oito módulos existem no mobile, de propósito.
  • Não é prova de que os outros sete módulos renderizem diferente por perfil. O acesso é especificado nas Configurações e não desenhado como variantes por papel de cada tela, então essas variantes não existem no arquivo e eu não as reivindico.
  • Não é pagamento nem checkout. Orçamento mais controle financeiro é faturamento.
  • Não é o período do contrato. As datas desta página delimitam apenas o repositório da landing page — o design do produto veio antes, e o versionamento não consegue datá-lo.
  • Não é o site que está hoje no endereço do produto. Aquilo é o redesign de outra pessoa no endereço que a minha página ocupava.

O design sobreviveu à própria implementação

A coisa mais útil que este projeto prova não é que ele foi publicado. É que, quando a aplicação foi reconstruída do zero numa stack completamente diferente, por um desenvolvedor com quem eu nunca trabalhei, o design atravessou. Ninguém o redesenhou no caminho. Isso é o mais perto que um designer chega de um teste de carga: a interface estava especificada com clareza suficiente para um estranho reconstruir o que estava embaixo e deixá-la de pé.

Evidência

O produto está no ar e rodando um negócio real hoje: qualquer pessoa alcança a tela de login. Ele evidencia o design, não a engenharia — a aplicação foi construída em Bubble por outro desenvolvedor e depois refeita em Next.js por outro, e o design atravessou essa troca de plataforma intacto, o que é um teste mais duro do que publicar uma vez. A landing page que eu construí não existe mais no endereço original; ela foi substituída pelo redesign de outra pessoa depois que eu saí, então a cópia no meu próprio domínio é o único artefato sobrevivente dela — e é uma cópia, não a instância que serviu o cliente. Não existe nenhuma métrica de desempenho para este projeto: uma ausência confirmada, não uma ausência por falta de coleta.