Happy weekend, picnickers! 

Although I don’t get the sense that the UX world got a lot of work done this week. Instead, everyone has been talking about Figma Sites, a new feature that brings back memories of the early 00s. 

A bit of a history lesson for our younger readers: the quest for a WYSIWYG (What You See Is What You Get – once upon a time, a revolutionary concept in and of itself, because on old hardware you could either edit or render the final product but not both) website editor hearkens back all the way to since there have been websites. At one point, the best you could do was use the Slice tool in Photoshop to divide an image into <table> cells, and export that as HTML. 

So when Dreamweaver came along and let you draw a rectangle that instantly became a <div> in actual HTML, in real time, people cheered. For about ten seconds, until Dreamweaver became the punchline of a joke about code quality and slowly faded into obscurity. The first era of “should designers code” began. 

The Timeline

20 years after Dreamweaver was acquired by Adobe, Figma (which failed to be acquired by Adobe) has produced its own Dreamweaver. But while the technology of generating code has gotten better, so too the standards for that code. And in a world where it’s never been easier to work with a dynamic CSS grid, designers across the internet are finding Figma wanting. 

One of the big things that kicked off about 15 years ago was HTML5 and semantic website structure. It's a big deal for a lot of reasons, primarily for how accessibility tools process content. But Figma is not ontology software; it is layout software and so it does not generate semantic HTML.  

In fact, the markup it generates is so chaotic that it is entirely inaccessible. The very demo sites Figma made to show off the product fail automated WCAG testing (also check out the links in the footer of that post for more critiques). ARIA labels are sprinkled at random, making screen readers re-read text twice. Buttons are powered by Javascript for no clear reason (which the industry as a whole really ought to wean itself off of). Some of the code really ought to be seen to be believed.  

The failure of Figma Sites to engage with concepts that are decades old really makes me feel like we are at an inflection point for what it means to do UX design. If tools like this take off, the nature of the job will shift irrevocably from making a website to making website-shaped outputs; something that looks good enough at first glance for out stakeholders who will not need to use it themselves. 

Reading Material

Over the years, I have repeatedly critiqued the shift in UX practice away from strategy and towards delivery. But that cloud was supposed to have one silver lining: that designers would no longer rely on Java developers who drew the short straw in order to translate their vision from “pixel-perfect” mockups to working code. Indeed, the best argument for designers learning to code is that a command of the basics of websites such as the box model would allow them to design element behaviors and not just layouts. The past decade of the practice has been devoted to getting really really good at Design Systems, which was supposed to mean making high-quality components and rules for how those components interact, to the point that they would be like building blocks that could be clipped together during the delivery stage. 

In theory, this should have been perfect for the era of AI. What could be easier than generating websites when you have a library of these elements at hand? 

And yet somehow, that’s not what’s happening. The design systems at the design tool company are not there yet. And I don’t think any of the other ones are going to be there, now or possibly ever, because the discipline is prioritizing the wrong thing. Garbage in equals garbage out, and the focus on demoing the perfect layout is guaranteeing that we are going to have garbage in. 

We are never going to get a web UI generator that doesn’t suck until we learn to start by creating content that doesn’t suck. AI can’t help with that because structured, semantically marked-up content is what it needs as an input in the first place. 

And this brings us back to WYSIWYG, and the distinction that Carrie Hane draws between it and rich text. Before you ask “what is it going to look like?” you need to define the “it”; before you define what emphasized content looks like visually, you must determine what emphasis means. 

Andrei Hodorog’s thesis covers pretty much everything you need to know to understand how to do semantics for the Web, but the most important lesson is that it's too late to start doing semantic structure at the visual stage. You should start with the content model, and use it to structure everything from the logic of the solution on down. 

This is the level of rigor required to create a website, rather than just an image of a website – whether you do it with an LLM, or by hand. 

— Pavel at the Product Picnic