<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Product Design on Fernando Ruiz</title><link>https://www.fernandoux.com/tags/product-design/</link><description>Recent content in Product Design on Fernando Ruiz</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://www.fernandoux.com/tags/product-design/index.xml" rel="self" type="application/rss+xml"/><item><title>About Fernando Ruiz</title><link>https://www.fernandoux.com/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/about/</guid><description>I came to product design through architecture, content, and marketing. Three lenses on how things hold together. Here&amp;rsquo;s how that shows up in the work.</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>Affordances vs Signifiers: El Lenguaje Invisible del Diseño</title><link>https://www.fernandoux.com/es/wiki/conceptos/affordances-vs-signifiers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/affordances-vs-signifiers/</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;Affordance&lt;/strong&gt; es la relación entre un objeto y una persona: es la propiedad del objeto que permite realizar una acción (ej. un pomo permite girar). Un &lt;strong&gt;Signifier&lt;/strong&gt; es la señal visual o sonora que comunica esa capacidad (ej. la forma del pomo indica qué hay que hacer con él).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-legado-de-don-norman-en-ux"&gt;El Legado de Don Norman en UX&lt;/h2&gt;
&lt;p&gt;El concepto de Affordance fue introducido originalmente por James J. Gibson en psicología perceptual, pero fue &lt;strong&gt;Don Norman&lt;/strong&gt; quien lo adaptó al diseño en su libro fundamental &lt;em&gt;The Design of Everyday Things&lt;/em&gt;. Para Norman, un buen diseño es aquel que no necesita manuales de instrucciones: el usuario sabe qué hacer con solo mirar el objeto.&lt;/p&gt;</description></item><item><title>Affordances vs Signifiers: El Lenguaje Invisible del Diseño</title><link>https://www.fernandoux.com/es/wiki/concepts/affordances-vs-signifiers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/affordances-vs-signifiers/</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;Affordance&lt;/strong&gt; es la relación entre un objeto y una persona: es la propiedad del objeto que permite realizar una acción (ej. un pomo permite girar). Un &lt;strong&gt;Signifier&lt;/strong&gt; es la señal visual o sonora que comunica esa capacidad (ej. la forma del pomo indica qué hay que hacer con él).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-legado-de-don-norman-en-ux"&gt;El Legado de Don Norman en UX&lt;/h2&gt;
&lt;p&gt;El concepto de Affordance fue introducido originalmente por James J. Gibson en psicología perceptual, pero fue &lt;strong&gt;Don Norman&lt;/strong&gt; quien lo adaptó al diseño en su libro fundamental &lt;em&gt;The Design of Everyday Things&lt;/em&gt;. Para Norman, un buen diseño es aquel que no necesita manuales de instrucciones: el usuario sabe qué hacer con solo mirar el objeto.&lt;/p&gt;</description></item><item><title>Affordances vs. Signifiers: The Invisible Language of Design</title><link>https://www.fernandoux.com/en/wiki/concepts/affordances-vs-signifiers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/affordances-vs-signifiers/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 An &lt;strong&gt;Affordance&lt;/strong&gt; is the relationship between an object and a person: it is the property of the object that allows an action to be performed (e.g., a handle allows turning). A &lt;strong&gt;Signifier&lt;/strong&gt; is the visual or auditory signal that communicates that capability (e.g., the shape of the handle indicates what to do with it).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="don-normans-legacy-in-ux"&gt;Don Norman&amp;rsquo;s Legacy in UX&lt;/h2&gt;
&lt;p&gt;The concept of Affordance was originally introduced by James J. Gibson in perceptual psychology, but it was &lt;strong&gt;Don Norman&lt;/strong&gt; who adapted it to design in his seminal book &lt;em&gt;The Design of Everyday Things&lt;/em&gt;. For Norman, good design is one that doesn&amp;rsquo;t need instruction manuals: the user knows what to do just by looking at the object.&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>Básicos de CRDT para Diseñadores de Producto</title><link>https://www.fernandoux.com/es/wiki/conceptos/crdt-para-disenadores/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/crdt-para-disenadores/</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;CRDT&lt;/strong&gt; (Conflict-free Replicated Data Types) son estructuras de datos que permiten que múltiples usuarios realicen cambios simultáneos de forma independiente y que, al sincronizarse, todos lleguen al mismo estado final automáticamente &lt;strong&gt;sin necesidad de una autoridad central o resolución manual de conflictos&lt;/strong&gt;. Es la tecnología que hace posible la colaboración en tiempo real moderna.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-saber-qué-es-un-crdt"&gt;¿Por qué el Diseñador debe saber qué es un CRDT?&lt;/h2&gt;
&lt;p&gt;Tradicionalmente, en las aplicaciones web, el servidor era &amp;ldquo;la única fuente de verdad&amp;rdquo;. Si querías cambiar algo, le pedías permiso al servidor y esperabas su respuesta de &amp;ldquo;OK&amp;rdquo;.&lt;/p&gt;</description></item><item><title>Básicos de CRDT para Diseñadores de Producto</title><link>https://www.fernandoux.com/es/wiki/concepts/crdt-for-designers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/crdt-for-designers/</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;CRDT&lt;/strong&gt; (Conflict-free Replicated Data Types) son estructuras de datos que permiten que múltiples usuarios realicen cambios simultáneos de forma independiente y que, al sincronizarse, todos lleguen al mismo estado final automáticamente &lt;strong&gt;sin necesidad de una autoridad central o resolución manual de conflictos&lt;/strong&gt;. Es la tecnología que hace posible la colaboración en tiempo real moderna.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-diseñador-debe-saber-qué-es-un-crdt"&gt;¿Por qué el Diseñador debe saber qué es un CRDT?&lt;/h2&gt;
&lt;p&gt;Tradicionalmente, en las aplicaciones web, el servidor era &amp;ldquo;la única fuente de verdad&amp;rdquo;. Si querías cambiar algo, le pedías permiso al servidor y esperabas su respuesta de &amp;ldquo;OK&amp;rdquo;.&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>Breakpoint vs. Container Queries: Component-Based Design</title><link>https://www.fernandoux.com/en/wiki/concepts/breakpoint-vs-container-queries/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Breakpoints&lt;/strong&gt; (Media Queries) change the design based on the total width of the device screen (Viewport). &lt;strong&gt;Container Queries&lt;/strong&gt; change the design based on the space available to the component within its parent container.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-paradigm-shift-in-product-design"&gt;The Paradigm Shift in Product Design&lt;/h2&gt;
&lt;p&gt;For the last decade, we have designed &amp;ldquo;screens&amp;rdquo;: mobile, tablet, and desktop. However, in a modern design system, we design &lt;strong&gt;components that live in different places&lt;/strong&gt;. The same &amp;ldquo;Product Card&amp;rdquo; component can appear in a 3-column grid on the home page, or in a single narrow column in a sidebar.&lt;/p&gt;</description></item><item><title>Chunking en los Flujos de UI: Fragmentación Inteligente</title><link>https://www.fernandoux.com/es/wiki/techniques/ui-flow-chunking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/ui-flow-chunking/</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;Chunking&lt;/strong&gt; es la técnica de dividir información compleja o flujos de usuario extensos en &amp;ldquo;pedazos&amp;rdquo; (chunks) más pequeños y lógicamente agrupados. Esto facilita que el cerebro del usuario procese, entienda y recuerde la información sin sentirse abrumado.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-chunking-es-vital-para-la-memoria"&gt;¿Por qué el Chunking es vital para la Memoria?&lt;/h2&gt;
&lt;p&gt;Nuestra memoria de trabajo es extremadamente limitada. Según George Miller, solo podemos mantener entre 5 y 9 elementos a la vez en nuestra mente. Si una interfaz nos presenta 20 campos de formulario o un manual de 10 pasos sin pausas, nuestro cerebro se satura y la &lt;a href="https://www.fernandoux.com/concepts/cognitive-load-management/"&gt;carga cognitiva&lt;/a&gt; se dispara.&lt;/p&gt;</description></item><item><title>Chunking en los Flujos de UI: Fragmentación Inteligente</title><link>https://www.fernandoux.com/es/wiki/tecnicas/chunking-flujos-ui/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/chunking-flujos-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;
 El &lt;strong&gt;Chunking&lt;/strong&gt; es la técnica de dividir información compleja o flujos de usuario extensos en &amp;ldquo;pedazos&amp;rdquo; (chunks) más pequeños y lógicamente agrupados. Esto facilita que el cerebro del usuario procese, entienda y recuerde la información sin sentirse abrumado.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-chunking-es-vital-para-la-memoria"&gt;¿Por qué el Chunking es vital para la Memoria?&lt;/h2&gt;
&lt;p&gt;Nuestra memoria de trabajo es extremadamente limitada. Según George Miller, solo podemos mantener entre 5 y 9 elementos a la vez en nuestra mente. Si una interfaz nos presenta 20 campos de formulario o un manual de 10 pasos sin pausas, nuestro cerebro se satura y la &lt;a href="https://www.fernandoux.com/conceptos/gestion-de-carga-cognitiva/"&gt;carga cognitiva&lt;/a&gt; se dispara.&lt;/p&gt;</description></item><item><title>Chunking in UI Flows: Intelligent Fragmentation</title><link>https://www.fernandoux.com/en/wiki/techniques/ui-flow-chunking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/techniques/ui-flow-chunking/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Chunking&lt;/strong&gt; is the technique of dividing complex information or extensive user flows into smaller, logically grouped &amp;ldquo;chunks.&amp;rdquo; This makes it easier for the user&amp;rsquo;s brain to process, understand, and remember information without feeling overwhelmed.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-chunking-is-vital-for-memory"&gt;Why Chunking is vital for Memory?&lt;/h2&gt;
&lt;p&gt;Our working memory is extremely limited. According to George Miller, we can only hold between 5 and 9 items at once in our mind. If an interface presents us with 20 form fields or a 10-step manual without pauses, our brain becomes saturated, and &lt;a href="https://www.fernandoux.com/concepts/managing-cognitive-load/"&gt;cognitive load&lt;/a&gt; skyrockets.&lt;/p&gt;</description></item><item><title>Cognitive Load Management in UX</title><link>https://www.fernandoux.com/en/wiki/concepts/cognitive-load-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/cognitive-load-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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Cognitive Load&lt;/strong&gt; is the total amount of mental effort a user must invest to complete a task or process information in an interface. Good UX design seeks to minimize unnecessary load so that the user can focus on achieving their goal with as little friction as possible.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="types-of-cognitive-load-the-sweller-model"&gt;Types of Cognitive Load: The Sweller Model&lt;/h2&gt;
&lt;p&gt;In cognitive psychology, three types of mental load are distinguished. For a UX designer, understanding these concepts is key to creating intuitive interfaces:&lt;/p&gt;</description></item><item><title>Component API Design: Predictability and Flexibility</title><link>https://www.fernandoux.com/en/wiki/techniques/component-api-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Designing a &lt;strong&gt;Component API&lt;/strong&gt; consists of defining a clear entry contract (props) and behavior for elements in a design system, with the goal that they are easy to use, predictable, and maintainable for both designers and developers.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="what-makes-a-good-component-api"&gt;What Makes a Good Component API?&lt;/h2&gt;
&lt;p&gt;A component is not just a visual piece; it is a unit of functional logic. A well-designed API must clearly answer these three fundamental premises:&lt;/p&gt;</description></item><item><title>Component Prop Organization: Structure and Hierarchy</title><link>https://www.fernandoux.com/en/wiki/techniques/component-props-organization/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Prop Organization&lt;/strong&gt; consists of structuring and prioritizing a component&amp;rsquo;s properties so its use is intuitive and predictable. This reduces the cognitive load of designers in Figma and developers in code, facilitating the creation of consistent interfaces.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-does-prop-order-matter"&gt;Why does Prop order matter?&lt;/h2&gt;
&lt;p&gt;Imagine a complex component (e.g., an &lt;code&gt;Input&lt;/code&gt; with a label, icon, error message, and help text). If the configuration properties are disorganized, the design system user (the designer or developer) will waste time looking for how to change the icon color or text size.&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>Conflict Resolution in Collaboration: UI and UX</title><link>https://www.fernandoux.com/en/wiki/concepts/conflict-resolution/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/conflict-resolution/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Conflict Resolution&lt;/strong&gt; occurs when two or more users attempt to perform contradictory actions on the same object at the same time (e.g., one deletes a paragraph while the other is editing it). In collaborative product design, our goal is for the user never to see a &amp;ldquo;Sync Error&amp;rdquo; notification if we can avoid it.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-challenge-of-multi-user-applications"&gt;The Challenge of Multi-user Applications&lt;/h2&gt;
&lt;p&gt;In modern applications like Google Docs, Figma, or Notion, real-time collaboration is a basic feature. However, behind the magic lies extremely complex conflict resolution logic. If two people save different versions, who wins? Is anyone&amp;rsquo;s work lost?&lt;/p&gt;</description></item><item><title>Constraints and Auto Layout Logic in Figma</title><link>https://www.fernandoux.com/en/wiki/techniques/auto-layout-constraints/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/techniques/auto-layout-constraints/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Constraints&lt;/strong&gt; define how elements are positioned and scaled within a static container. &lt;strong&gt;Auto Layout&lt;/strong&gt; is a flexible design system that creates containers that automatically expand or contract based on their content. Together, they form the foundation of any modern responsive design in Figma.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-are-these-tools-vital"&gt;Why are these Tools Vital?&lt;/h2&gt;
&lt;p&gt;In modern digital product design, we don&amp;rsquo;t design for a single static screen. We design for an infinite number of devices and contexts. The correct use of Constraints and Auto Layout allows you to:&lt;/p&gt;</description></item><item><title>Control de Explosión de Variantes (Wrangling Systems)</title><link>https://www.fernandoux.com/es/wiki/techniques/variant-explosion-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/variant-explosion-control/</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;Control de la Explosión de Variantes&lt;/strong&gt; es el proceso de optimizar y simplificar la arquitectura de un componente para evitar un número excesivo de versiones manuales, utilizando herramientas como &lt;strong&gt;Component Properties&lt;/strong&gt; y &lt;strong&gt;Booleanos&lt;/strong&gt; para mantener el sistema ligero y fácil de mantener.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-problema-el-laberinto-de-variantes"&gt;El Problema: El Laberinto de Variantes&lt;/h2&gt;
&lt;p&gt;Antes de las mejoras en herramientas como Figma, crear un componente simple (como un botón) con &lt;code&gt;3 tamaños&lt;/code&gt;, &lt;code&gt;4 variantes de color&lt;/code&gt;, &lt;code&gt;2 estados de icono&lt;/code&gt; y &lt;code&gt;5 estados de interacción&lt;/code&gt; (default, hover, active, focus y disabled) requería la creación manual de &lt;strong&gt;120 variantes individuales&lt;/strong&gt; (3 x 4 x 2 x 5).&lt;/p&gt;</description></item><item><title>Control de Explosión de Variantes (Wrangling Systems)</title><link>https://www.fernandoux.com/es/wiki/tecnicas/control-explosion-variantes/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/control-explosion-variantes/</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;Control de la Explosión de Variantes&lt;/strong&gt; es el proceso de optimizar y simplificar la arquitectura de un componente para evitar un número excesivo de versiones manuales, utilizando herramientas como &lt;strong&gt;Component Properties&lt;/strong&gt; y &lt;strong&gt;Booleanos&lt;/strong&gt; para mantener el sistema ligero y fácil de mantener.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-problema-el-laberinto-de-variantes"&gt;El Problema: El Laberinto de Variantes&lt;/h2&gt;
&lt;p&gt;Antes de las mejoras en herramientas como Figma, crear un componente simple (como un botón) con &lt;code&gt;3 tamaños&lt;/code&gt;, &lt;code&gt;4 variantes de color&lt;/code&gt;, &lt;code&gt;2 estados de icono&lt;/code&gt; y &lt;code&gt;5 estados de interacción&lt;/code&gt; (default, hover, active, focus y disabled) requería la creación manual de &lt;strong&gt;120 variantes individuales&lt;/strong&gt; (3 x 4 x 2 x 5).&lt;/p&gt;</description></item><item><title>CRDT Basics for Product Designers</title><link>https://www.fernandoux.com/en/wiki/concepts/crdt-for-designers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/crdt-for-designers/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;CRDTs&lt;/strong&gt; (Conflict-free Replicated Data Types) are data structures that allow multiple users to make simultaneous, independent changes that, when synchronized, automatically reach the same final state &lt;strong&gt;without the need for a central authority or manual conflict resolution&lt;/strong&gt;. It is the technology that makes modern real-time collaboration possible.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-designer-should-know-what-a-crdt-is"&gt;Why the Designer should know what a CRDT is?&lt;/h2&gt;
&lt;p&gt;Traditionally, in web applications, the server was &amp;ldquo;the single source of truth.&amp;rdquo; If you wanted to change something, you asked the server for permission and waited for its &amp;ldquo;OK&amp;rdquo; response.&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>Designing for Perceived Performance: Faster Than Light</title><link>https://www.fernandoux.com/en/wiki/concepts/perceived-performance-design/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Perceived Performance&lt;/strong&gt; is the time a user feels it takes for a system to respond, regardless of the actual speed (milliseconds) of the connection or processor. In product design, &lt;strong&gt;perception is reality.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-does-perceived-performance-matter"&gt;Why does Perceived Performance matter?&lt;/h2&gt;
&lt;p&gt;We can have the best-optimized application in the world, but if the user stares at a blank screen for 2 seconds, they will think the app is slow.&lt;/p&gt;
&lt;p&gt;On the contrary, an app that takes the same 2 seconds but shows a &lt;a href="https://www.fernandoux.com/concepts/skeleton-vs-optimistic-ui/"&gt;Skeleton Screen&lt;/a&gt;, a loading bar with a smooth animation, or interesting context messages will be perceived as much faster and more pleasant.&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>Error Prevention vs. Recovery: A Forgiving Interface</title><link>https://www.fernandoux.com/en/wiki/concepts/prevention-vs-recovery-errors/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/prevention-vs-recovery-errors/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Error Prevention&lt;/strong&gt; seeks to design the system so that the user cannot make mistakes. &lt;strong&gt;Error Recovery&lt;/strong&gt; designs the way out when failure has already occurred, helping the user return to the right path without frustration.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-forgiving-interface-paradigm"&gt;The Forgiving Interface Paradigm&lt;/h2&gt;
&lt;p&gt;Human beings are fallible by nature: we get distracted, we make typing mistakes, or we don&amp;rsquo;t fully understand instructions. Mature UX design doesn&amp;rsquo;t blame the user for their errors but assumes they will happen and designs an ecosystem that mitigates or solves them gracefully. This concept is based on two of Jakob Nielsen&amp;rsquo;s 10 usability heuristics: #5 (Error prevention) and #9 (Help users recognize, diagnose, and recover from errors).&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>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>Fitts's Law: Reach and Ergonomics in UI</title><link>https://www.fernandoux.com/en/wiki/concepts/fittss-law/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/fittss-law/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Fitts&amp;rsquo;s Law&lt;/strong&gt; states that the time required to reach a target depends on the distance to the target and the size of the target itself. In short for UX: &lt;strong&gt;Make important actions large and close.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="what-is-fittss-law-and-why-should-you-care"&gt;What is Fitts&amp;rsquo;s Law (and why should you care)?&lt;/h2&gt;
&lt;p&gt;Paul Fitts, an American psychologist, formulated this law in 1954 to measure human movement. In modern interface design, Fitts&amp;rsquo;s Law is the foundation of ergonomics: if a button is too small or too far from where the cursor (or thumb) is located, the user will take longer to interact and will make more errors due to lack of precision.&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>Form Validation Timing: Reward and Rules</title><link>https://www.fernandoux.com/en/wiki/techniques/form-validation-timing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/techniques/form-validation-timing/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Validation Timing&lt;/strong&gt; decides exactly when we communicate to the user whether the information entered is correct or incorrect. Choosing the right moment drastically reduces flow interruption, user anxiety, and form abandonment rates.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-validation-timing-is-everything"&gt;Why Validation Timing is Everything&lt;/h2&gt;
&lt;p&gt;Filling out forms is a taxing task for the human brain. If you interrupt the user at the wrong time, you break their mental flow and create a sense of constant surveillance. Validation should not be a judgment, but a guide that helps finish the task as quickly as possible.&lt;/p&gt;</description></item><item><title>Gestión de Carga Cognitiva en UX</title><link>https://www.fernandoux.com/es/wiki/conceptos/gestion-de-carga-cognitiva/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/gestion-de-carga-cognitiva/</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;Carga Cognitiva&lt;/strong&gt; es la cantidad total de esfuerzo mental que un usuario debe invertir para completar una tarea o procesar información en una interfaz. Un buen diseño de UX busca minimizar la carga innecesaria para que el usuario pueda concentrarse en lograr su objetivo con el menor roce posible.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="tipos-de-carga-cognitiva-el-modelo-de-sweller"&gt;Tipos de Carga Cognitiva: El Modelo de Sweller&lt;/h2&gt;
&lt;p&gt;En psicología cognitiva, se distinguen tres tipos de carga mental. Para un diseñador de UX, entender estos conceptos es la clave para crear interfaces intuitivas:&lt;/p&gt;</description></item><item><title>Gestión de Carga Cognitiva en UX</title><link>https://www.fernandoux.com/es/wiki/concepts/cognitive-load-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/cognitive-load-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;Carga Cognitiva&lt;/strong&gt; es la cantidad total de esfuerzo mental que un usuario debe invertir para completar una tarea o procesar información en una interfaz. Un buen diseño de UX busca minimizar la carga innecesaria para que el usuario pueda concentrarse en lograr su objetivo con el menor roce posible.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="tipos-de-carga-cognitiva-el-modelo-de-sweller"&gt;Tipos de Carga Cognitiva: El Modelo de Sweller&lt;/h2&gt;
&lt;p&gt;En psicología cognitiva, se distinguen tres tipos de carga mental. Para un diseñador de UX, entender estos conceptos es la clave para crear interfaces intuitivas:&lt;/p&gt;</description></item><item><title>Haptic Feedback Principles: Feeling the Interface</title><link>https://www.fernandoux.com/en/wiki/concepts/haptic-feedback-principles/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/haptic-feedback-principles/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Haptic Feedback&lt;/strong&gt; is the physical response (vibration or tactile impact) that a mobile device or wearable emits in response to a user action. It is the third communication channel, along with sight and hearing, which allows the user to &amp;ldquo;feel&amp;rdquo; that something has happened without needing to look at the screen.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-haptics-are-critical-for-ux"&gt;Why Haptics are Critical for UX?&lt;/h2&gt;
&lt;p&gt;We live in a world full of visual distractions. Human beings have evolved to feel textures and physical responses when manipulating objects. On a smooth glass screen, we lose that sense.&lt;/p&gt;</description></item><item><title>Hick's Law: Decision and Response Time</title><link>https://www.fernandoux.com/en/wiki/concepts/hicks-law/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/hicks-law/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Hick&amp;rsquo;s Law&lt;/strong&gt; states that the time it takes for a person to make a decision increases logarithmically as the number and complexity of choices increase. In UX, this translates into a golden rule: &lt;strong&gt;Less is faster.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="what-is-hicks-law-and-why-should-you-care"&gt;What is Hick&amp;rsquo;s Law (and why should you care)?&lt;/h2&gt;
&lt;p&gt;William Edmund Hick and Ray Hyman discovered in the early 1950s that adding extra options not only slows down the user linearly but can actually paralyze them or make them feel overwhelmed (a phenomenon known as &lt;strong&gt;&amp;ldquo;Analysis Paralysis&amp;rdquo;&lt;/strong&gt;).&lt;/p&gt;</description></item><item><title>Input Masking Dangers: Usability vs. Format</title><link>https://www.fernandoux.com/en/wiki/techniques/input-masking-dangers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/techniques/input-masking-dangers/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Input Masking&lt;/strong&gt; is the technique of visually forcing a data format while the user types (e.g., automatically adding hyphens in a date &lt;code&gt;DD / MM / YYYY&lt;/code&gt;). Although it seems like a visual aid, if implemented incorrectly, it is one of the greatest sources of error, frustration, and form abandonment.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-input-mask-dilemma"&gt;The Input Mask Dilemma&lt;/h2&gt;
&lt;p&gt;Imagine you are typing your phone number and the field decides to put parentheses and spaces for you. If you make a mistake in one number and press Backspace, the mask deletes not only the number but also the automatic space, and then re-inserts it for you. This infinite loop is the definition of a poor user experience.&lt;/p&gt;</description></item><item><title>Intrinsic Layout Decisions: Content vs. Boxes</title><link>https://www.fernandoux.com/en/wiki/techniques/intrinsic-layout-decisions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Intrinsic Layout Decisions&lt;/strong&gt; are design rules that define how interface elements are positioned and scaled based on the needs of their own content (such as text width or image size) rather than being forced by an external grid (Layout Grid).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-intrinsic-layout-is-the-best-option-for-dynamic-products"&gt;Why Intrinsic Layout is the best option for dynamic products?&lt;/h2&gt;
&lt;p&gt;Historically, we designed websites with 12-column grids. It&amp;rsquo;s a safe and predictable system, but fragile. If a username is too long, the grid design breaks or text is cut off.&lt;/p&gt;</description></item><item><title>Intrinsic Sizing Behavior in UI</title><link>https://www.fernandoux.com/en/wiki/concepts/intrinsic-sizing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Intrinsic Sizing&lt;/strong&gt; is a design behavior where an element&amp;rsquo;s dimensions (width or height) are determined by its own content (letters, images, icons) rather than being forced by an external container with fixed measurements.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="what-is-intrinsic-sizing"&gt;What is Intrinsic Sizing?&lt;/h2&gt;
&lt;p&gt;Imagine you want to put shirts in a suitcase.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Extrinsic Sizing:&lt;/strong&gt; The suitcase has a fixed size of 50x40 cm. No matter if you put in 1 shirt or 20, the suitcase measures the same.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Intrinsic Sizing:&lt;/strong&gt; The suitcase is made of elastic fabric and adjusts exactly to the volume of the shirts you put in. If you put in one shirt, it&amp;rsquo;s small; if you put in 20, it stretches.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In UI, this means a button doesn&amp;rsquo;t measure &amp;ldquo;200px,&amp;rdquo; but rather &lt;code&gt;Text Width + Lateral Paddings&lt;/code&gt;. If the text changes from &amp;ldquo;OK&amp;rdquo; to &amp;ldquo;Unsubscribe,&amp;rdquo; the button widens automatically.&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>La Ley de Fitts: Alcance y Ergonomía en UI</title><link>https://www.fernandoux.com/es/wiki/conceptos/ley-de-fitts/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/ley-de-fitts/</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;Ley de Fitts&lt;/strong&gt; establece que el tiempo necesario para alcanzar un objetivo depende de la distancia al objetivo y del tamaño del propio objetivo. En resumen para UX: &lt;strong&gt;Haz que las acciones importantes sean grandes y estén cerca.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-la-ley-de-fitts-y-por-qué-debería-importarte"&gt;¿Qué es la Ley de Fitts (y por qué debería importarte)?&lt;/h2&gt;
&lt;p&gt;Paul Fitts, un psicólogo estadounidense, formuló esta ley en 1954 para medir el movimiento humano. En el diseño de interfaces moderno, la Ley de Fitts es la base de la ergonomía: si un botón es demasiado pequeño o está demasiado lejos de donde se encuentra el cursor (o el pulgar), el usuario tardará más tiempo en interactuar y cometerá más errores por falta de precisión.&lt;/p&gt;</description></item><item><title>La Ley de Fitts: Alcance y Ergonomía en UI</title><link>https://www.fernandoux.com/es/wiki/concepts/fittss-law/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/fittss-law/</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;Ley de Fitts&lt;/strong&gt; establece que el tiempo necesario para alcanzar un objetivo depende de la distancia al objetivo y del tamaño del propio objetivo. En resumen para UX: &lt;strong&gt;Haz que las acciones importantes sean grandes y estén cerca.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-la-ley-de-fitts-y-por-qué-debería-importarte"&gt;¿Qué es la Ley de Fitts (y por qué debería importarte)?&lt;/h2&gt;
&lt;p&gt;Paul Fitts, un psicólogo estadounidense, formuló esta ley en 1954 para medir el movimiento humano. En el diseño de interfaces moderno, la Ley de Fitts es la base de la ergonomía: si un botón es demasiado pequeño o está demasiado lejos de donde se encuentra el cursor (o el pulgar), el usuario tardará más tiempo en interactuar y cometerá más errores por falta de precisión.&lt;/p&gt;</description></item><item><title>La Ley de Hick: Decisión y Tiempo de Respuesta</title><link>https://www.fernandoux.com/es/wiki/conceptos/ley-de-hick/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/ley-de-hick/</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;Ley de Hick&lt;/strong&gt; establece que el tiempo que tarda una persona en tomar una decisión aumenta logarítmicamente a medida que aumenta el número y la complejidad de las opciones disponibles. En UX, esto se traduce en una regla de oro: &lt;strong&gt;Menos es más rápido.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-la-ley-de-hick-y-por-qué-debería-importarte"&gt;¿Qué es la Ley de Hick (y por qué debería importarte)?&lt;/h2&gt;
&lt;p&gt;William Edmund Hick y Ray Hyman descubrieron a principios de la década de 1950 que añadir opciones adicionales no solo ralentiza al usuario de forma lineal, sino que puede llegar a paralizarlo o hacer que se sienta abrumado (fenómeno conocido como &lt;strong&gt;&amp;ldquo;Parálisis por Análisis&amp;rdquo;&lt;/strong&gt;).&lt;/p&gt;</description></item><item><title>La Ley de Hick: Decisión y Tiempo de Respuesta</title><link>https://www.fernandoux.com/es/wiki/concepts/hicks-law/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/hicks-law/</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;Ley de Hick&lt;/strong&gt; establece que el tiempo que tarda una persona en tomar una decisión aumenta logarítmicamente a medida que aumenta el número y la complejidad de las opciones disponibles. En UX, esto se traduce en una regla de oro: &lt;strong&gt;Menos es más rápido.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="qué-es-la-ley-de-hick-y-por-qué-debería-importarte"&gt;¿Qué es la Ley de Hick (y por qué debería importarte)?&lt;/h2&gt;
&lt;p&gt;William Edmund Hick y Ray Hyman descubrieron a principios de la década de 1950 que añadir opciones adicionales no solo ralentiza al usuario de forma lineal, sino que puede llegar a paralizarlo o hacer que se sienta abrumado (fenómeno conocido como &lt;strong&gt;&amp;ldquo;Parálisis por Análisis&amp;rdquo;&lt;/strong&gt;).&lt;/p&gt;</description></item><item><title>Latency Budgets in UX: Response Times</title><link>https://www.fernandoux.com/en/wiki/strategy/interaction-latency-budgets/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 A &lt;strong&gt;Latency Budget&lt;/strong&gt; is the maximum time allowed (in milliseconds) for a user action to produce a visible response in the interface. It is not a technical metric; it is a design commitment to ensure experience fluidity.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-designer-should-establish-latency-budgets"&gt;Why the Designer should establish Latency Budgets?&lt;/h2&gt;
&lt;p&gt;Often, designers create complex flows and heavy interactions without considering the technical cost. If an opening animation of a menu takes 500ms and the server another 1000ms to return data, the user will feel the application is a heavy boat.&lt;/p&gt;</description></item><item><title>Layout Decisions: Grid vs. Intrinsic</title><link>https://www.fernandoux.com/en/wiki/techniques/layout-grid-vs-intrinsic/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Layout Grids&lt;/strong&gt; are predefined grids that force elements to follow a rigid structure of specific columns and distances. &lt;strong&gt;Intrinsic Layout&lt;/strong&gt; is an approach where the size and position of elements depend on their content and internal relationship, without relying on an external grid.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-modern-layout-dilemma"&gt;The Modern Layout Dilemma&lt;/h2&gt;
&lt;p&gt;In the web of the early 2010s, everything was based on 12-column grids. Today, thanks to the capabilities of Figma (Auto Layout) and modern browsers (Flexbox/CSS Grid), design is becoming more fluid and less dependent on these fixed structures. The key question is: When should we force the grid and when should we let content rule the space?&lt;/p&gt;</description></item><item><title>Loading States: The Indulgent Wait in UX</title><link>https://www.fernandoux.com/en/wiki/techniques/loading-states/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 A &lt;strong&gt;Loading State&lt;/strong&gt; is the visual or audible information shown to the user while the system processes an action (e.g., loading data from a server, uploading a file, or performing a search). Good loading design eliminates the fear of a &amp;ldquo;frozen system.&amp;rdquo;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-loading-states-are-critical"&gt;Why Loading States are Critical&lt;/h2&gt;
&lt;p&gt;The moment a user clicks a button and waits for a response is the time of greatest vulnerability and potential frustration. Without a clear loading state, the user doesn&amp;rsquo;t know if:&lt;/p&gt;</description></item><item><title>Lógica de Constraints y Auto Layout en Figma</title><link>https://www.fernandoux.com/es/wiki/techniques/auto-layout-constraints/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/auto-layout-constraints/</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;Constraints&lt;/strong&gt; definen cómo se posicionan y escalan los elementos dentro de un contenedor estático. El &lt;strong&gt;Auto Layout&lt;/strong&gt; es un sistema de diseño flexible que crea contenedores que se expanden o contraen automáticamente según su contenido. Juntos, forman la base de cualquier diseño responsivo moderno en Figma.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-son-vitales-estas-herramientas"&gt;¿Por qué son Vitales estas Herramientas?&lt;/h2&gt;
&lt;p&gt;En el diseño de productos digitales moderno, no diseñamos para una única pantalla estática. Diseñamos para una infinidad de dispositivos y contextos. El uso correcto de Constraints y Auto Layout te permite:&lt;/p&gt;</description></item><item><title>Lógica de Constraints y Auto Layout en Figma</title><link>https://www.fernandoux.com/es/wiki/tecnicas/constraints-auto-layout/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/constraints-auto-layout/</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;Constraints&lt;/strong&gt; definen cómo se posicionan y escalan los elementos dentro de un contenedor estático. El &lt;strong&gt;Auto Layout&lt;/strong&gt; es un sistema de diseño flexible que crea contenedores que se expanden o contraen automáticamente según su contenido. Juntos, forman la base de cualquier diseño responsivo moderno en Figma.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-son-vitales-estas-herramientas"&gt;¿Por qué son Vitales estas Herramientas?&lt;/h2&gt;
&lt;p&gt;En el diseño de productos digitales moderno, no diseñamos para una única pantalla estática. Diseñamos para una infinidad de dispositivos y contextos. El uso correcto de Constraints y Auto Layout te permite:&lt;/p&gt;</description></item><item><title>Mental Models of Undo and Redo: Time in the Interface</title><link>https://www.fernandoux.com/en/wiki/concepts/mental-models-undo-redo/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/mental-models-undo-redo/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Mental Models of Undo and Redo&lt;/strong&gt; are how the user understands that they can go back or forward in the history of their actions. Correct Undo design reduces user anxiety, allowing them to experiment freely with the interface without fear of making irreversible errors.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-power-of-indulgence-forgiving-ui"&gt;The Power of Indulgence (Forgiving UI)&lt;/h2&gt;
&lt;p&gt;The &amp;ldquo;Undo&amp;rdquo; button is the most powerful psychological safety tool in interface design. When a user knows they have a &amp;ldquo;safety net&amp;rdquo; under their feet, their cognitive load decreases and their willingness to explore new features increases dramatically. Without Undo, the user becomes conservative and fearful with every click.&lt;/p&gt;</description></item><item><title>Modelado de Presencia en Tiempo Real: UX Colaborativo</title><link>https://www.fernandoux.com/es/wiki/conceptos/modelado-de-presencia/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/modelado-de-presencia/</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;Modelado de Presencia&lt;/strong&gt; es el conjunto de indicadores visuales y funcionales que comunican a un usuario quién más está con él en el mismo espacio digital (ej. una página de Notion o un archivo de Figma) y qué están haciendo exactamente en ese preciso momento.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="la-magia-de-no-estar-solo-el-sentimiento-de-presencia"&gt;La Magia de No Estar Solo: El Sentimiento de Presencia&lt;/h2&gt;
&lt;p&gt;Hace unos años, las aplicaciones eran solitarias: trabajabas, guardabas y cerrabas. Hoy, las aplicaciones de producto son &lt;strong&gt;multijugador&lt;/strong&gt;. El modelado de presencia no es solo un adorno estético; es una herramienta crítica de comunicación que evita que los usuarios cometan errores (como editar el mismo objeto al mismo tiempo) y fomenta la colaboración fluida.&lt;/p&gt;</description></item><item><title>Modelado de Presencia en Tiempo Real: UX Colaborativo</title><link>https://www.fernandoux.com/es/wiki/concepts/presence-modeling/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/presence-modeling/</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;Modelado de Presencia&lt;/strong&gt; es el conjunto de indicadores visuales y funcionales que comunican a un usuario quién más está con él en el mismo espacio digital (ej. una página de Notion o un archivo de Figma) y qué están haciendo exactamente en ese preciso momento.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="la-magia-de-no-estar-solo-el-sentimiento-de-presencia"&gt;La Magia de No Estar Solo: El Sentimiento de Presencia&lt;/h2&gt;
&lt;p&gt;Hace unos años, las aplicaciones eran solitarias: trabajabas, guardabas y cerrabas. Hoy, las aplicaciones de producto son &lt;strong&gt;multijugador&lt;/strong&gt;. El modelado de presencia no es solo un adorno estético; es una herramienta crítica de comunicación que evita que los usuarios cometan errores (como editar el mismo objeto al mismo tiempo) y fomenta la colaboración fluida.&lt;/p&gt;</description></item><item><title>Modelos Mentales de Undo y Redo: El Tiempo en la Interfaz</title><link>https://www.fernandoux.com/es/wiki/conceptos/mental-models-undo-redo/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/mental-models-undo-redo/</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;Modelos Mentales de Undo y Redo&lt;/strong&gt; son la forma en que el usuario entiende que puede retroceder o avanzar en el historial de sus acciones. Un diseño correcto de Undo reduce la ansiedad del usuario, permitiéndole experimentar libremente con la interfaz sin miedo a cometer errores irreversibles.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-poder-de-la-indulgencia-forgiving-ui"&gt;El Poder de la Indulgencia (Forgiving UI)&lt;/h2&gt;
&lt;p&gt;El botón de &amp;ldquo;Deshacer&amp;rdquo; es la herramienta de seguridad psicológica más potente en el diseño de interfaces. Cuando un usuario sabe que tiene una &amp;ldquo;red de seguridad&amp;rdquo; bajo sus pies, su carga cognitiva disminuye y su disposición a explorar nuevas funcionalidades aumenta drásticamente. Sin Undo, el usuario se vuelve conservador y temeroso ante cada clic.&lt;/p&gt;</description></item><item><title>Modelos Mentales de Undo y Redo: El Tiempo en la Interfaz</title><link>https://www.fernandoux.com/es/wiki/concepts/mental-models-undo-redo/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/mental-models-undo-redo/</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;Modelos Mentales de Undo y Redo&lt;/strong&gt; son la forma en que el usuario entiende que puede retroceder o avanzar en el historial de sus acciones. Un diseño correcto de Undo reduce la ansiedad del usuario, permitiéndole experimentar libremente con la interfaz sin miedo a cometer errores irreversibles.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-poder-de-la-indulgencia-forgiving-ui"&gt;El Poder de la Indulgencia (Forgiving UI)&lt;/h2&gt;
&lt;p&gt;El botón de &amp;ldquo;Deshacer&amp;rdquo; es la herramienta de seguridad psicológica más potente en el diseño de interfaces. Cuando un usuario sabe que tiene una &amp;ldquo;red de seguridad&amp;rdquo; bajo sus pies, su carga cognitiva disminuye y su disposición a explorar nuevas funcionalidades aumenta drásticamente. Sin Undo, el usuario se vuelve conservador y temeroso ante cada clic.&lt;/p&gt;</description></item><item><title>Offline-First Flows: Designing for Disconnection</title><link>https://www.fernandoux.com/en/wiki/strategy/offline-first-flows/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 The &lt;strong&gt;Offline-First&lt;/strong&gt; strategy is a design and development approach that assumes the user will have an intermittent or null internet connection at some point. Instead of treating &amp;ldquo;Offline&amp;rdquo; as an error state, it is treated as a fundamental feature of the product. The goal is for the application to always keep working.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-challenge-of-modern-product-applications"&gt;The Challenge of Modern Product Applications&lt;/h2&gt;
&lt;p&gt;Most traditional web apps (like Jira or Gmail) usually break or show a Chrome dinosaur when Wifi is cut. In advanced digital product design, such as Notion, Figma, or Linear, this is no longer acceptable.&lt;/p&gt;</description></item><item><title>Optimistic Updates and Rollback UX</title><link>https://www.fernandoux.com/en/wiki/techniques/optimistic-updates-rollback/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Optimistic Updates&lt;/strong&gt; are an interaction design technique where the user interface updates immediately after an action (such as giving a &amp;ldquo;Like&amp;rdquo; or sending a message), assuming the server will process the request successfully, without waiting for its actual response. &lt;strong&gt;Rollback&lt;/strong&gt; is the process of reversing that visual change if the request ends up failing.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-secret-of-speed-in-modern-apps"&gt;The Secret of Speed in Modern Apps&lt;/h2&gt;
&lt;p&gt;Imagine you press the &amp;ldquo;Like&amp;rdquo; button on Instagram. If the heart icon didn&amp;rsquo;t turn red until the server returned an &amp;ldquo;OK,&amp;rdquo; the application would feel slow and heavy.&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>Peligros del Input Masking: Usabilidad vs Formato</title><link>https://www.fernandoux.com/es/wiki/techniques/input-masking-dangers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/input-masking-dangers/</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;Input Masking&lt;/strong&gt; es la técnica de forzar visualmente un formato de datos mientras el usuario escribe (ej. añadir automáticamente los guiones en una fecha &lt;code&gt;DD / MM / YYYY&lt;/code&gt;). Aunque parece una ayuda visual, si se implementa incorrectamente, es una de las mayores fuentes de error, frustración y abandono de formularios.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-dilema-de-la-máscara-de-entrada"&gt;El Dilema de la Máscara de Entrada&lt;/h2&gt;
&lt;p&gt;Imagina que estás escribiendo tu número de teléfono y el campo decide poner paréntesis y espacios por ti. Si te equivocas en un número y pulsas retroceso (Backspace), la máscara borra no solo el número, sino también el espacio automático, y entonces te lo reinserta solo. Este bucle infinito es la definición de una mala experiencia de usuario.&lt;/p&gt;</description></item><item><title>Peligros del Input Masking: Usabilidad vs Formato</title><link>https://www.fernandoux.com/es/wiki/tecnicas/peligros-input-masking/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/peligros-input-masking/</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;Input Masking&lt;/strong&gt; es la técnica de forzar visualmente un formato de datos mientras el usuario escribe (ej. añadir automáticamente los guiones en una fecha &lt;code&gt;DD / MM / YYYY&lt;/code&gt;). Aunque parece una ayuda visual, si se implementa incorrectamente, es una de las mayores fuentes de error, frustración y abandono de formularios.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-dilema-de-la-máscara-de-entrada"&gt;El Dilema de la Máscara de Entrada&lt;/h2&gt;
&lt;p&gt;Imagina que estás escribiendo tu número de teléfono y el campo decide poner paréntesis y espacios por ti. Si te equivocas en un número y pulsas retroceso (Backspace), la máscara borra no solo el número, sino también el espacio automático, y entonces te lo reinserta solo. Este bucle infinito es la definición de una mala experiencia de usuario.&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>Prevención vs Recuperación de Errores: Una Interfaz Indulgente</title><link>https://www.fernandoux.com/es/wiki/conceptos/prevencion-vs-recuperacion-errores/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/prevencion-vs-recuperacion-errores/</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;Prevención de Errores&lt;/strong&gt; busca diseñar el sistema para que el usuario no pueda cometer fallos. La &lt;strong&gt;Recuperación de Errores&lt;/strong&gt; diseña la salida cuando el fallo ya ha ocurrido, ayudando al usuario a volver al camino correcto sin frustración.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-paradigma-de-la-interfaz-indulgente-forgiving-interface"&gt;El Paradigma de la Interfaz Indulgente (Forgiving Interface)&lt;/h2&gt;
&lt;p&gt;Los seres humanos somos falibles por naturaleza: nos distraemos, nos equivocamos al teclear o no entendemos bien las instrucciones. Un diseño de UX maduro no culpa al usuario por sus errores, sino que asume que ocurrirán y diseña un ecosistema que los mitigue o los solucione con elegancia. Este concepto se basa en dos de las 10 heurísticas de usabilidad de Jakob Nielsen: la #5 (Prevención de errores) y la #9 (Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores).&lt;/p&gt;</description></item><item><title>Prevención vs Recuperación de Errores: Una Interfaz Indulgente</title><link>https://www.fernandoux.com/es/wiki/concepts/prevention-vs-recovery-errors/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/prevention-vs-recovery-errors/</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;Prevención de Errores&lt;/strong&gt; busca diseñar el sistema para que el usuario no pueda cometer fallos. La &lt;strong&gt;Recuperación de Errores&lt;/strong&gt; diseña la salida cuando el fallo ya ha ocurrido, ayudando al usuario a volver al camino correcto sin frustración.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-paradigma-de-la-interfaz-indulgente-forgiving-interface"&gt;El Paradigma de la Interfaz Indulgente (Forgiving Interface)&lt;/h2&gt;
&lt;p&gt;Los seres humanos somos falibles por naturaleza: nos distraemos, nos equivocamos al teclear o no entendemos bien las instrucciones. Un diseño de UX maduro no culpa al usuario por sus errores, sino que asume que ocurrirán y diseña un ecosistema que los mitigue o los solucione con elegancia. Este concepto se basa en dos de las 10 heurísticas de usabilidad de Jakob Nielsen: la #5 (Prevención de errores) y la #9 (Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores).&lt;/p&gt;</description></item><item><title>Principios de Feedback Háptico: Sentir la Interfaz</title><link>https://www.fernandoux.com/es/wiki/conceptos/principios-feedback-haptico/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/principios-feedback-haptico/</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;Feedback Háptico&lt;/strong&gt; es la respuesta física (vibración o impacto táctil) que un dispositivo móvil o un wearable emite ante una acción del usuario. Es el tercer canal de comunicación, junto a la vista y el oído, que permite que el usuario &amp;ldquo;sienta&amp;rdquo; que algo ha ocurrido sin necesidad de mirar la pantalla.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-háptico-es-crítico-para-la-ux"&gt;¿Por qué el Háptico es Crítico para la UX?&lt;/h2&gt;
&lt;p&gt;Vivimos en un mundo lleno de distracciones visuales. Los seres humanos hemos evolucionado para sentir texturas y respuestas físicas cuando manipulamos objetos. En una pantalla de cristal lisa, perdemos ese sentido.&lt;/p&gt;</description></item><item><title>Principios de Feedback Háptico: Sentir la Interfaz</title><link>https://www.fernandoux.com/es/wiki/concepts/haptic-feedback-principles/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/haptic-feedback-principles/</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;Feedback Háptico&lt;/strong&gt; es la respuesta física (vibración o impacto táctil) que un dispositivo móvil o un wearable emite ante una acción del usuario. Es el tercer canal de comunicación, junto a la vista y el oído, que permite que el usuario &amp;ldquo;sienta&amp;rdquo; que algo ha ocurrido sin necesidad de mirar la pantalla.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-háptico-es-crítico-para-la-ux"&gt;¿Por qué el Háptico es Crítico para la UX?&lt;/h2&gt;
&lt;p&gt;Vivimos en un mundo lleno de distracciones visuales. Los seres humanos hemos evolucionado para sentir texturas y respuestas físicas cuando manipulamos objetos. En una pantalla de cristal lisa, perdemos ese sentido.&lt;/p&gt;</description></item><item><title>Real-Time Presence Modeling: Collaborative UX</title><link>https://www.fernandoux.com/en/wiki/concepts/presence-modeling/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/presence-modeling/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Presence Modeling&lt;/strong&gt; is the set of visual and functional indicators that communicate to a user who else is with them in the same digital space (e.g., a Notion page or a Figma file) and exactly what they are doing at that precise moment.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-magic-of-not-being-alone-the-feeling-of-presence"&gt;The Magic of Not Being Alone: The Feeling of Presence&lt;/h2&gt;
&lt;p&gt;A few years ago, applications were lonely: you worked, saved, and closed. Today, product applications are &lt;strong&gt;multiplayer&lt;/strong&gt;. Presence modeling is not just an aesthetic ornament; it is a critical communication tool that prevents users from making mistakes (like editing the same object at the same time) and fosters fluid collaboration.&lt;/p&gt;</description></item><item><title>Resolución de Conflictos en Colaboración: UI y UX</title><link>https://www.fernandoux.com/es/wiki/conceptos/resolucion-de-conflictos/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/conceptos/resolucion-de-conflictos/</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;Resolución de Conflictos&lt;/strong&gt; ocurre cuando dos o más usuarios intentan realizar acciones contradictorias sobre el mismo objeto al mismo tiempo (ej. uno borra un párrafo mientras el otro lo está editando). En el diseño de producto colaborativo, nuestro objetivo es que el usuario nunca vea una notificación de &amp;ldquo;Error de Sincronización&amp;rdquo; si podemos evitarlo.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-reto-de-las-aplicaciones-multiusuario"&gt;El Reto de las Aplicaciones Multiusuario&lt;/h2&gt;
&lt;p&gt;En aplicaciones modernas como Google Docs, Figma o Notion, la colaboración en tiempo real es una funcionalidad básica. Sin embargo, detrás de la magia hay una lógica de resolución de conflictos extremadamente compleja. Si dos personas guardan versiones diferentes, ¿quién gana? ¿Se pierde el trabajo de alguien?&lt;/p&gt;</description></item><item><title>Resolución de Conflictos en Colaboración: UI y UX</title><link>https://www.fernandoux.com/es/wiki/concepts/conflict-resolution/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/concepts/conflict-resolution/</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;Resolución de Conflictos&lt;/strong&gt; ocurre cuando dos o más usuarios intentan realizar acciones contradictorias sobre el mismo objeto al mismo tiempo (ej. uno borra un párrafo mientras el otro lo está editando). En el diseño de producto colaborativo, nuestro objetivo es que el usuario nunca vea una notificación de &amp;ldquo;Error de Sincronización&amp;rdquo; si podemos evitarlo.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-reto-de-las-aplicaciones-multiusuario"&gt;El Reto de las Aplicaciones Multiusuario&lt;/h2&gt;
&lt;p&gt;En aplicaciones modernas como Google Docs, Figma o Notion, la colaboración en tiempo real es una funcionalidad básica. Sin embargo, detrás de la magia hay una lógica de resolución de conflictos extremadamente compleja. Si dos personas guardan versiones diferentes, ¿quién gana? ¿Se pierde el trabajo de alguien?&lt;/p&gt;</description></item><item><title>Responsive Scaling Strategies: Liquid UI</title><link>https://www.fernandoux.com/en/wiki/techniques/responsive-scaling-strategies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Responsive Scaling Strategies&lt;/strong&gt; define how interface elements behave when available space changes. It&amp;rsquo;s not just about resizing boxes, but deciding which elements grow, which stack, which disappear, and which maintain their original size to ensure usability on any device.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-challenge-of-infinite-screens"&gt;The Challenge of Infinite Screens&lt;/h2&gt;
&lt;p&gt;Today, we design for a 30mm smartwatch (Apple Watch) and a 49-inch curved monitor. We cannot design a screen for every width. We need a &lt;strong&gt;Scaling Strategy&lt;/strong&gt; that is liquid and resilient.&lt;/p&gt;</description></item><item><title>Safeguards for Destructive Actions: Positive Friction</title><link>https://www.fernandoux.com/en/wiki/techniques/destructive-action-safeguards/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/techniques/destructive-action-safeguards/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Safeguards&lt;/strong&gt; are intentional friction mechanisms designed to prevent a user from performing irreversible actions (deleting, formatting, closing an account, or removing critical data) accidentally or impulsively. In this case, &lt;strong&gt;friction is an ally of the user experience.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-power-of-positive-friction"&gt;The Power of Positive Friction&lt;/h2&gt;
&lt;p&gt;In standard interface design, we seek to remove any obstacles or friction that slows down the user. However, for destructive actions, friction is &lt;strong&gt;humanly necessary&lt;/strong&gt;. Without it, a single mistaken click could erase years of user work. A good safeguard forces the brain to switch from automatic mode (&amp;ldquo;System 1&amp;rdquo;) to analytical and conscious mode (&amp;ldquo;System 2&amp;rdquo;).&lt;/p&gt;</description></item><item><title>Salvaguardas para Acciones Destructivas: Fricción Positiva</title><link>https://www.fernandoux.com/es/wiki/techniques/destructive-action-safeguards/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/destructive-action-safeguards/</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;Salvaguardas&lt;/strong&gt; son mecanismos de fricción intencionada diseñados para evitar que un usuario realice acciones irreversibles (borrar, formatear, cerrar cuenta o eliminar datos críticos) de forma accidental o impulsiva. En este caso, la &lt;strong&gt;fricción es un aliado de la experiencia de usuario.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-poder-de-la-fricción-positiva"&gt;El Poder de la Fricción Positiva&lt;/h2&gt;
&lt;p&gt;En el diseño de interfaces habitual, buscamos eliminar cualquier obstáculo o fricción que ralentice al usuario. Sin embargo, en las acciones destructivas, la fricción es &lt;strong&gt;humanamente necesaria&lt;/strong&gt;. Sin ella, un clic erróneo podría borrar años de trabajo del usuario. Una buena salvaguarda obliga al cerebro a pasar del modo automático (&amp;ldquo;Sistema 1&amp;rdquo;) al modo analítico y consciente (&amp;ldquo;Sistema 2&amp;rdquo;).&lt;/p&gt;</description></item><item><title>Salvaguardas para Acciones Destructivas: Fricción Positiva</title><link>https://www.fernandoux.com/es/wiki/tecnicas/salvaguardas-acciones-destructivas/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/salvaguardas-acciones-destructivas/</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;Salvaguardas&lt;/strong&gt; son mecanismos de fricción intencionada diseñados para evitar que un usuario realice acciones irreversibles (borrar, formatear, cerrar cuenta o eliminar datos críticos) de forma accidental o impulsiva. En este caso, la &lt;strong&gt;fricción es un aliado de la experiencia de usuario.&lt;/strong&gt;
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="el-poder-de-la-fricción-positiva"&gt;El Poder de la Fricción Positiva&lt;/h2&gt;
&lt;p&gt;En el diseño de interfaces habitual, buscamos eliminar cualquier obstáculo o fricción que ralentice al usuario. Sin embargo, en las acciones destructivas, la fricción es &lt;strong&gt;humanamente necesaria&lt;/strong&gt;. Sin ella, un clic erróneo podría borrar años de trabajo del usuario. Una buena salvaguarda obliga al cerebro a pasar del modo automático (&amp;ldquo;Sistema 1&amp;rdquo;) al modo analítico y consciente (&amp;ldquo;Sistema 2&amp;rdquo;).&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>Skeleton VS Optimistic UI: Loading Strategies</title><link>https://www.fernandoux.com/en/wiki/concepts/skeleton-vs-optimistic-ui/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Skeleton Screens&lt;/strong&gt; are gray placeholders that mimic the final structure of the page while data is loading. &lt;strong&gt;Optimistic UI&lt;/strong&gt; is a technique that shows the result of an action immediately, assuming the server will respond successfully.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-art-of-waiting-perceived-performance"&gt;The Art of Waiting: Perceived Performance&lt;/h2&gt;
&lt;p&gt;In modern product design, speed is not just a matter of real milliseconds (latency), but of how the user &lt;strong&gt;feels&lt;/strong&gt; the system is responding. Both techniques seek to reduce user anxiety during loading, but they are applied at different points in the flow.&lt;/p&gt;</description></item><item><title>Status Awareness in UI</title><link>https://www.fernandoux.com/en/wiki/concepts/status-awareness/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Status Awareness&lt;/strong&gt; (State Awareness) is an interface&amp;rsquo;s ability to clearly and continuously communicate what is happening in the system, at what step of the process the user is, and what the current condition of each component is (e.g., if a button is pressed, if data is loading, or if there is an error).
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-user-needs-status-awareness"&gt;Why the User Needs Status Awareness?&lt;/h2&gt;
&lt;p&gt;As human beings, we hate uncertainty. In the physical world, if you flip a switch and the light doesn&amp;rsquo;t turn on, you know there&amp;rsquo;s a fault because the switch physically changed position. In the digital world, if a user clicks a button and nothing happens visually in the first few milliseconds, the user will click the button 5 more times, generating server errors and frustration.&lt;/p&gt;</description></item><item><title>The Command Pattern in Product Design</title><link>https://www.fernandoux.com/en/wiki/concepts/command-pattern/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 The &lt;strong&gt;Command Pattern&lt;/strong&gt; is a software design pattern that encapsulates a user request or action as an independent object. In the world of product design, this allows us to treat each action (delete, move, edit, change color) as an entity that can be stored, undone, redone, and synchronized across multiple users.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-designer-should-know-the-command-pattern"&gt;Why the Designer Should Know the Command Pattern?&lt;/h2&gt;
&lt;p&gt;Traditionally, design focused on the &lt;strong&gt;final state&lt;/strong&gt; of screens (the fixed photo). However, modern products (like Figma, Notion, or Google Docs) focus on the &lt;strong&gt;actions&lt;/strong&gt; that lead from one state to another. The Command Pattern is the technical language that makes these transitions possible.&lt;/p&gt;</description></item><item><title>Timing de Validación en Formularios: Recompensa y Reglas</title><link>https://www.fernandoux.com/es/wiki/techniques/form-validation-timing/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/techniques/form-validation-timing/</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;Timing de Validación&lt;/strong&gt; decide en qué momento exacto le comunicamos al usuario si la información introducida es correcta o incorrecta. Elegir el momento adecuado reduce drásticamente la interrupción del flujo, la ansiedad del usuario y la tasa de abandono de los formularios.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-momento-de-validación-lo-es-todo"&gt;¿Por qué el Momento de Validación lo es Todo?&lt;/h2&gt;
&lt;p&gt;Rellenar formularios es una tarea pesada para el cerebro humano. Si interrumpes al usuario en el momento equivocado, rompes su flujo mental (flow) y le generas una sensación de vigilancia constante. La validación no debe ser un juicio, sino una guía que ayude a terminar la tarea lo más rápido posible.&lt;/p&gt;</description></item><item><title>Timing de Validación en Formularios: Recompensa y Reglas</title><link>https://www.fernandoux.com/es/wiki/tecnicas/timing-validacion-formularios/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/es/wiki/tecnicas/timing-validacion-formularios/</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;Timing de Validación&lt;/strong&gt; decide en qué momento exacto le comunicamos al usuario si la información introducida es correcta o incorrecta. Elegir el momento adecuado reduce drásticamente la interrupción del flujo, la ansiedad del usuario y la tasa de abandono de los formularios.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="por-qué-el-momento-de-validación-lo-es-todo"&gt;¿Por qué el Momento de Validación lo es Todo?&lt;/h2&gt;
&lt;p&gt;Rellenar formularios es una tarea pesada para el cerebro humano. Si interrumpes al usuario en el momento equivocado, rompes su flujo mental (flow) y le generas una sensación de vigilancia constante. La validación no debe ser un juicio, sino una guía que ayude a terminar la tarea lo más rápido posible.&lt;/p&gt;</description></item><item><title>Token Aliasing and Inheritance Strategy</title><link>https://www.fernandoux.com/en/wiki/techniques/token-aliasing-inheritance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Token &lt;strong&gt;Aliasing&lt;/strong&gt; consists of defining a token that refers to another token instead of a raw value (like a hexadecimal or pixels). &lt;strong&gt;Inheritance&lt;/strong&gt; is the logical structure that allows design decisions to flow from the most general to the most specific, ensuring consistency and total flexibility in the system.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="what-is-token-aliasing"&gt;What is Token Aliasing?&lt;/h2&gt;
&lt;p&gt;Imagine you want to buy a car in &amp;ldquo;Sporty Color&amp;rdquo;.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Raw Value:&lt;/strong&gt; &lt;code&gt;Red #FF0000&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Primitive Token (Global):&lt;/strong&gt; &lt;code&gt;brand-red&lt;/code&gt; -&amp;gt; &lt;code&gt;#FF0000&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Semantic Token (Alias):&lt;/strong&gt; &lt;code&gt;color-background-cta&lt;/code&gt; -&amp;gt; &lt;code&gt;brand-red&lt;/code&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;In this example, &lt;code&gt;color-background-cta&lt;/code&gt; is an alias of &lt;code&gt;brand-red&lt;/code&gt;. If tomorrow you decide that your brand&amp;rsquo;s sporty color is Orange, you only have to change the alias reference to &lt;code&gt;brand-orange&lt;/code&gt;, and automatically all the call-to-action (CTA) buttons in your product will update. Without aliasing, you would have had to manually search for setiap instance of the color red and change it.&lt;/p&gt;</description></item><item><title>Token Architecture (Global vs. Semantic vs. Component)</title><link>https://www.fernandoux.com/en/wiki/concepts/token-architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Design token architecture is the logical structure that organizes design decisions (colors, typography, spacing) into layers of abstraction. A well-designed model allows you to change the appearance of an entire product in minutes, ensuring consistency and scalability between design and code.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="what-is-token-architecture"&gt;What is Token Architecture?&lt;/h2&gt;
&lt;p&gt;Imagine you are building a city. You don&amp;rsquo;t want to have to paint every brick of every house individually. Instead, you define a &amp;ldquo;palette of materials&amp;rdquo; (global tokens), decide that all public buildings will be &amp;ldquo;institutional color&amp;rdquo; (semantic tokens), and finally apply that color to the &amp;ldquo;town hall main door&amp;rdquo; (component tokens).&lt;/p&gt;</description></item><item><title>Token Parity Across Multiple Platforms</title><link>https://www.fernandoux.com/en/wiki/concepts/token-parity/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Token parity ensures that design decisions are translated identically and accurately across different platforms (Web, iOS, Android, Desktop) using a single source system. This eliminates visual inconsistencies and significantly reduces QA effort.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-challenge-of-platform-fragmentation"&gt;The Challenge of Platform Fragmentation&lt;/h2&gt;
&lt;p&gt;Each technological ecosystem handles styles (colors, fonts, shadows) uniquely. If a designer chooses a &amp;ldquo;Primary Blue,&amp;rdquo; they face:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Web:&lt;/strong&gt; CSS/SCSS files (rem, px, hex, hsl, rgb).&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;iOS:&lt;/strong&gt; Swift/SwiftUI files (Points, UIColor, Asset Catalogs, JSON).&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Android:&lt;/strong&gt; Resource XML or Jetpack Compose (dp, sp, hex ARGB).&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Without a parity strategy, the same color may look slightly different or have a different name on each platform, breaking brand consistency and causing confusion among development teams.&lt;/p&gt;</description></item><item><title>Variant Explosion Control (Wrangling Systems)</title><link>https://www.fernandoux.com/en/wiki/techniques/variant-explosion-control/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/techniques/variant-explosion-control/</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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Variant Explosion Control&lt;/strong&gt; is the process of optimizing and simplifying component architecture to avoid an excessive number of manual versions, using tools like &lt;strong&gt;Component Properties&lt;/strong&gt; and &lt;strong&gt;Booleans&lt;/strong&gt; to keep the system lightweight and easy to maintain.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-problem-the-variant-labyrinth"&gt;The Problem: The Variant Labyrinth&lt;/h2&gt;
&lt;p&gt;Before improvements in tools like Figma, creating a simple component (like a button) with &lt;code&gt;3 sizes&lt;/code&gt;, &lt;code&gt;4 color variants&lt;/code&gt;, &lt;code&gt;2 icon states&lt;/code&gt;, and &lt;code&gt;5 interaction states&lt;/code&gt; (default, hover, active, focus, and disabled) required the manual creation of &lt;strong&gt;120 individual variants&lt;/strong&gt; (3 x 4 x 2 x 5).&lt;/p&gt;</description></item><item><title>Visual Hierarchy VS DOM Hierarchy: Accessibility</title><link>https://www.fernandoux.com/en/wiki/concepts/visual-vs-dom-hierarchy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/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;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Visual Hierarchy&lt;/strong&gt; is the order in which a user sees and processes information on a screen based on size, color, position, and contrast. &lt;strong&gt;DOM Hierarchy&lt;/strong&gt; (Document Object Model) is the order in which HTML code structures and reads that same information. Aligning both is the key to accessibility and SEO.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-designer-should-know-the-dom-hierarchy"&gt;Why the Designer Should Know the DOM Hierarchy&lt;/h2&gt;
&lt;p&gt;As designers, we often &amp;ldquo;draw&amp;rdquo; elements on the Figma canvas without worrying about their internal order. However, for a &lt;a href="https://www.fernandoux.com/techniques/screen-reader-testing/"&gt;Screen Reader&lt;/a&gt; or &lt;a href="https://www.fernandoux.com/techniques/focus-management/"&gt;Keyboard&lt;/a&gt; user, your design is not an image; it is a sequential list of elements.&lt;/p&gt;</description></item></channel></rss>