Design centrado no usuário (DCU) é uma abordagem de projeto que orienta decisões por evidências sobre as pessoas, suas tarefas e o contexto em que usam um produto ou serviço. Em vez de partir diretamente de uma funcionalidade solicitada, a equipe investiga o problema, estabelece requisitos, experimenta soluções e avalia se elas realmente ajudam alguém a alcançar um objetivo.
Na prática, o DCU exige uma mudança de pergunta. Em vez de “qual tela precisamos desenhar?”, comece com “que tarefa a pessoa está tentando concluir, o que a impede e como saberemos que melhorou?”. Esse deslocamento conecta pesquisa, estratégia, design e desenvolvimento sem transformar entrevistas ou testes em etapas burocráticas.
A referência internacional é a ISO 9241-210:2019, sobre human-centred design de sistemas interativos. A edição de 2019 foi revisada e confirmada em 2025. A norma trata de princípios e atividades ao longo do ciclo de vida do sistema; não prescreve uma sequência fixa de oficinas nem uma lista obrigatória de ferramentas.
O que é design centrado no usuário?
É uma maneira de tomar decisões de produto considerando explicitamente quem usa o sistema, o que precisa fazer, quais condições influenciam a tarefa e o que acontece quando uma solução é colocada à prova. Um checkout, por exemplo, não melhora apenas porque recebeu menos campos. A mudança precisa ser compreensível, compatível com as regras do serviço e verificada com pessoas que realizam aquela compra.
O termo costuma aparecer em inglês como user-centered design (UCD). A ISO utiliza human-centred design (HCD), ou design centrado no ser humano. Os conceitos são próximos e frequentemente se sobrepõem. “Humano” ajuda a lembrar que o projeto também pode envolver quem presta atendimento, acompanha a jornada ou é afetado pelas decisões, não somente quem toca a interface. Para este guia, DCU designa o processo de projetar experiências com base em necessidades e avaliação de usuários reais, sem reduzir o problema a uma tela.
Na definição da Interaction Design Foundation (IxDF), o envolvimento de usuários ocorre ao longo das iterações, com pesquisa, criação e avaliação. Isso não significa seguir literalmente toda sugestão recebida. Significa entender a necessidade por trás do relato e verificar as soluções propostas.
DCU é a mesma coisa que UX Design ou Design Thinking?
Não exatamente. O UX Design é o campo de trabalho sobre a experiência das pessoas com produtos e serviços. O DCU é uma abordagem de projeto que ajuda equipes de UX e produto a fundamentar suas decisões. O Design Thinking é uma família de abordagens de resolução de problemas, com práticas de compreensão, exploração e teste; pode utilizar princípios centrados no usuário, mas não substitui automaticamente pesquisa e avaliação de uso.
Já design inclusivo amplia a atenção às pessoas e aos contextos que decisões de projeto costumam deixar de fora. Uma equipe pode adotar DCU e ainda assim excluir pessoas com deficiência se sua amostra e seus materiais não permitirem participação. Por isso, os dois assuntos se complementam: veja o guia da CamaraUX sobre design inclusivo.
Os seis princípios de design centrado no ser humano da ISO 9241-210
Uma confusão recorrente é apresentar quatro etapas do processo como se fossem os princípios da ISO. São coisas diferentes. A síntese do NIST, instituto de padrões e tecnologia dos Estados Unidos, explicita seis princípios; mais adiante veremos as quatro atividades que orientam o trabalho.
1. Entenda pessoas, tarefas e ambientes de uso
Conhecer o perfil de quem usa o produto não é o mesmo que entender o uso. Investigue quais tarefas precisam ser concluídas, que conhecimentos são necessários, em quais dispositivos ou ambientes a pessoa age e quais sistemas externos influenciam o resultado. A mesma interface pode ser usada por alguém em um escritório silencioso ou por alguém com conexão instável durante o expediente.
Evidência esperada: descrição das tarefas, do contexto e das dificuldades observadas, com fonte e limites claros. Dados de analytics podem indicar onde há abandono; entrevistas e observação ajudam a investigar por que isso acontece.
2. Envolva usuários durante o desenvolvimento
Convidar usuários apenas para aprovar uma solução pronta chega tarde para questionar o problema. A participação pode acontecer ao entender necessidades, avaliar conceitos, testar um protótipo e acompanhar o serviço em produção. O formato e o número de participantes dependem da pergunta e do método, não de uma cota universal.
Evidência esperada: registros de observações e resultados de avaliações que tiveram influência em decisões documentadas. A orientação do GOV.UK Service Manual é pesquisar de forma contínua, incluindo pessoas que enfrentam barreiras de acesso.
3. Avalie o design com base no uso
Uma revisão interna pode identificar inconsistências, mas não demonstra que a pessoa entende os rótulos, encontra o caminho e reconhece o resultado. Avalie as propostas a partir de tarefas e critérios estabelecidos. Observe comportamentos, dificuldades e alternativas, sem conduzir o participante até a resposta desejada.
Evidência esperada: registro de sucesso ou falha na tarefa, obstáculos e perguntas que continuam sem resposta. Não trate opinião favorável sobre a aparência como comprovação de facilidade de uso.
4. Trabalhe de forma iterativa
Uma solução inicial pode falhar por um motivo inesperado. Iterar significa usar a avaliação para alterar uma hipótese, um requisito, um fluxo ou uma interação e testá-los novamente. Nem toda descoberta pede refazer a interface inteira; às vezes o problema está na mensagem de erro ou na regra de negócio.
Evidência esperada: o que foi alterado, por que foi alterado e como a nova versão foi comparada à anterior. A Nielsen Norman Group destaca a importância de explorar e avaliar alternativas, em vez de apostar em uma única proposta.
5. Considere a experiência completa
O produto não começa na primeira tela nem termina no clique de confirmação. Mensagens, prazos, atendimento, notificações, recuperação de erro e interações fora do canal digital também fazem parte da experiência. Uma reserva pode ser fácil de fazer e difícil de cancelar: nesse caso, o fluxo completo ainda não está resolvido.
Evidência esperada: mapeamento dos pontos de contato necessários à tarefa e análise das consequências para pessoas e equipes envolvidas.
6. Trabalhe com perspectivas multidisciplinares
Designer, pesquisa, produto, desenvolvimento, atendimento, acessibilidade e áreas operacionais enxergam riscos diferentes. Colaboração não significa validar cada pixel em uma reunião grande, mas tornar disponíveis evidências e restrições para que a solução seja desejável, viável e implementável.
Evidência esperada: decisões e responsabilidades explícitas, incluindo requisitos de negócio e limitações técnicas, sem substituir a perspectiva das pessoas usuárias pela opinião dos especialistas.
As quatro atividades do processo centrado no usuário
Os seis princípios orientam como trabalhar. As quatro atividades, descritas pelo NIST e pela IxDF, ajudam a organizar o que investigar, produzir e avaliar. Elas se repetem, não necessariamente em sequência linear.
| Atividade | Pergunta central | Entregável útil |
|---|---|---|
| Entender e especificar o contexto de uso | Quem precisa fazer o quê, em quais condições e com quais obstáculos? | Tarefas, contexto, evidências e hipóteses registradas |
| Especificar requisitos dos usuários | O que a solução precisa permitir e quais restrições deve respeitar? | Requisitos verificáveis e critérios de sucesso |
| Produzir soluções de design | Quais alternativas atendem aos requisitos sem criar novas barreiras? | Fluxos, esboços, protótipos e decisões justificadas |
| Avaliar em relação aos requisitos | As pessoas conseguem concluir a tarefa nas condições necessárias? | Resultados de avaliação, prioridades e próxima iteração |
É possível começar com uma investigação pequena, descobrir uma regra de negócio ignorada durante a avaliação e retornar aos requisitos. O ciclo serve para reduzir incerteza, não para produzir documentos em uma ordem cerimonial.
Exemplo prático: redesenhar o agendamento de atendimento para MEI
Imagine um serviço digital fictício no qual microempreendedores precisam agendar um atendimento. O negócio solicita “modernizar o calendário” porque percebe desistências. Esse pedido já contém uma solução presumida: trocar a interface do calendário. O processo centrado no usuário começa sem aceitar essa suposição como diagnóstico.
Etapa 1: diferencie o sintoma do problema
O sintoma conhecido é o abandono do agendamento. Antes de redesenhar, a equipe procura evidências: em qual ponto as sessões são interrompidas? Há mensagens de erro? Quais dúvidas chegam ao atendimento? As pessoas sabem quais documentos preparar? Conseguem encontrar uma data compatível com sua rotina?
Hipóteses, não resultados de pesquisa: talvez o calendário dificulte a comparação de horários; talvez as datas estejam indisponíveis; talvez o serviço peça informações antes de explicar o benefício da consulta. Nenhuma dessas causas está comprovada no cenário fictício.
Etapa 2: transforme observações em requisitos
Suponha que uma rodada de investigação venha a revelar dificuldade em comparar dias e horários, além de dúvidas sobre o que acontece após confirmar. A equipe poderia registrar requisitos como “mostrar disponibilidade de modo distinguível sem depender apenas de cor”, “informar duração e modalidade do atendimento antes da escolha” e “exibir resumo completo após confirmar”. Cada requisito precisa ser relacionado a uma evidência observável.
Dizer apenas “deixar o calendário intuitivo” não permite verificar se o trabalho foi concluído. Em vez disso, estabeleça critérios, como localizar uma opção disponível, compreender a confirmação e conseguir retornar para alterar a escolha.
Etapa 3: explore soluções antes de escolher uma
Uma alternativa usa calendário mensal; outra oferece uma lista dos próximos horários disponíveis. Ambas podem atender à mesma necessidade, mas respondem de forma diferente às restrições de tela, navegação por teclado e disponibilidade do serviço. Compare as duas em protótipos simples antes de investir em interface de alta fidelidade. Para isso, aprofunde-se em prototipagem UX e user flow.
Etapa 4: avalie a tarefa e decida
Peça que participantes compatíveis com o público do serviço agendem um atendimento em uma situação realista. Observe se encontram um horário, entendem as condições, identificam o que foi confirmado e sabem alterar ou cancelar. Registre dificuldades e falas como evidência, sem transformar uma sessão isolada em prova universal.
Se os problemas principais estiverem relacionados à indisponibilidade real da agenda, mudar o componente visual não resolverá a causa. Essa também é uma conclusão útil do DCU: às vezes a decisão correta é revisar uma política ou processo, não desenhar outra tela.
Matriz: da evidência à decisão de produto
A tabela abaixo é um modelo de planejamento, não apresenta resultados de uma pesquisa realizada pela CamaraUX.
| Sinal observado ou hipótese | O que investigar | Requisito ou alternativa | Como verificar |
|---|---|---|---|
| Abandono ao escolher horário | A pessoa entende disponibilidade e filtros? | Comparar lista de horários e calendário | Tarefa de localizar horário compatível |
| Dúvida após confirmação | O resumo comunica data, local e modalidade? | Confirmação com detalhes e próximo passo | Compreensão sem ajuda após finalizar |
| Solicitações repetidas ao suporte | Qual informação o serviço deixa de explicar? | Orientações no momento necessário | Observar dúvidas e contatos posteriores |
| Erro ao retornar à etapa anterior | O sistema preserva escolhas válidas? | Retorno sem perder dados | Percorrer ida e volta do fluxo |
Como implementar DCU em um projeto sem criar burocracia
Em equipes pequenas, o risco costuma ser confundir o processo com uma grande sequência de workshops. Comece com uma decisão relevante e organize um ciclo enxuto de aprendizagem. A rotina abaixo é uma adaptação prática para times de produto, não uma lista obrigatória de passos da ISO.
Ciclo operacional de DCU: da pergunta de produto à validação e ao acompanhamento.
Defina a pergunta e a decisão
Descreva a tarefa e qual decisão de produto precisa de evidência. Escreva hipóteses como questões que podem ser investigadas.
Reúna evidências relevantes
Revise pesquisas existentes, suporte e dados de uso. Se faltar evidência, escolha um método e recrute pessoas compatíveis com a tarefa.
Especifique requisitos verificáveis
Transforme as necessidades observadas em requisitos de uso, critérios de sucesso e restrições técnicas e de acessibilidade.
Desenhe alternativas
Explore fluxos ou protótipos suficientes para comparar caminhos possíveis, sem partir de uma única solução definitiva.
Avalie e decida
Observe pessoas em tarefas realistas, registre barreiras e compare os resultados com os requisitos antes de selecionar ou revisar a solução.
Registre e acompanhe
Documente a decisão, as evidências, os riscos restantes e os indicadores que serão acompanhados depois da implementação.
O primeiro encontro com stakeholders deve explicitar qual decisão precisa ser tomada. A seguir, selecione a menor investigação capaz de diminuir a incerteza que impede essa decisão. Pode ser analisar tickets, observar pessoas em uma tarefa, examinar dados de produto ou testar conceitos; uma fonte única costuma mostrar apenas parte do problema. O manual de métodos de pesquisa UX ajuda a escolher o método em função da pergunta, não da ferramenta disponível.
Ao compartilhar os resultados, separe observação, interpretação, hipótese e decisão. “Três pessoas não identificaram o botão” é uma observação da amostra; “o rótulo pode estar pouco claro” é uma hipótese de causa. Essa separação diminui a chance de transformar uma opinião de equipe em evidência.
Uma boa prática é manter um registro curto com: problema investigado, fonte da informação, decisão tomada, pessoa responsável, critério de sucesso e data da próxima verificação. Não é preciso produzir uma apresentação extensa para cada ciclo; é preciso evitar que a justificativa da decisão desapareça.
Vídeo: como registrar suposições durante o processo de UX
Um desafio real do DCU aparece quando a equipe precisa decidir antes de ter evidência suficiente. No vídeo oficial Assumptions: How to Track Them in the UX Design Process, a Nielsen Norman Group explica por que registrar suposições e revisá-las ao longo das iterações é mais seguro do que tratá-las como fatos. É um complemento ao modelo de evidência acima, em inglês.
Como medir se o processo está melhorando o produto
Evite usar apenas a quantidade de entrevistas, telas criadas ou workshops realizados como prova de resultado. São atividades, não evidências de que as pessoas passaram a atingir o objetivo com menos barreiras. Escolha indicadores que respondam à tarefa estudada e estabeleça um ponto de comparação.
| Dimensão | Exemplo de indicador | Atenção ao interpretar |
|---|---|---|
| Eficácia | Proporção de pessoas que concluem a tarefa definida | Defina o que conta como conclusão, inclusive com ajuda ou erros |
| Eficiência | Tempo e esforço para realizar a tarefa | Menor tempo não significa melhoria quando há decisões importantes |
| Compreensão | Capacidade de explicar o resultado após uma confirmação | Avalie entendimento, não só preferência estética |
| Acessibilidade | Barreiras encontradas com tecnologias assistivas e diferentes condições de uso | Não confunda conformidade técnica com participação efetiva |
| Operação | Contatos ao suporte ou retrabalho relacionados ao fluxo | Mudanças operacionais podem alterar os números independentemente do layout |
Use métricas qualitativas e quantitativas conforme a pergunta. Se a equipe ainda não possui uma linha de base, registre essa limitação antes de afirmar melhora. Resultados podem variar por contexto, volume e perfil; uma variação depois do lançamento não prova causalidade, por si só. Para aprofundar, veja as métricas de UX e o benchmark de UX.
O que não é design centrado no usuário
Não é simplesmente perguntar o que as pessoas querem. Relatos ajudam a compreender objetivos e dificuldades, mas podem não revelar todas as condições da tarefa. Combine o que as pessoas dizem com observação, dados e avaliação de uso.
Não é executar toda sugestão literal de um participante. O usuário conhece seu problema e sua experiência; cabe à equipe avaliar alternativas que respeitem necessidades, restrições técnicas, acessibilidade e sustentabilidade do serviço.
Não é validar somente no lançamento. Se o primeiro contato com usuários acontece quando a interface está aprovada, a investigação pode ficar limitada a ajustes superficiais. O processo precisa permitir voltar a hipóteses e requisitos.
Não é criar uma persona fictícia e encerrar a pesquisa. Personas podem comunicar aprendizados, desde que construídas e revistas com evidências. Não substituem a participação de pessoas reais, especialmente grupos frequentemente excluídos. Veja o guia de pesquisa UX inclusiva.
Não é apenas uma tarefa do designer. Quem define regras, prazos, tecnologia, atendimento e operação influencia diretamente a experiência. A visão multidisciplinar serve para discutir esse sistema completo.
E quando não há orçamento para pesquisa extensa?
É possível começar com evidências já disponíveis, desde que a equipe registre seus limites: tickets de suporte, dúvidas recorrentes, análises de abandono, entrevistas anteriores e observação de atendimento são pontos de partida úteis. Depois, escolha uma pergunta de maior risco e organize uma rodada pequena de investigação direcionada. Nenhuma quantidade de dashboards substitui automaticamente observar pessoas quando a dúvida é sobre interpretação ou contexto.
No GOV.UK Service Manual, a orientação é atualizar o planejamento conforme a equipe aprende, priorizando perguntas relevantes em vez de pesquisar tudo ao mesmo tempo. O princípio também vale para empresas: pesquisar pouco, com uma pergunta clara, pode ser melhor do que produzir muitos artefatos que não influenciam uma decisão.
Checklist para avaliar se uma decisão foi centrada no usuário
- [ ] A tarefa e o resultado esperado estão descritos sem pressupor uma solução.
- [ ] Sabemos de onde vêm as informações sobre usuários, contexto e barreiras.
- [ ] Diferenciamos observações, interpretações, hipóteses e recomendações.
- [ ] Os requisitos estão ligados a necessidades e possuem critérios verificáveis.
- [ ] Consideramos pessoas com diferentes capacidades e condições de uso.
- [ ] Exploramos alternativas e sabemos por que selecionamos uma delas.
- [ ] Avaliamos a solução em uma tarefa relevante, com participantes adequados.
- [ ] Registramos o que mudou após a avaliação e o que ainda precisa ser aprendido.
- [ ] Definimos responsáveis e métricas para acompanhar a experiência após o lançamento.
O valor do DCU está na qualidade da decisão. Um time não se torna centrado no usuário porque adicionou uma etapa chamada “pesquisa” ao cronograma. Torna-se mais centrado no usuário quando consegue mostrar qual evidência mudou uma decisão, como verificou o resultado e o que fará caso a hipótese não se confirme.
Perguntas frequentes sobre design centrado no usuário
Design centrado no usuário exige entrevistas em todo projeto?
Não. O método depende da pergunta e das evidências disponíveis. Entrevistas, observação, testes de usabilidade, atendimento e dados de uso podem contribuir de maneiras diferentes. O essencial é não apresentar suposições internas como necessidades já comprovadas.
Qual é a diferença entre design centrado no usuário e Design Thinking?
O DCU é uma abordagem para orientar decisões por necessidades, contexto de uso e avaliação contínua. Design Thinking organiza práticas de exploração e resolução de problemas. As abordagens podem ser combinadas, mas uma oficina de ideação não substitui evidências com usuários.
É possível aplicar DCU em uma equipe pequena?
Sim. Comece por uma decisão de alto risco, reúna a evidência disponível, teste a hipótese com o método adequado e registre a decisão. O DCU não exige uma equipe grande nem uma coleção fixa de artefatos.
Design centrado no usuário e design centrado no ser humano são sinônimos?
Os conceitos se sobrepõem bastante, mas o termo human-centred design pode enfatizar um sistema mais amplo de pessoas afetadas pelo serviço. A ISO 9241-210 utiliza design centrado no ser humano; ambos valorizam contexto, participação e avaliação.
Referências e leituras recomendadas
- ISO. ISO 9241-210:2019 — Human-centred design for interactive systems. Padrão internacional; página oficial de referência. A norma completa é licenciada e não foi reproduzida aqui.
- NIST. Human Centered Design (HCD). Síntese dos seis princípios e das quatro atividades.
- Interaction Design Foundation. User Centered Design (UCD). Definição e caráter iterativo do processo.
- Nielsen Norman Group. Parallel and Iterative Design + Competitive Testing. Exploração, avaliação e refinamento de soluções.
- Nielsen Norman Group. Assumptions: How to Track Them in the UX Design Process. Vídeo oficial para complementar o guia.
- GOV.UK Service Manual. Plan user research for your service. Planejamento e aplicação contínua de pesquisa.
- GOV.UK. Government Design Principles. Necessidades reais, iteração e contexto.
- W3C WAI. Involving Users in Web Projects for Better Accessibility. Inclusão de pessoas com deficiência no desenvolvimento.
