Most real teams don't have a designer reviewing every button, spacing value, and error message an engineer ships. Whether or not a design file exists, an engineer makes real UX decisions constantly — this domain is about making those decisions on purpose instead of by accident.
3 min read
Every time you write a form without deciding what happens on a validation error, choose a loading state (or don't), or pick how much space sits between two elements, you've made a real UX decision — whether or not you thought of it that way. Most real engineering teams, especially smaller ones, don't have a designer specifying every detail; a huge number of actual interface decisions get made by whoever is writing the code, in the moment, often without realizing it's a decision at all.
This isn't about learning Figma, mastering color theory as an art form, or becoming a visual designer — that's a different, deeper discipline with its own tools and craft. This domain is specifically the design thinking an engineer needs to make the interfaces they already build noticeably better: recognizing what makes an interface confusing or unusable, and having a vocabulary and a checklist for fixing it, even without a dedicated designer in the loop.
A design file, even a very detailed one, can never specify every state a real interface will actually hit — every possible error message, every edge case where content is longer or shorter than expected, every loading delay. The engineer implementing it fills in those gaps constantly, and filling them in well or poorly has a direct, measurable effect on whether the thing you built actually works for the people using it — independent of how good the original design mockup was.
A confusing form, an ambiguous error message, or a button that doesn't look clickable doesn't show up as a failing test or a lint warning — it shows up as users abandoning a flow, submitting support tickets, or simply not understanding what to do next. This class of problem is genuinely invisible to every automated check this app's other domains cover (Testing & QA, CI/CD) — it only shows up when a real person tries to use the thing, which is exactly why it needs its own deliberate attention rather than being assumed to be "someone else's job."
Visual hierarchy and typography (how to guide attention on purpose), color and contrast (beyond "looks nice" — real accessibility requirements), spacing and layout, form design (the single most common and most commonly mishandled UI pattern), feedback and affordances (making interactive things look interactive), designing for the whole lifecycle of a screen — not just the happy path — accessibility fundamentals, responsive design thinking, design systems, and a closing set of practical usability heuristics you can apply to evaluate any interface, including your own.
The CSS & Modern Styling domain covers how to implement layout and styling — the cascade, Grid, custom properties, the actual CSS mechanics. This domain covers what to build and why — the design decisions those CSS tools get used to express. Knowing Grid syntax doesn't tell you where to put emphasis on a page; that's the layer this domain adds.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why do engineers make real UX decisions even without a dedicated designer on the team?
2. How does this domain differ from a general design-tool course like learning Figma?
3. Why can UX problems be invisible to automated checks like tests and linters?
UI/UX for Developers