En este tutorial te muestro cómo llevar una idea desde un wireframe en baja fidelidad hasta un prototipo interactivo en Figma listo para validar con clientes y pasar a desarrollo, con tips prácticos de un flujo real.
Planifica antes de abrir Figma
Define el objetivo del prototipo (flujo, look & feel, microinteracciones), las pantallas clave y el contenido mínimo. Ten a mano referencias y patrones UI.
Tip pro: acordad con el equipo qué se valida en esta ronda (navegación, copy, jerarquía visual) para evitar rehacer trabajo.
Crea el wireframe en baja fidelidad
Crea un Frame con dimensiones del dispositivo (1440 desktop / 768 tablet / 375 móvil).
Usa formas básicas y texto para estructura; sin color para centrarte en funcionalidad.
Construye con Auto Layout para tener bloques fluidos y escalables.
Anota comportamientos y estados (hover, error, vacío) con etiquetas.
Resultado: mapa claro de contenidos y prioridades, listo para revisión rápida.
Pasa a media y alta fidelidad
Tras validar el esqueleto, sube fidelidad:
Tipografía y jerarquía: define estilos (H1, H2, body).
Paleta y temas: crea variables de color (light/dark) y espaciado.
Componentes: botones, tarjetas, inputs con variants y propiedades.
Estados: default, hover, focus, disabled y error.
Tip pro: usa Variables para colores/espaciados y conecta con Design Tokens en tu repo. Un cambio global = diseño actualizado.
Añade interacciones para el prototipo
Activa la pestaña Prototype y conecta los flujos con hotspots.
Configura eventos: On click → Navigate to, Open overlay, Swap variant.
Usa Smart Animate para transiciones suaves entre estados.
Simula microinteracciones (menús, acordeones, modales) sin caer en fuegos artificiales.
Testea, comparte y itera
Present Mode: prueba en escala 100% para detectar fricciones.
Compartir: enlace con permisos de vista/comentario para stakeholders.
Hand-off a devs: añade una página de especificaciones con medidas, estilos y assets marcados para exportar.
Checklist rápida
Wireframe validado
Estilos tipográficos y de color centralizados
Componentes con variants y estados
Interacciones principales definidas
Feedback aplicado y prototipo estable
Preguntas frecuentes
¿Necesito experiencia en diseño para usar Figma?
No. Puedes empezar con plantillas y componentes; lo clave es entender el flujo que quieres validar.
¿Diferencia entre wireframe y prototipo?
El wireframe es estructura y contenido; el prototipo añade interactividad y simula el flujo real.
¿La versión gratuita sirve para prototipos?
Sí. Para proyectos pequeños y validaciones internas suele ser suficiente.
En este artículo yo te presento un análisis profundo y actualizado (Agosto de 2025) sobre tres frameworks modernos: Astro, Next.js y Nuxt, comparándolos en cuanto a rendimiento, experiencia de desarrollo, escalabilidad y ecosistema. El enfoque es técnico y avanzado, con ejemplos de interacción y diseño. La idea es que te ayude a decidir cuál usar según tu tipo de proyecto.
Visión general de cada framework
Astro
Astro es un framework orientado a la generación estática y renderizado parcial en el cliente. Su propuesta central es entregar solo el JavaScript estrictamente necesario, lo que lo convierte en una opción ideal para sitios rápidos, blogs estáticos y documentación. Utiliza componentes islands para activarse solo donde se necesita interactividad.
Next.js
Next.js es el stack de React de referencia. Soporta rendering híbrido (SSG, SSR, ISR), SWR para datos y routing file‑based. Perfecto para aplicaciones con contenido dinámico, e‑commerce, paneles de control, etc. Con su soporte de Edge Functions y Middleware, se adapta a escenarios complejos con rendimiento global.
Nuxt
Nuxt es el equivalente en el ecosistema Vue. En su versión 3, utiliza Vue 3 + Vite, soporte para SSG, SSR y auto‑imports. También ofrece configuraciones automáticas de CSS, optimización de imágenes y módulos como @nuxt/content para contenido basado en Markdown.
Rendimiento y tiempo de carga
2.1 Generación estática y peso del bundle
Astro sobresale: genera sitios casi sin bundle JavaScript por defecto.
Next.js produce bundles más grandes debido al runtime completo de React.
Nuxt con SSR produce un HTML pre‑renderizado, pero el cliente recibe código Vue completo.
2.2 Hydration y experiencia del usuario
En Astro, las islands se hidratan individualmente.
Next.js y Nuxt hidratan toda la página.
2.3 Métricas reales
Con Lighthouse en un blog típico:
Astro: 98–99
Next.js: 90–95
Nuxt: 92–96
Experiencia de desarrollo y escalabilidad
3.1 Curva de aprendizaje
Astro es sencillo y directo.
Next.js exige dominio de React y SSR.
Nuxt requiere experiencia con Vue 3 y Composition API.
Desarrollo local y recarga rápida
Astro usa Vite.
Next.js usa SWC y Fast Refresh.
Nuxt 3 también usa Vite y ofrece auto‑imports.
3.2 Escalabilidad en grandes proyectos
Next.js: routing avanzado, middleware, Edge.
Nuxt: modularidad y SSR.
Astro: complejo en apps muy interactivas.
Ecosistema y comunidad
Ecosistema de paquetes y plugins
Next.js: gran ecosistema.
Nuxt: muchos módulos Vue‑nativos.
Astro: en crecimiento, integraciones variadas.
Comunidad, soporte y recursos
Next.js: liderado por Vercel.
Nuxt: comunidad activa Vue.
Astro: documentación clara, comunidad joven.
Casos de uso recomendados (con ejemplos)
Proyectos donde brilla Astro
Blog técnico, landing page, documentación ligera.
Proyectos ideales para Next.js
Tiendas, SaaS, paneles de control.
Proyectos donde encaja Nuxt
Web corporativa, portfolios, sitios Vue SSR/SSG.
Comparativa general en tabla
Característica
Astro
Next.js
Nuxt 3
Peso de bundle
Muy ligero (islands)
Medio‑alto
Medio
Tiempo de carga
Excelente
Muy bueno
Muy bueno
Complejidad SSR/ISR
Básica
Alta
Media‑alta
Comunidad
Creciendo
Muy madura
Activa
Ideal para
Sitios estáticos
Apps complejas React
Apps completas Vue
Preguntas Frecuentes(FAQs)
1. ¿Puedo usar Astro junto con Next.js o Nuxt?
Sí, puedes combinarlos pero requiere configuración avanzada.
2. ¿Cuál rendimiento funciona mejor en móviles?
Astro lidera por su mínimo JavaScript.
3. ¿Y si quiero CMS o contenido dinámico?
Next.js y Nuxt tienen integraciones más completas. Astro requiere fetch manual.
La decisión depende de tu objetivo:
Astro: sitios rápidos, estáticos.
Next.js: control total y escala.
Nuxt: entorno Vue optimizado.
Yo te animo a usar el que mejor se adapte a tu tipo de proyecto, equipo y necesidades futuras.
Yo siempre he tenido curiosidad sobre si esa famosa regla de la memoria a corto plazo —7±2 elementos— sigue siendo útil en el diseño de interfaces modernas. En este artículo, te muestro mi visión crítica y fundamentada: cuándo tiene sentido aplicar esa guía clásica, cuándo se queda corta y cómo adaptarla a distintos dispositivos en 2025.
Desde los experimentos de George Miller en 1956, se popularizó la idea de que el ser humano puede retener entre 5 y 9 elementos en la memoria de corto plazo. En el mundo del UX y del diseño de interacción, muchos lo interpretan como una restricción: «no pongas más de siete opciones en un menú». Sin embargo, en 2025, con interfaces más ricas y contextos variados, esa simplificación se desmorona si no se ajusta correctamente.
Te explico los fundamentos cognitivos detrás del 7±2.
Analizo si sigue vigente en desktop, mobile y wearables.
Doy ejemplos concretos de diseño e interacción.
Presento un enfoque técnico para decidir si usarlo o no.
Concluyo con una reflexión sobre su relevancia actual.
Fundamentos cognitivos del 7±2
Origen y significado
La regla surge de estudios experimentales de Miller, que encontró que el número de “chunks” (fragmentos de información) que una persona puede mantener simultáneamente en memoria de corto plazo ronda entre 5 y 9. Los chunks no necesariamente son elementos discretos: pueden agruparse conceptualmente.
Cómo lo interpretan en UX
En UX se tradujo a la recomendación de limitar los elementos visibles (menús, opciones, botones) a ese rango para evitar sobrecargas cognitivas. Pero esta interpretación falla si:
no se define qué es exactamente un elemento o chunk,
no se considera el contexto de uso,
o se ignora el soporte visual, patrones previos o ayudas progresivas.
¿Mito o guía útil en 2025?
Mi conclusión: no es un mito, pero tampoco es una fórmula universal. Depende del contexto.
Contexto de audio, voz o minimalistas interfaces
En asistentes de voz o interfaces simplificadas, el número de opciones simultáneas debe ser pequeño. Aquí sí tiene sentido pensar en 5 ± 2 opciones vocales o respuestas. Te evitarás que el usuario tenga que memorizar largas listas.
Escenarios de interfaces ricas con soporte visual
En aplicaciones que muestran tarjetas, listas con iconos, textos cortos o pre‑chunking (semantic grouping), el usuario puede manejar más información: el contexto reduce la carga.
Avances de interacción en 2025
Con scroll infinito, comportamiento predictivo, recomendaciones dinámicas y machine learning, la capacidad de procesamiento cognitivo se ve apoyada. En este caso, el horizonte de 7±2 pierde rigor como límite inflexible.
Comparación por plataformas: desktop, mobile y wearables
Desktop
Ventajas:
Mayor espacio visual.
Menús desplegables y mega‑menús.
Hover proporciona información adicional.
Cómo aplicarlo bien:
Menú principal con 5–9 items.
Agrupar opciones por categorías lógicas.
Filtros que se expanden progresivamente.
Mobile
Retos:
Pantalla pequeña.
Gestos táctiles limitados.
Atención fragmentada.
Aplicación recomendada:
Carrousel o scroll vertical con 5–7 ítems.
Tab bars con 3–5 íconos. Si hay más, usar «Más».
Hamburger menus con subniveles si hay más de 7 ítems.
Wearables
Limitaciones extremas:
Mini‑pantalla.
Interfaz por gestos y voz.
Interacciones rápidas.
Uso de 7±2: máximo 5–7 opciones por pantalla o gesto, agrupadas visualmente.
Ejemplos de diseño e interacción en la práctica
Ejemplo — plataforma e-learning
Menú superior con 5 ítems; subniveles limitados a 4–6 elementos agrupados. Módulos no superan los 7 ítems por sección.
Ejemplo — app fintech
Tab bar con 4 ítems. Categorías dentro de una sección limitadas a 6 visibles con “Ver más”.
Ejemplo — wearable de salud
Menú radial con 5 íconos. Subniveles con máximo de 4 opciones por vista.
¿Cómo decidir cuándo aplicar 7±2 elementos?
Paso 1 – analizar el contexto de uso
¿El usuario está distraído? ¿Está en movimiento? ¿Hay apoyo visual?
Paso 2 – definir unidades cognitivas
No cuentes elementos fríos: piensa en chunks. ¿Puedes agrupar visualmente?
Paso 3 – definir interfaz progresiva
Divide contenido largo en secciones que no excedan los 9 ítems visibles.
Paso 4 – medir con pruebas
Testea carga cognitiva, errores, tiempo de reacción y abandono.
Paso 5 – iterar con datos
Usa analítica UX para tomar decisiones informadas.
Ventajas y limitaciones de la regla en 2025
Ventajas
Evita sobrecarga de información.
Fomenta estructuras lógicas (chunking).
Útil en interfaces simples o contextos rápidos.
Limitaciones
No considera experiencia previa del usuario.
No se adapta bien a interfaces dinámicas o personalizadas.
Puede limitar funcionalidades si se aplica rígidamente.
Preguntas frecuentes (FAQs)
1. ¿Debo limitar siempre los menús a 7 ítems?
No. Puedes tener más si los agrupas o jerarquizas adecuadamente.
2. ¿El usuario promedio memoriza 5‑9 opciones en móvil?
No. Pero con diseño visual bien estructurado puede manejar más.
3. ¿Cómo pruebo si mi interfaz está sobrecargada?
Haz tests de usabilidad y revisa métricas de abandono y tiempo de interacción.
La regla de 7±2 elementos sigue siendo un pilar conceptual en UX. En 2025 ya no la trato como una norma rígida, sino como una herramienta estratégica. El verdadero desafío es estructurar la información y comprender al usuario. Ahí está el valor del diseño moderno.
La regla no es un mito, pero debe usarse con criterio. No se trata del número exacto, sino de cómo lo estructuramos para facilitar la experiencia del usuario.
