Demasiado produto, dito tudo de uma vez.
A plataforma geria pedidos, aprovações, documentos confidenciais e processos administrativos para vários papéis da organização: quem cria pedidos, administradores e responsáveis seniores que os analisam, delegam e aprovam.
Com o tempo, acumulou complexidade. Formulários densos, estados pouco claros, feedback inconsistente e falhas de acessibilidade obrigavam as pessoas a perceber o sistema antes de o poderem usar. A quantidade de funcionalidades não era o problema. A forma como eram comunicadas, era.
- 01Criar e submeter pedidos através de formulários complexos, em vários passos
- 02Carregar e gerir documentos, alguns deles confidenciais
- 03Acompanhar o progresso, rever, aprovar e delegar
- 04Perceber quem fez o quê, e ver apenas o que o seu papel permite
Menos carga cognitiva. A mesma capacidade.
Antes: emails, folhas de cálculo e chats entre equipas. Depois: um pedido com responsável, estado e próximo passo claros.
Cinco movimentos que o reformularam.
Os ecrãs usam conteúdo fictício. Os dados reais e os detalhes do cliente são confidenciais.
Olhar para o sistema, não para os ecrãs.
Analisei a experiência como um conjunto de percursos ligados: criação de pedidos, gestão de pedidos, delegação e atividade, documentos e dashboards. Os mesmos problemas repetiam-se: demasiados estados para ler de relance, atualizações importantes perdidas no ruído, tabelas grandes e repetitivas, e detalhes de pedido com muitas secções de metadados.
Por baixo estavam seis problemas recorrentes: carga cognitiva elevada, feedback ambíguo, estados inconsistentes, falhas de acessibilidade, formulários complexos e jargão interno.
Pergunta-guia: o que precisa este utilizador em concreto de perceber, decidir ou fazer neste ponto do percurso?
Mapear quem toca num pedido, e quando.
Cada pedido passa por várias equipas: requerente, responsável de setor, revisor, jurídico, financeiro e aprovação final. Mapeei o ciclo de vida de ponta a ponta para tornar explícitos os papéis, as passagens de testemunho, as mudanças de estado e os caminhos de devolução.
Os pedidos reais não seguem em linha reta. Podem ser devolvidos para mais informação em qualquer fase, delegados a outra equipa ou pessoa, ou escalados. O mapa tornou-se a base da linguagem de estados e das vistas por papel.
Decisão: desenhar para todos os caminhos que um pedido pode seguir, não só o caminho feliz.
Mais fácil de perceber, não só mais curto.
O fluxo em vários passos foi reestruturado em fases claras: informação, validação, revisão e submissão. Em vez de dar o mesmo peso a todos os requisitos, cada passo mostra o que é preciso agora.
Os campos relacionados estão agrupados, os obrigatórios são explícitos, a prioridade é uma escolha simples, e os termos que não puderam ser simplificados têm uma explicação contextual. Os rascunhos podem ser guardados, e cancelar nunca é ambíguo.
Princípio: reduzir a carga cognitiva sem esconder a complexidade de que o negócio precisa.
Contexto antes da ação.
Quem aprova não está a introduzir dados. Precisa de perceber um pedido e decidir. O detalhe do pedido responde ao que é, quem o submeteu, que documentos o sustentam, o que já aconteceu e o que muda depois de aprovar ou rejeitar. A atividade passou a ser um fluxo legível: quem, fez o quê, quando, em que contexto.
O dashboard transformou-se num espaço de trabalho operacional: números-chave de relance, notificações que mostram o que mudou e uma tabela de pedidos com estado, prazo e responsável, que se pode pesquisar e filtrar. Cada papel vê a informação e as ações que lhe dizem respeito.
Decisão: aprovar, rejeitar e delegar estão claramente separados das ações secundárias, para que uma decisão nunca seja um clique enganado.
De ecrãs a padrões.
Construí uma base de UI reutilizável com as equipas de desenvolvimento e entrega, pensada para funcionar com o modelo de implementação da plataforma: formulários, tabelas, estados, notificações, janelas, interações com documentos, e estados vazios, de carregamento, de erro e de sucesso.
A acessibilidade fez parte desde o início: etiquetas claras, foco visível, contraste suficiente, validação explícita e estados que nunca dependem só da cor. Como team lead, revi o trabalho e ajudei os outros designers a usar uma linguagem comum.
A mudança para a equipa: de «como devemos desenhar este ecrã?» para «que padrão deve o produto usar sempre que este problema surge?»
Uma experiência de produto coerente e escalável.
O projeto definiu uma direção de UX mais clara para uma plataforma complexa de gestão de processos, e uma base para o desenvolvimento futuro do produto.
- 01Fluxos complexos estruturados em percursos mais claros
- 02Estados do sistema comunicados de forma consistente
- 03Principais problemas de acessibilidade resolvidos
- 04Experiências de pedido e aprovação mais claras
- 05Atividade e responsabilidade visíveis
- 06Padrões de UI reutilizáveis em todo o produto
As métricas quantitativas e a informação que identifica o cliente não podem ser divulgadas, por restrições de confidencialidade.
Aprendizagens e próximos passos
Tornar a complexidade compreensível, não simples.
- 01O UX empresarial é sobretudo gerir complexidade. Raramente faltam funcionalidades. O trabalho é decidir o que as pessoas veem, quando, e com que contexto.
- 02A consistência é uma funcionalidade de UX. Quando as interações se comportam de forma previsível, as pessoas gastam menos esforço a aprender a interface.
- 03A acessibilidade melhora-o para todos. Hierarquia, feedback e estados de foco mais claros ajudam todos os utilizadores, não só quem tem necessidades de acessibilidade.
- 04Sistemas vencem ecrãs. As soluções mais fortes foram padrões que resolviam o mesmo problema em muitos percursos.
A explorar uma ideia semelhante no seu serviço ou organização?
Seja um processo de aprovação que ninguém percebe, uma ferramenta empresarial que ficou demasiado complexa, ou um design system para juntar uma equipa, podemos começar por uma conversa.
Nuno Flórido é UX/UI Designer e Design Team Lead na S4 Digital, em Setúbal, com experiência em projetos de transformação digital nos setores público e privado a nível internacional. Trabalha com IA e métodos de user experience desde a descoberta: definir o problema a resolver e fechar uma solução de cada vez.
Too much product, said all at once.
The platform managed requests, approvals, confidential documents and administrative processes for roles across the organisation: people creating requests, administrators, and senior stakeholders reviewing, delegating and approving them.
Over time it had accumulated complexity. Dense forms, unclear statuses, inconsistent feedback and accessibility gaps meant people had to understand the system before they could use it. The amount of functionality wasn’t the problem. The way it was communicated was.
- 01Create and submit requests through complex, multi-step forms
- 02Upload and manage documents, some of them confidential
- 03Follow progress, review, approve and delegate
- 04Understand who did what, and see only what their role allows
Less cognitive load. The same capability.
Before: emails, spreadsheets and chats across teams. After: one request with clear ownership, status and next step.
Five moves that reshaped it.
Screens use placeholder content. Real data and client details are confidential.
Looking at the system, not the screens.
I analysed the experience as a set of connected journeys: request creation, request management, delegation and activity, documents, and dashboards. The same problems kept appearing: too many statuses to read at a glance, important updates lost in the noise, large repetitive tables, and request details with many sections of metadata.
Underneath sat six recurring issues: high cognitive load, ambiguous feedback, inconsistent statuses, accessibility gaps, complex forms and internal jargon.
Guiding question: what does this specific user need to understand, decide or do at this point in the journey?
Mapping who touches a request, and when.
Each request passes through several teams: requester, sector lead, reviewer, legal, finance and final approval. I mapped the end-to-end lifecycle to make roles, hand-offs, status changes and return paths explicit.
Real requests don’t move in a straight line. They can be returned for more information at any stage, delegated to another team or person, or escalated. The map became the basis for the status language and the role-based views.
Decision: design for every path a request can take, not only the happy one.
Easier to understand, not just shorter.
The multi-step flow was restructured into clear phases: information, validation, review and submission. Instead of giving every requirement equal weight, each step shows what is needed now.
Related fields are grouped, required fields are explicit, priority is a simple choice, and terms that couldn’t be simplified get a contextual explanation. Drafts can be saved, and cancelling is never ambiguous.
Principle: reduce cognitive load without hiding the complexity the business requires.
Context before action.
An approver isn’t entering data. They need to understand a request and decide. The request detail answers what it is, who submitted it, which documents support it, what already happened, and what changes after approving or rejecting. Activity became a readable workflow: who, did what, when, in which context.
The dashboard turned into an operational workspace: key numbers at a glance, notifications that surface what changed, and a request table with status, due date and owner that people can search and filter. Each role sees the information and actions relevant to it.
Decision: approve, reject and delegate are clearly separated from secondary actions, so a decision is never a misclick.
From screens to patterns.
I built a reusable UI foundation with development and delivery teams, designed to work with the platform’s implementation model: forms, tables, statuses, notifications, modals, document interactions, and empty, loading, error and success states.
Accessibility was part of it from the start: clear labels, visible focus, sufficient contrast, explicit validation, and states that never rely on colour alone. As team lead I reviewed work and helped other designers use one shared language.
The shift for the team: from “how should we design this screen?” to “what pattern should the product use whenever this problem occurs?”
A coherent, scalable product experience.
The project set a clearer UX direction for a complex process-management platform, and a foundation for future product development.
- 01Complex workflows structured into clearer journeys
- 02System states communicated consistently
- 03Key accessibility issues addressed
- 04Clearer request and approval experiences
- 05Visible activity and ownership
- 06Reusable UI patterns across the product
Quantitative metrics and identifiable client information can’t be disclosed because of confidentiality restrictions.
Learnings & next steps
Make complexity understandable, not simple.
- 01Enterprise UX is mostly managing complexity. Rarely is functionality missing. The work is deciding what people see, when, and with how much context.
- 02Consistency is a UX feature. When interactions behave predictably, people spend less effort learning the interface.
- 03Accessibility improves it for everyone. Clearer hierarchy, feedback and focus states help every user, not only those with accessibility needs.
- 04Systems beat screens. The strongest solutions were patterns that solved the same problem across many journeys.
Exploring a similar idea in your service or organisation?
Whether it’s an approval process nobody understands, an enterprise tool that grew too complex, or a design system to bring a team together, we can start with a conversation.
Nuno Flórido is a UX/UI Designer and Design Team Lead at S4 Digital, based in Setúbal, with experience in digital transformation projects across the public and private sectors internationally. He works with AI and user experience methods from discovery onwards: defining the problem to solve and closing one solution at a time.