É fácil discutir telas porque elas são visíveis.
Um painel pode ser esboçado. Um formulário pode ser reorganizado. Uma árvore de navegação pode ser debatida. As partes interessadas podem apontar para um protótipo e reagir imediatamente.
O modelo de produto por trás disso é mais difícil de enxergar.
Quem pode executar uma ação? Quais transições de estado são válidas? O que um registro significa? Qual informação é a referência oficial? Quais permissões dependem do contexto? O que acontece quando um processo atravessa organizações?
Quando os times começam pelas telas cedo demais, essas perguntas não desaparecem. Elas ficam escondidas nas decisões de interface.
Uma sequência mais sólida começa pelas capacidades.
Uma tela é uma projeção de um sistema
A tela não é a capacidade em si.
Uma página de “Cadastrar aluno” pode representar uma capacidade que envolve:
- identidade do responsável;
- identidade do aluno;
- autorização baseada no vínculo;
- vínculo com a escola;
- regras de elegibilidade;
- consentimento;
- detecção de duplicidades;
- estado do convite;
- histórico de auditoria.
A tela é uma representação dessa capacidade para um ator em um contexto.
Outro ator pode acessar a mesma capacidade por um portal administrativo, uma API, um fluxo móvel ou um processo automatizado.
Se o time equipara a tela à capacidade, o domínio se fragmenta entre interfaces.
Modelar capacidades é perguntar o que o produto precisa ser capaz de fazer
Uma capacidade é uma habilidade relevante do produto ou da organização.
Ela costuma ser mais estável do que a descrição de uma funcionalidade e menos específica de implementação do que uma tela.
Por exemplo:
Capacidade: gerenciar cotações de fornecedores
Isso pode incluir:
- criar um processo de cotação;
- definir itens e quantidades;
- convidar fornecedores elegíveis;
- aceitar propostas até um prazo;
- tratar revisões;
- normalizar condições comerciais;
- comparar propostas;
- atribuir toda ou parte da contratação;
- preservar o histórico da decisão.
As telas podem mudar. A capacidade permanece.
Isso oferece a produto, design e engenharia um objeto compartilhado sobre o qual raciocinar antes de otimizar a interface.
Os atores importam antes da navegação
A navegação frequentemente reflete premissas sobre os atores.
Se o produto tem responsáveis, alunos, professores, administradores escolares e operadores da plataforma, uma única arquitetura de informação pode não fazer sentido.
O time primeiro precisa saber:
- O que cada ator pode ver?
- O que cada ator pode alterar?
- Quais vínculos conferem autoridade?
- Quais ações exigem outro ator?
- Uma pessoa pode exercer múltiplos papéis?
- O mesmo usuário pode atuar em contextos organizacionais diferentes?
Uma abordagem que começa pela tela pode criar um modelo global User.Role porque a interface mostra apenas um papel por vez.
Mais tarde, o produto descobre que um responsável também pode ser professor ou que um professor está ligado a várias escolas.
O problema parece técnico, mas sua causa era um modelo de produto que nunca separou identidade, vínculo e escopo de permissão.
Transições de estado são mais duradouras do que etapas de interface
Interfaces frequentemente sugerem um fluxo linear:
Rascunho → Enviar → Aprovar
Domínios reais raramente são tão simples.
Um item enviado pode ser retirado? Pode expirar? Quem aprova pode solicitar alterações? Várias aprovações podem acontecer em paralelo? Um item rejeitado pode ser reenviado? Um evento externo pode mudar seu estado?
A modelagem de estados torna essas perguntas explícitas.
Quando a máquina de estados é compreendida, a experiência de uso passa a ter uma base melhor.
A interface pode comunicar o que aconteceu, o que pode acontecer em seguida e por que uma ação está indisponível.
Sem esse modelo, botões desabilitados e componentes condicionais se tornam a especificação acidental das regras de negócio.
As permissões fazem parte do modelo de produto
A autorização é frequentemente adiada para a engenharia porque é descrita como segurança.
Mas permissão também é comportamento de produto.
Um responsável pode ter autorização para inscrever uma criança. A criança pode sugerir uma oportunidade, mas não enviar a inscrição. Um professor pode ver o desempenho da turma, mas não registros familiares privados. Um administrador escolar pode gerenciar configurações institucionais, mas não os dados de outra escola.
Essas regras moldam a experiência.
Design não consegue criar um fluxo correto sem elas.
Segurança não consegue implementá-las de forma segura se o produto não as definiu.
O modelo de capacidades deve, portanto, incluir quem pode executar uma ação e sob qual escopo.
A linguagem do domínio reduz a ambiguidade da interface
As palavras em uma interface costumam ser o primeiro sintoma visível de um domínio pouco claro.
Times usam “conta”, “perfil”, “membro”, “aluno”, “usuário” e “participante” como se fossem equivalentes. Depois, os modelos do backend herdam a mesma ambiguidade.
Um processo mais sólido define os conceitos antes de usá-los de maneira casual.
Por exemplo:
- Usuário: identidade autenticada.
- Aluno: pessoa representada no domínio acadêmico.
- Vínculo de responsável: relação de autoridade entre um usuário e um aluno.
- Vínculo escolar: relação com uma instituição delimitada no tempo.
- Participação: envolvimento de um aluno em uma edição específica de uma competição.
Quando essas distinções existem, fica mais fácil projetar o conteúdo das telas, porque o produto deixa de exigir que um único objeto da interface represente vários conceitos diferentes.
Capacidade não significa funcionalidade
Capacidades e funcionalidades se sobrepõem, mas não são intercambiáveis.
Uma funcionalidade costuma ser uma expressão de valor que pode ser entregue.
Uma capacidade é uma habilidade subjacente que pode sustentar muitas funcionalidades.
Por exemplo:
Capacidade: manter o histórico de decisões
Funcionalidades possíveis:
- registro de alterações
- linha do tempo de aprovações
- exportação para auditoria
- comparação de decisões
- restauração da configuração anterior
Pensar em capacidades ajuda os times a identificar responsabilidades reutilizáveis do sistema, em vez de reproduzir a mesma regra em várias telas.
Isso se torna especialmente valioso em produtos orientados a APIs, produtos multicanal e plataformas em que a interface é apenas um consumidor do comportamento subjacente.
A experiência de uso não deve ser adiada
“Capacidades antes de telas” pode ser interpretado erroneamente como “engenharia antes de design”.
Isso seria um erro.
UX é essencial para descobrir se o modelo de capacidades corresponde à maneira como as pessoas realmente pensam e trabalham.
Um modelo de domínio pode ser internamente coerente e, ainda assim, produzir um produto impossível de usar.
A relação mais adequada é iterativa:
Compreensão do domínio
↔
Modelo de capacidades
↔
Jornada do usuário
↔
Protótipo
↔
Evidências
Cada perspectiva testa as outras.
Um protótipo pode revelar que uma distinção do domínio é confusa. Um fluxo pode expor um estado ausente. Uma pesquisa com usuários pode mostrar que duas capacidades precisam ser combinadas para atender a uma tarefa real.
Design se fortalece quando trabalha sobre uma semântica explícita de produto, em vez de inventá-la implicitamente.
Quando começar pela interface funciona
Explorar primeiro a interface pode ser extremamente eficaz quando o problema é principalmente de experiência e o risco do domínio subjacente é baixo.
Exemplos incluem:
- testar navegação;
- explorar hierarquia visual;
- validar conteúdo;
- comparar padrões de interação;
- prototipar um fluxo de consumo com estados simples;
- explorar uma nova interface para uma capacidade bem compreendida.
O problema aparece quando os times confundem um protótipo útil com uma definição completa do produto.
Um protótipo pode ocultar segurança, histórico de dados, tratamento de exceções, papéis organizacionais e restrições operacionais, porque muitas vezes é justamente isso que o torna rápido.
Sua incompletude é uma vantagem durante a descoberta.
Ela só se torna perigosa quando a organização trata o protótipo como especificação.
As capacidades melhoram decisões de API e arquitetura
Quando os times definem capacidades com clareza, fica mais fácil raciocinar sobre as fronteiras das APIs.
Em vez de criar endpoints que espelham telas, eles podem criar contratos em torno de comportamentos significativos.
Mais fraco:
POST /save-step-3
Mais sólido:
POST /quotation-events/{id}/proposals
POST /registrations/{id}/submit
POST /memberships/{id}/revoke
As interfaces mais sólidas expõem comportamentos de domínio, em vez de uma sequência de telas.
Essa separação permite que as interfaces evoluam sem obrigar o backend a acompanhar cada mudança de apresentação.
Também ajuda a arquitetura a evitar a decomposição de sistemas por página.
Capacidades ajudam a evitar a implementação prematura
Um modelo de capacidades é um dos artefatos que podem reduzir o custo da incerteza inicial.
Ele não precisa ser exaustivo.
Precisa tornar atores, responsabilidades, regras e estados importantes visíveis o suficiente para que o time reconheça lacunas relevantes antes de a implementação cristalizar premissas.
Isso se conecta diretamente a Implementar é uma forma cara de descobrir o produto.
Quando os times pulam a formação de capacidades, desenvolvedores frequentemente descobrem o modelo ausente enquanto escrevem código.
Dê uma base melhor à experiência de uso
O argumento a favor de capacidades antes de telas não é um argumento contra o design de interfaces.
É um argumento para dar ao design de interfaces algo coerente para expressar.
Um trabalho sólido de produto transita por várias representações:
Problema
↓
Atores
↓
Domínio
↓
Capacidades
↓
Regras e estados
↓
Jornadas
↓
Interfaces
↓
Implementação
As setas não têm sentido único. Evidências devem percorrer o sistema de volta e mudar premissas anteriores.
A pergunta prática não é “Devemos começar por UX ou pelo domínio?”.
É “O que estamos tratando como conhecido sem que tenha sido realmente compreendido?”.
Telas são ferramentas poderosas de descoberta.
Elas se tornam ainda mais poderosas quando o time sabe qual sistema está tentando revelar.
Referências
- Marty Cagan. The Four Big Risks. Silicon Valley Product Group, 2017. https://www.svpg.com/four-big-risks/
- Silicon Valley Product Group. Product, Design and AI. 2025. https://www.svpg.com/product-design-and-ai/
- Silicon Valley Product Group. Discovery vs. Design. 2021. https://www.svpg.com/discovery-vs-design/