Serviços Financeiros
Concept Case Study — MCD Lab
FinFlow
Um pedido de financiamento digital repensado de raiz: menos esforço percebido, decisões mais claras e confiança em cada passo.
Serviços
- UX Research
- Product Strategy
- UX Design
- UI Design
- Design System
- Accessibility
- UX Analytics
Disciplinas
- Research
- Product Strategy
- Product Design
- Design System
- Acessibilidade
FinFlow é um estudo conceptual independente, desenvolvido pelo MCD Lab. Não representa um cliente real, nem contém resultados, métricas, testemunhos ou dados de utilizadores reais.
02
Visão geral
O FinFlow explora como seria um produto financeiro digital desenhado à volta da compreensão, e não do formulário.
Contexto
Pedidos de financiamento online acumulam passos, documentos e regras que raramente são explicados a quem os percorre.
Objetivo
Desenhar um percurso onde cada passo é curto, previsível e justificado — do primeiro ecrã à confirmação.
Abordagem
Estruturar a jornada, reduzir a carga por ecrã e construir um sistema de interface consistente e acessível.
03
O desafio
O problema deste tipo de produto raramente é visual. É de compreensão: pede-se muito, explica-se pouco e os erros só aparecem no fim.
- Percursos longos sem noção de progresso
- Linguagem técnica em momentos de decisão
- Documentos pedidos sem contexto
- Erros detetados tarde, já depois do esforço
04
A pergunta de design
Como tornar um processo financeiro complexo compreensível, sem o simplificar em excesso nem esconder o que é importante?
Esta pergunta orientou todas as decisões seguintes do estudo.
05
Descoberta
Este é um estudo conceptual: não foi conduzida investigação com utilizadores reais. A descoberta assentou em análise documental e em padrões estabelecidos de design de interação.
Análise de padrões
Estudo de fluxos de candidatura digital e de convenções já validadas na literatura de UX.
Mapeamento de tarefas
Decomposição do pedido em tarefas mínimas, dependências e pontos de espera.
Heurísticas
Revisão do fluxo à luz de heurísticas de usabilidade e de prevenção de erro.
Normas de acessibilidade
Leitura das WCAG 2.2 AA como restrição de design desde o início, não como revisão final.
Sem entrevistas, sem amostras, sem conclusões apresentadas como evidência empírica.
06
Necessidades assumidas
Necessidades conceptuais, formuladas como hipóteses de trabalho a validar num contexto real.
Saber onde estou
Perceber quanto falta antes de começar e durante.
Perceber porquê
Saber a razão de cada dado ou documento pedido.
Poder parar
Interromper e retomar sem perder o que já foi feito.
Confiar
Perceber o que acontece aos dados e o que vem a seguir.
07
Princípios de experiência
- 01
Um passo, uma decisão
Cada ecrã pede o mínimo necessário para avançar.
- 02
Explicar antes de pedir
O contexto aparece junto ao campo, não em rodapé.
- 03
Prevenir em vez de corrigir
Validar no momento da introdução, não no fim.
- 04
Consistência acima de novidade
Padrões repetidos reduzem a carga cognitiva.
08
Arquitetura de informação
O pedido foi reorganizado por intenção do utilizador — e não pela estrutura interna de um sistema.
- 01
Simulação
Montante, prazo e estimativa antes de qualquer dado pessoal.
- 02
Dados pessoais
Identificação em blocos curtos, com progresso visível.
- 03
Informação financeira
Rendimento e encargos com explicação do propósito.
- 04
Documentos
Pedido no momento certo, com estado individual por ficheiro.
- 05
Revisão
Resumo editável antes de qualquer submissão.
09
Progressive disclosure
Em vez de um formulário monolítico, o percurso revela informação à medida que é necessária, mantendo sempre o progresso à vista.
- Indicador de passo sempre presente
- Blocos curtos com um objetivo cada
- Detalhe adicional disponível a pedido
10
Dashboard do pedido
O pedido deixa de ser um túnel e passa a ter um sítio próprio: um painel que mostra estado, próximos passos e histórico.
- Estado atual em linguagem simples
- Próxima ação sempre identificada
- Continuidade entre dispositivos
11
Formulários inteligentes
Os campos foram desenhados para reduzir esforço: agrupamento lógico, formatos assistidos e ajuda contextual.
- Etiquetas visíveis, nunca só placeholder
- Formatação assistida em datas e valores
- Ajuda inline junto ao campo que a exige
12
Prevenção de erro
O objetivo não é mostrar erros melhor: é evitar que aconteçam.
- Validação no momento da introdução
- Mensagens que explicam como corrigir
- Nenhuma perda de dados ao voltar atrás
- Confirmação explícita antes de ações irreversíveis
13
Envio de documentos
O momento mais frágil do processo passou a ter estado próprio, requisitos claros e recuperação simples.
- 01
Antes
O que é pedido, porquê e em que formatos.
- 02
Durante
Progresso do envio e verificação imediata do ficheiro.
- 03
Depois
Estado por documento e ação clara quando algo falha.
14
Revisão e confirmação
Antes de submeter, tudo o que foi introduzido é mostrado num resumo editável, sem surpresas no último ecrã.
- Resumo por secção, com edição direta
- Condições visíveis antes da submissão
- Confirmação com próximos passos explícitos
15
Acessibilidade
As WCAG 2.2 AA foram tratadas como restrição de design, não como auditoria final.
- Contraste verificado em todos os estados
- Percurso completo por teclado
- Áreas de toque generosas em mobile
- Erros associados programaticamente aos campos
- Respeito por preferências de movimento reduzido
16
Mobile first
O percurso foi pensado primeiro no ecrã mais pequeno, onde a carga é mais sentida — e só depois expandido.
- Uma decisão por ecrã
- Ações principais ao alcance do polegar
- Progresso e ação seguinte sempre visíveis
17
Design system
O FinFlow assenta num sistema próprio de tokens e componentes, pensado para escalar sem perder coerência.
- Tokens de cor, tipografia, espaço e raio
- Componentes de formulário com todos os estados
- Padrões de progresso, estado e feedback
- Regras de conteúdo e tom de voz
18
Confiança
Num contexto financeiro, a confiança constrói-se com clareza — não com selos ou promessas.
- Explicar o uso de cada dado no momento em que é pedido
- Mostrar sempre o que acontece a seguir
- Evitar linguagem comercial em momentos de decisão
19
Do conceito inicial à experiência refinada
Conceito interno — não é um cliente real
Comparação entre a primeira exploração interna do fluxo e a versão refinada do conceito. Ambos os lados são trabalho do MCD Lab — nenhum representa um produto real.
20
Como o sucesso seria medido
Nenhum resultado é apresentado: este estudo define apenas o que faria sentido medir num contexto real.
- Taxa de conclusão por passo
- Abandono associado a campos específicos
- Frequência e tipo de erro por formulário
- Tempo até à submissão completa
- Pedidos de ajuda por etapa
21
UX Analytics
Dados ilustrativos
O conceito prevê um plano de medição desde o design: eventos nomeados, funil por passo e leitura por dispositivo.
- Eventos definidos ao nível do componente
- Funil do pedido do início à confirmação
- Segmentação por dispositivo e por passo
Qualquer valor visível nas imagens é conteúdo ilustrativo de interface, não um resultado.
22
Experimentação e validação futura
O que seria necessário fazer para transformar hipóteses em evidência.
- 01
Testes de usabilidade
Percursos moderados com participantes reais.
- 02
Testes A/B
Comparar variantes de agrupamento e de linguagem.
- 03
Auditoria de acessibilidade
Validação assistiva com utilizadores.
- 04
Investigação longitudinal
Acompanhar pedidos ao longo de semanas.
23
Resultado do estudo
O FinFlow resulta num sistema completo e coerente, pronto a ser testado — não num conjunto de resultados.
- Um fluxo completo, do primeiro ecrã à confirmação
- Um design system aplicável a outros produtos financeiros
- Um plano de medição e de validação definido
Nota final
O FinFlow demonstra o método do estúdio: estruturar a complexidade, desenhar com restrições reais e deixar tudo preparado para ser medido.