Reportar
Identificar a bagagem
Acompanhar
Distinguir o que se sabe
Recuperar
Perceber o próximo passo
Resolver
Despesas e apoio
- Conceito de produto
- Mobile
- Antes da previsão
- Estado verificado
- Acompanha o apoio
- Contexto
Contexto e decisões de design
O PROJETO EM SÍNTESE
As atualizações confundem o que está confirmado, previsto e ainda desconhecido.
Separar níveis de certeza, manter a próxima ação visível e levar o contexto para o apoio.
Conceito + QA do protótipo. Sem testes com passageiros nem integração real com companhias aéreas.
DECISÕES-CHAVE
Usar linguagem diferente para estados confirmados, previstos e desconhecidos.
Manter visível o último scan confirmado mesmo quando o plano de recuperação muda.
Abrir o apoio já com o histórico do caso, o estado do tracker e as despesas.
- FERRAMENTAS
- Figma · Prototipagem interativa
- O QUE CRIEI
- Um fluxo de recuperação que distingue eventos confirmados, estimativas e informação em falta.
- EVIDÊNCIA & ESTADO
- Verificações de design no protótipo. Testes com passageiros e integração com uma companhia aérea real continuam como próximos passos.
Localizar não chega
Os passageiros não precisam apenas de uma localização. Precisam de perceber quão fiável é a atualização e o que podem fazer a seguir.
39% associado a transferências
SITA · Baggage IT Insights 2026Contexto da indústria, não resultados do projeto.
Ver raciocínio
A parte difícil começa depois do reporte
The 72 hours é um conceito independente para o período entre comunicar o atraso de uma bagagem e recuperá-la. Os passageiros recebem atualizações de estado, mas continua a ser difícil perceber o que se sabe e o que acontece a seguir.
Trabalhei entre síntese de investigação, design de serviço, UX/UI e prototipagem para separar informação confirmada de estimativas e desconhecidos.
Como pode a aplicação comunicar incerteza com clareza sem criar uma promessa?
As ferramentas já existem. O problema é perceber o que significam as atualizações
A investigação começou com o Baggage IT Insights 2026 da SITA, usando dados de 2025. Embora a taxa de bagagens mal processadas tenha descido 23%, o foco deste conceito foi a informação que os passageiros recebem enquanto esperam.
Lufthansa, KLM e Air France já suportam reporte, acompanhamento do caso, atualizações de entrega, partilha de localização e pedidos de reembolso. Não redesenhei sistemas de localização de bagagem como o WorldTracer. Alterei a forma como as atualizações são apresentadas aos passageiros.
- 24M, Bagagens mal processadas em 2025
- 39%, Associadas a transferências
- $6.3B, Custo anual da indústria em 2025
Dados da indústria: SITA, Baggage IT Insights 2026. Descrevem o contexto, não resultados deste projeto.
A investigação por detrás das decisões
Relatórios, orientações de companhias aéreas e documentação de produto informaram o conceito. Os ecrãs mostram um cenário de exemplo e não estão ligados ao WorldTracer nem a um serviço real de companhia aérea.
Da perda à recuperação
-
01
Reportar
Confirmar o caso
-
02
Esperar
Perceber o que está a acontecer
-
03
Recuperar
Acompanhar o próximo evento
-
04
Resolver
Devolução, recibos, pedido
Ver raciocínio
A companhia aérea sabe mais do que o passageiro vê
Mapeei três momentos de um caso de recuperação de exemplo para comparar o evento operacional com a experiência do passageiro. O exemplo termina com a entrega a 15 de março às 15:12, aproximadamente 72 horas depois do reporte.
| Momento | Evento do sistema | Experiência do passageiro |
|---|---|---|
| 12 Mar · 15:20 | A bagagem não embarcou. Último scan: Frankfurt, 14:02. | Uma passadeira de bagagens vazia, sem explicação útil. |
| 13 Mar · 09:41 | Bagagem confirmada em Frankfurt. | “Encontrada”: uma localização, ainda sem data de entrega. |
| 14 Mar · 10:29 | Voo de recuperação atribuído. | Surge uma chegada prevista. |
Detalhes do voo, datas e referências do caso são ilustrativos.
Do reporte à devolução
Quatro momentos organizam a jornada. Os dados da reserva já estão preenchidos quando o passageiro confirma o caso; depois, a interface explica a procura, a recuperação e as ações restantes após a entrega.
- 01 / Reportar
- Confirmar o caso e os dados da reserva.
- 02 / Esperar
- Perceber o que a companhia aérea está a fazer.
- 03 / Recuperar
- Acompanhar o progresso, mantendo confirmado e previsto separados.
- 04 / Resolver
- Confirmar a entrega, organizar despesas e preparar o pedido.
Certeza, previsão, desconhecido
Uma localização confirmada e um voo previsto têm rótulos diferentes. Nenhum promete uma data de entrega.
Confirmado
Evento verificado pela companhia aérea
Previsto
Um plano que pode mudar
Fornecido pelo passageiro
Informação partilhada do tracker
Desconhecido
Ainda não disponível
A linguagem muda consoante a fonte
Muda a fonte de informação para perceber porque a interface mantém estado e proveniência separados.
Um evento verificado pela companhia aérea pode ser mostrado como confirmado sem o transformar numa promessa de entrega.
- Fonte
- Sistema da companhia aérea
- A seguir
- Esperar pelo próximo evento de recuperação verificado.
Explicação interativa da lógica de design, não um feed real de uma companhia aérea.
O que passa para primeiro plano
Esquema da alteração de hierarquia documentada, não capturas das versões originais. Iteração de design; a compreensão dos passageiros ainda não foi testada.
Ver raciocínio
Dar prioridade ao estado atual em vez dos números de etapa
Tornei o estado mais visível e separei a próxima atualização. O último scan confirmado permanece visível, para que um voo planeado não pareça uma promessa de entrega.
Encontrada não significa que esteja a caminho
Uma localização confirmada não é uma estimativa de entrega. A interface separa o que a companhia aérea verificou de um plano que ainda pode mudar. Quando uma bagagem é encontrada, a data de entrega pode continuar desconhecida.
Localização confirmada ≠ data de entrega.
- Confirmado
- Um evento verificado pela companhia aérea.
- Esperado
- Um plano atual que pode mudar.
- Fornecido pelo passageiro
- Informação do viajante ou do seu tracker.
- Desconhecido
- Informação ainda não disponível.
Não haver uma nova atualização não significa que a procura tenha parado
O resumo mantém visível o último scan confirmado, explica a atividade atual do sistema e indica o que irá desencadear a próxima atualização. Assim, a espera ganha contexto sem inventar progresso.
Uma localização partilhada por tracker permanece separada da informação confirmada pela companhia aérea. A referência de partilha inclui localização aproximada, expiração ao fim de sete dias e opção de parar a partilha.
Despesas e apoio, ligados
Os recibos permanecem associados ao caso. O apoio começa com o histórico já anexado.
Ver raciocínio
Explicar despesas sem prometer reembolso
Enquanto a bagagem está atrasada, a interface explica compras essenciais e pede ao passageiro para guardar recibos. A companhia aérea decide quais os custos que reembolsa. Após a devolução, o caso de exemplo mostra o prazo de 21 dias para reclamação escrita por atraso.
A investigação distingue o limite de responsabilidade de 1.519 SDR de um orçamento de despesa ou reembolso automático. A referência do prazo é o artigo 31.º, n.os 2 e 3, da Convenção de Montreal; os danos têm um prazo diferente. Os procedimentos variam por companhia.
Referências de design: orientações de bagagem da KLM, Convenção de Montreal e revisão da ICAO com efeitos a 28 de dezembro de 2024. São regras usadas no conceito, não um serviço real de reclamações.
Quando o apoio abre, o caso já lá está
Antes de começar o chat ou o pedido de chamada, o agente recebe a referência do caso, descrição da bagagem, eventos confirmados e previstos, estado do tracker e despesas guardadas. O passageiro não deve ter de reconstruir toda a história.
- Histórico do caso
- Referência, dados da bagagem e eventos verificados.
- Contexto atual
- Recuperação prevista, localização partilhada e despesas guardadas.
Duas alterações que tornaram o próximo passo mais claro
No resumo de estado, aumentei o estado atual e dei uma linha própria à próxima atualização. O design anterior dava mais destaque à numeração das etapas; a revisão dá prioridade ao que o passageiro precisa de saber agora.
No apoio, movi o resumo do caso para cima das opções de contacto e clarifiquei que informação já está disponível para o agente. O contexto vem antes da escolha entre chat e pedido de chamada.
São iterações de design, não resultados de testes de usabilidade.
O estado muda com clareza
À procura / encontrada / voo atribuído. O último scan confirmado permanece visível durante todo o percurso.
Apenas verificações de design. Sem testes de usabilidade com passageiros nem ligação a uma companhia aérea real.
Ver raciocínio
O movimento assinala uma mudança de estado
A sequência do protótipo passa de procura, para correspondência confirmada, para voo de recuperação atribuído. O último scan confirmado mantém-se visível mesmo depois de existir um voo atribuído.
As transições usam 250 a 500 ms com easing ease-out. Um crossfade funciona como alternativa para movimento reduzido.
O que verifiquei. O que ainda precisa de ser testado
Verifiquei contraste, áreas de toque, rótulos de estado, alternativas para movimento reduzido e reflow com escala de texto a 120% em cinco ecrãs-chave. Nessas verificações de protótipo não surgiram colisões nem cortes de texto.
Cada atualização identifica a sua fonte e estado. Confirmado e previsto usam linguagem diferente, e o apoio mantém o histórico do caso. Não realizei testes de usabilidade com passageiros nem liguei o protótipo a um sistema real de bagagem. Dynamic Type completo, teclado, leitor de ecrã e zoom do browser exigem uma implementação em código.
Conseguem os passageiros distinguir atualizações confirmadas de estimativas sem explicação adicional?
- 7.9:1, Contraste Ink / Confirmed Blue
- 44×44, Critério de área de toque
- 120%, Verificação de reflow de texto
Par calculado: #0D2135 / #84BCDC = 7.937:1. As verificações do protótipo não constituem certificação de acessibilidade.