Transformar uma locação manual de cadeiras de rodas em autoatendimento por app, para um público de 70 a 95 anos que quase sempre é atendido por um familiar, em um MVP de escopo fechado.
Fraktal SoftwaresSob NDA · Em andamento
App de locação de cadeiras de rodas
Do discovery ao protótipo em um MVP de 90 dias
Como conduzi, como responsável pelo produto, a primeira release de um app de autoatendimento para locação de cadeiras de rodas, com IA acelerando o processo.
- Empresa
- Fraktal Softwares
- Produto
- App nativo e painel web (cliente sob NDA)
- Status
- Em andamento · MVP de 90 dias
- Meu papel
- Product Designer responsável pelo produto: discovery, arquitetura, fluxos e protótipo da Release 1
- Time
- Conduzi as decisões de produto, validando cada etapa com a cliente do briefing ao protótipo navegável, e acompanhei o desenvolvimento junto ao time de dev até a entrega final à cliente
Conduzi o discovery com a cliente, defini personas, arquitetura e releases, especifiquei os fluxos para o dev e desenhei o protótipo navegável do app e do painel da Release 1.
Um piloto que valida o autoatendimento com pouca intervenção manual e uma base pronta para novos pontos de coleta.
Um negócio manual que precisava escalar sem crescer a equipe
A cliente é uma locadora de equipamentos de mobilidade que sempre operou de forma manual, por WhatsApp e redes sociais, com um único funcionário entregando e higienizando as cadeiras. Ela queria validar um modelo de autoatendimento: o usuário encontra um ponto parceiro perto de casa, escolhe a cadeira pelo app e retira lendo um QR Code. O projeto foi contratado como um MVP de escopo fechado, com 90 dias para ficar pronto, em um ponto piloto.
Operação que não escala
Toda locação dependia de atendimento manual e de um único funcionário para entregar e higienizar.
Quem usa não é quem aluga
Quem usa a cadeira tem de 70 a 95 anos e pouca familiaridade com tecnologia. Quem procura o serviço, na maioria das vezes, é um filho ou uma filha.
Prazo curto e escopo fechado
Um MVP de 90 dias, sem espaço para retrabalho entre design e desenvolvimento.
Objetivos do projeto
- Validar o autoatendimento em um ponto piloto
- Permitir localizar, alugar, retirar e devolver sem depender da equipe
- Dar à locadora controle da operação com pouca intervenção manual
- Deixar a base pronta para novos pontos no futuro
Entender o negócio antes de desenhar qualquer tela
Na Fraktal, o designer de produto é o responsável pelo produto: eu conduzia a cliente desde o discovery e tomava as decisões de produto. Por ser um projeto sob NDA, nomes, marca e dados foram trocados por fictícios.
Um processo em fases
O time de design, com cinco designers, tinha um processo de discovery em fases que nós otimizávamos continuamente. Cada fase só começava depois da aprovação da cliente.
O que isso me mostrouNenhuma tela é desenhada sem uma decisão de negócio por trás, e o retrabalho diminui, o que importa muito num prazo de 90 dias.
Formulário de discovery
Criei o formulário que a cliente respondeu logo depois do kickoff. Em vez de perguntas abertas sobre o que ela queria, ele trazia cenários reais da operação.
O que isso me mostrouAs respostas viraram regras de negócio antes de qualquer tela: cobrança automática das horas extras, política de cancelamento, responsabilidade por danos e as dúvidas que a ficha da cadeira precisava responder. E revelaram que 70% dos contatos vinham dos filhos de quem usa a cadeira.
Perguntas-âncora e Business Model Canvas
Resumi o desafio de negócio e a definição de sucesso em duas respostas, e montei um canvas enxuto para entender quem paga, como o serviço gera valor e quais custos precisam ser gerenciados.
O que isso me mostrouSucesso, no piloto, era o cliente conseguir localizar, alugar, pagar, retirar e devolver sozinho, e a locadora operar com pouca intervenção manual. Esse critério guiou as prioridades da primeira release.
Três personas, três lados do mesmo serviço
A usuária da cadeira
78 anos, pouca familiaridade com tecnologia. Quer se locomover com segurança e manter a autonomia, mas depende de familiares e cuidadores.
Precisa de uma cadeira disponível quando a necessidade surge, sem esforço.
A familiar que aluga
48 anos. Organiza os compromissos dos pais, pesquisa serviços no Google e paga com cartão de crédito.
Precisa saber rápido qual cadeira serve, se tem uma perto e quanto custa.
O responsável pelo ponto parceiro
39 anos. Atende os clientes do estabelecimento e passa informações aos colegas na troca de turno.
Precisa liberar e receber cadeiras rápido, sem atrapalhar o trabalho principal.
Um escopo pensado para caber em 90 dias
Com prazo curto e escopo fechado, a estrutura do produto foi a primeira decisão de design.
Dois ambientes, um para cada lado
App nativo para quem aluga e painel web para a locadora. O app é nativo porque a retirada valida a localização do usuário no ponto, o que reduz o risco de fraude.
Nasce deO modelo de retirada em pontos parceiros.
Fundação primeiro
A Release 1 entrega a base: entrar, encontrar um ponto, escolher a cadeira e cadastrar a operação no painel. Locação e pagamento chegam na Release 2.
Nasce deO prazo de 90 dias e o escopo fechado.
Escopo protegido
Toda ideia nova que surge no mapeamento passa por uma pergunta: cabe nesta release? Se não cabe, vai para o estacionamento de ideias, como V2 ou V3.
Nasce deO risco de o escopo crescer no meio do caminho.
As decisões, uma a uma
Das decisões de estrutura às de interface. Para cada uma: o problema, o que eu fiz e por que fiz assim.
Estrutura
Módulos e releases antes das telas
Problema
Com 90 dias e escopo fechado, não dava para desenhar tudo de uma vez nem descobrir dependências no meio do desenvolvimento.
Decisão
Organizei os dois ambientes em módulos, cada um com descrição, release e estimativa, e desenhei um fluxograma macro com as validações principais. Atuei na Release 1 e também desenhei a Leitura de QR Code, da Release 2.
Por quê
A ordem de construção fica clara para o time e para a cliente, e cada release entrega algo que funciona sozinho.
Especificação
Fluxos que o dev consome sem adivinhar
Problema
Num MVP rápido, qualquer regra de negócio deixada em aberto vira dúvida no desenvolvimento e retrabalho.
Decisão
Cada módulo virou um fluxo completo: telas numeradas por profundidade, decisões, estados de erro e bloqueio, regras de negócio em notas e critérios de aceite verificáveis por tela. Os fluxos foram gerados com uma skill de IA criada pelo nosso time de design, para mapear cada etapa com mais velocidade e precisão.
Por quê
O dev recebe os fluxos junto com o protótipo e sabe o que cada tela faz, inclusive quando algo dá errado. Mapear o impacto entre módulos evita surpresas na integração.
Interface
Uma paleta que acolhe
Problema
Serviços de saúde e mobilidade costumam usar o azul hospitalar, que lembra doença. O público eram pessoas idosas e seus filhos, num momento delicado.
Decisão
Uma paleta quente, de bege-areia, terracota e branco. A terracota fica reservada para a ação principal de cada tela. Verde, amarelo e roxo são de status, e o amarelo-claro destaca os avisos importantes.
Por quê
O tom transmite cuidado em vez de doença, e com cada cor tendo um papel fixo, o usuário aprende rápido onde tocar e o que é só informação.
Conversão
Cadastro curto, dados só na hora certa
Problema
Pedir CPF, endereço e celular logo no cadastro afasta quem só quer ver se tem cadeira perto, e dificulta a aprovação nas lojas de aplicativos.
Decisão
O cadastro pede só e-mail, senha e o aceite dos termos. A própria tela avisa: “Leva menos de um minuto. Seus dados pessoais só serão pedidos na primeira locação.”
Por quê
Menos fricção na entrada, e o texto da interface explica a decisão para o usuário em vez de esconder a regra.
Segurança
Segurança sem expor o usuário
Problema
Um login precisa proteger a conta sem revelar quem é cliente do serviço.
Decisão
Credenciais erradas e e-mail sem conta mostram a mesma mensagem genérica. A recuperação de senha nunca confirma se o e-mail existe. A 5ª tentativa errada bloqueia o login por 15 minutos, e o código de verificação expira.
Por quê
Segurança que não depende do usuário entender de segurança, com a mesma clareza de mensagens em todos os casos.
Descoberta
Disponibilidade antes do toque
Problema
A familiar que aluga tem pressa: precisa saber se tem cadeira perto antes de investir tempo no app.
Decisão
A home mostra os pontos em mapa ou lista, com o número de cadeiras disponíveis no próprio pin. A localização é pedida com contexto. Se a pessoa negar, o app mostra a lista em ordem alfabética, com um botão para ativar depois.
Por quê
A informação que decide aparece primeiro, e negar uma permissão nunca vira beco sem saída.
Descoberta
Um ponto de coleta para decidir rápido
Problema
Antes de ir até o ponto, a pessoa precisa saber se ele está aberto e se ainda tem cadeira.
Decisão
O detalhe do ponto mostra o status com a distância, o número de cadeiras disponíveis em destaque com o selo “Atualiza em tempo real”, o horário com a tag “Hoje” e as ações “Como chegar” e “Ver cadeiras” fixas no rodapé.
Por quê
Tudo o que importa para a decisão cabe numa tela, e as ações principais ficam sempre ao alcance do polegar.
Confiança
Uma ficha que responde às dúvidas reais
Problema
No discovery, as perguntas mais comuns eram físicas: a cadeira é leve? Cabe no carro? Quanto peso aguenta?
Decisão
A ficha mostra peso, largura do assento, carga máxima e tipo de pneu, com uma descrição na língua de quem aluga (“indicada para quem vai subir no carro com ajuda”). Um aviso em amarelo diz que a cadeira não fica reservada até a retirada.
Por quê
A ficha responde antes de a dúvida virar ligação, e ser honesto sobre a reserva evita frustração no ponto.
Painel
Um painel para quem não é técnico
Problema
Quem opera o painel é a dona do negócio, sem time técnico ao lado.
Decisão
Cada tela abre com uma frase que explica o que ela faz (“o app do locatário mostra o que estiver aqui”). O status sempre aparece com ícone e texto, os filtros mostram a contagem de cada status e o nome da cadeira é sugerido em sequência.
Por quê
A administradora entende a consequência de cada ação sem precisar de treinamento, e o status nunca depende só da cor.
Painel
Ver o app enquanto edita o painel
Problema
Ao cadastrar uma cadeira, a administradora não tinha como saber como ela apareceria para o cliente.
Decisão
O formulário da nova cadeira tem, ao lado, a prévia “Como aparece no app”, atualizada conforme os campos são preenchidos.
Por quê
Liga os dois ambientes do produto e evita erros que só seriam percebidos pelo cliente final.
Painel
Regras que protegem a operação
Problema
Uma exclusão errada no painel some do app na hora e pode quebrar uma locação em andamento.
Decisão
Não é possível excluir uma cadeira em uso nem um ponto com cadeiras vinculadas, e o sistema sugere marcar o ponto como inativo. O parceiro é cadastrado antes do ponto, e o CEP preenche o endereço e posiciona o ponto no mapa.
Por quê
As regras de negócio ficam na interface, e não na memória de quem opera.
Como validar e acompanhar
O projeto está em andamento e o piloto ainda não foi lançado. Estes são os indicadores que eu usaria para validar o modelo no ponto piloto, ligados à definição de sucesso que a cliente aprovou:
Conclusão da jornada
O que medirA % de usuários que vão do cadastro à retirada da cadeira sem pedir ajuda.
ObjetivoValidar que o autoatendimento funciona sem a equipe.
Cadastro para locação
O que medirQuantos cadastros chegam à primeira locação.
ObjetivoConfirmar que adiar os dados pessoais não cria um gargalo na hora de alugar.
Intervenção manual
O que medirO volume de contatos da locadora com clientes e parceiros por locação.
ObjetivoMedir se a operação ficou de fato mais autônoma.
Ocupação do ponto piloto
O que medirAs horas alugadas por cadeira, por semana.
ObjetivoAvaliar se o modelo justifica abrir novos pontos.
O que este projeto me ensinou
- Em escopo fechado e prazo curto, a maior entrega do designer é a clareza: decisões tomadas cedo e registradas evitam retrabalho.
- Perguntar por cenários, e não por opiniões, faz o cliente tomar decisões de negócio antes que elas virem dúvida no desenvolvimento.
- A IA acelerou a especificação sem tirar o critério do processo: as decisões continuaram sendo minhas, e a IA ajudou a mapear cada caminho com mais precisão.
- Discovery
- Arquitetura de informação
- Especificação para dev
- Design com IA
- App mobile
- UX para público 60+