UX through a Frontend Developer’s eyes - practical UX protips for FEDs

Why Frontend Developers own UX quality

Shipping a working interface has never been easier. Design tools, AI, component libraries, and modern scaffolding have dramatically lowered the barrier to getting something on screen.

Ideally, you work alongside a UX designer who handles research, prototyping, and interaction design. But that’s not always the case. Sometimes there is no designer on the team. Sometimes the designer’s bandwidth doesn’t cover every screen, edge case, or state transition. In those moments, the frontend developer becomes the last line of defense for user experience - and often the person best positioned to improve it.

But a UI that works and a UI that feels good are different things. A large part of that gap lives at the implementation level: intermediate states, loading behavior, motion, feedback, layout stability, and interaction patterns. These aren’t purely design decisions - they’re engineering decisions that designers rarely spec in full detail. And they directly shape how an interface is experienced.

This article is a practical, hands-on collection of workflow improvements, UX patterns, and implementation-level pro tips - all from a frontend developer’s perspective. No lengthy theory lectures (though a few concepts need a quick explanation to make sense). Jump in and try these techniques in your own projects to measurably improve how your interface feels.

AI in modern frontend workflow

Before we dive into UX patterns, let’s talk about the tools shaping how frontenders work today. AI-powered workflows are changing how we go from design to code - and understanding their strengths and limitations helps you know exactly where your own UX instincts need to kick in.

Figma Developer Mode

Let’s start with something that significantly improves the frontend developer’s life when working with a designer.

One of the most popular tools among UI/UX designers is Figma - a collaborative design platform for creating interface prototypes that eventually land on the developer’s desk for implementation.

In 2023, Figma introduced a feature called Dev Mode, which lets developers inspect all CSS properties of any element: dimensions, margins, paddings, colors, font sizes, border radii, and much more. Think of it as “Inspect Element” but for design files - before anything is coded.

Thanks to Dev Mode, you can build pixel-perfect interfaces without guessing values or constantly pinging the designer for spacing details. It bridges the gap between what the designer intended and what you actually ship.

AI integration with Figma and MCP

Figma also offers integration of your local AI agent - tools like Cursor or Claude Code - with an MCP (Model Context Protocol) server for Figma. MCP is an open standard (originally developed by Anthropic) for connecting AI tools to external data sources; Figma provides its own server implementation that exposes design data via this protocol. This opens up the possibility of implementing individual components or entire UIs in your chosen technology stack, based on a specific mockup, with a single prompt.

This is great for:

• Rapid prototyping - go from a Figma frame to working code in minutes, not hours. Perfect for validating ideas before committing to full implementation.
• Exploring visual variants - ask the AI to generate three different layouts for the same component and compare them side by side in your actual tech stack.
• Speeding up the boring parts - let the AI handle boilerplate styling and structural markup while you focus on the interaction logic that actually matters.

But it still requires manual refinement around:

• Interaction states - AI-generated code typically covers the default, “happy path” look. Hover, focus, disabled, and error states are often missing or inconsistent.
• Dynamic data behavior - real apps don’t have three perfectly-sized cards. What happens when a title wraps to two lines? When does a list have 200 items? When a field is empty?
• Data source integration - AI-generated components use placeholder data. Connecting to your actual APIs, databases, or state management layer - and handling the async lifecycle that comes with it - is entirely on you.
• Loading and error handling - AI rarely generates skeleton loaders, optimistic updates, or graceful error boundaries. These are exactly the patterns covered later in this article.

For a step-by-step guide on setting up the Figma MCP server, check out the official Figma MCP integration guide.

UI Generators (Lovable, Bolt, v0)

If you don’t have access to a UX designer to design your interface, you can reach for dedicated AI-powered UI generation tools.

As of early 2026, the most popular options are: v0.dev, bolt.new, and lovable.dev. This space evolves rapidly - specific tools may change, but the strengths and limitations described below apply to AI-generated UI in general.

They all work similarly - you describe what you want in a prompt, and they generate ready-to-use interface code that you can drop into your application. It’s not a perfect process; sometimes you need to regenerate the UI a few times or ask the AI to tweak individual elements. But the general rule holds: the more specific your prompt, the better the output.

Your prompt controls which technologies are used, though each platform has internal system prompts with sensible defaults (v0 defaults to Next.js and Tailwind, for example).

These services also support full-stack generation. For instance, v0 can create server components, API endpoints in Next.js, and fully wired-up frontend actions that connect to those backend functions - all from a single prompt.

Excellent for:

• MVPs and proofs of concept - when you need a working UI in hours, not days, and pixel-perfection is less important than getting something tangible in front of stakeholders.
• Initial scaffolding - generating a component library baseline or page layout that you then customize, rather than starting from a blank file every time.
• Structural exploration - trying out different page layouts, navigation patterns, or component arrangements before committing to one approach.

Commonly weak in:

• Loading states - most generated UIs jump straight from “nothing” to “everything rendered” with no skeleton screens, spinners, or progressive loading.
• Error states - what happens when an API call fails? When a form submission is rejected? Generated code rarely addresses these scenarios.
• Async flows - real apps deal with network latency, retries, race conditions, and stale data. AI-generated code almost never accounts for this.
• Microinteractions - no hover feedback, no transition animations, no subtle visual cues that make an interface feel alive.
• Feedback patterns - no toasts, no success confirmations, no undo prompts. The user clicks a button and has to guess whether anything happened.

Generated UI is usually a solid baseline - but it’s not a finished UX. The remainder of this article covers exactly the patterns and details you need to layer on top.

Perception and decision rules Developers should know

AI tools handle the surface-level structure well, but good UX requires understanding why certain layouts and interactions work. Before diving into specific implementation patterns, let’s start with the foundational principles that underpin everything else.

Gestalt Principles (practical use)

The Gestalt principles describe how the human brain organizes visual information into groups and patterns. They were formulated by psychologists in the early 20th century, but they’re directly applicable to every component layout and dashboard you’ll ever build.

• Proximity groups items - elements placed close together are perceived as related, even without lines or boxes around them. This is why spacing is one of your most powerful design tools. A form where labels are closer to their inputs than to the next field’s label is instantly more readable. A dashboard where related metrics are clustered with generous space between groups communicates hierarchy without a single heading.
• Similarity implies relation - elements that share visual properties (color, size, shape, font weight) are perceived as belonging to the same category. This is why all your primary action buttons should look the same, why all destructive actions should share a color, and why breaking visual consistency unintentionally can confuse users.
• Continuity guides scanning - the eye follows smooth lines and curves. Aligned elements create visual flow. This is why left-aligned form labels are easier to scan than centered ones, why consistent column alignment in tables matters, and why a misaligned element feels “wrong” even when the user can’t articulate why.
• Figure–ground builds layers - the brain separates foreground content from background surfaces. This is the principle behind cards, modals, and overlays. A card with a subtle shadow “lifts” off the background and becomes the focus. A modal with a dark backdrop makes the background recede. Using lightness and shadow to create depth helps users understand what’s interactive and what’s context.

These aren’t abstract concepts - they’re the reason good layouts “just work”, and bad ones feel confusing.

Hick’s Law

Hick’s Law states that the time it takes to make a decision increases logarithmically with the number of choices. In plain terms, more options mean slower, harder decisions.

This has direct implications for navigation menus, settings pages, form dropdowns, and any interface where the user must choose from a set of options. A sidebar with 18 flat, unsorted links is measurably harder to navigate than one with 4 grouped categories that expand to reveal specific options.

Practical applications:

• Group and categorize - instead of a flat list of 15 options, organize them into 3–5 logical groups. The user first picks a category (easy, few choices), then picks an item within it (easy, few choices). Two simple decisions are faster than one complex one.
• Progressive disclosure - show essential options first, and hide advanced ones behind an “Advanced” toggle or submenu. Most users never need the advanced settings; don’t slow them down with options they’ll never use.
• Smart defaults - pre-select the most common option. This reduces the decision from “pick one of these” to “accept this or change it” - a much simpler cognitive task.
• Search as an escape hatch - for very large option sets (country selectors, font pickers), provide a search/filter input so users can jump directly to what they want instead of scanning a massive list.

Fitts’s Law

Fitts’s Law predicts that the time to reach a target depends on two things: the distance to the target and the size of the target. Bigger, closer targets are faster and easier to hit.

This sounds obvious, but it’s violated constantly in real interfaces:

• Tiny action buttons - a 24x24px icon button with no padding is technically clickable, but it’s a frustrating target, especially on mobile. A 44x44px minimum touch target (Apple’s recommendation) or 48x48px (Google’s) makes a huge difference.
• Submit buttons far from input fields - if a user just finished typing in a text field, their cursor (or thumb) is near that field. A submit button placed far away forces unnecessary travel. Place primary actions adjacent to the inputs they act on.
• Icon-only buttons without labels - a small gear icon for settings is harder to click than a button that says “Settings” with a gear icon. The text dramatically increases the clickable area and, as a bonus, removes the ambiguity of icon-only actions.
• Mobile edge targets - buttons placed at the corners or top of a mobile screen are the hardest to reach with one hand. Critical actions should be in the lower-center area, within the thumb’s natural arc.

The takeaway: make important things big, make them close to where the user’s attention already is, and never rely on tiny click targets for critical actions.

Progressive disclosure

Progressive disclosure is the principle of showing only what’s necessary at each stage of an interaction and revealing more as the user requests it or it becomes relevant.

The goal is to reduce initial overwhelm and let users engage at their own pace:

• Multi-step wizards - instead of a single form with 30 fields, break it into logical steps (account info → preferences → review). Each step shows only a handful of fields, making the task feel manageable. Progress indicators (“Step 2 of 4”) add motivation and context.
• Collapsible accordions - FAQ pages, settings panels, and long documentation benefit from accordions that show section titles with content hidden until clicked. The user scans the titles, opens only what’s relevant, and isn’t overwhelmed by a wall of text.
• “Advanced” and “More options” sections - in forms, dashboards, and configuration screens, hide rarely used options behind a toggle or an expandable section. Power users know to look for it; casual users aren’t distracted by options they don’t understand or need.

Progressive disclosure works hand-in-hand with Hick’s Law - by revealing fewer options at each step, you’re reducing decision complexity at every stage.

Visual Clarity: typography, color, and states

Those principles are useful in theory - now let’s apply them concretely, starting with the most fundamental visual building blocks: typography, color, and component states. When you’re building the interface, the decisions about font rendering, color consistency, and component state coverage are yours to make. These details compound - a consistent type scale, a cohesive color palette, and fully defined component states are what separate a “developer-built” UI from a “designed” one.

Typography

Typography is the backbone of any interface. Users spend most of their time reading - labels, buttons, headings, paragraphs, tooltips - so the choices you make about fonts directly impact usability.

• Stick to 1–2 font families maximum - one for headings and one for body text is a classic, safe combination. Using more than two creates visual fragmentation - the page feels unfocused, like multiple designs were merged together. If you’re choosing a single font, pick a versatile sans-serif (Inter, Open Sans, or the system font stack). Avoid defaulting to serif system fonts like Times New Roman in app UIs - they immediately signal “unstyled” or “unfinished” to modern users accustomed to clean sans-serif interfaces.
• Limit weight variants - within your chosen fonts, use 2–3 weights consistently: regular (400) for body text, medium (500) for emphasis, and bold (700) for headings. Using every weight from 100 to 900 creates subtle inconsistencies that make the hierarchy feel muddy.
• Establish a consistent type scale - pick a scale (e.g., 12px, 14px, 16px, 20px, 24px, 32px) and use only those sizes. Random sizes like 13px, 17px, and 22px scattered throughout the app create an unconscious sense of disorder. Most design systems use a mathematical scale (each step is 1.25× or 1.33× the previous).
• Use a readable line-height - for body text, a line-height of 1.5–1.7 relative to font size ensures comfortable reading. For headings (which are larger and shorter), 1.2–1.3 is typically sufficient. Cramped text (line-height: 1) is visually dense and tiring to read; overly loose text (line-height: 2+) feels disconnected and wastes space.

Color and layering

A common mistake in developer-built interfaces is using too many different colors. A red header, green buttons, blue links, orange badges, and purple highlights might each seem reasonable in isolation, but together they create visual chaos.

Instead of reaching for a new color every time you need to distinguish something:

• Use shades and tints of one base color - pick a single brand color (e.g., indigo) and derive your entire palette from it. Light tints for backgrounds, medium shades for borders and secondary elements, the full-saturation color for primary actions, and dark shades for text. This creates instant visual cohesion. Tools like Coolors or Realtime Colors can help you generate and preview a cohesive palette in seconds.
• Create depth through lightness, not hue - differentiate UI layers (page background → card → elevated card → modal) by increasing lightness from dark to light (or vice versa for dark themes). This uses the Gestalt figure-ground principle to create hierarchy without introducing new colors.
• Keep the palette consistent and meaningful - reserve specific colors for specific meanings: red for errors and destructive actions, green for success, amber for warnings, and your brand color for primary actions. When color has a consistent meaning, users learn the visual language and navigate faster.

Color should signal state, not just decorate. Every color choice should answer the question: “What does this tell the user?”

Complete component states

A button that just sits there looking the same whether it’s clickable, hovered, focused, loading, disabled, or errored isn’t a component - it’s a rectangle with text in it.

Every interactive component should define these states:

• Default - the resting state. What the component looks like when no interaction is happening.
• Hover - visual feedback on mouse-over. A subtle background change, a slight lift shadow, or a color shift that says “this is interactive, and I know your cursor is here.”
• Focus - a visible focus ring or outline for keyboard navigation. Don’t remove :focus styles without providing a visible alternative (more on this in the Accessibility section).
• Active / Pressed - a momentary visual change when the element is being clicked or tapped. Usually, or darker background. Confirms “your click registered.”
• Disabled - grayed out, with cursor: not-allowed and the disabled attribute (or aria-disabled when you still want the element to remain focusable - see the Accessibility section for when and why). Note: avoid combining cursor: not-allowed with pointer-events: none - the latter prevents all pointer events, which means the cursor style won’t be visible. Use one approach or the other. A common mistake is leaving a button looking clickable when it shouldn’t be - for instance, a “Submit” button that should be disabled until all required fields are filled.
• Loading - a spinner or loading animation replacing the button text (or appearing next to it). Prevents duplicate submissions and informs the user that their action is being processed. The button should also be functionally disabled during loading.
• Error - red borders, tinted background, or an icon indicating something went wrong with this specific component. An input field that failed validation, a button whose action failed.
• Success - a brief green tint, checkmark icon, or “Done!” text that confirms a successful action before returning to the default state.

AI generators and rapid prototyping tools almost always skip most of these states. They generate the default look and call it done. It’s the developer’s responsibility to ensure every interactive element feels complete and responsive across all these interaction scenarios.

Empty states as UX opportunities

An empty state - a page, list, or section with no data yet - is one of the most overlooked UX opportunities. The default developer instinct is to show “No data” or an empty table with headers but no rows. This is technically correct and deeply unhelpful.

An empty state is the first thing a new user sees when they open your app. It’s also what a user sees after clearing a list, archiving all items, or applying filters that return zero results. In every case, showing “No data” leaves the user stranded - they see nothing and don’t know what to do next.

Instead, treat empty states as a chance to guide behavior:

• Suggest the next action - “No projects yet” is only half the message. The full message is “No projects yet - click ‘Create Project’ to get started.” Tell the user what to do, not just what’s missing.
• Provide a hint or explanation - briefly explain what this section will contain when populated. “Your recent activity will appear here” sets expectations and reassures the user that the feature works.
• Include a prominent CTA - a clear, visible “Create your first…” button right in the empty state area. Don’t make the user hunt for the “New” button in a toolbar or navigation menu.
• Add a friendly illustration - a simple, lightweight graphic (an empty inbox icon, a folder with a plus sign) makes the empty state feel intentional rather than broken. It signals that this is a designed experience, not a missing feature.

Empty space can - and should - guide behavior rather than just occupy pixels.

This concludes the first part of the UX guide for Frontend Developers. If you're ready for more, continue reading "Performance as UX (Perceived Performance)".