Your Interface Has a Second Audience Now, and It Can't See Your Visual Design at All
You shipped the redesign. The visual hierarchy is clean, the spacing is consistent, the whole thing tested well with users in the lab. And an AI assistant summarizing your product to a prospective customer still describes it wrong — skips your pricing section entirely, or flattens your three-tier plan comparison into a single garbled sentence — because the thing you optimized had nothing to do with the thing that assistant was actually reading.
Every product now has two audiences looking at the same interface and extracting almost entirely different information from it. One is a human, parsing color, contrast, whitespace, and visual rhythm to figure out what matters and where to look next. The other is a language model — inside a search engine's AI overview, a browser assistant, an agent doing a task on a user's behalf — and it isn't seeing your visual design at all. It's parsing structure. And most design teams have spent zero hours designing for that audience, because until recently, it didn't really exist.
The audience that reads markup, not pixels
Call it machine experience, or MX — the emerging discipline of designing for the systems that increasingly stand between your product and the human who'll eventually use it. When an LLM summarizes a page, answers a question using your content, or acts as an agent navigating your interface, it isn't rendering your CSS and admiring your grid. It's working from the semantic skeleton underneath: heading hierarchy, landmark regions, list structure, the actual DOM order content appears in versus the order it visually displays in thanks to CSS positioning tricks that look identical to a sighted user and completely different to a parser.
This is not a new problem in disguise — it's structurally the same problem screen readers have been running into for two decades, which is exactly why the accessibility community got here first and has the tooling to prove it. A <div> styled to look exactly like a heading, with no actual heading tag underneath, has always been invisible to a screen reader. It is now, for the identical structural reason, frequently misread or skipped by an LLM parsing the page for a summary. The parallel isn't a metaphor. It's the same failure, showing up for a second audience that's suddenly much larger and much more commercially consequential than the audience accessibility teams have been arguing for since screen readers existed — and it's arriving at the exact moment the accessibility standard itself is getting harder to automate against, which means the human-judgment skill teams need to build for compliance is the same skill that now determines machine legibility too.
Why visual polish is invisible to the thing that increasingly decides if you get seen at all
Here's the part that should genuinely unsettle a design team that's spent the last several years optimizing almost exclusively for visual craft: an LLM asked to summarize, compare, or extract information from your product page doesn't know your typography is elegant. It doesn't register that your color palette has won awards. If your pricing tiers live in a visually-obvious three-column layout built from unstructured <div> soup with no list semantics, no table markup, and no clear heading labeling each tier, the model reading that page has a meaningfully harder time reconstructing which price belongs to which plan than it would from a boring, semantically correct HTML table with zero visual design applied to it at all.
That's an inversion of the design priority order most teams have operated under for a decade. Visual design used to be close to the whole game, because the only audience was a human eye. Now there's a second audience for whom visual design is not just secondary — it's completely unreadable, full stop, and the thing that actually determines whether that audience gets your content right is the exact layer designers have historically treated as implementation detail, not design work: the semantic structure a developer builds from a Figma file that never specified it. A design system that ships beautiful components with ambiguous or absent underlying semantics is optimizing entirely for an audience that's about to matter less, at the direct expense of one that's about to matter a great deal more.
What this actually changes in a design process
The practical shift isn't "learn to code" for designers, and it isn't a plea to make everything look like a screen-reader test page. It's that heading hierarchy, landmark structure, and predictable component patterns need to move from "something engineering handles during implementation" to a decision made and specified at design time, the same way spacing and color are specified at design time. A component library needs a documented semantic contract alongside its visual one: this is a heading at this level, this is a list, this is a data table, regardless of how it's styled — because the moment styling and semantics are allowed to diverge, which is trivially easy in modern CSS, you get a page that looks perfectly organized to a human and reads as a flat, undifferentiated wall of text to the thing summarizing it for the next customer who finds you through an AI search result instead of a direct visit.
This also reframes a design-system decision that's been treated as a nice-to-have for years: token and pattern consistency across a product isn't just about brand coherence or engineering velocity anymore. A design system that enforces one true way to build a pricing table, a comparison grid, or a navigation structure — instead of letting every team hand-roll their own visually-similar-but-structurally-different version — is the thing standing between a consistent, correct machine reading of your product and a coin-flip on whether any given page gets summarized accurately at all. The team that already invested in a rigorous, semantically disciplined design system didn't know it was also building AI-legibility infrastructure. It was, and that's about to become the more visible payoff of the investment.
So actually, the accessibility work most design teams have been quietly under-resourcing for years — proper heading structure, real semantic HTML, landmark regions, list and table markup used correctly instead of visually approximated — was never a compliance checkbox running parallel to "real" design work. It was, this whole time, training for an audience that hadn't fully arrived yet. It's arrived now, it reads your product before most humans do, and it cannot see a single pixel of the visual design you've been optimizing for alone.