<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Desarrollo on Fernando Ruiz</title><link>https://www.fernandoux.com/tags/desarrollo/</link><description>Recent content in Desarrollo on Fernando Ruiz</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 01 Jun 2026 15:01:17 -0500</lastBuildDate><atom:link href="https://www.fernandoux.com/tags/desarrollo/index.xml" rel="self" type="application/rss+xml"/><item><title>Claude Code Skills: La Capa Profesional que la Mayoría Ignora</title><link>https://www.fernandoux.com/blog/es/claude-code-skills-the-professional-layer-most-users-ignore/</link><pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/blog/es/claude-code-skills-the-professional-layer-most-users-ignore/</guid><description>&lt;p&gt;Ya estás en Claude Code. Conoces lo básico. Has visto lo que puede hacer. Pero cada nueva sesión empieza igual: los primeros cinco minutos los pasas reexplicando tu contexto, reescribiendo los prompts que has escrito cien veces, y reestableciendo las reglas del juego antes de que empiece el trabajo real.&lt;/p&gt;
&lt;p&gt;Esa fricción no es un problema de Claude. Es un problema de infraestructura. Y la solución es una funcionalidad que la mayoría de los usuarios pasa de largo: los &lt;strong&gt;Skills&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Vibe Coding: Lo que la IA No te Va a Decir Antes de Construir tu Primera App</title><link>https://www.fernandoux.com/blog/es/vibe-coding-what-ai-wont-tell-you-before-building-your-first-app/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/blog/es/vibe-coding-what-ai-wont-tell-you-before-building-your-first-app/</guid><description>&lt;p&gt;Hay una conversación que ocurre miles de veces al día alrededor del mundo. Va más o menos así:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;&amp;ldquo;Hola Claude, necesito que me hagas una aplicación tipo YouTube pero sin errores.&amp;rdquo;&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Y la [[IA]] responde feliz, genera código, y el usuario piensa que acaba de contratar un equipo de ingenieros por 20 dólares al mes. Tres semanas después, la aplicación tiene 47 bugs, nadie sabe por qué el login falla los martes y el creador no puede cambiar el color de un botón sin romper el sistema de pagos.&lt;/p&gt;</description></item><item><title>Spec-Driven Development: El fin del Vibe Coding amateur y el inicio de la ingeniería de sistemas para UX</title><link>https://www.fernandoux.com/blog/es/spec-driven-development-the-end-of-amateur-vibe-coding-and-the-beginning-of-systems-engineering-for-ux/</link><pubDate>Tue, 10 Mar 2026 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/blog/es/spec-driven-development-the-end-of-amateur-vibe-coding-and-the-beginning-of-systems-engineering-for-ux/</guid><description>&lt;p&gt;El concepto de [[Vibe Coding]] es atractivo. Escribes en lenguaje natural, la IA escupe código, y en minutos tienes un prototipo. Funciona perfecto si estás haciendo un script de 100 líneas. Si intentas escalar eso a un producto real, el sistema colapsa.&lt;/p&gt;
&lt;p&gt;Me reuní con &lt;a href="https://dot.cards/ryanedge"&gt;Ryan Edge&lt;/a&gt; para desglosar exactamente cómo está utilizando agentes de [[IA]] para construir software complejo. El consenso es claro: depender de interfaces de chat para programar tiene un techo de cristal. Pierdes el contexto, la IA alucina, sobrescribe lógica existente y terminas haciendo trabajo manual para corregir a un robot.&lt;/p&gt;</description></item><item><title>Actualizaciones Optimistas y UX de Rollback</title><link>https://www.fernandoux.com/es/wiki/techniques/optimistic-updates-rollback/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/optimistic-updates-rollback/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Actualizaciones Optimistas&lt;/strong&gt; son una técnica de diseño de interacción donde la interfaz del usuario se actualiza inmediatamente tras una acción (como dar un &amp;ldquo;Like&amp;rdquo; o enviar un mensaje), asumiendo que el servidor procesará la petición con éxito, sin esperar a su respuesta real. El &lt;strong&gt;Rollback&lt;/strong&gt; es el proceso de revertir ese cambio visual si la petición acaba fallando.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-secreto-de-la-velocidad-en-apps-modernas"&gt;El Secreto de la Velocidad en Apps Modernas&lt;/h2&gt;
&lt;p&gt;Imagina que pulsas el botón de &amp;ldquo;Me gusta&amp;rdquo; en Instagram. Si el icono de corazón no se iluminara de rojo hasta que el servidor devuelva un &amp;ldquo;OK&amp;rdquo;, la aplicación se sentiría lenta y pesada.&lt;/p&gt;</description></item><item><title>Actualizaciones Optimistas y UX de Rollback</title><link>https://www.fernandoux.com/es/wiki/tecnicas/optimistic-updates-rollback/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/optimistic-updates-rollback/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Actualizaciones Optimistas&lt;/strong&gt; son una técnica de diseño de interacción donde la interfaz del usuario se actualiza inmediatamente tras una acción (como dar un &amp;ldquo;Like&amp;rdquo; o enviar un mensaje), asumiendo que el servidor procesará la petición con éxito, sin esperar a su respuesta real. El &lt;strong&gt;Rollback&lt;/strong&gt; es el proceso de revertir ese cambio visual si la petición acaba fallando.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-secreto-de-la-velocidad-en-apps-modernas"&gt;El Secreto de la Velocidad en Apps Modernas&lt;/h2&gt;
&lt;p&gt;Imagina que pulsas el botón de &amp;ldquo;Me gusta&amp;rdquo; en Instagram. Si el icono de corazón no se iluminara de rojo hasta que el servidor devuelva un &amp;ldquo;OK&amp;rdquo;, la aplicación se sentiría lenta y pesada.&lt;/p&gt;</description></item><item><title>ARIA vs HTML Semántico: La Regla de Oro</title><link>https://www.fernandoux.com/es/wiki/conceptos/aria-vs-semantica/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/aria-vs-semantica/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;HTML Semántico&lt;/strong&gt; utiliza las etiquetas nativas del navegador (como &lt;code&gt;&amp;lt;button&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;input&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;nav&amp;gt;&lt;/code&gt;) que ya traen accesibilidad y comportamiento integrados. &lt;strong&gt;ARIA&lt;/strong&gt; (Accessible Rich Internet Applications) es un conjunto de atributos que se añaden al código para &amp;ldquo;parchear&amp;rdquo; o explicar elementos personalizados que el navegador no entiende por defecto.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="la-primera-regla-de-aria"&gt;La Primera Regla de ARIA&lt;/h2&gt;
&lt;p&gt;Si hay una cosa que todo diseñador y desarrollador debe recordar es la &lt;strong&gt;Primer Regla de ARIA&lt;/strong&gt;:&lt;/p&gt;</description></item><item><title>ARIA vs HTML Semántico: La Regla de Oro</title><link>https://www.fernandoux.com/es/wiki/concepts/aria-vs-semantics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/aria-vs-semantics/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;HTML Semántico&lt;/strong&gt; utiliza las etiquetas nativas del navegador (como &lt;code&gt;&amp;lt;button&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;input&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;nav&amp;gt;&lt;/code&gt;) que ya traen accesibilidad y comportamiento integrados. &lt;strong&gt;ARIA&lt;/strong&gt; (Accessible Rich Internet Applications) es un conjunto de atributos que se añaden al código para &amp;ldquo;parchear&amp;rdquo; o explicar elementos personalizados que el navegador no entiende por defecto.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="la-primera-regla-de-aria"&gt;La Primera Regla de ARIA&lt;/h2&gt;
&lt;p&gt;Si hay una cosa que todo diseñador y desarrollador debe recordar es la &lt;strong&gt;Primer Regla de ARIA&lt;/strong&gt;:&lt;/p&gt;</description></item><item><title>Arquitectura de Tokens (Global vs Semántico vs Componente)</title><link>https://www.fernandoux.com/es/wiki/conceptos/arquitectura-de-tokens/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/arquitectura-de-tokens/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La arquitectura de tokens de diseño es la estructura lógica que organiza las decisiones de diseño (colores, tipografía, espaciado) en capas de abstracción. Un modelo bien diseñado permite cambiar la apariencia de todo un producto en minutos, garantizando coherencia y escalabilidad entre diseño y código.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-la-arquitectura-de-tokens"&gt;¿Qué es la Arquitectura de Tokens?&lt;/h2&gt;
&lt;p&gt;Imagina que estás construyendo una ciudad. No quieres tener que pintar cada ladrillo de cada casa individualmente. En su lugar, defines una &amp;ldquo;paleta de materiales&amp;rdquo; (tokens globales), decides que todos los edificios públicos serán de &amp;ldquo;color institucional&amp;rdquo; (tokens semánticos) y finalmente aplicas ese color a la &amp;ldquo;puerta principal del ayuntamiento&amp;rdquo; (tokens de componente).&lt;/p&gt;</description></item><item><title>Arquitectura de Tokens (Global vs Semántico vs Componente)</title><link>https://www.fernandoux.com/es/wiki/concepts/token-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/token-architecture/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La arquitectura de tokens de diseño es la estructura lógica que organiza las decisiones de diseño (colores, tipografía, espaciado) en capas de abstracción. Un modelo bien diseñado permite cambiar la apariencia de todo un producto en minutos, garantizando coherencia y escalabilidad entre diseño y código.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-la-arquitectura-de-tokens"&gt;¿Qué es la Arquitectura de Tokens?&lt;/h2&gt;
&lt;p&gt;Imagina que estás construyendo una ciudad. No quieres tener que pintar cada ladrillo de cada casa individualmente. En su lugar, defines una &amp;ldquo;paleta de materiales&amp;rdquo; (tokens globales), decides que todos los edificios públicos serán de &amp;ldquo;color institucional&amp;rdquo; (tokens semánticos) y finalmente aplicas ese color a la &amp;ldquo;puerta principal del ayuntamiento&amp;rdquo; (tokens de componente).&lt;/p&gt;</description></item><item><title>Breakpoint VS Container Queries: Diseño Basado en Componentes</title><link>https://www.fernandoux.com/es/wiki/conceptos/breakpoint-vs-container-queries/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/breakpoint-vs-container-queries/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Los &lt;strong&gt;Breakpoints&lt;/strong&gt; (Media Queries) cambian el diseño basándose en el ancho total de la pantalla del dispositivo (Viewport). Las &lt;strong&gt;Container Queries&lt;/strong&gt; cambian el diseño basándose en el espacio que tiene disponible el componente dentro de su contenedor padre.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-cambio-de-paradigma-en-el-diseño-de-producto"&gt;El Cambio de Paradigma en el Diseño de Producto&lt;/h2&gt;
&lt;p&gt;Durante la última década, hemos diseñado &amp;ldquo;pantallas&amp;rdquo;: móvil, tablet y escritorio. Sin embargo, en un sistema de diseño moderno, diseñamos &lt;strong&gt;componentes que habitan en diferentes lugares&lt;/strong&gt;. Un mismo componente de &amp;ldquo;Tarjeta de Producto&amp;rdquo; puede aparecer en una rejilla de 3 columnas en la página principal, o en una sola columna estrecha en una barra lateral.&lt;/p&gt;</description></item><item><title>Breakpoint VS Container Queries: Diseño Basado en Componentes</title><link>https://www.fernandoux.com/es/wiki/concepts/breakpoint-vs-container-queries/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/breakpoint-vs-container-queries/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Los &lt;strong&gt;Breakpoints&lt;/strong&gt; (Media Queries) cambian el diseño basándose en el ancho total de la pantalla del dispositivo (Viewport). Las &lt;strong&gt;Container Queries&lt;/strong&gt; cambian el diseño basándose en el espacio que tiene disponible el componente dentro de su contenedor padre.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-cambio-de-paradigma-en-el-diseño-de-producto"&gt;El Cambio de Paradigma en el Diseño de Producto&lt;/h2&gt;
&lt;p&gt;Durante la última década, hemos diseñado &amp;ldquo;pantallas&amp;rdquo;: móvil, tablet y escritorio. Sin embargo, en un sistema de diseño moderno, diseñamos &lt;strong&gt;componentes que habitan en diferentes lugares&lt;/strong&gt;. Un mismo componente de &amp;ldquo;Tarjeta de Producto&amp;rdquo; puede aparecer en una rejilla de 3 columnas en la página principal, o en una sola columna estrecha en una barra lateral.&lt;/p&gt;</description></item><item><title>Comportamiento de Intrinsic Sizing en UI</title><link>https://www.fernandoux.com/es/wiki/conceptos/intrinsic-sizing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/intrinsic-sizing/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Intrinsic Sizing&lt;/strong&gt; es un comportamiento de diseño donde las dimensiones de un elemento (ancho o alto) son determinadas por su propio contenido (letras, imágenes, iconos) en lugar de ser forzadas por un contenedor externo con medidas fijas.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-el-dimensionamiento-intrínseco"&gt;¿Qué es el Dimensionamiento Intrínseco?&lt;/h2&gt;
&lt;p&gt;Imagina que quieres meter camisas en una maleta.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Extrinsic Sizing (Extrínseco):&lt;/strong&gt; La maleta tiene un tamaño fijo de 50x40 cm. No importa si metes 1 camisa o 20, la maleta mide lo mismo.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Intrinsic Sizing (Intrínseco):&lt;/strong&gt; La maleta es de tela elástica y se ajusta exactamente al volumen de las camisas que metas. Si metes una camisa, es pequeña; si metes 20, se estira.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;En UI, esto significa que un botón no mide &amp;ldquo;200px&amp;rdquo;, sino que mide &lt;code&gt;Ancho del Texto + Paddings laterales&lt;/code&gt;. Si el texto cambia de &amp;ldquo;OK&amp;rdquo; a &amp;ldquo;Cancelar suscripción&amp;rdquo;, el botón se ensancha automáticamente.&lt;/p&gt;</description></item><item><title>Comportamiento de Intrinsic Sizing en UI</title><link>https://www.fernandoux.com/es/wiki/concepts/intrinsic-sizing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/intrinsic-sizing/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Intrinsic Sizing&lt;/strong&gt; es un comportamiento de diseño donde las dimensiones de un elemento (ancho o alto) son determinadas por su propio contenido (letras, imágenes, iconos) en lugar de ser forzadas por un contenedor externo con medidas fijas.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-el-dimensionamiento-intrínseco"&gt;¿Qué es el Dimensionamiento Intrínseco?&lt;/h2&gt;
&lt;p&gt;Imagina que quieres meter camisas en una maleta.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Extrinsic Sizing (Extrínseco):&lt;/strong&gt; La maleta tiene un tamaño fijo de 50x40 cm. No importa si metes 1 camisa o 20, la maleta mide lo mismo.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Intrinsic Sizing (Intrínseco):&lt;/strong&gt; La maleta es de tela elástica y se ajusta exactamente al volumen de las camisas que metas. Si metes una camisa, es pequeña; si metes 20, se estira.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;En UI, esto significa que un botón no mide &amp;ldquo;200px&amp;rdquo;, sino que mide &lt;code&gt;Ancho del Texto + Paddings laterales&lt;/code&gt;. Si el texto cambia de &amp;ldquo;OK&amp;rdquo; a &amp;ldquo;Cancelar suscripción&amp;rdquo;, el botón se ensancha automáticamente.&lt;/p&gt;</description></item><item><title>Conciencia de Estado (State Awareness) en UI</title><link>https://www.fernandoux.com/es/wiki/conceptos/conciencia-de-estado/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/conciencia-de-estado/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Conciencia de Estado&lt;/strong&gt; (State Awareness) es la capacidad de una interfaz para comunicar de forma clara y continua qué está ocurriendo en el sistema, en qué paso del proceso se encuentra el usuario y cuál es la condición actual de cada componente (ej. si un botón está pulsado, si un dato se está cargando o si hay un error).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-usuario-necesita-conciencia-de-estado"&gt;¿Por qué el Usuario necesita Conciencia de Estado?&lt;/h2&gt;
&lt;p&gt;Como seres humanos, odiamos la incertidumbre. En el mundo físico, si pulsas un interruptor y la luz no se enciende, sabes que hay un fallo porque el interruptor cambió de posición físicamente. En el mundo digital, si un usuario pulsa un botón y no pasa nada visualmente en los primeros milisegundos, el usuario pulsará el botón 5 veces más, generando errores en el servidor y frustración.&lt;/p&gt;</description></item><item><title>Conciencia de Estado (State Awareness) en UI</title><link>https://www.fernandoux.com/es/wiki/concepts/status-awareness/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/status-awareness/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Conciencia de Estado&lt;/strong&gt; (State Awareness) es la capacidad de una interfaz para comunicar de forma clara y continua qué está ocurriendo en el sistema, en qué paso del proceso se encuentra el usuario y cuál es la condición actual de cada componente (ej. si un botón está pulsado, si un dato se está cargando o si hay un error).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-usuario-necesita-conciencia-de-estado"&gt;¿Por qué el Usuario necesita Conciencia de Estado?&lt;/h2&gt;
&lt;p&gt;Como seres humanos, odiamos la incertidumbre. En el mundo físico, si pulsas un interruptor y la luz no se enciende, sabes que hay un fallo porque el interruptor cambió de posición físicamente. En el mundo digital, si un usuario pulsa un botón y no pasa nada visualmente en los primeros milisegundos, el usuario pulsará el botón 5 veces más, generando errores en el servidor y frustración.&lt;/p&gt;</description></item><item><title>Decisiones de Intrinsic Layout: Contenido VS Cajas</title><link>https://www.fernandoux.com/es/wiki/techniques/intrinsic-layout-decisions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/intrinsic-layout-decisions/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Decisiones de Intrinsic Layout&lt;/strong&gt; son las reglas de diseño que definen cómo se posicionan y escalan los elementos de una interfaz basándose en las necesidades de su propio contenido (como el ancho del texto o el tamaño de la imagen) en lugar de ser forzados por una rejilla externa (Layout Grid).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-intrinsic-layout-es-la-mejor-opción-para-productos-dinámicos"&gt;¿Por qué el Intrinsic Layout es la mejor opción para productos dinámicos?&lt;/h2&gt;
&lt;p&gt;Históricamente, diseñamos webs con rejillas de 12 columnas. Es un sistema seguro y predecible, pero frágil. Si un nombre de usuario es demasiado largo, el diseño de la rejilla se rompe o el texto se corta.&lt;/p&gt;</description></item><item><title>Decisiones de Intrinsic Layout: Contenido VS Cajas</title><link>https://www.fernandoux.com/es/wiki/tecnicas/intrinsic-layout-decisions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/intrinsic-layout-decisions/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Decisiones de Intrinsic Layout&lt;/strong&gt; son las reglas de diseño que definen cómo se posicionan y escalan los elementos de una interfaz basándose en las necesidades de su propio contenido (como el ancho del texto o el tamaño de la imagen) en lugar de ser forzados por una rejilla externa (Layout Grid).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-intrinsic-layout-es-la-mejor-opción-para-productos-dinámicos"&gt;¿Por qué el Intrinsic Layout es la mejor opción para productos dinámicos?&lt;/h2&gt;
&lt;p&gt;Históricamente, diseñamos webs con rejillas de 12 columnas. Es un sistema seguro y predecible, pero frágil. Si un nombre de usuario es demasiado largo, el diseño de la rejilla se rompe o el texto se corta.&lt;/p&gt;</description></item><item><title>Decisiones de Layout: Grid vs Intrinsic</title><link>https://www.fernandoux.com/es/wiki/techniques/layout-grid-vs-intrinsic/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/layout-grid-vs-intrinsic/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Layout Grids&lt;/strong&gt; son rejillas predefinidas que fuerzan los elementos a seguir una estructura rígida de columnas y distancias específicas. El &lt;strong&gt;Intrinsic Layout&lt;/strong&gt; es un enfoque donde el tamaño y la posición de los elementos dependen de su contenido y su relación interna, sin depender de una cuadrícula externa.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-dilema-del-layout-moderno"&gt;El Dilema del Layout Moderno&lt;/h2&gt;
&lt;p&gt;En la web de principios de la década de 2010, todo se basaba en rejillas de 12 columnas. Hoy, gracias a las capacidades de Figma (Auto Layout) y de los navegadores modernos (Flexbox/CSS Grid), el diseño se está volviendo más fluido y menos dependiente de estas estructuras fijas. La pregunta clave es: ¿Cuándo debemos forzar la rejilla y cuándo debemos dejar que el contenido mande sobre el espacio?&lt;/p&gt;</description></item><item><title>Decisiones de Layout: Grid vs Intrinsic</title><link>https://www.fernandoux.com/es/wiki/tecnicas/layout-grid-vs-intrinsic/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/layout-grid-vs-intrinsic/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Layout Grids&lt;/strong&gt; son rejillas predefinidas que fuerzan los elementos a seguir una estructura rígida de columnas y distancias específicas. El &lt;strong&gt;Intrinsic Layout&lt;/strong&gt; es un enfoque donde el tamaño y la posición de los elementos dependen de su contenido y su relación interna, sin depender de una cuadrícula externa.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-dilema-del-layout-moderno"&gt;El Dilema del Layout Moderno&lt;/h2&gt;
&lt;p&gt;En la web de principios de la década de 2010, todo se basaba en rejillas de 12 columnas. Hoy, gracias a las capacidades de Figma (Auto Layout) y de los navegadores modernos (Flexbox/CSS Grid), el diseño se está volviendo más fluido y menos dependiente de estas estructuras fijas. La pregunta clave es: ¿Cuándo debemos forzar la rejilla y cuándo debemos dejar que el contenido mande sobre el espacio?&lt;/p&gt;</description></item><item><title>Diseño de APIs de Componentes: Predictibilidad y Flexibilidad</title><link>https://www.fernandoux.com/es/wiki/techniques/component-api-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/component-api-design/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El diseño de una &lt;strong&gt;API de Componentes&lt;/strong&gt; consiste en definir un contrato claro de entrada (props) y comportamiento para los elementos de un sistema de diseño, con el objetivo de que sean fáciles de usar, predecibles y mantenibles tanto para diseñadores como para desarrolladores.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-compone-una-buena-api-de-componentes"&gt;¿Qué Compone una Buena API de Componentes?&lt;/h2&gt;
&lt;p&gt;Un componente no es solo una pieza visual; es una unidad de lógica funcional. Una API bien diseñada debe responder de forma clara a estas tres premisas fundamentales:&lt;/p&gt;</description></item><item><title>Diseño de APIs de Componentes: Predictibilidad y Flexibilidad</title><link>https://www.fernandoux.com/es/wiki/tecnicas/diseno-apis-componentes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/diseno-apis-componentes/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El diseño de una &lt;strong&gt;API de Componentes&lt;/strong&gt; consiste en definir un contrato claro de entrada (props) y comportamiento para los elementos de un sistema de diseño, con el objetivo de que sean fáciles de usar, predecibles y mantenibles tanto para diseñadores como para desarrolladores.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-compone-una-buena-api-de-componentes"&gt;¿Qué Compone una Buena API de Componentes?&lt;/h2&gt;
&lt;p&gt;Un componente no es solo una pieza visual; es una unidad de lógica funcional. Una API bien diseñada debe responder de forma clara a estas tres premisas fundamentales:&lt;/p&gt;</description></item><item><title>Diseño para el Rendimiento Percibido: Más Rápido que la Luz</title><link>https://www.fernandoux.com/es/wiki/conceptos/perceived-performance-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/perceived-performance-design/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Rendimiento Percibido&lt;/strong&gt; es el tiempo que un usuario siente que tarda un sistema en responder, independientemente de la velocidad real (milisegundos) de la conexión o el procesador. En el diseño de producto, &lt;strong&gt;la percepción es la realidad.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-importa-el-rendimiento-percibido"&gt;¿Por qué importa el Rendimiento Percibido?&lt;/h2&gt;
&lt;p&gt;Podemos tener la aplicación mejor optimizada del mundo, pero si el usuario se queda mirando una pantalla en blanco durante 2 segundos, pensará que la app es lenta.&lt;/p&gt;</description></item><item><title>Diseño para el Rendimiento Percibido: Más Rápido que la Luz</title><link>https://www.fernandoux.com/es/wiki/concepts/perceived-performance-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/perceived-performance-design/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Rendimiento Percibido&lt;/strong&gt; es el tiempo que un usuario siente que tarda un sistema en responder, independientemente de la velocidad real (milisegundos) de la conexión o el procesador. En el diseño de producto, &lt;strong&gt;la percepción es la realidad.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-importa-el-rendimiento-percibido"&gt;¿Por qué importa el Rendimiento Percibido?&lt;/h2&gt;
&lt;p&gt;Podemos tener la aplicación mejor optimizada del mundo, pero si el usuario se queda mirando una pantalla en blanco durante 2 segundos, pensará que la app es lenta.&lt;/p&gt;</description></item><item><title>El Command Pattern en el Diseño de Producto</title><link>https://www.fernandoux.com/es/wiki/conceptos/command-pattern/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/command-pattern/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Command Pattern&lt;/strong&gt; es un patrón de diseño de software que encapsula una solicitud o acción del usuario como un objeto independiente. En el mundo del diseño de producto, esto nos permite tratar cada acción (borrar, mover, editar, cambiar color) como una entidad que se puede almacenar, deshacer, rehacer y sincronizar a través de varios usuarios.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-conocer-el-command-pattern"&gt;¿Por qué el Diseñador debe Conocer el Command Pattern?&lt;/h2&gt;
&lt;p&gt;Tradicionalmente, el diseño se centraba en el &lt;strong&gt;estado final&lt;/strong&gt; de las pantallas (la foto fija). Sin embargo, los productos modernos (como Figma, Notion o Google Docs) se centran en las &lt;strong&gt;acciones&lt;/strong&gt; que llevan de un estado a otro. El Command Pattern es el lenguaje técnico que permite que estas transiciones sean posibles.&lt;/p&gt;</description></item><item><title>El Command Pattern en el Diseño de Producto</title><link>https://www.fernandoux.com/es/wiki/concepts/command-pattern/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/command-pattern/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Command Pattern&lt;/strong&gt; es un patrón de diseño de software que encapsula una solicitud o acción del usuario como un objeto independiente. En el mundo del diseño de producto, esto nos permite tratar cada acción (borrar, mover, editar, cambiar color) como una entidad que se puede almacenar, deshacer, rehacer y sincronizar a través de varios usuarios.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-conocer-el-command-pattern"&gt;¿Por qué el Diseñador debe Conocer el Command Pattern?&lt;/h2&gt;
&lt;p&gt;Tradicionalmente, el diseño se centraba en el &lt;strong&gt;estado final&lt;/strong&gt; de las pantallas (la foto fija). Sin embargo, los productos modernos (como Figma, Notion o Google Docs) se centran en las &lt;strong&gt;acciones&lt;/strong&gt; que llevan de un estado a otro. El Command Pattern es el lenguaje técnico que permite que estas transiciones sean posibles.&lt;/p&gt;</description></item><item><title>Estados de Carga: La Espera Indulgente en UX</title><link>https://www.fernandoux.com/es/wiki/techniques/loading-states/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/loading-states/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Un &lt;strong&gt;Estado de Carga&lt;/strong&gt; (Loading State) es la información visual o sonora que se muestra al usuario mientras el sistema procesa una acción (ej. cargar datos de un servidor, subir un archivo o realizar una búsqueda). Un buen diseño de carga elimina el miedo al &amp;ldquo;sistema congelado&amp;rdquo;.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-estado-de-carga-es-crítico"&gt;¿Por qué el Estado de Carga es Crítico?&lt;/h2&gt;
&lt;p&gt;El momento en que un usuario pulsa un botón y espera una respuesta es el momento de mayor vulnerabilidad y posible frustración. Sin un estado de carga claro, el usuario no sabe si:&lt;/p&gt;</description></item><item><title>Estados de Carga: La Espera Indulgente en UX</title><link>https://www.fernandoux.com/es/wiki/tecnicas/estados-de-carga/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/estados-de-carga/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Un &lt;strong&gt;Estado de Carga&lt;/strong&gt; (Loading State) es la información visual o sonora que se muestra al usuario mientras el sistema procesa una acción (ej. cargar datos de un servidor, subir un archivo o realizar una búsqueda). Un buen diseño de carga elimina el miedo al &amp;ldquo;sistema congelado&amp;rdquo;.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-estado-de-carga-es-crítico"&gt;¿Por qué el Estado de Carga es Crítico?&lt;/h2&gt;
&lt;p&gt;El momento en que un usuario pulsa un botón y espera una respuesta es el momento de mayor vulnerabilidad y posible frustración. Sin un estado de carga claro, el usuario no sabe si:&lt;/p&gt;</description></item><item><title>Estrategia de Aliasing y Herencia de Tokens</title><link>https://www.fernandoux.com/es/wiki/techniques/token-aliasing-inheritance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/token-aliasing-inheritance/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Aliasing&lt;/strong&gt; de tokens consiste en definir un token que hace referencia a otro token en lugar de a un valor bruto (como un hexadecimal o píxeles). La &lt;strong&gt;Herencia&lt;/strong&gt; es la estructura lógica que permite que las decisiones de diseño fluyan de lo más general a lo más específico, garantizando coherencia y flexibilidad total en el sistema.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-el-aliasing-de-tokens"&gt;¿Qué es el Aliasing de Tokens?&lt;/h2&gt;
&lt;p&gt;Imagina que quieres comprar un coche de &amp;ldquo;Color Deportivo&amp;rdquo;.&lt;/p&gt;</description></item><item><title>Estrategia de Aliasing y Herencia de Tokens</title><link>https://www.fernandoux.com/es/wiki/tecnicas/aliasing-herencia-tokens/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/aliasing-herencia-tokens/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Aliasing&lt;/strong&gt; de tokens consiste en definir un token que hace referencia a otro token en lugar de a un valor bruto (como un hexadecimal o píxeles). La &lt;strong&gt;Herencia&lt;/strong&gt; es la estructura lógica que permite que las decisiones de diseño fluyan de lo más general a lo más específico, garantizando coherencia y flexibilidad total en el sistema.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-el-aliasing-de-tokens"&gt;¿Qué es el Aliasing de Tokens?&lt;/h2&gt;
&lt;p&gt;Imagina que quieres comprar un coche de &amp;ldquo;Color Deportivo&amp;rdquo;.&lt;/p&gt;</description></item><item><title>Estrategia de Tab Order: El Camino del Usuario de Teclado</title><link>https://www.fernandoux.com/es/wiki/estrategia/estrategia-tab-order/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/estrategia/estrategia-tab-order/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Tab Order&lt;/strong&gt; es la secuencia exacta en la que un usuario de teclado (pulsando &lt;code&gt;Tab&lt;/code&gt; y &lt;code&gt;Shift + Tab&lt;/code&gt;) recorre los elementos interactivos de una interfaz. Una buena estrategia de tabulación asegura que el usuario no se pierda, no tenga que dar clics innecesarios y pueda completar sus tareas de forma rápida y lógica.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-decidir-el-tab-order"&gt;¿Por qué el Diseñador debe Decidir el Tab Order?&lt;/h2&gt;
&lt;p&gt;Aunque el orden de tabulación suele ser una consecuencia automática del orden en el código HTML (el DOM), el diseño visual puede ser mucho más complejo. Como diseñadores, a veces creamos layouts con columnas, rejillas (grids) o elementos flotantes que no siguen un orden lineal puro.&lt;/p&gt;</description></item><item><title>Estrategia de Tab Order: El Camino del Usuario de Teclado</title><link>https://www.fernandoux.com/es/wiki/strategy/tab-order-strategy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/strategy/tab-order-strategy/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Tab Order&lt;/strong&gt; es la secuencia exacta en la que un usuario de teclado (pulsando &lt;code&gt;Tab&lt;/code&gt; y &lt;code&gt;Shift + Tab&lt;/code&gt;) recorre los elementos interactivos de una interfaz. Una buena estrategia de tabulación asegura que el usuario no se pierda, no tenga que dar clics innecesarios y pueda completar sus tareas de forma rápida y lógica.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-decidir-el-tab-order"&gt;¿Por qué el Diseñador debe Decidir el Tab Order?&lt;/h2&gt;
&lt;p&gt;Aunque el orden de tabulación suele ser una consecuencia automática del orden en el código HTML (el DOM), el diseño visual puede ser mucho más complejo. Como diseñadores, a veces creamos layouts con columnas, rejillas (grids) o elementos flotantes que no siguen un orden lineal puro.&lt;/p&gt;</description></item><item><title>Estrategias de Escalado Responsivo: UI Líquida</title><link>https://www.fernandoux.com/es/wiki/techniques/responsive-scaling-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/responsive-scaling-strategies/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Estrategias de Escalado Responsivo&lt;/strong&gt; definen cómo se comportan los elementos de una interfaz cuando el espacio disponible cambia. No es solo redimensionar cajas, sino decidir qué elementos crecen, cuáles se apilan, cuáles desaparecen y cuáles mantienen su tamaño original para garantizar la usabilidad en cualquier dispositivo.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-reto-de-las-pantallas-infinitas"&gt;El Reto de las Pantallas Infinitas&lt;/h2&gt;
&lt;p&gt;Hoy en día, diseñamos para un reloj inteligente (Apple Watch) de 30mm y para un monitor curvo de 49 pulgadas. No podemos diseñar una pantalla para cada ancho. Necesitamos una &lt;strong&gt;Estrategia de Escalado&lt;/strong&gt; que sea líquida y resiliente.&lt;/p&gt;</description></item><item><title>Estrategias de Escalado Responsivo: UI Líquida</title><link>https://www.fernandoux.com/es/wiki/tecnicas/estrategias-de-escalado-responsivo/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/estrategias-de-escalado-responsivo/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Estrategias de Escalado Responsivo&lt;/strong&gt; definen cómo se comportan los elementos de una interfaz cuando el espacio disponible cambia. No es solo redimensionar cajas, sino decidir qué elementos crecen, cuáles se apilan, cuáles desaparecen y cuáles mantienen su tamaño original para garantizar la usabilidad en cualquier dispositivo.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-reto-de-las-pantallas-infinitas"&gt;El Reto de las Pantallas Infinitas&lt;/h2&gt;
&lt;p&gt;Hoy en día, diseñamos para un reloj inteligente (Apple Watch) de 30mm y para un monitor curvo de 49 pulgadas. No podemos diseñar una pantalla para cada ancho. Necesitamos una &lt;strong&gt;Estrategia de Escalado&lt;/strong&gt; que sea líquida y resiliente.&lt;/p&gt;</description></item><item><title>Flujos Offline-First: Diseñar para la Desconexión</title><link>https://www.fernandoux.com/es/wiki/estrategia/flujos-offline-first/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/estrategia/flujos-offline-first/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La estrategia &lt;strong&gt;Offline-First&lt;/strong&gt; es un enfoque de diseño y desarrollo que asume que el usuario tendrá una conexión a internet intermitente o nula en algún momento. En lugar de tratar el &amp;ldquo;Offline&amp;rdquo; como un estado de error, se trata como una característica fundamental del producto. El objetivo es que la aplicación siga funcionando siempre.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-reto-de-las-aplicaciones-de-producto-modernas"&gt;El Reto de las Aplicaciones de Producto Modernas&lt;/h2&gt;
&lt;p&gt;La mayoría de las apps web tradicionales (como Jira o Gmail) suelen romperse o mostrar un dinosaurio de Chrome cuando el Wifi se corta. En el diseño de productos digitales avanzado, como Notion, Figma o Linear, esto ya no es aceptable.&lt;/p&gt;</description></item><item><title>Flujos Offline-First: Diseñar para la Desconexión</title><link>https://www.fernandoux.com/es/wiki/strategy/offline-first-flows/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/strategy/offline-first-flows/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La estrategia &lt;strong&gt;Offline-First&lt;/strong&gt; es un enfoque de diseño y desarrollo que asume que el usuario tendrá una conexión a internet intermitente o nula en algún momento. En lugar de tratar el &amp;ldquo;Offline&amp;rdquo; como un estado de error, se trata como una característica fundamental del producto. El objetivo es que la aplicación siga funcionando siempre.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-reto-de-las-aplicaciones-de-producto-modernas"&gt;El Reto de las Aplicaciones de Producto Modernas&lt;/h2&gt;
&lt;p&gt;La mayoría de las apps web tradicionales (como Jira o Gmail) suelen romperse o mostrar un dinosaurio de Chrome cuando el Wifi se corta. En el diseño de productos digitales avanzado, como Notion, Figma o Linear, esto ya no es aceptable.&lt;/p&gt;</description></item><item><title>Fundamentos del Accessibility Tree: Cómo Ven las Máquinas</title><link>https://www.fernandoux.com/es/wiki/conceptos/accessibility-tree/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/accessibility-tree/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Accessibility Tree&lt;/strong&gt; (Árbol de Accesibilidad) es una estructura de datos generada por el navegador (basada en el DOM) que contiene solo la información relevante para las tecnologías asistivas (como lectores de pantalla o dictado por voz). No es visual; es una traducción de tu diseño en nombres, roles, estados y valores.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-conocer-el-árbol-de-accesibilidad"&gt;¿Por qué el Diseñador debe Conocer el Árbol de Accesibilidad?&lt;/h2&gt;
&lt;p&gt;Como diseñadores, solemos centrarnos en el &lt;strong&gt;DOM Visual&lt;/strong&gt; (colores, formas, posiciones). Sin embargo, para los usuarios ciegos o con discapacidad visual, tu diseño es solo lo que el Árbol de Accesibilidad dice que es.&lt;/p&gt;</description></item><item><title>Fundamentos del Accessibility Tree: Cómo Ven las Máquinas</title><link>https://www.fernandoux.com/es/wiki/concepts/accessibility-tree/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/accessibility-tree/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 El &lt;strong&gt;Accessibility Tree&lt;/strong&gt; (Árbol de Accesibilidad) es una estructura de datos generada por el navegador (basada en el DOM) que contiene solo la información relevante para las tecnologías asistivas (como lectores de pantalla o dictado por voz). No es visual; es una traducción de tu diseño en nombres, roles, estados y valores.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-conocer-el-árbol-de-accesibilidad"&gt;¿Por qué el Diseñador debe Conocer el Árbol de Accesibilidad?&lt;/h2&gt;
&lt;p&gt;Como diseñadores, solemos centrarnos en el &lt;strong&gt;DOM Visual&lt;/strong&gt; (colores, formas, posiciones). Sin embargo, para los usuarios ciegos o con discapacidad visual, tu diseño es solo lo que el Árbol de Accesibilidad dice que es.&lt;/p&gt;</description></item><item><title>Gestión de Foco: La Navegación sin Ratón</title><link>https://www.fernandoux.com/es/wiki/techniques/focus-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/focus-management/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Gestión de Foco&lt;/strong&gt; es el control de qué elemento de la interfaz está seleccionado en cada momento para interactuar con él. Es la columna vertebral de la navegación para usuarios de teclado (que pulsan &lt;code&gt;Tab&lt;/code&gt;), lectores de pantalla y cualquier persona que no use un ratón.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-gestionar-el-foco"&gt;¿Por qué el Diseñador debe Gestionar el Foco?&lt;/h2&gt;
&lt;p&gt;Imagina que entras en una habitación a oscuras y solo tienes una linterna. La zona que ilumina tu linterna es &amp;ldquo;el foco&amp;rdquo;. Si mueves la linterna y, de repente, la luz desaparece o salta a la habitación de al lado sin sentido, te sentirás perdido y frustrado.&lt;/p&gt;</description></item><item><title>Gestión de Foco: La Navegación sin Ratón</title><link>https://www.fernandoux.com/es/wiki/tecnicas/gestion-de-foco/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/gestion-de-foco/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Gestión de Foco&lt;/strong&gt; es el control de qué elemento de la interfaz está seleccionado en cada momento para interactuar con él. Es la columna vertebral de la navegación para usuarios de teclado (que pulsan &lt;code&gt;Tab&lt;/code&gt;), lectores de pantalla y cualquier persona que no use un ratón.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-gestionar-el-foco"&gt;¿Por qué el Diseñador debe Gestionar el Foco?&lt;/h2&gt;
&lt;p&gt;Imagina que entras en una habitación a oscuras y solo tienes una linterna. La zona que ilumina tu linterna es &amp;ldquo;el foco&amp;rdquo;. Si mueves la linterna y, de repente, la luz desaparece o salta a la habitación de al lado sin sentido, te sentirás perdido y frustrado.&lt;/p&gt;</description></item><item><title>Jerarquía Visual VS Jerarquía del DOM: Accesibilidad</title><link>https://www.fernandoux.com/es/wiki/conceptos/visual-vs-dom-hierarchy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/visual-vs-dom-hierarchy/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Jerarquía Visual&lt;/strong&gt; es el orden en que un usuario ve y procesa la información en una pantalla basándose en el tamaño, color, posición y contraste. La &lt;strong&gt;Jerarquía del DOM&lt;/strong&gt; (Document Object Model) es el orden en que el código HTML estructura y lee esa misma información. Alinear ambas es la clave de la accesibilidad y el SEO.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-conocer-la-jerarquía-del-dom"&gt;¿Por qué el Diseñador debe Conocer la Jerarquía del DOM?&lt;/h2&gt;
&lt;p&gt;Como diseñadores, solemos &amp;ldquo;dibujar&amp;rdquo; elementos en el lienzo de Figma sin preocuparnos de su orden interno. Sin embargo, para un usuario de &lt;a href="https://www.fernandoux.com/tecnicas/pruebas-lectores-pantalla/"&gt;Lector de Pantalla&lt;/a&gt; o de &lt;a href="https://www.fernandoux.com/tecnicas/gestion-de-foco/"&gt;Teclado&lt;/a&gt;, tu diseño no es una imagen; es una lista secuencial de elementos.&lt;/p&gt;</description></item><item><title>Jerarquía Visual VS Jerarquía del DOM: Accesibilidad</title><link>https://www.fernandoux.com/es/wiki/concepts/visual-vs-dom-hierarchy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/visual-vs-dom-hierarchy/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Jerarquía Visual&lt;/strong&gt; es el orden en que un usuario ve y procesa la información en una pantalla basándose en el tamaño, color, posición y contraste. La &lt;strong&gt;Jerarquía del DOM&lt;/strong&gt; (Document Object Model) es el orden en que el código HTML estructura y lee esa misma información. Alinear ambas es la clave de la accesibilidad y el SEO.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-conocer-la-jerarquía-del-dom"&gt;¿Por qué el Diseñador debe Conocer la Jerarquía del DOM?&lt;/h2&gt;
&lt;p&gt;Como diseñadores, solemos &amp;ldquo;dibujar&amp;rdquo; elementos en el lienzo de Figma sin preocuparnos de su orden interno. Sin embargo, para un usuario de &lt;a href="https://www.fernandoux.com/techniques/screen-reader-testing/"&gt;Lector de Pantalla&lt;/a&gt; o de &lt;a href="https://www.fernandoux.com/techniques/focus-management/"&gt;Teclado&lt;/a&gt;, tu diseño no es una imagen; es una lista secuencial de elementos.&lt;/p&gt;</description></item><item><title>Organización de Props de Componentes: Estructura y Jerarquía</title><link>https://www.fernandoux.com/es/wiki/techniques/component-props-organization/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/component-props-organization/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Organización de Props&lt;/strong&gt; consiste en estructurar y priorizar las propiedades de un componente para que su uso sea intuitivo y predecible. Esto reduce la carga cognitiva de los diseñadores en Figma y de los desarrolladores en el código, facilitando la creación de interfaces consistentes.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-importa-el-orden-de-las-props"&gt;¿Por qué importa el orden de las Props?&lt;/h2&gt;
&lt;p&gt;Imagina un componente complejo (ej. un &lt;code&gt;Input&lt;/code&gt; con etiqueta, icono, mensaje de error y ayuda). Si las propiedades de configuración están desordenadas, el usuario del sistema de diseño (el diseñador o el desarrollador) perderá tiempo buscando cómo cambiar el color del icono o el tamaño del texto.&lt;/p&gt;</description></item><item><title>Organización de Props de Componentes: Estructura y Jerarquía</title><link>https://www.fernandoux.com/es/wiki/tecnicas/organizacion-props-componentes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/organizacion-props-componentes/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La &lt;strong&gt;Organización de Props&lt;/strong&gt; consiste en estructurar y priorizar las propiedades de un componente para que su uso sea intuitivo y predecible. Esto reduce la carga cognitiva de los diseñadores en Figma y de los desarrolladores en el código, facilitando la creación de interfaces consistentes.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-importa-el-orden-de-las-props"&gt;¿Por qué importa el orden de las Props?&lt;/h2&gt;
&lt;p&gt;Imagina un componente complejo (ej. un &lt;code&gt;Input&lt;/code&gt; con etiqueta, icono, mensaje de error y ayuda). Si las propiedades de configuración están desordenadas, el usuario del sistema de diseño (el diseñador o el desarrollador) perderá tiempo buscando cómo cambiar el color del icono o el tamaño del texto.&lt;/p&gt;</description></item><item><title>Paridad de Tokens en Múltiples Plataformas</title><link>https://www.fernandoux.com/es/wiki/conceptos/paridad-de-tokens/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/paridad-de-tokens/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La paridad de tokens asegura que las decisiones de diseño se traduzcan de manera idéntica y precisa a través de diferentes plataformas (Web, iOS, Android, Desktop) utilizando un único sistema de origen. Esto elimina inconsistencias visuales y reduce significativamente el esfuerzo de QA.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-desafío-de-la-fragmentación-de-plataformas"&gt;El Desafío de la Fragmentación de Plataformas&lt;/h2&gt;
&lt;p&gt;Cada ecosistema tecnológico maneja los estilos (colores, fuentes, sombras) de forma única. Si un diseñador elige un &amp;ldquo;Azul Primario&amp;rdquo;, se enfrenta a:&lt;/p&gt;</description></item><item><title>Paridad de Tokens en Múltiples Plataformas</title><link>https://www.fernandoux.com/es/wiki/concepts/token-parity/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/token-parity/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 La paridad de tokens asegura que las decisiones de diseño se traduzcan de manera idéntica y precisa a través de diferentes plataformas (Web, iOS, Android, Desktop) utilizando un único sistema de origen. Esto elimina inconsistencias visuales y reduce significativamente el esfuerzo de QA.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-desafío-de-la-fragmentación-de-plataformas"&gt;El Desafío de la Fragmentación de Plataformas&lt;/h2&gt;
&lt;p&gt;Cada ecosistema tecnológico maneja los estilos (colores, fuentes, sombras) de forma única. Si un diseñador elige un &amp;ldquo;Azul Primario&amp;rdquo;, se enfrenta a:&lt;/p&gt;</description></item><item><title>Presupuestos de Latencia en UX: Tiempos de Respuesta</title><link>https://www.fernandoux.com/es/wiki/estrategia/interaction-latency-budgets/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/estrategia/interaction-latency-budgets/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Un &lt;strong&gt;Presupuesto de Latencia&lt;/strong&gt; (Latency Budget) es el tiempo máximo permitido (en milisegundos) para que una acción del usuario produzca una respuesta visible en la interfaz. No es una métrica técnica; es un compromiso de diseño para garantizar la fluidez de la experiencia.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-establecer-presupuestos-de-latencia"&gt;¿Por qué el Diseñador debe establecer Presupuestos de Latencia?&lt;/h2&gt;
&lt;p&gt;A menudo, los diseñadores crean flujos complejos e interacciones pesadas sin considerar el coste técnico. Si una animación de apertura de un menú tarda 500ms y el servidor otros 1000ms en devolver los datos, el usuario sentirá que la aplicación es una barca pesada.&lt;/p&gt;</description></item><item><title>Presupuestos de Latencia en UX: Tiempos de Respuesta</title><link>https://www.fernandoux.com/es/wiki/strategy/interaction-latency-budgets/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/strategy/interaction-latency-budgets/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Un &lt;strong&gt;Presupuesto de Latencia&lt;/strong&gt; (Latency Budget) es el tiempo máximo permitido (en milisegundos) para que una acción del usuario produzca una respuesta visible en la interfaz. No es una métrica técnica; es un compromiso de diseño para garantizar la fluidez de la experiencia.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-establecer-presupuestos-de-latencia"&gt;¿Por qué el Diseñador debe establecer Presupuestos de Latencia?&lt;/h2&gt;
&lt;p&gt;A menudo, los diseñadores crean flujos complejos e interacciones pesadas sin considerar el coste técnico. Si una animación de apertura de un menú tarda 500ms y el servidor otros 1000ms en devolver los datos, el usuario sentirá que la aplicación es una barca pesada.&lt;/p&gt;</description></item><item><title>Skeleton VS Optimistic UI: Estrategias de Carga</title><link>https://www.fernandoux.com/es/wiki/conceptos/skeleton-vs-optimistic-ui/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/skeleton-vs-optimistic-ui/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Skeleton Screens&lt;/strong&gt; (Pantallas de Esqueleto) son marcadores de posición grises que imitan la estructura final de la página mientras se cargan los datos. La &lt;strong&gt;Optimistic UI&lt;/strong&gt; (Interfaz Optimista) es una técnica que muestra el resultado de una acción inmediatamente, asumiendo que el servidor responderá con éxito.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-arte-de-la-espera-rendimiento-percibido"&gt;El Arte de la Espera: Rendimiento Percibido&lt;/h2&gt;
&lt;p&gt;En el diseño de producto moderno, la velocidad no es solo una cuestión de milisegundos reales (latencia), sino de cómo el usuario &lt;strong&gt;siente&lt;/strong&gt; que el sistema está respondiendo. Ambas técnicas buscan reducir la ansiedad del usuario durante la carga, pero se aplican en momentos diferentes del flujo.&lt;/p&gt;</description></item><item><title>Skeleton VS Optimistic UI: Estrategias de Carga</title><link>https://www.fernandoux.com/es/wiki/concepts/skeleton-vs-optimistic-ui/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/skeleton-vs-optimistic-ui/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Las &lt;strong&gt;Skeleton Screens&lt;/strong&gt; (Pantallas de Esqueleto) son marcadores de posición grises que imitan la estructura final de la página mientras se cargan los datos. La &lt;strong&gt;Optimistic UI&lt;/strong&gt; (Interfaz Optimista) es una técnica que muestra el resultado de una acción inmediatamente, asumiendo que el servidor responderá con éxito.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-arte-de-la-espera-rendimiento-percibido"&gt;El Arte de la Espera: Rendimiento Percibido&lt;/h2&gt;
&lt;p&gt;En el diseño de producto moderno, la velocidad no es solo una cuestión de milisegundos reales (latencia), sino de cómo el usuario &lt;strong&gt;siente&lt;/strong&gt; que el sistema está respondiendo. Ambas técnicas buscan reducir la ansiedad del usuario durante la carga, pero se aplican en momentos diferentes del flujo.&lt;/p&gt;</description></item><item><title>Storybook</title><link>https://www.fernandoux.com/es/wiki/herramientas/storybook/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/herramientas/storybook/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Storybook es una herramienta de desarrollo de código abierto para construir, probar y documentar componentes de UI de forma aislada. Permite a los desarrolladores crear componentes en un entorno de &amp;ldquo;sandbox&amp;rdquo; fuera de la aplicación principal, lo que facilita la visualización de todos sus estados y la colaboración con los diseñadores.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-storybook"&gt;¿Qué es Storybook?&lt;/h2&gt;
&lt;p&gt;Imagina que estás construyendo un coche con piezas de LEGO. Storybook es como un taller donde puedes construir y probar cada pieza por separado antes de ensamblar el coche. Puedes construir el motor (un componente complejo) y probarlo por sí solo, o puedes construir una simple rueda (un botón) y ver todos sus colores y tamaños disponibles, todo sin necesidad de tener el chasis del coche completo.&lt;/p&gt;</description></item><item><title>Storybook</title><link>https://www.fernandoux.com/es/wiki/tools/storybook/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tools/storybook/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Definición Rápida&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Storybook es una herramienta de desarrollo de código abierto para construir, probar y documentar componentes de UI de forma aislada. Permite a los desarrolladores crear componentes en un entorno de &amp;ldquo;sandbox&amp;rdquo; fuera de la aplicación principal, lo que facilita la visualización de todos sus estados y la colaboración con los diseñadores.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-storybook"&gt;¿Qué es Storybook?&lt;/h2&gt;
&lt;p&gt;Imagina que estás construyendo un coche con piezas de LEGO. Storybook es como un taller donde puedes construir y probar cada pieza por separado antes de ensamblar el coche. Puedes construir el motor (un componente complejo) y probarlo por sí solo, o puedes construir una simple rueda (un botón) y ver todos sus colores y tamaños disponibles, todo sin necesidad de tener el chasis del coche completo.&lt;/p&gt;</description></item></channel></rss>