Carpool
Colaboradores podiam reservar carros da empresa. O brief parecia um problema de produto de reservas. A pesquisa disse outra coisa.
UX research · Service design · Explorações de design
A interface tinha problemas reais de usabilidade. A restrição dominante continuava a ser a disponibilidade de veículos e a readiness operacional.
Detalhes de cliente e produto foram anonimizados. As interfaces foram reconstruídas para efeitos de portefólio.
- Evidência de pesquisa
- Contexto de projecto
- Interpretação
- Reconstrução
- Exploração de design
Um benefício interno de frota partilhada
As pessoas reservavam carros da empresa para lazer ou trabalho. Se o fluxo de reserva parecia partido, era fácil assumir que o remendo estava no produto.
O que a pesquisa já tornava visível
Um mapa editorial da evidência documentada. Não é analytics. Sem taxas inventadas.
Cada painel abaixo foi mapeado à pesquisa de origem antes de aparecer aqui.
A indisponibilidade de veículos era o desafio principal.
As preocupações de usabilidade tornavam-se secundárias quando não havia veículos.
Este serviço tinha um problema de capacidade que se manifestava na experiência de reserva.
O Carpool era um benefício de colaboradores: um sistema interno para reservar veículos da frota partilhada para lazer ou trabalho.
Próxima oportunidade utilizável. Fins-de-semana importam.
As entrevistas de lazer eram a amostra mais forte. Trabalho e operações ainda precisavam de research mais profundo.
- Contextual inquiry
- Entrevistas de lazer
- Personas
- Expert review
- Difícil encontrar slots disponíveis
- Planeamento com meses de antecedência
- Cancelamentos inesperados
- Confirmação pouco clara
- Estado de reserva pouco claro
- Disponibilidade pouco clara
- Regras pouco claras
- Incerteza operacional
- Tempo de carregamento
- Inspeção do veículo
- Manutenção
- Condição do veículo
- Limitações de reserva
- Processos de levantamento e devolução
Maior flexibilidade / próximo slot disponível
Contraste de necessidades documentado. Não é uma afirmação de que o produto já separava estes fluxos.
Carregamento e inspeção ficam entre a devolução e a próxima reserva utilizável.
Modelo conceptual de serviço derivado da pesquisa. Não é um SOP oficial.
A reserva é um nó. Operações e readiness estão à sua volta.
Cancelamentos tardios documentados podiam chegar sem motivo claro nem alternativa.
Pensámos que a plataforma era o problema.
Se reservar parecia partido, reconstruir o produto de reservas. Razoável. Incompleto.
- Plataforma
- Reserva
- Carro
Antes de desenhar uma solução, investigámos o serviço.
Uma reconstrução de plataforma estava enquadrada em cerca de 6 a 12 meses. Esse número é contexto de projecto, não métrica de research.
Olhámos para além dos ecrãs
As operações disseram o que acontecia entre reservas. Utilizadores de lazer disseram o que era esperar. Um expert review percorreu o produto em produção, linha a linha.
Levantamento, devolução, carregamento, inspeção, políticas, condição, multas.
Procurar, reservar, cancelar, e se a espera ainda compensava.
Flexibilidade de lazer, precisão de trabalho, operações de frota.
Timing de regras, histórico, confirmação, clareza de erros.
Mais forte no lazer. Reservas de trabalho e operações mais profundas ficaram como próximos passos.
Um utilizador de lazer disse-o sem rodeios: quando havia carros, a interface deixava de ser a queixa principal.
Três relações com o mesmo serviço
Papéis comportamentais da pesquisa, não cartazes demográficos.
Aires
Procura flexível
A próxima oportunidade utilizável. Fins-de-semana importam.
Ricardo
Compromisso fixo
Um carro numa data fixa, dentro de um intervalo preciso.
Rita
Frota e pedidos
Procura versus readiness entre uma reserva e a seguinte.
O problema não era encontrar o botão de reservar.
Veículos
- Compact EV 01Disponível para reservar
- Compact EV 02Disponível para reservar
- Estate 1Listado · sem slot utilizável
Experimentar outro dia
As pessoas caçavam dias livres, planeavam com meses de antecedência, e ainda encontravam opções indisponíveis que pareciam seleccionáveis. Não havia lista de espera.
Até uma reserva podia desaparecer.
Jan to Sep
Um caso documentado: reservado em janeiro para setembro; cerca de vinte dias antes, o carro deixava de estar disponível. Sem explicação útil. Sem alternativa.
Da pesquisa com utilizadores de lazer. Não é afirmado como regra de todas as reservas.
Disponível nem sempre significava pronto.
Devolução
Carros eléctricos de lazer precisam de tempo de carregamento. A inspeção fica entre a devolução e a próxima reserva. Uma célula livre no calendário pode ainda significar um carro que ainda não pode sair.
Trabalho e lazer precisavam de coisas diferentes.
Próximo fim-de-semana disponível
Um modelo de interacção servia dois trabalhos: compromissos fixos e oportunidade flexível. A pesquisa recomendava declarar a intenção.
O sistema conhecia a regra antes do clique.
Limites como uma reserva de lazer activa apareciam depois de Reservar, não antes do compromisso.
O estado era difícil de ver quando importava.
- Compact EVAberta
Defaults podiam esconder reservas futuras. O estado importante vinha tarde na tabela. As pessoas abriam tickets para reservas que já existiam.
A hora agendada não prova o que aconteceu.
- Levantamento
- 09:00
- Devolução
- 17:00
Os horários abaixo são ilustrativos.
Horários ilustrativos
A pesquisa recomendava registar pickup e return reais, para responsabilização quando os planos mudam.
A indisponibilidade de veículos era o desafio principal. A usabilidade era secundária.
A interface tinha problemas reais. Esse finding não absolve o produto. Reordena o problema.
De “como melhoramos a reserva?” para “o que torna uma reserva verdadeira?”
A plataforma era só uma camada do problema.
Afastar da camada de reserva
Reservar
O que o software podia ajudar, e o que não resolvia sozinho
O software podia melhorar
- Descoberta de disponibilidade
- Regras mais cedo
- Estado, confirmação, histórico
- Motivos de cancelamento
- Sinais de readiness, se houver dados
- Intenção trabalho / lazer
O software não podia sozinho
- Criar capacidade de frota
- Apagar a física do carregamento
- Inventar capacidade de inspeção
- Impedir todos os cancelamentos de manutenção
- Fazer a escassez parecer abundância
Dizer a verdade operacional mais cedo. Só reconstruir se a reconstrução mirar a restrição dominante.
Se uma plataforma leva 6 a 12 meses, para que problema é esse tempo?
Contexto de projecto, não métrica de research. Sem ROI inventado.
- Nova plataforma
- Melhor UI de reserva
- Melhor acesso?
- Nova plataforma
- Melhor UI de reserva
- Mesma frota
- Mesma restrição de disponibilidade
Contexto de projecto
A pesquisa desafiou se reconstruir a plataforma responderia à restrição dominante.
O que a pesquisa abre ao design
Perguntar quando é preciso um carro antes de escolher o modelo.
Tornar carregamento e preparação visíveis.
Janela fixa versus próxima disponibilidade.
Estado que responde ao que está a acontecer agora.
Motivo e próximo passo, não silêncio.
Registar pickup e return quando acontecem.
A decisão de design mais útil foi decidir o que precisava de ser resolvido primeiro.
A pesquisa mudou a pergunta
Um enquadramento de decisão mais afiado. Sem história de lançamento. Sem poupanças inventadas.
Como construímos uma melhor plataforma de reservas?
O que está de facto a impedir o serviço de funcionar?
A plataforma de reservas era o sítio onde intervir.
Problemas reais de interface, sob uma restrição mais profunda de disponibilidade e readiness.
A pergunta de investimento passou de reconstruir UI para verdade de serviço.
Meses de trabalho de plataforma só ajudam se mirarem a restrição que as pessoas sentem.
Limites
Ferramentas internas herdam a física do serviço que representam. Quando esse serviço é escasso e operacionalmente tamponado, o primeiro trabalho do produto é ser verdadeiro.
A amostra era concentrada em lazer. A evidência de trabalho era mais fina. A profundidade operacional ficou por concluir. Esses limites pertencem ao espaço público.
Detalhes de cliente e produto foram anonimizados. As interfaces foram reconstruídas para efeitos de portefólio.