ist-h-i/ui-ux-design

Módulo de Design UI/UX

Objetivo

Restringir o design, implementação e revisão de UI em torno da meta evidenciada do usuário, hierarquia visual e acabamento, usabilidade da tarefa, semântica de interação, consciência de consequências e estado recuperável. Este é um suplemento de execução, não uma substituição de ciclo de vida e não um sistema de design visual.

Use o menor subconjunto aplicável. Não invente personas, prioridades de negócio, suposições de dispositivo, garantias de recuperação ou comportamento de interação que a tarefa não evidencie.

Quando usar

Use esta habilidade somente depois que o fluxo de trabalho de entrega genérico for selecionado e a tarefa alterar ou revisar uma interface visível ao usuário com um ou mais destes sinais:

• uma tela, formulário, fluxo de navegação, seleção ou ação principal;
• foco, selecionado, desabilitado, carregando, sucesso, erro, concluído ou outro estado de interação;
• ações do usuário consequentes ou reversíveis;
• falha parcial de dados/ renderização, dados obsoletos ou ausentes, nova tentativa ou comportamento de recuperação;
• linguagem de UI cuja redação afeta a conclusão da tarefa ou a recuperação de erros.

Não use para trabalho não relacionado a UI, saída puramente consumida por máquina, ou como motivo para carregar toda preocupação de UX. Marca, usuários, terminologia, fluxos críticos e regras de negócio específicos do projeto permanecem como contexto do projeto.

Processo

1. Ancorar em evidências. Identifique a meta conhecida do usuário, contexto de uso, primeira informação a notar, prioridades de ação, conclusão/próxima ação e restrições. Escolha densidade e composição para esse propósito: um espaço de trabalho de comparação e uma introdução de produto precisam de tratamentos diferentes. Contratos existentes são entradas, não um teto de qualidade; reexamine fraquezas observadas dentro do escopo. Pare apenas decisões que dependam de fatos ausentes consequentes, sem inventar uma persona ou fluxo de trabalho.
2. Selecionar princípios e padrões aplicáveis. Leia apenas as seções relevantes de references/principles.md, references/decision-patterns.md e references/anti-patterns.md. Registre por que eles se aplicam. Trate exemplos como dicas de evidência, não proibições globais.
3. Tornar a composição concreta. Conecte agrupamento, ordem, hierarquia de texto e quebra, âncoras de alinhamento, espaçamento, relacionamentos de imagem e controle à tarefa. Prefira estrutura/estado claro antes de adicionar explicação; retenha o significado necessário e rótulos acessíveis. Para japonês, julgue rótulos, texto de alvo/resultado e feedback em sua posição e estado exibidos, não apenas gramática; use uma capacidade japanese-expression disponível sob as regras de descoberta abaixo.
4. Especificar comportamento. Defina affordances/significadores aplicáveis, semântica de estado, feedback imediato, transições, foco/estado atual, continuação e caminhos de interação equivalentes. Marque preocupações não aplicáveis explicitamente; não fabrique comportamento de hover, arrastar, gesto ou movimento.
5. Separar classes de consequência. Distinga cancelamento antes do compromisso, desfazer após uma alteração reversível concluída e ação compensatória após uma alteração confirmada. Para ações irreversíveis ou materialmente consequentes, mostre alvo, escopo, consequência e limite de recuperação antes do compromisso. Não adicione confirmação genérica a ações reversíveis de baixo risco.
6. Delimitar falhas. Mantenha regiões saudáveis, autorizadas, semanticamente válidas e entrada do usuário utilizáveis quando uma região independente falhar. Mantenha a falha não resolvida visível na região afetada, torne a nova tentativa com escopo definido e verifique o resultado da nova tentativa. Distinga estados de carregamento, vazio legítimo, ausente, obsoleto, parcial e completo. Não preencha dados ausentes com zero ou exponha ações derivadas cuja pré-condição de verdade esteja incompleta. Amplie o bloco somente quando autorização, segurança, consistência ou semântica de dependência exigirem.
7. Refinar e verificar a renderização real. Durante a implementação, inspecione uma tela inteira representativa antes de polir controles, depois refine detalhes relevantes de componentes, layouts estreitos e estados antes da revisão independente. Julgue acabamento visual, usabilidade da tarefa e comportamento funcional separadamente; cliques funcionando, valores CSS iguais e sem overflow não estabelecem acabamento. Exercite transições aplicáveis, teclado/foco, desfazer real, cancelamento pré-confirmação, entrada retida e nova tentativa com escopo. Uma captura de tela suporta aparência estática, não recuperação ou restauração de estado. Use as regras de observação e transferência em references/ui-capability-contract.md.
8. Conectar capacidades de UI disponíveis. Siga references/ui-capability-contract.md para solicitações de contrato apenas, construção de contrato existente ou UI direta. Mantenha a propriedade do princípio aqui, resolva proprietários de capacidade externa do ambiente ativo e preserve links de contrato-para-implementação-para-evidência. Lacunas de capacidade ou tempo de execução param apenas o trabalho dependente afetado e nunca contam como revisão concluída.
9. Devolver restrições ao fluxo de trabalho selecionado. requirement-grill, grill-design, controlled-implementation, test-first-verification, portões de revisão e portões finais de merge mantêm suas responsabilidades. Este suplemento restringe decisões de UI; ele não autoriza implementação ou aprovação por si só.

Saída

Emita um suplemento delimitado no registro de decisão da tarefa atual. Para um ajuste local, registre apenas as decisões alteradas e evidências afetadas; não exija um novo contrato JSON ou um modelo preenchido. Omita campos irrelevantes ou use not_applicable: <motivo>; nunca os preencha especulativamente.

Suplemento UX:
  contexto_do_usuario:
    meta_do_usuario:
    contexto_de_uso:
    restricoes_conhecidas:
    consideracoes_de_capacidade_ou_ambiente:
  modelo_da_tarefa:
    objetivo_da_pagina_ou_fluxo:
    acao_principal:
    estado_de_conclusao:
    proxima_acao:
  modelo_de_informacao:
    informacoes_necessarias:
    informacoes_secundarias:
    omitir:
    idioma_necessario_para_clareza:
  modelo_de_interacao:
    affordances_e_significadores:
    semantica_de_estado:
    feedback_de_acao:
    comportamento_de_transicao:
    expectativas_de_consistencia:
    manipulacao_direta:
    caminhos_de_interacao_equivalentes:
  restricoes_de_inclusao:
    dependencias_de_unico_sinal_a_evitar:
    prevencao_de_erro:
    caminhos_de_recuperacao:
    restricoes_de_entrada_e_esforco:
  resiliencia_e_consequencias:
    reversibilidade_da_acao_e_limites:
    consequencias_pre_compromisso:
    limites_de_falha_e_dependencias:
    conteudo_e_acoes_seguros_remanescentes:
    feedback_de_falha_parcial_e_atualidade:
    refs_de_nova_tentativa_e_recuperacao_com_escopo:
    condicoes_de_bloqueio:
  padroes_aplicaveis:
  antipadroes:
  restricoes_de_implementacao:
  cenarios_de_verificacao:
  condicoes_de_parada:

Cada cenário de verificação nomeia o estado inspecionado e o relacionamento observável. Para interações, adicione ação/entrada, estado visível e subjacente esperado, e resultado de recuperação/continuação aplicável. Mantenha decisões de design no modelo de informação existente e restrições de implementação, em vez de criar outro esquema.

Critérios de saída

• O suplemento está conectado apenas porque a evidência atual contém um sinal de UI.
• Suposições de usuário, produto, marca e negócio são originadas ou marcadas como desconhecidas.
• A tarefa principal e a próxima ação estão mais claras sem remover a semântica necessária.
• Para julgamentos de UI renderizada, a composição e o acabamento do componente têm evidência renderizada distinta de verificações funcionais; o trabalho apenas de contrato especifica critérios de observação sem reivindicar aprovação de tela real. Um contrato aprovado não descarta rugosidade observada.
• Reivindicações dinâmicas têm requisitos de evidência interativa/estado, não prova apenas de captura de tela.
• Comportamento reversível, irreversível, de falha parcial e de bloqueio fundamental são distinguidos quando aplicável.
• Estado saudável e entrada do usuário são preservados em toda falha independente e nova tentativa.
• O fluxo de trabalho genérico e a autoridade final de revisão permanecem inalterados.