Usabilidad

Nunca mostrar multiples modales, banners y widgets de bienvenida simultaneamente. Usar una maquina de estados con pasos canonicos y una sola superficie visible. El primer minuto del usuario debe tener UNA respuesta a "qué hago primero?", no cinco.

Botones de "Entrar como Developer", switchers de estado demo, botones de "Forzar siguiente paso" jamás deben llegar a producción. Un solo guard: import.meta.env.DEV o equivalente. Que grep en el build devuelva 0 matches.

Nunca mantener dos jerarquías paralelas (/ajustes/* vs /settings/*). Elegir UNA ruta canonica, redirigir la otra con 301, congelar slugs. Los links rotos (404s) erosionan confianza más que cualquier defecto visual.

No usar setTimeout(280) cosmetico para mostrar "Guardando...". Si localStorage es instantaneo, mostrar "Guardado" directo. Si hay API, acoplar el indicador al ciclo real de la promesa. El sistema no debe mentir sobre lo que está haciendo.

novalidate en forms solo es válido si implementas validación custom completa. En onNext (y antes de submit): verificar required vacios, aria-invalid="true", mensaje inline, scroll-into-view al primer error, foco al campo.

Paso 1 pide lo mínimo (dirección, tipo, precio, foto). Datos financieros (vacancy, TIR, CAP, exit cost) van como sugerencias editables con defaults razonables, no como campos bloqueantes. El TTC de la primera propiedad debe ser <90s.

Tags de estado (HOT/WARM/COLD, Activa/Borrador/Vendida) deben incluir un dot semántico o ícono además del color. 8% de hombres tienen algún grado de daltonismo. Un solo cambio en el componente Tag/Badge del DS propaga a todo el producto.

Si el panel de filtros colapsa en mobile, mostrar chips removibles fuera del panel con "x" individual y "Limpiar todo". El usuario no debe abrir el panel para saber qué filtros tiene aplicados. Patrón Material/Polaris.

No usar trucos (autocomplete="off", data-lpignore) para evitar el autocomplete del browser. Usar name="city" con autocomplete="address-level2" correcto. WCAG 1.3.5 lo requiere. Funciona en Chrome, Safari, Firefox sin hacks.

En apps con sidebar + topbar + chrome, el usuario de teclado tabula 5-10+ links antes de llegar al contenido. Skip-link visible solo en :focus-visible, apuntando a <main id="main">. WCAG 2.4.1.

Nunca mezclar window.confirm() nativo con un ConfirmDialog custom del DS. La inconsistencia mina la confianza ("es nativa porque es más serio, o porque se olvidaron?"). Lint rule o eslint custom que prohiba window.confirm( en src/.

No borrar flags de bienvenida en cada login. Un agente con 12 propiedades no debe ver el WelcomeModal el lunes porque cerro sesión el viernes. Los flags deben ser per-user, no per-sessión. Reset solo vía ?demo=fresh explicito.

Nunca renderizar estado "configurado" si el usuario no ha hecho nada. Cada superficie lee userState.onboardingComplete y muestra state=empty si aplica. La demo state=full solo accesible por query param.

No inventar datos diferentes en cada página. Un dashboard que muestra "Cumbres Vista Real" como destacada, pero /properties no la tiene, erosiona confianza. Centralizar mocks en src/data/*.ts con tipado, derivar vistas de ahí.

Tooltips con conceptos complejos (vacancia, TIR, exit cost) deben incluir "Ver articulo completo" que abra un Drawer in-page sin perder el formulario. No enviar al usuario a Help > Buscar > Leer > Volver.

Los botones grises frustran al usuario: ve la acción pero no puede usarla y no sabe por que. Mantener botones habilitados y mostrar validación inline al intentar enviar. Si es imprescindible deshabilitarlo, siempre mostrar tooltip o mensaje visible explicando por que y como habilitarlo.

Minimal = menos elementos visuales. Simple = entendible y usable. No son lo mismo. Siempre incluir labels de texto junto a íconos (nunca icon-only para acciones ambiguas). Incluir help text y placeholder cuando reducen errores. Una interfaz sparse que confunde es mal diseño, no buen minimalismo.

Multi-columna en formularios incrementa errores. Labels arriba del campo (no inline como placeholder, que desaparece al escribir). Mostrar todos los campos; no esconder opcionales en accordions. Usar input types apropiados (email, tel, number, date) para teclados móviles. Auto-focus en el primer campo cuando el form es la acción principal.

Los usuarios escanean, no leen. Poner la información más importante al inicio de labels, botones y headings. "Guardar cambios" no "Haz click aquí para guardar tus cambios". "Contraseña muy corta" no "Tu contraseña necesita ser más larga". Aplicar en nav, CTAs, errores y títulos.

Botones gris claro comunican "no disponible" visualmente incluso cuando son funcionales. Crean duda y hesitación. Preferir botones outlined o text-style para acciones secundarias/neutras. Si se usa gris, verificar contraste 3:1 y testear percepción del usuario.

Botones demasiado juntos causan taps accidentales y misclicks. Un gap de 4px entre botones hace que las áreas de toque se superpongan, especialmente en pantallas tactiles donde el dedo cubre ~44px. 16px es la distancia segura recomendada por las guías de Material Design y HIG. Aplicar consistentemente en grupos de botones, dialog footers y toolbars.

Cada página debe ser auto-evidente. Si un usuario necesita detenerse a pensar "Donde hago click?" o "Que significa esto?", el diseño fallo. Navegación, labels y jerarquía deben hacer obvio el siguiente paso sin leer instrucciones.

Las personas consumen páginas web como espectaculares a 100km/h. Escanean buscando palabras clave relevantes a su tarea, no leen palabra por palabra. Diseñar para escaneo: jerarquía visual clara, negritas en términos clave, párrafos cortos, listas con viñetas y headings que anclen la mirada.

Las personas no evaluan todas las opciones para encontrar la óptima. Eligen la PRIMERA opción que parece razonable y avanzan. Diseñar para que la mejor opción sea también la más visible y la primera que el usuario encuentre. No enterrar la opción correcta.

No importa cuantos clicks necesite el usuario si cada click es una decisión obvia e inequivoca. 3 clicks claros superan a 1 click confuso. Nunca sacrificar claridad para "reducir clicks".

Quitar texto de bienvenida, auto-congratulaciones y explicaciones que nadie lee. Si algo necesita instrucciones, redisena. El texto restante debe ganarse su lugar. Eliminar la mitad, luego eliminar la mitad de lo que queda.

Imprime cualquier página al azar. En 5 segundos debes poder identificar: nombre del sitio, nombre de la página, secciones principales, navegación local, indicador "estas aquí" y busqueda. Si falta alguno, la navegación fallo.

Los usuarios llegan con un deposito limitado de paciencia. Cada fricción lo drena. Cuando se vacia, se van. Es idiosincratico (varia por persona), situacional (estres lo reduce), y recargable (buenas experiencias lo rellenan). Un error catastrofico lo vacia de golpe.

Si ser consistente significa ser confuso, rompe la consistencia. Un botón "Eliminar" rojo en todas partes es consistente, pero si en un contexto la acción real es "Quitar de la lista" (no destructiva), claridad gana. El objetivo es comprensión, no uniformidad.

3-4 usuarios revelan la mayoría de problemas criticos. Testear temprano y frecuente (una mañana al mes) supera un test masivo al final. Testear cualquier cosa en cualquier etapa: sketches, wireframes, prototipos, producción. Un test imperfecto es infinitamente mejor que cero.

No existe el "usuario promedio". Diseñar para el promedio es diseñar para nadie: las preferencias, habilidades y contextos de uso son idiosincraticos. Identifica 2-3 arquetipos reales con necesidades, niveles de experiencia y metas concretas, y disena para cada uno explicitamente. La única forma de resolver debates de usabilidad es con datos de usuarios reales, no con opiniones sobre lo que "el usuario" quiere.

Cuando hay 5 opciones o menos, mostrarlas todas como lista estática (radio cards, chips, botones) en lugar de esconderlas en un dropdown. Los dropdowns agregan un click, ocultan las alternativas, impiden la comparación visual y ralentizan al usuario. Solo usar dropdowns para 6+ items o cuando el espacio es genuinamente limitado.

Los usuarios memorizan rutas de navegación. Una reorganización los fuerza a reaprender y rompe bookmarks. Solo reorganizar cuando hay evidencia clara de que la estructura actual confunde. Nunca por "limpieza interna" o "modernización".

Users scan in F-pattern (content pages) or Z-pattern (landing pages). Place key information along these natural scan paths. Headlines top-left, CTAs at natural endpoints of the scan path.

Slips (acción automática incorrecta) se previenen con inputs restringidos, date pickers y formato automático. Mistakes (modelo mental erroneo) se previenen con convenciones y preview de consecuencias. Confirmar solo acciones destructivas irreversibles.

Nivel 1: opciones del 80% de usuarios. Nivel 2: avanzadas, etiquetadas "Opciones avanzadas". Si necesitas nivel 3, el problema es arquitectura, no UI.

Recordar es 2-3x más costoso cognitivamente que reconocer. Historial de busqueda, items recientes y favoritos son funciones de seguridad cognitiva. Menús siempre visibles; los atajos de teclado son complemento, no reemplazo.

La interfaz debe servir a principiantes y usuarios avanzados. Los novatos necesitan affordances visibles, labels claros y guía contextual. Los expertos necesitan atajos de teclado, command palettes y opciones de densidad. Diseñar en capas: superficie para novatos, profundidad para expertos. Nunca sacrificar uno por el otro.

Formato: [qué salió mal] + [por qué] + [qué hacer ahora]. Jamás códigos de error como texto principal. Ubicar el mensaje adyacente al elemento causante.

El sistema debe mostrar su estado actual con claridad en todo momento. Guardando, sincronizado, offline, procesando: el usuario nunca debe preguntarse "funciono?". Indicadores de estado, badges de sincronización, estados de carga y confirmación visual en tiempo real eliminan la incertidumbre.

Usar terminología del usuario validada con research, nunca jerga técnica interna. Los íconos solos son ambiguos; siempre acompanarlos con label de texto.

Undo en cualquier acción reversible. Cancelar visible en todo flujo multi-paso. Los modales cierran con Escape y click fuera del contenedor, no solo con el botón X.

Rojo siempre error o peligro, verde siempre exito. Nunca al reves. Los íconos deben ser semanticamente consistentes: papelera para eliminar, lapiz para editar. Labels de botones específicos ("Eliminar cuenta", no "OK").