<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Development on Fernando Ruiz</title><link>https://www.fernandoux.com/tags/development/</link><description>Recent content in Development on Fernando Ruiz</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 01 Jun 2026 15:01:17 -0500</lastBuildDate><atom:link href="https://www.fernandoux.com/tags/development/index.xml" rel="self" type="application/rss+xml"/><item><title>Claude Code Skills: The Professional Layer Most Users Ignore</title><link>https://www.fernandoux.com/blog/en/claude-code-skills-the-professional-layer-most-users-ignore/</link><pubDate>Thu, 19 Mar 2026 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/blog/en/claude-code-skills-the-professional-layer-most-users-ignore/</guid><description>&lt;p&gt;You&amp;rsquo;re already in Claude Code. You know the basics. You&amp;rsquo;ve seen what it can do. But every new session starts the same way: you spend the first five minutes re-explaining your context, re-typing the prompts you&amp;rsquo;ve written a hundred times, and re-establishing the ground rules before any real work gets done.&lt;/p&gt;
&lt;p&gt;That friction isn&amp;rsquo;t a Claude problem. It&amp;rsquo;s an infrastructure problem. And the fix is a feature most users walk right past: &lt;strong&gt;Skills&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Vibe Coding: What AI Won't Tell You Before Building Your First App</title><link>https://www.fernandoux.com/blog/en/vibe-coding-what-ai-wont-tell-you-before-building-your-first-app/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/blog/en/vibe-coding-what-ai-wont-tell-you-before-building-your-first-app/</guid><description>&lt;p&gt;There&amp;rsquo;s a conversation happening thousands of times a day around the world. It goes something like this:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;&amp;ldquo;Hey Claude, I need you to build me a YouTube-like application but without bugs.&amp;rdquo;&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;And the [[AI]] responds happily, generates code, and the user thinks they&amp;rsquo;ve just hired an engineering team for $20 a month. Three weeks later, the application has 47 bugs, nobody knows why login fails on Tuesdays, and the creator can&amp;rsquo;t change a button color without breaking the payment system.&lt;/p&gt;</description></item><item><title>Spec-Driven Development: The End of Amateur Vibe Coding and the Dawn of Systems Engineering for UX</title><link>https://www.fernandoux.com/blog/en/spec-driven-development-the-end-of-amateur-vibe-coding-and-the-beginning-of-systems-engineering-for-ux/</link><pubDate>Tue, 10 Mar 2026 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/blog/en/spec-driven-development-the-end-of-amateur-vibe-coding-and-the-beginning-of-systems-engineering-for-ux/</guid><description>&lt;p&gt;The concept of [[Vibe Coding]] is appealing. You write in natural language, AI spits out code, and you have a prototype in minutes. It works perfectly for a 100-line script. Try scaling that to a real product, and the system collapses.&lt;/p&gt;
&lt;p&gt;I sat down with &lt;a href="https://dot.cards/ryanedge"&gt;Ryan Edge&lt;/a&gt; to break down exactly how he&amp;rsquo;s using [[AI]] agents to build complex software. The consensus is clear: relying on chat interfaces to code has a glass ceiling. You lose context, the AI hallucinates, overwrites existing logic, and you end up doing manual work to correct a robot.&lt;/p&gt;</description></item><item><title>ARIA vs. Semantic HTML: The Golden Rule</title><link>https://www.fernandoux.com/en/wiki/concepts/aria-vs-semantics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/aria-vs-semantics/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Semantic HTML&lt;/strong&gt; uses the browser&amp;rsquo;s native tags (such as &lt;code&gt;&amp;lt;button&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;input&amp;gt;&lt;/code&gt;, &lt;code&gt;&amp;lt;nav&amp;gt;&lt;/code&gt;) which already come with built-in accessibility and behavior. &lt;strong&gt;ARIA&lt;/strong&gt; (Accessible Rich Internet Applications) is a set of attributes added to the code to &amp;ldquo;patch&amp;rdquo; or explain custom elements that the browser doesn&amp;rsquo;t understand by default.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="the-first-rule-of-aria"&gt;The First Rule of ARIA&lt;/h2&gt;
&lt;p&gt;If there is one thing every designer and developer should remember, it is the &lt;strong&gt;First Rule of ARIA&lt;/strong&gt;:&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>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>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>Focus Management: Navigation without a Mouse</title><link>https://www.fernandoux.com/en/wiki/techniques/focus-management/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/techniques/focus-management/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Focus Management&lt;/strong&gt; is the control of which interface element is selected at any given time to interact with it. It is the backbone of navigation for keyboard users (who press &lt;code&gt;Tab&lt;/code&gt;), screen readers, and anyone not using a mouse.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-designer-must-manage-focus"&gt;Why the Designer Must Manage Focus?&lt;/h2&gt;
&lt;p&gt;Imagine walking into a dark room with only a flashlight. The area your flashlight illuminates is &amp;ldquo;the focus.&amp;rdquo; If you move the flashlight and, suddenly, the light disappears or jumps to the next room without sense, you&amp;rsquo;ll feel lost and frustrated.&lt;/p&gt;</description></item><item><title>Foundations of the Accessibility Tree: How Machines See</title><link>https://www.fernandoux.com/en/wiki/concepts/accessibility-tree/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/concepts/accessibility-tree/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 The &lt;strong&gt;Accessibility Tree&lt;/strong&gt; is a data structure generated by the browser (based on the DOM) that contains only the information relevant to assistive technologies (such as screen readers or voice dictation). It is not visual; it is a translation of your design into names, roles, states, and values.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-designer-should-know-the-accessibility-tree"&gt;Why the Designer should know the Accessibility Tree?&lt;/h2&gt;
&lt;p&gt;As designers, we often focus on the &lt;strong&gt;Visual DOM&lt;/strong&gt; (colors, shapes, positions). However, for blind or visually impaired users, your design is only what the Accessibility Tree says it is.&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>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>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>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>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>Storybook</title><link>https://www.fernandoux.com/en/wiki/tools/storybook/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/tools/storybook/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 Storybook is an open-source development tool for building, testing, and documenting UI components in isolation. It allows developers to create components in a &amp;ldquo;sandbox&amp;rdquo; environment outside the main application, making it easy to visualize all their states and collaborate with designers.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="what-is-storybook"&gt;What Is Storybook?&lt;/h2&gt;
&lt;p&gt;Imagine you are building a car with LEGO pieces. Storybook is like a workshop where you can build and test each piece separately before assembling the car. You can build the engine (a complex component) and test it on its own, or you can build a simple wheel (a button) and see all its available colors and sizes, all without needing the complete car chassis.&lt;/p&gt;</description></item><item><title>Tab Order Strategy: The Keyboard User's Path</title><link>https://www.fernandoux.com/en/wiki/strategy/tab-order-strategy/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://www.fernandoux.com/en/wiki/strategy/tab-order-strategy/</guid><description>&lt;div class="info-panel"&gt;
 &lt;div class="info-header"&gt;
 &lt;span class="material-symbols-outlined info-panel-icon"&gt;info&lt;/span&gt;
 &lt;span class="info-panel-label"&gt;Quick Definition&lt;/span&gt;
 &lt;/div&gt;
 &lt;div class="info-content"&gt;
 &lt;strong&gt;Tab Order&lt;/strong&gt; is the exact sequence in which a keyboard user (pressing &lt;code&gt;Tab&lt;/code&gt; and &lt;code&gt;Shift + Tab&lt;/code&gt;) traverses an interface&amp;rsquo;s interactive elements. A good tabbing strategy ensures that the user doesn&amp;rsquo;t get lost, doesn&amp;rsquo;t have to perform unnecessary clicks, and can complete their tasks quickly and logically.
 &lt;/div&gt;
&lt;/div&gt;

&lt;h2 id="why-the-designer-should-decide-the-tab-order"&gt;Why the Designer Should Decide the Tab Order?&lt;/h2&gt;
&lt;p&gt;Although tab order is usually an automatic consequence of the order in the HTML code (the DOM), visual design can be much more complex. As designers, we sometimes create layouts with columns, grids, or floating elements that don&amp;rsquo;t follow a pure linear order.&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>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>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>