Design engineering

Design and code,
one discipline.

Why the most considered interfaces are built by people who can do both, and how that thinking shapes every component in Nyx UI.

What is design engineering

Design engineering is what happens when one person owns both the mockup and the code that ships it. A design engineer thinks in systems, things like spacing scales, motion curves and state machines, and then writes the actual UI instead of handing a picture of it to someone else.

The discipline sits where Figma ends and the browser begins. That territory used to belong to nobody. Designers shipped files, engineers shipped features, and everything in between, the hover states, the easing, the way a dialog settles into place, got decided by whoever happened to be holding the ticket.

The title is new but the work is not. People have been doing it under names like UX engineering, creative development and prototyping for years, usually without getting noticed or paid for it. Calling it design engineering just made the job visible enough to hire for.

Why it matters

Most UI debt is translation debt. A design specifies 24px of space and a certain feel for how a menu should open. Somewhere in the handoff that becomes mt-4 and a default tween. One screen survives it. A whole product does not.

The further a decision travels from the person who made it, the more of the decision gets lost. Design engineering shortens that distance to zero. The person who chose the easing curve is the person who writes the transition, so nothing gets approximated on the way to production.

There is also a speed argument. A prototype built in real code answers questions a static mockup cannot: does this feel right at 60fps, does it hold up with real data, does the motion survive contact with actual content. Teams that prototype this way learn faster because they test the real thing.

How Nyx UI is built around it

Every component in this library is designed and built together. When you copy a component into your app, those decisions come with the code.

That means you are not starting with a blank canvas full of defaults. You get a component that already has a point of view, with the small details figured out and the different states working together.

Of course, you can change anything you want. The difference is that you are building on top of something intentional instead of having to make all those decisions yourself. You start with something that already feels good, then make it yours.

That is really the idea behind the library. Design and engineering are not treated as separate layers. Every component is made with both in mind, so it looks right, behaves right and works well in a real product.

See design engineering in practice

Browse components