is-h-i/ui-ux-design

Arnés de Diseño UI/UX

Objetivo

Restringir el diseño, implementación y revisión de la UI en torno al objetivo evidenciado del usuario, la jerarquía visual y el acabado, la usabilidad de la tarea, la semántica de interacción, la conciencia de consecuencias y el estado recuperable. Esto es un suplemento de ejecución, no un reemplazo del ciclo de vida ni un sistema de diseño visual.

Utilice el subconjunto aplicable más pequeño. No invente personas, prioridades comerciales, suposiciones de dispositivo, garantías de recuperación ni comportamientos de interacción que la tarea no evidencie.

Cuándo usarlo

Use esta habilidad solo después de que se haya seleccionado el flujo de trabajo de entrega genérico y la tarea modifique o revise una interfaz visible para el usuario con una o más de estas señales:

• una pantalla, formulario, flujo de navegación, selección o acción principal;
• foco, seleccionado, deshabilitado, cargando, éxito, error, completado u otro estado de interacción;
• acciones de usuario consecuentes o reversibles;
• fallo parcial de datos/renderizado, datos obsoletos o faltantes, reintento o comportamiento de recuperación;
• lenguaje de UI cuyo redactado afecte la finalización de la tarea o la recuperación de errores.

No lo use para trabajo que no sea de UI, salida puramente consumida por máquina, ni como razón para cargar todas las preocupaciones de UX. Las marcas, usuarios, terminología, flujos críticos y reglas de negocio específicos del proyecto siguen siendo contexto del proyecto.

Proceso

1. Anclar en la evidencia. Identifique el objetivo conocido del usuario, el contexto de uso, la primera información a notar, las prioridades de acción, la finalización/acción siguiente y las restricciones. Elija densidad y composición para ese propósito: un espacio de trabajo de comparación y una introducción de producto necesitan tratamientos diferentes. Los contratos existentes son entradas, no un techo de calidad; revise las debilidades observadas dentro del alcance. Detenga solo las decisiones que dependan de hechos faltantes consecuentes, sin inventar una persona o flujo de trabajo.
2. Seleccionar principios y patrones aplicables. Lea solo las secciones relevantes de referencias/principios.md, referencias/patrones-de-decisión.md y referencias/antipatrones.md. Registre por qué aplican. Trate los ejemplos como indicaciones de evidencia, no como prohibiciones globales.
3. Concretar la composición. Conecte la agrupación, el orden, la jerarquía de texto y el ajuste, los anclajes de alineación, el espaciado, las relaciones de imágenes y controles con la tarea. Prefiera estructura/estado claro antes de agregar explicación; retenga el significado requerido y las etiquetas accesibles. Para japonés, juzgue las etiquetas, el redactado del objetivo/resultado y la retroalimentación en su posición y estado mostrados, no solo por gramática; use una capacidad japanese-expression disponible bajo las reglas de descubrimiento a continuación.
4. Especificar comportamiento. Defina las capacidades/significadores aplicables, la semántica de estados, la retroalimentación inmediata, las transiciones, el foco/estado actual, la continuación y las rutas de interacción equivalentes. Marque las preocupaciones no aplicables explícitamente; no fabrique comportamiento de hover, arrastre, gesto o movimiento.
5. Separar clases de consecuencias. Distinga cancelación antes del compromiso, deshacer después de un cambio reversible completado y acción compensatoria después de un cambio comprometido. Para acciones irreversibles o materialmente consecuentes, muestre el objetivo, alcance, consecuencia y límite de recuperación antes del compromiso. No agregue confirmación genérica a acciones reversibles de bajo riesgo.
6. Delimitar fallos. Mantenga las regiones saludables, autorizadas y semánticamente válidas, y la entrada del usuario utilizable cuando una región independiente falle. Mantenga el fallo no resuelto visible en la región afectada, haga el reintento acotado y verifique el resultado del reintento. Distinga entre estados de carga, vacío legítimo, faltante, obsoleto, parcial y completo. No rellene con ceros datos faltantes ni exponga acciones derivadas cuya verdad prerrequisito esté incompleta. Amplíe el bloque solo cuando la autorización, seguridad, consistencia o semántica de dependencia lo requieran.
7. Refinar y verificar el renderizado real. Durante la implementación, inspeccione una pantalla completa representativa antes de pulir controles, luego refine los detalles de componentes relevantes, diseños estrechos y estados antes de la revisión independiente. Juzgue el acabado visual, la usabilidad de la tarea y el comportamiento funcional por separado; los clics funcionales, los valores CSS iguales y la ausencia de desbordamiento no establecen acabado. Ejercite las transiciones aplicables, teclado/foco, deshacer real, cancelación previa al compromiso, entrada retenida y reintento acotado. Una captura de pantalla respalda la apariencia estática, no la recuperación ni la restauración del estado. Use las reglas de observación y entrega en referencias/contrato-de-capacidad-ui.md.
8. Conectar capacidades UI disponibles. Siga referencias/contrato-de-capacidad-ui.md para solicitudes de solo contrato, construcción de contrato existente o UI directa. Mantenga la propiedad del principio aquí, resuelva los propietarios de capacidad externa desde el entorno activo y conserve los enlaces de contrato a implementación a evidencia. Las brechas de capacidad o tiempo de ejecución detienen solo el trabajo dependiente afectado y nunca cuentan como revisión completada.
9. Devolver restricciones al flujo de trabajo seleccionado. parrilla-de-requisitos, diseño-parrilla, implementación-controlada, verificación-primero-prueba, puertas de revisión y puertas de fusión final conservan sus responsabilidades. Este suplemento reduce las decisiones de UI; no autoriza la implementación ni la aprobación por sí mismo.

Salida

Emita un suplemento acotado en el registro de decisiones de la tarea actual. Para un ajuste local, registre solo las decisiones cambiadas y la evidencia afectada; no requiera un nuevo contrato JSON ni una plantilla rellenada. Omita campos irrelevantes o use no_aplicable: <razón>; nunca los rellene de forma especulativa.

Suplemento UX:
  contexto_usuario:
    objetivo_usuario:
    contexto_uso:
    restricciones_conocidas:
    consideraciones_capacidad_o_entorno:
  modelo_tarea:
    objetivo_pagina_o_flujo:
    accion_principal:
    estado_completado:
    accion_siguiente:
  modelo_informacion:
    informacion_requerida:
    informacion_secundaria:
    omitir:
    idioma_requerido_para_claridad:
  modelo_interaccion:
    capacidades_y_significadores:
    semantica_estados:
    retroalimentacion_accion:
    comportamiento_transicion:
    expectativas_consistencia:
    manipulacion_directa:
    rutas_interaccion_equivalentes:
  restricciones_inclusion:
    dependencias_unica_señal_a_evitar:
    prevencion_errores:
    rutas_recuperacion:
    restricciones_entrada_y_esfuerzo:
  resiliencia_y_consecuencias:
    reversibilidad_accion_y_limites:
    consecuencias_pre_compromiso:
    limites_fallo_y_dependencias:
    contenido_y_acciones_seguros_restantes:
    retroalimentacion_fallo_parcial_y_actualizacion:
    referencias_reintento_y_recuperacion_acotados:
    condiciones_bloqueo:
  patrones_aplicables:
  antipatrones:
  restricciones_implementacion:
  escenarios_verificacion:
  condiciones_parada:

Cada escenario de verificación nombra el estado inspeccionado y la relación observable. Para interacciones, agregue acción/entrada, estado visible y subyacente esperado, y resultado de recuperación/continuación aplicable. Mantenga las decisiones de diseño en el modelo de información existente y las restricciones de implementación en lugar de crear otro esquema.

Criterios de salida

• El suplemento está conectado solo porque la evidencia actual contiene una señal de UI.
• Las suposiciones de usuario, producto, marca y negocio tienen origen o están marcadas como desconocidas.
• La tarea principal y la acción siguiente son más claras sin eliminar la semántica requerida.
• Para juicios de UI renderizada, la composición y el acabado de los componentes tienen evidencia renderizada distinta de las comprobaciones funcionales; el trabajo de solo contrato especifica criterios de observación sin reclamar la aprobación de la pantalla real. Un contrato que pasa no descarta la aspereza observada.
• Las afirmaciones dinámicas tienen requisitos de evidencia interactiva/de estado, no solo prueba de captura de pantalla.
• El comportamiento reversible, irreversible, de fallo parcial y de bloqueo fundamental se distingue cuando corresponde.
• El estado saludable y la entrada del usuario se conservan a través de fallos independientes y reintentos.
• El flujo de trabajo genérico y la autoridad de revisión final permanecen sin cambios.