Case 01 · Product design · 0 → 1
Blue Services é um marketplace australiano de serviços residenciais. Desenhei e programei o produto de ponta a ponta: o fluxo de reserva do cliente, o aplicativo de campo dos profissionais com GPS em tempo real e o console de operações.
Telas reais · build local do código de produção, dados de teste
O problema
Limpeza residencial parece simples até você tentar desenhá-la. O valor varia conforme o imóvel, os extras e a frequência. A disponibilidade depende de cada profissional individualmente. E o cliente está abrindo a sua casa para um estranho.
A experiência típica dessa categoria é um formulário longo que termina num orçamento enviado por e-mail: as pessoas se comprometem antes de saber o valor, e o setor operacional perde tempo cobrando confirmações por telefone.
Mapa do sistema
O maior desafio de design não foi uma tela isolada, mas garantir que três públicos distintos, com dispositivos e níveis de ansiedade diferentes, enxergassem a mesma verdade em tempo real.
"Me diga quanto custa, quando vai acontecer e quem está vindo."
"Me mostre o próximo serviço, a rota e exatamente o que fazer. Com apenas uma mão."
"Me avise o que está prestes a dar errado, antes que o cliente perceba."
Processo
Trabalhei direto no ambiente de produção, com um ciclo curto entre a decisão de design e o uso real. 206 commits no repositório contam a história desse ciclo; o documento do design system registra a maturidade do sistema, incluindo onde ele ainda demanda refinamento.
Decisão 01 · Fluxo de reserva
Desenhei o fluxo como uma página viva única em vez de um formulário com múltiplas etapas: endereço, data, horário e extras recalculam o resumo instantaneamente. Nenhuma etapa exige compromisso antes de precificar.
booking.php, descontos reais de recorrência e duração de extras. Valores ilustrativos.
O calendário consulta a capacidade real por dia via API. Três estados visuais (disponível, limitado, esgotado) permitem ao cliente escolher com contexto, em vez de descobrir um conflito após preencher tudo. Dias com vagas limitadas continuam selecionáveis; eles apenas oferecem menos janelas de chegada e deixam isso claro.
O horário é escolhido como uma janela de chegada, refletindo como as equipes de limpeza realmente se deslocam na cidade, com seus próprios estados de carregamento e contingência.
Abaixo de 768px a página se transforma em um assistente guiado com barra inferior persistente: indicador da etapa, total acumulado, duração estimada e uma única ação primária. O resumo no desktop e o assistente no mobile compartilham a mesma lógica de componentes, apenas adaptando seus contêineres.
O total e a estimativa de tempo recalculam automaticamente quando itens com requisitos mínimos alteram o escopo, garantindo que a promessa feita no checkout corresponda exatamente à entrega física.
01Onde & quando, plano e contrato
02Capacidade diária via API
03Janelas de chegada por período04Cômodos e extras recalculam ao vivo05Preferências transparentes no preço06Resumo antes de qualquer pagamentoDecisão 02 · Design system
Entregar as chaves de casa é um ato emocional. A linguagem visual precisava ser acolhedora e limpa, sem frieza: camadas translúcidas, base em azul-marinho profundo e um único destaque vibrante na ação primária.
Uma família, quatro pesos. Hierarquia por tamanho e peso; micro-etiquetas em caixa alta para legendas.
Uma curva "líquida" em 200ms e 400ms. Usuários com preferência por redução de movimento recebem superfícies sólidas sem blur.
0.25 → 3rem de espaçamento; raios de 12 / 14 / 16 / 20px pela função do componente. Campos de entrada fixados em 48px.
Decisão 03 · Orquestração
Antes de desenhar telas, formalizei o ciclo de vida completo do serviço em diagramas swimlanes: cada estado da reserva, quem é o responsável e o que cada pessoa tem permissão de visualizar naquele instante.
Profissionais visualizam endereço e telefone apenas entre os status "aceito" e "concluído". O cliente só vê os dados do profissional após a correspondência ser confirmada. As permissões acompanham o estado da reserva, eliminando qualquer tela em que alguém veja mais do que deveria.
Recusas de serviço, portas trancadas, saída do raio geográfico e avaliações baixas têm, cada uma, um responsável e um desfecho definido (nova tentativa, pagamento parcial, ligação telefônica ou chamado automático de suporte). O fluxo principal ilustra o caminho ideal; as ramificações de exceção são onde o produto conquista a confiança.
Decisão 04 · App de campo & rastreamento
O app do profissional prioriza leitura instantânea em movimento: próximo serviço, rota no mapa e checklist de cômodos. A central e o cliente consomem o mesmo stream de localização, garantindo uma única verdade operacional.
connectblue/professional/jobs.php e checklist.php, customer/track-professional.php, admin/live-tracking.php): os mesmos rótulos, status, cores e layout, com nomes, locais e valores demonstrativos. Os mapas são ilustrados, não Google Maps. Telas reais alimentadas por dados ao vivo.Smartphones suspendem aplicações web no instante em que o profissional abre o Google Maps. Empacotei a PWA em um shell nativo exclusivamente para manter a geolocalização em segundo plano ativa, emitindo tokens de API com escopo restrito para que o app transmita sua posição sem exigir uma sessão ativa no navegador. O desafio de design foi tornar isso invisível: apenas uma solicitação de permissão, em linguagem direta e sem jargões técnicos.
Cada tipo de serviço possui seu próprio checklist estruturado. O que o cliente contratou, o que o profissional marca como concluído e o que o operador administrativo audita compartilham a mesma estrutura de dados — assim, a pergunta "o forno foi limpo?" sempre tem uma resposta auditável com foto do antes e depois.
Decisão 05 · Propostas de interface para a próxima versão
Quatro fluxos cujas regras já existem no código em produção, mas cuja interface poderia explicá-las com maior clareza. Cada proposta detalha o comportamento atual e o que eu aperfeiçoaria.
:root e uso excessivo de !important em campos tornam a troca de temas frágil (ver trade-offs abaixo).As abas avançam automaticamente; clique em uma para pausar nela. Tudo neste palco é uma proposta de evolução, não interface final em produção.
Dos arquivos de trabalho
Dois artefatos reais extraídos do repositório, sem edições: o fluxo em swimlanes utilizado para alinhar o comportamento do cliente, da administração e dos profissionais, e o painel do design system utilizado no handoff de engenharia. A nomenclatura original está em português, o idioma de trabalho da equipe técnica.
blue.css de produção.Decisões técnicas e trade-offs
Um design system construído em ritmo acelerado dentro de um produto em lançamento inevitavelmente acumula dívida técnica. Auditei cada ponto com franqueza e documentei para o time de engenharia. Assumir isso faz parte do trabalho de um designer sênior.
| Problema identificado | Impacto | Direção planejada |
|---|---|---|
Três conjuntos sobrepostos de tokens em :root | Cores de superfície e borda podem divergir silenciosamente entre páginas. | Arquivo único de tokens; criar aliases temporários e depois remover variáveis legadas. |
Uso de !important em campos de formulário | Customização de temas e modo escuro tornam-se frágeis. | Migrar para cascade layers do CSS; componente único e padronizado de input. |
| Dois padrões distintos de seleção de horário | Interface inconsistente entre diferentes fluxos do produto. | Padronizar tudo sobre o modelo de janela de chegada. |
| Estilos inline em templates de páginas | Dificuldade de revisão de código e baixa reutilização. | Extrair para arquivos CSS modulares por componente. |
Reflexões
A maior parte da percepção de qualidade mora nos estados de carregamento, telas vazias, retornos parciais e cenários de erro: disponibilidade reduzida, falha na busca de endereço ou um profissional atrasado. Especifiquei cada um desses comportamentos antes mesmo de refinar o caminho feliz.
Desenvolver aquilo que projetei significou que cada compromisso técnico (performance de renderização, integração com mapas ou limitações de background do iOS) foi uma decisão de design consciente e tomada com pleno conhecimento de causa.
O documento de design system e o quadro de handoff foram concebidos com empatia para o próximo profissional da equipe — incluindo o meu próprio eu do futuro.