Substituir um sistema de ponto consolidado por uma plataforma própria, sem perder confiabilidade nem a validade jurídica exigida pelo Ministério do Trabalho, para públicos com proficiência tecnológica muito diferente.
Fraktal SoftwaresSob NDA · Em andamento
SaaS de controle de ponto
Três ambientes, uma marcação com valor legal
Como desenhei, como responsável pelo produto, um sistema de ponto completo: o app do trabalhador, o ambiente do RH e o painel de quem vende a plataforma.
- Empresa
- Fraktal Softwares
- Produto
- SaaS de controle de ponto (cliente sob NDA)
- Plataforma
- App nativo, web do gestor e painel da plataforma
- Status
- Em andamento
- Meu papel
- Product Designer responsável pelo produto nos três ambientes: discovery, arquitetura, especificação e protótipo
- Time
- Conduzi as decisões de produto, validando cada etapa com o cliente do briefing ao protótipo navegável, e acompanhei o desenvolvimento junto ao time de dev até a entrega final ao cliente
Conduzi o discovery, defini a arquitetura dos três ambientes e especifiquei os 27 módulos com regras de negócio e critérios de aceite, até o protótipo navegável.
Fechamento da folha 100% dentro da plataforma, menos ajustes manuais e chamados de suporte, e um produto pronto para ser vendido como SaaS.
Trocar um sistema consolidado sem perder a confiança de ninguém
O cliente revendia um sistema de ponto consolidado de outra empresa e decidiu ter uma plataforma própria: sem depender do fornecedor, com liberdade para personalizar e para vender o produto a outras empresas como SaaS. O desafio não era só técnico. Era substituir um sistema estável sem perder confiabilidade nem a validade jurídica exigida pelo Ministério do Trabalho. Atuei como responsável pelo produto nos três ambientes, do discovery ao protótipo.
Dependência de fornecedor
Custo alto e pouca liberdade para atender os pedidos de personalização dos clientes.
Segurança jurídica
Cada marcação, ajuste e cartão ponto precisa ser auditável e aceito pela fiscalização e pela folha de pagamento.
Públicos muito diferentes
Trabalhadores, o RH de pequenas e médias empresas e o time que opera a plataforma, com proficiência tecnológica de 2 a 4 de 5.
Objetivos do projeto
- Registro de ponto confiável, pelo app ou por equipamento
- Fechamento da folha 100% dentro da nova plataforma
- Cartão ponto com validade jurídica
- Autonomia para vender e operar o produto como SaaS
Entender quem registra, quem confere e quem vende
Segui o processo de discovery do time de design da Fraktal. Por ser um projeto sob NDA, nomes, marca e dados foram trocados por fictícios.
Priorização a partir do kickoff
No formulário de kickoff, o cliente classificou as funcionalidades em essenciais, coração do sistema e interessantes.
O que isso me mostrouO essencial era jurídico (homologação, rastreabilidade, cartão ponto) e o coração era o motor de regras de jornada. Isso definiu a ordem de construção e o que podia esperar.
Perguntas-âncora e Business Model Canvas
Resumi o desafio de negócio e a definição de sucesso, e montei o canvas com clientes, proposta de valor, canais, receita e custos.
O que isso me mostrouO produto não era só um sistema de ponto: era um SaaS cobrado por colaborador ativo. Por isso ele precisava de um terceiro ambiente, para o time que vende, cobra e dá suporte.
Personas com interesses que se cruzam
A responsável pelo ponto
38 anos. Acumula RH, departamento pessoal e gestão. Confere atrasos e faltas todos os dias e fecha o mês sob pressão, entre o sistema e planilhas paralelas.
Precisa fechar o mês com segurança jurídica, rastreabilidade total e menos retrabalho.
O trabalhador
29 anos. Registra entrada, intervalos e saída pelo celular, às vezes em campo, às vezes com internet ruim.
Precisa ter certeza de que o ponto foi registrado, entender o próprio saldo e corrigir erros sem constrangimento.
O time da plataforma
Quem vende, cobra e dá suporte ao sistema: comercial, financeiro e suporte.
Precisa saber se a base de clientes, a receita e a infraestrutura estão saudáveis.
Três pilares para um sistema com valor legal
A legislação trabalhista não era um detalhe técnico: era a principal restrição de design do produto.
Três ambientes, três perguntas
Trabalhador: “meu ponto foi registrado?”. RH: “posso fechar a folha com segurança?”. Plataforma: “o negócio está saudável?”. Cada ambiente responde a uma.
Nasce deAs personas e o modelo de negócio SaaS.
A lei como restrição de design
Marcações auditáveis, rastreabilidade de quem alterou, quando e por quê, cartão ponto com validade jurídica e arquivos fiscais da Portaria 671.
Nasce deO requisito de homologação junto ao Ministério do Trabalho.
Simples por padrão, robusto quando preciso
Padrões seguros já configurados e opções avançadas separadas, para atender da pequena empresa à média.
Nasce deA proficiência tecnológica que varia conforme o porte da empresa.
As decisões, uma a uma
Organizadas por ambiente. Para cada uma: o problema, o que eu fiz e por que fiz assim.
Sistema
Um dado que atravessa três ambientes
Problema
Com três públicos e 27 módulos, o risco era cada ambiente virar um produto isolado, com informações que não batem.
Decisão
Organizei o produto em três ambientes ligados pelo mesmo dado, a marcação. Mapeei como cada evento atravessa os ambientes: um ajuste pedido no app vira alerta no dashboard, é decidido pelo RH, corrige o espelho sozinho e termina no cartão ponto assinado.
Por quê
Pensar no ciclo, e não só nas telas, garante que o que o trabalhador vê e o que o RH aprova sejam sempre a mesma informação.
Especificação
Regra de negócio escrita, não deduzida
Problema
Num sistema de ponto, cada status depende de uma regra legal. Se o dev tiver que deduzir, o cálculo erra e o cliente perde a confiança.
Decisão
Cada um dos 27 módulos foi especificado com critérios de aceite, regras de negócio e notas para UI e dev. Por exemplo: folga nunca vira falta; atraso considera a tolerância configurada; “ajuste pendente” tem prioridade de exibição sobre atraso e falta; interjornada abaixo de 11 horas vira inconsistência.
Por quê
A interface só consegue ser clara quando a regra por trás dela não deixa espaço para interpretação.
App do trabalhador
Um registro de ponto à prova de erro
Problema
A maior dor do trabalhador era o medo de “bater e não registrar”, e a maior dor do RH, marcações duplicadas ou sem comprovação.
Decisão
O fluxo tem três passos: o horário atual com o mapa da localização, a foto de verificação (quando o gestor exige) e uma tela de confirmação com hora, local e foto. Por trás: o ponto nunca é registrado sem GPS válido, o app tenta capturar o sinal 3 vezes, o botão desabilita no toque, cada confirmação tem chave de idempotência e duas marcações do mesmo tipo em menos de 1 minuto são bloqueadas.
Por quê
O trabalhador vê exatamente o que vai ser registrado antes de confirmar e sai com um comprovante. O RH recebe marcações íntegras.
App do trabalhador
O status da jornada em primeiro lugar
Problema
O trabalhador abria o app para uma de duas coisas: registrar o ponto ou saber se havia algo errado.
Decisão
A home mostra a jornada do dia com uma barra de progresso, a última marcação e a próxima, o botão “Registrar ponto” como elemento dominante e os alertas de pendência no topo, cada um levando direto ao módulo que resolve.
Por quê
As duas tarefas principais ficam a um toque, e uma pendência nunca fica escondida.
App do trabalhador
Transparência sobre o saldo
Problema
Uma das dores mais citadas era não entender o cálculo: por que deu falta, de onde veio a hora extra, qual é o saldo do banco.
Decisão
No cartão ponto, cada dia mostra as horas, o saldo do dia e uma etiqueta de status (horas extras, falta, ajuste pendente, folga), e abre com todas as marcações. O banco de horas mostra o saldo em destaque e cada movimentação como crédito, em verde, ou débito, em vermelho, com o motivo.
Por quê
Quando o trabalhador entende o cálculo, ele confia no sistema e os conflitos com o RH diminuem.
App do trabalhador
Ajuste sem constrangimento e assinatura consciente
Problema
Pedir correção ao gestor pessoalmente gerava ansiedade. E assinar o cartão ponto sem conferir tirava o valor da assinatura.
Decisão
O ajuste é pedido pelo app, com os horários do dia já preenchidos, motivo pré-cadastrado e observação. Na assinatura, o app mostra o resumo do período e as inconsistências, e avisa que o cartão fica bloqueado depois de assinado. Se houver erro, o trabalhador pode recusar a assinatura informando o motivo.
Por quê
O trabalhador corrige sem depender de uma conversa difícil, e a assinatura passa a ser uma confirmação consciente.
Ambiente do gestor
O dashboard como centro de comando do dia
Problema
O RH perdia tempo navegando por vários módulos para descobrir o que estava errado no dia.
Decisão
O dashboard mostra, em tempo real, quem está trabalhando, em atraso, ausente, de férias ou afastado, e as solicitações pendentes. Uma segunda aba lista as inconsistências com o motivo explicado (batidas ímpares, falta sem justificativa, intrajornada, interjornada) e a ação ao lado. Cada indicador tem uma regra explícita: quem está de folga ou em feriado não aparece como ausente.
Por quê
O RH identifica o problema e age sem sair da tela inicial, e confia nos números porque sabe como são calculados.
Ambiente do gestor
Regras de jornada com a lei como padrão
Problema
Configurar escalas, horas extras, DSR e banco de horas é o módulo mais técnico do sistema, e o público inclui RHs com pouca familiaridade digital.
Decisão
O módulo foi dividido em Horários, Escalas mensais e Banco de horas, com contadores de status em cada card. Uma escala padrão já vem criada, no lugar de um estado vazio. As tolerâncias legais da CLT vêm marcadas por padrão, e as configurações avançadas ficam em uma aba separada.
Por quê
Quem não sabe configurar começa protegido pela lei, e quem precisa de detalhe encontra tudo sem poluir a tela.
Ambiente do gestor
Corrigir sem sair do lugar
Problema
Conferir e corrigir marcações exigia abrir várias telas, e as decisões sobre os pedidos dos trabalhadores precisavam ficar registradas.
Decisão
O ajuste é feito direto na célula da marcação, com um menu de contexto para editar, mover para o dia anterior ou posterior e lançar justificativas. Há dois modos: por colaborador ou por dia, com todos os colaboradores numa tela. Nas solicitações pendentes, o RH vê lado a lado as marcações atuais e as alterações pedidas, com a justificativa, e aprova ou rejeita mantendo o histórico.
Por quê
Menos navegação no momento de maior pressão, o fechamento, e cada decisão fica auditável.
Ambiente do gestor
Cartão ponto e fechamento com segurança jurídica
Problema
O fechamento do mês é o momento de maior risco: um dado alterado depois de fechado invalida a folha.
Decisão
O cartão ponto mostra uma linha por dia, com status em cor e as colunas de horas (normais, faltas, atrasos e extras por faixa). A interjornada não cumprida pinta a saída e a entrada em vermelho. O encerramento do período, automático ou manual, bloqueia os dias no cartão, nas marcações e nos apps até o RH reabrir.
Por quê
A interface torna visível o que a lei exige, e o bloqueio protege o dado depois que a folha foi fechada.
Painel da plataforma
Permissões como uma matriz
Problema
O time da plataforma tem perfis diferentes (suporte, comercial, financeiro), e cada um precisa ver uma parte do sistema.
Decisão
Cada perfil define, para cada um dos 7 menus, um de três modos: Oculto, Leitura ou Edição. O perfil Admin tem a gestão de acessos travada em Edição, para a equipe nunca se trancar para fora. Especifiquei que Leitura precisa ser bloqueio real no backend, não só esconder o botão, e criei o seletor “Ver como” para o admin visualizar a interface de cada perfil.
Por quê
A permissão fica visível e fácil de entender, e a segurança não depende da interface.
Painel da plataforma
Receita e capacidade sem números divergentes
Problema
O dono da plataforma precisava acompanhar receita e infraestrutura, e números que não batem entre telas destroem a confiança.
Decisão
O financeiro mostra MRR ativo, receita em risco e ticket médio, com negociação de preço por módulo e um histórico de plano imutável, com autor. Especifiquei uma única função de cálculo para alimentar tabela, indicadores e histórico. O monitoramento mostra a capacidade com faixas de status e uma projeção em linguagem simples (“deve atingir a capacidade em torno de junho de 2027”).
Por quê
Números que nunca divergem e problemas de capacidade percebidos antes de chegar ao cliente.
Sistema
Pensado como sistema de design
Problema
Três ambientes e 27 módulos desenhados tela a tela gerariam inconsistência e retrabalho para o dev.
Decisão
Desenhei a estrutura de navegação (topbar e sidebar) uma vez e a reaproveitei em todos os módulos. Previ tema claro e escuro desde o primeiro módulo, os estados de alerta dos indicadores (vermelho quando há pendência, neutro quando não há), o comportamento da grade em telas menores e o reaproveitamento dos componentes de tabela.
Por quê
Consistência para o usuário e menos retrabalho para quem desenvolve.
Como validar e acompanhar
O projeto está em andamento. Estes são os indicadores que eu usaria, a partir da definição de sucesso que o cliente aprovou no discovery:
Fechamento na plataforma
O que medirA % de clientes que fecham a folha exclusivamente dentro do novo sistema.
ObjetivoValidar que o produto substitui o sistema anterior de ponta a ponta.
Ajustes manuais
O que medirO número de ajustes feitos pelo RH por fechamento.
ObjetivoConfirmar que o registro confiável e as regras claras reduzem o retrabalho.
Chamados de suporte
O que medirO volume de chamados por cliente ativo.
ObjetivoMedir se a transparência dos cálculos reduz as dúvidas.
Retenção e churn
O que medirA permanência dos clientes mês a mês.
ObjetivoAvaliar se o produto se sustenta como SaaS.
O que este projeto me ensinou
- Num produto com valor legal, a melhor interface é a que deixa a regra visível: o usuário entende o cálculo e confia no resultado.
- Desenhar o ciclo de um dado entre ambientes revela problemas que nenhuma tela isolada mostraria.
- Bons padrões protegem quem tem pouca familiaridade digital sem limitar quem precisa de configurações avançadas.
- Produto B2B e SaaS
- Arquitetura de informação
- Especificação para dev
- App mobile
- Dashboards
- Regras de negócio complexas