UI sin ruido
Construye una interfaz que la gente pueda usar, no una narración de la interfaz. Por defecto, utiliza el control, su nombre, el objeto relevante y el estado necesario. Añade texto de apoyo solo cuando cambie la comprensión, decisión, próxima acción o evaluación de riesgo del usuario.
Al generar
- Comienza sin mobiliario explicativo. No añadas automáticamente un subtítulo, párrafo introductorio, tarjeta de ayuda, banner, ceja, insignia o icono a cada sección. Añade uno solo por una necesidad concreta del usuario, no para llenar espacio o hacer que la página tenga un aspecto terminado.
- Deja que la interfaz haga la explicación. Prefiere etiquetas específicas, verbos de acción familiares, agrupación y ubicación. "Crear espacio de trabajo" no necesita "Haz clic a continuación para crear un espacio de trabajo". Si una etiqueta no es clara, arregla la etiqueta antes de añadir un párrafo.
- No narres la implementación. La arquitectura, las elecciones de componentes, los descargos de responsabilidad genéricos y los informes de progreso del desarrollador no son texto de producto por defecto. Conserva los hechos técnicos cuando afecten a la privacidad, el alcance, la recuperación o la próxima decisión del usuario.
- Di cada hecho donde sea útil. Un encabezado, una insignia, una oración y un banner no deben repetir el mismo hecho en el mismo ámbito. Conserva la repetición intencionada, como un resumen de error vinculado a un campo, o una advertencia junto a una acción consecuente distinta. No combines estados entre objetos, solicitudes o espacios de trabajo.
- Elimina también el contenedor vacío. Cuando se elimine el texto redundante, elimina también su tarjeta, alerta, icono, divisor o espacio reservado ahora inútil. No reemplaces un párrafo con una insignia decorativa o una fila de iconos. No ocultes el texto innecesario en un tooltip, divulgación, letra pequeña o bajo contraste.
- Mantén la información necesaria para actuar de forma segura. Mantén las etiquetas de campo asociadas y normalmente visibles; las restricciones reales de formato/longitud/obligatoriedad; los errores procesables; los estados de carga, no guardado, no disponible, permiso y desconocido significativos; y el alcance y las consecuencias de las acciones peligrosas. Desconocido no es vacío, éxito o fracaso. Nunca impliques que una capacidad no disponible funciona.
- Haz legible la información necesaria. El estado importante y las razones de acciones deshabilitadas deben ser visibles cerca de su ámbito, no solo para lectores de pantalla o al pasar el ratón. Mantén nombres accesibles, descripciones, urgencia de región activa, acceso por teclado y legibilidad en pantalla estrecha. La concisión nunca anula la accesibilidad.
- No crees un producto más pequeño por accidente. Conserva las funciones, datos, acciones, confirmaciones, autorización y comportamiento de solicitud/reintento. No elimines un requisito de seguridad o empresarial poco claro: señala la ambigüedad específica al propietario.
Antes de entregar una pantalla modificada
Revisa la pantalla renderizada cuando esté disponible, no solo cadenas aisladas. Para cada cadena de soporte y su contenedor, elige un resultado:
- Conservar: añade un hecho, distinción, restricción, consecuencia o próximo paso necesario.
- Reescribir: el hecho es necesario, pero su redacción es vaga, repetida o más larga de lo necesario.
- Fusionar: repite el mismo hecho en el mismo ámbito; conserva la ubicación y las asociaciones útiles.
- Eliminar: la interfaz ya lo comunica y no se pierde ningún significado necesario; elimina el contenedor vacío.
- Mover: solo la ayuda genuinamente poco frecuente pertenece detrás de una entrada de ayuda explícita y accesible. No entierres acciones comunes o estados importantes.
Verifica el ámbito modificado en estados normal, vacío, error, no disponible y desconocido cuando corresponda. Incluye la confirmación de acciones destructivas si se ve afectada, la navegación por teclado y una ventana gráfica estrecha. No afirmes una verificación de navegador o accesibilidad que no se haya realizado.
Informa los cambios significativos brevemente como antes → después — razón; incluye un hecho necesario deliberadamente conservado. No escribas un nuevo ensayo explicativo en el producto ni inventes un sistema de puntuación para demostrar que es conciso.
Ejemplos
| Antes | Después / decisión |
|---|---|
| Área de trabajo · Aquí gestionas y organizas tu área de trabajo | Área de trabajo — eliminar la descripción repetida. |
| Haz clic en el botón de abajo para crear un nuevo proyecto / Crear proyecto | Crear proyecto — conservar la acción real. |
| Nombre del proyecto / Introduce aquí el nombre de tu proyecto | Nombre del proyecto — conservar la etiqueta; eliminar la instrucción obvia. |
| Archivo / Solo CSV, máximo 20 MB | Conservar ambos — la segunda línea es una restricción real. |
| Guardado + Guardado correctamente + Tus cambios se han guardado | Un acuse de recibo con el ámbito adecuado si es necesario; sin acumulación de sinónimos. |
| Resultado de guardado desconocido. Consulta primero este resultado, no guardes repetidamente. | Conservar — la incertidumbre y el próximo paso seguro son importantes. |
| Se eliminará permanentemente «Plan de viaje» y las 12 notas que contiene, sin posibilidad de recuperación. | Conservar el objeto, alcance, cantidad y consecuencia. |
Límites
Esta skill es una guía del modelo, no un linter, hook automático ni prueba de cumplimiento. Sigue la terminología existente del proyecto, los contratos de producto y seguridad. No introduzcas una especificación competidora ni instales dependencias, contactes servicios externos o cambies la configuración global para usar esta skill. Los ejemplos son sensibles al idioma: conserva la terminología consistente; no fuerces recuentos de palabras en inglés, variación literaria de sinónimos, recuentos universales de fuentes o un icono en cada línea.