Design Engineer's Intro to Modular Components in Code

There was a moment a few years ago when I was staring at a Figma file: one of those sprawling, multi-artboard masterpieces that had grown organically over months. Dozens of screens, hundreds of components, all meticulously crafted. But something felt off.

I'd just finished designing what I thought was a solid user flow, complete with micro-interactions and hover states detailed in separate frames. Then I handed it off to our engineering team and waited for the inevitable questions.

"What happens when this text wraps to three lines?"

"Should this button be disabled if the form is invalid?"

"How does this component behave on mobile?"

Each question revealed another gap between my static screens and the dynamic reality we were building. That's when it hit me: I wasn't designing the thing itself. I was drawing pictures of the thing.

That realization sent me into the world of design engineering tools and modular component approaches. I want to explore these concepts and what they mean for you as a designer who wants to work directly with code.

What Designing in Figma Gave Me — And What It Didn't

Figma is remarkable. It changed how teams approach collaborative design, brought vector editing to the browser, and gave us component systems that felt almost magical when they first appeared.

In Figma, I could create a button component once and use it everywhere. Change the color, and every instance updated. Brilliant. But there was always this nagging sense that I was working one layer removed from reality.

I'd spend hours perfecting the visual hierarchy of a dashboard, only to discover in development that the data could be empty, overflow, or arrive in unexpected formats. My beautiful, controlled Figma environment couldn't account for the messy unpredictability of real applications.

The handoff process became this elaborate translation exercise. You'd annotate components with specs, create redlines for spacing, and write detailed notes about intended behavior. Engineers would interpret these instructions as best they could, but something always got lost in translation.

We were speaking different languages, working in different mediums.

The Promise of Modular Components

Modular components change everything about how you think about design. Instead of collections of pre-built UI elements, they're design primitives that live in code: components that handle real data, respond to user interactions, and adapt to different contexts without requiring separate artboards for every state.

This changes how you approach your work. Rather than drawing rectangles and typing placeholder text, you configure systems that understand data types, user interactions, and business logic.

Picture building a data table component where you don't need to mock up a few rows with sample data or show loading states in separate artboards. The table handles these automatically:

• Empty states with appropriate messaging • Sorting with correct icons and interaction states • Pagination that adapts to different data sizes • Responsive breakpoints as integrated behaviors

These aren't design decisions you need to anticipate and document. They're built into the component's logic.

This eliminates guesswork. You configure actual behavior instead of describing it abstractly.

AI-Assisted Component Development in Code

Tools like Cursor, VS Code with GitHub Copilot, and Windsurf are AI-powered development environments that make code feel less intimidating by providing natural language interfaces and contextual assistance. AI-assisted development creates real possibilities for designers who want to work directly with code.

In an AI-assisted environment, you describe what you want in plain English: "create a user profile card that shows an avatar, name, email, and online status." Watch the system generate not just the markup but a complete component with proper state management and accessibility attributes. Then you can say "make the avatar larger and add a subtle shadow" and see the modifications in real time.

The iteration speed this enables transforms your design process. In Figma, making changes means opening the design file, finding the right component, making edits, updating instances, and then somehow communicating those changes to engineering. In AI-assisted environments, you describe what you want and see the result immediately in the browser.

AI assistance in development tools is like having a technical partner who translates design intent into working code. When you're struggling with CSS Grid syntax for a complex layout, you explain your layout in visual terms and get proper code. When you need to add hover states to a button component, you describe the interaction and get the CSS transitions.

This isn't just about writing code faster. It's about thinking in the medium where your designs will actually live.

Component Libraries: Design Systems That Think

The shift in modern component libraries represents a departure from traditional design systems. The movement is away from black-box solutions toward more transparent, customizable approaches.

New libraries give you actual source code for each component rather than hiding it away. It's like getting the Figma source file instead of just a PNG export.

Shadcn/ui as Design Primitives

New component libraries give you component source code: copy-and-paste building blocks that you can customize completely.

This approach creates design primitives that understand themselves. This type of component library provides:

• Buttons with all variants, states, and accessibility features built in • Complete customization of any aspect of appearance or behavior • Everything from basic form inputs to complex data tables and date pickers • Multiple variants with proper TypeScript definitions • Built-in accessibility features that work together as a cohesive system

Working with these primitives in advanced development environments means you're not just using someone else's design decisions. You're building with intelligent materials that handle the complex logic while giving you complete creative control.

Development tools enable workflows where adding and modifying these components feels fluid: where you can integrate new components while preserving your existing design system architecture.

Why This Workflow Is the Future

Working directly in the medium where your designs will ultimately live changes everything. It's like the difference between drawing a blueprint of a chair and actually building one: you discover things about structure, balance, and materials that you'd never see on paper.

When you write a component that renders a user's profile, you're not just defining how it looks. You're considering edge cases: what if they don't have a profile photo? What if their name is exceptionally long? What if they're offline? These considerations become part of the component's logic rather than separate documentation.

This moves you beyond static design decisions toward dynamic, contextual problem-solving. You're designing for uncertainty rather than trying to control every variable.

The feedback loop becomes immediate. When you modify a component's padding or color scheme, you see how it affects every instance across the application in real-time. No export, no handoff, no interpretation: just direct manipulation of the live system.

Think about building a notification component where you don't design separate states for success, error, warning, and info notifications in different artboards. Instead, you build a single notification component that accepts a type prop, automatically applies the appropriate styling, handles text overflow gracefully, and includes proper ARIA attributes for screen readers.

The component becomes self-documenting. Instead of writing specifications about how the notification should behave, the behavior is encoded in the component itself.

Working with Living Materials

This is designing with materials that understand themselves. A responsive grid knows how to wrap. A form input knows how to validate. A button knows when it should be disabled.

Traditional design tools give us static representations: a button drawn in a specific state, a form captured at one moment in time. Modular components provide dynamic systems that can demonstrate their full range of behaviors.

When you're working on a search interface in development environments, the component shows you how it looks with zero results, one result, hundreds of results, and everything in between. It demonstrates the loading states, error states, and the smooth transitions between them.

You don't imagine how these states work. You experience them directly.

This creates a different relationship with constraints. In Figma, constraints often feel like limitations: the canvas size, the artboard boundaries, the need to manually create every state variation.

With modular components, constraints become creative tools. CSS Grid's intrinsic sizing capabilities suggest new layout possibilities. TypeScript's type system guides component API design. The browser's accessibility requirements inform interaction patterns.

The Learning Curve and New Skills

This transition requires developing new skills. You need to understand HTML, CSS, and JavaScript not just as implementation languages but as design materials with their own properties and possibilities.

CSS Grid isn't just a way to achieve a layout you've already designed. It's a design tool with unique capabilities that can inspire new approaches to organizing information.

CSS custom properties enable theming strategies that would be impractical to maintain in Figma. CSS animations and transitions create opportunities for micro-interactions that enhance usability without requiring complex specifications.

The mental model shifts from pixel-perfect control to thinking in systems. Instead of designing specific screens, you're designing the rules and relationships that generate screens.

Instead of creating individual components, you're building component systems that can evolve and adapt.

This requires embracing a certain amount of uncertainty. Not every visual detail can be predetermined. Some aspects of the design will emerge from the interaction between content, constraints, and user behavior.

This isn't a loss of design control. It's a different kind of design intelligence.

A New Tool, A New Way of Seeing

The medium shapes the thinking. Working in Figma leads to thinking in screens and artboards: contained, controlled compositions. Working with code components in development environments encourages thinking in systems and behaviors: flexible, adaptive structures.

Neither approach is inherently better, but they lead to different kinds of solutions. Screen-based design excels at crafting specific experiences, at controlling every pixel and interaction. Component-based design creates flexible, robust systems that can evolve and adapt over time.

There are concepts to grapple with, workflows to refine, and moments when you miss the immediate visual feedback of traditional design tools.

But there's something powerful about working directly with the materials of the web. HTML, CSS, and JavaScript aren't just implementation details: they're design media with their own properties, constraints, and possibilities.

The collaboration benefits alone make this transition worthwhile. When designers and developers work with the same components, using the same tools, looking at the same interfaces, entire teams move faster and with greater confidence.

This is just the beginning of a conversation about where design engineering is headed, and how our tools shape the way we think about creating digital experiences.

The choice, as always, is yours to make.