Abílio Azevedo.

UX/UI for developers

Cover Image for UX/UI for developers
Abílio Azevedo
Abílio Azevedo

UX/UI for Developers

How developers can bridge the gap with designers through design systems, better communication with Product Designers, and questioning component reusage.

In this post:

Why Developers Should Care About UX/UI

Design is not just a designer's job. Every developer makes UX decisions daily — choosing a loading state, handling an error, deciding how a form validates. Understanding UX fundamentals makes you a better engineer and a better collaborator.

As the Udacity Product Design course by Google puts it: "Design is a systematic and data-driven process." It's not about making things pretty — it's about solving problems for real people.

"Good design is invisible. Bad design is everywhere."

Design Systems: The Shared Language

A Design System is not just a component library. It's the contract between designers and developers — a shared vocabulary that eliminates ambiguity.

What a Design System Should Provide

  • Tokens: Colors, spacing, typography, shadows — the atoms of your UI
  • Components: Buttons, inputs, modals — reusable building blocks
  • Patterns: How components compose together (forms, navigation, data tables)
  • Guidelines: When to use what, and why

Atomic Design

Brad Frost's Atomic Design breaks interfaces into hierarchical levels:

Level Description Example
Atoms Basic HTML elements Button, Input, Label
Molecules Groups of atoms working together Search bar (input + button)
Organisms Complex UI sections Header, Product Card
Templates Page-level layouts Dashboard layout
Pages Specific instances of templates User dashboard with real data

Beyond the original model, some teams add:

  • Quarks: Elements that only appear within an organism (never standalone)
  • Bosons: Abstract elements like grids and color palettes

Tools and References

  • Figma — The industry standard for design collaboration
  • Origami Studio — Meta's prototyping tool for designing and testing interactions and animations
  • Radix UI — Unstyled, accessible component primitives
  • Flowbite — Tailwind CSS component library
  • Tailwind UI — Official Tailwind components
  • Design Systems Library — Collection of public design systems

Toolkit for the Standalone Engineer

You don't have a design team. Or maybe your designer is spread across 5 squads. Either way, you need to ship something that looks and feels professional. These tools give you that superpower.

Tailwind CSS Ecosystem

Tailwind CSS is the developer's best friend for UI. It gives you a design system out of the box — consistent spacing, colors, typography — without writing custom CSS.

Why Tailwind works for developers:

  • Enforces design constraints (you pick from a scale, not arbitrary values)
  • Responsive design with breakpoint prefixes (md:, lg:)
  • Dark mode support built-in (dark:)
  • Utility-first means you rarely context-switch to CSS files

Component Libraries (Tailwind-based)

These libraries give you production-ready components so you don't start from zero:

Library Best For Highlights
shadcn/ui Full applications Copy-paste components, fully customizable, built on Radix + Tailwind
Tailwind UI Premium templates Official Tailwind team, polished marketing/app components
Headless UI Accessible primitives By the Tailwind team, unstyled but fully accessible
DaisyUI Rapid prototyping Semantic class names on top of Tailwind, themeable
Flowbite Marketing sites & dashboards Large set of components with vanilla JS, React, and Vue support
NextUI Next.js apps Modern, beautiful defaults, built on Tailwind + React Aria
Tremor Dashboards & data viz Charts, KPIs, and data components built for Tailwind
Catalyst Application UI Official Tailwind application UI kit

Headless / Unstyled Libraries

When you want full control over styling but need accessibility and keyboard interactions handled:

  • Radix UI — Unstyled primitives (Dialog, Dropdown, Tooltip, etc.)
  • React Aria — Adobe's accessibility hooks
  • Headless UI — Tailwind Labs' accessible components
  • Ark UI — By the Chakra UI team, framework-agnostic

Full Design Systems

If you want an opinionated, batteries-included approach:

Prototyping and Interaction Design

Before writing code, validate your ideas:

  • Origami Studio — Meta's tool for designing interactive prototypes with complex animations and gestures. Great for testing micro-interactions before implementing them
  • Figma — Design, prototype, and collaborate in one tool
  • Framer — Design tool with production-ready code export
  • Pop — Turn paper sketches into interactive prototypes
  • Balsamiq — Low-fidelity wireframing

Icons and Illustrations

Communicating with Product Designers

The biggest source of friction between developers and designers is not skill — it's communication. Here's how to improve it.

Before Building: Ask the Right Questions

  1. "What problem are we solving?" — Not "what screen do I build?" Understanding the why changes how you implement.
  2. "What are the edge cases?" — Empty states, error states, loading states, long text, missing data. Designers often focus on the happy path. Your job is to ask about everything else.
  3. "Is this a new pattern or an existing one?" — Before building something new, check if the design system already has it.
  4. "What's the interaction?" — Static mockups don't show hover states, transitions, keyboard navigation, or screen reader behavior.
  5. "What does this look like on mobile?" — Responsive behavior is often assumed but not specified.

During Development: Communicate Tradeoffs

Designers propose; engineers expose constraints. This is not confrontation — it's collaboration.

  • "This custom dropdown will take 3x longer than using our existing Select component. The visual difference is minimal. Can we reuse?"
  • "This animation is possible but will degrade performance on low-end devices. Here's a simpler alternative that achieves the same feel."
  • "The API doesn't return this data in one call. We can either add a loading state or change the layout."

Specs That Work

A great article on this topic: Desenhando pra web — Como venho melhorando ao desenhar UI com specs melhores para os devs

Good specs should include:

  • Spacing in consistent units (use rem — relative to root font size, not pixels)
  • Color tokens (not hex codes — --color-primary, not #3b6dab)
  • Component states (default, hover, active, disabled, error, loading)
  • Responsive breakpoints

Questioning Component Reusage

"Should I reuse this component?" is one of the most important questions a developer can ask. The answer is not always yes.

When to Reuse

  • The component solves the same problem in a different context
  • The visual and behavioral contract is the same
  • Extending it doesn't require hacking around its API

When NOT to Reuse

  • You're adding props like isSpecialCase, variant="headerButDifferent", or hideWhenUsedInSidebar
  • The component has grown to 15+ props, most of them conditional
  • Changing it for one use case risks breaking 10 others

The Conversation with Your PD

When a designer gives you a mockup that looks almost like an existing component:

"Hey, this looks similar to our DataTable component but with a few differences — the row height is different and there's an inline edit mode. Should we: A) Extend DataTable with these features (risk: complexity), B) Create a new EditableTable component (risk: duplication), or C) Revisit the design to align with our existing patterns?"

Option C is often the best answer. Consistency benefits users more than pixel-perfect originality.

Key UX Principles Every Developer Should Know

Nielsen's 10 Usability Heuristics

These are the foundation. Every developer should internalize them:

  1. Visibility of system status — Always show the user what's happening (loading spinners, progress bars, success messages)
  2. Match between system and real world — Use language and concepts familiar to the user, not technical jargon
  3. User control and freedom — Provide undo, cancel, back. Let users escape from mistakes
  4. Consistency and standards — Follow platform conventions. Don't reinvent the wheel
  5. Error prevention — Prevent errors before they happen (confirmations, input masks, disabling invalid actions)
  6. Recognition over recall — Show options instead of requiring users to remember them
  7. Flexibility and efficiency — Support both novice and power users (keyboard shortcuts, defaults)
  8. Aesthetic and minimalist design — Every extra element competes with relevant information
  9. Help users recover from errors — Clear error messages that explain what went wrong and how to fix it
  10. Help and documentation — Provide contextual help when needed

Source: 10 heuristicas de Nielsen

The B.I.A.S. Framework

Every time users interact with your product, they:

  • Block — Filter the information
  • Interpret — Seek meaning
  • Act — Make decisions within a given time
  • Store — Remember parts of the interaction

To improve any experience, understand the psychological principles affecting each step. More at growth.design.

Don Norman's Design Concepts

From Intro to the Design of Everyday Things:

  • Affordance — What an object suggests you can do with it. A button affords clicking.
  • Signifier — Visual cues that indicate how to interact. An underlined text signifies a link.
  • Conceptual Model — The user's mental model of how something works.
  • Gulf of Execution — The gap between what a user wants to do and figuring out how to do it (discoverability).
  • Gulf of Evaluation — The gap between what happened and understanding what it means (feedback).

Good design has empathy for the people who will use it.

The Power of Familiarity

"Predictable interactions create trust in the product and the brand." — Nielsen

This is critical for developers to understand: your urge for technical elegance should never override user familiarity. If a standard <select> dropdown works, don't build a custom one just because you can.

Users are more traditional than they seem. They want what they already know. No surprises.

How to Build Familiar Interfaces

  1. Study references obsessively:

  2. Repeat what works. Like a musician practicing scales or a fighter drilling the same kick — mastery comes from repetition, not invention.

  3. Test with real users. As one advisor put it: "Go ask the world when you feel slow, stuck, or lost." Show your work to strangers. The feedback still needs interpretation — it's not a to-do list — but it will change your perspective.

Practice Resources

Accessibility Matters

Accessibility is not a feature — it's a requirement. And developers are the last line of defense.

Quick Wins

  • Color contrast: Use Colorable to check your combinations
  • Semantic HTML: Use <button> for buttons, <nav> for navigation. Screen readers depend on it
  • Keyboard navigation: Every interactive element must be reachable and operable with keyboard alone
  • Alt text: Every meaningful image needs descriptive alt text
  • Don't rely on color alone: 8% of men are colorblind. Use icons, patterns, or text alongside color

Recommended reading:

Typography Quick Reference

Understanding font types helps you discuss design decisions:

Type Characteristics Conveys
Serif Strokes/extensions at letter ends Seriousness, formality, tradition
Sans-serif Clean, no extensions Clarity, simplicity, modernity
Calligraphic Handwriting-like, formal or casual Elegance, personality
Decorative Unique, brand-specific (Lego, Fanta) Creativity, playfulness

Resources

Courses

Articles

Books

  • Nao Me Faca Pensar — Steve Krug
  • Hooked (Engajado) — Nir Eyal
  • Steal Like an Artist — Austin Kleon

Libraries and Tools

Animations in React

The experience is good when it's familiar. When I know where I am. When I don't get lost. And I know how to get where I want to go.

More posts

Cover Image for Building a Remote MCP Server for Google Workspace (Sheets, Docs and Presentation)

Building a Remote MCP Server for Google Workspace (Sheets, Docs and Presentation)

Learn how to build and deploy a remote MCP (Model Context Protocol) server for Google Workspace (Sheets, Docs and Presentation) using Next.js, Vercel, and Neon Postgres. Step-by-step guide covering two-layer OAuth authentication, tool registration, serverless deployment, and debugging with MCP Inspector — so any AI assistant can read, write, and manage spreadsheets with just a URL.

Abílio Azevedo
Abílio Azevedo
Cover Image for AI Dev Daily Tools

AI Dev Daily Tools

Learn how to debug smarter with AI prompts, audit SEO from your terminal, go from Sentry errors to PRs in minutes, and unlock hidden Claude Code features.

Abílio Azevedo
Abílio Azevedo

NewsLetter

I will send the content posted here. No Spam =)