One of the key concerns people raise about using AI to design and build UIs is that we lose the craft. My general thesis is that in the real world, with teams that have constraints (of time, of resources), AI can actually elevate our craft.
There are other concerns, some of which are perhaps even more interesting. When we use AI, we converge towards a solution too early: AI makes it very easy to skip the divergent step (opens in a new tab). It’s also just too tempting to use AI to fill in the gaps rather than think through the problems. Sometimes we’re vague because that’s simply how we write the prompt; sometimes we’re more deliberately leaving things for the AI to interpret. And there’s job security, which I’m setting aside here: that’s a different point, and perhaps a much more important one. They’re all valid concerns, but this piece is about craft specifically.
In an ideal world, where you have all the resources and time, it’s fair to say that using AI could lead to lower quality. Is that, however, the right question to ask?
Losing the craft
When you use AI to design or to develop, you use prompts. Almost by definition, you don’t make all of your decisions explicit; you don’t explicitly place all the buttons, pick all the colours, etc. That is, in my opinion, the main mechanism through which we could lose the craft: when we get the AI to do the stuff for us, and so don’t take the time to sweat the details ourselves.
Were we sweating the details anyway?
In the real world, things are a bit more complicated. Even before AI, there were many, many situations (perhaps most) where we didn’t really sweat the details, mostly because we didn’t have the time or the resources to do so.
Think of a component library downloaded from the internet and used as it comes, without much thought about whether it fits the product, or an animation library left with its defaults. When a product needs to ship quickly, these shortcuts are perfectly sensible, but nobody would call them craft. We were already doing this, long before AI was in our toolset.
An example: animation
Animation is quite important for UI. It can effectively guide the user’s attention, and it’s also a way to make the UI feel more organic, more natural. A bunch of pixels flicking on and off the screen is not the most organic experience you can get. Animation mitigates some of that by mimicking aspects of the real world.
Most product designers have a basic understanding of animation. They’re not specialists, but they know some principles.
One of those principles is the use of easing curves (opens in a new tab). In nature, very few things move linearly: there’s friction, there’s inertia, and organic beings don’t act in a linear fashion. Think about opening a drawer. You probably start relatively slowly as you grab the handle and begin pulling, then you accelerate, and then you slow down to stop at the right point. If we animated an interaction linearly, it would come across as unnatural; easing curves recreate that physicality.
Take a dropdown menu. You click it, and it fades or slides in (or both). Which curve should it use? The principle here is to use an ease-out curve, which starts fast and then slows down. When you open a dropdown, you’re looking at what you’re clicking, so your attention is right there. If anything comes across as slow, the whole UI will probably feel slow. That’s why you avoid an ease-in here (it starts slowly), and use an ease-out to make the UI feel snappy and responsive. Do read Emil Kowalski’s much better explanation (opens in a new tab) (alongside more practical animation tips).
This is one principle I know of, but there are many that I don’t.
A skill for that
If I’m designing or building a UI, I won’t be able to think of all the right animation principles. There are, however, specialists. I just mentioned Emil Kowalski, a design engineer known for his attention to detail in animation. He has an animation course for UI designers (opens in a new tab) but, crucially for this piece, he has also put together a set of AI skills (opens in a new tab) that codify these animation principles, so they can give an LLM good guidance on animation.
The LLM will (of course) have its own knowledge about animation, having been trained on real-world data, which includes plenty of bad examples. The skill circumvents that by being explicit about the principles the LLM should follow when implementing or reviewing.
For a different example, let’s consider the dreaded AI aesthetic. Impeccable (opens in a new tab) is a set of skills that (among other things) guides an LLM to detect and remove AI slop (opens in a new tab).
I’ve been using these skills extensively, with great results.
Now, back to the animation example: would a UI designer who specialises in motion do a better job? I’m fairly sure they would. Would I, on my own, with enough time, do something better? If I had the time to explore, research and experiment, I could probably get good results too. Most days, though, I don’t have it. Relying on knowledge codified by others, in a way an LLM can interpret and implement, raises the bar for what I deliver.
The catch(es)
Yes, there’s a risk that a designer will go and generate a lot of slop, or rely on the AI without understanding what it’s doing. That’s why the designer needs to stay aware of it, and learn from it. Then again, it’s not so different from the animation library left on its defaults. What’s new is the scale and (lack of) friction.
Which raises another point: who checks the AI? We’ve always had this problem with that component library downloaded from the internet: how would a designer know if it’s the right choice? A good design system helps, but the designer still needs to understand the problem. The same goes for the easing example above: you can only tell the skill did the right thing if you understand why an ease-out works there.
Then there’s sameness: a model (left to its own devices) tends towards the average of what it was trained on. Codified, opinionated guidance pushes against that: it’s explicit about what good looks like, and it can also codify what AI slop looks like, so we can try and avoid it. Emil’s skills include one that removes the animations an app doesn’t need (a fade-in on every section, for instance), and there are similar skills for writing, which flag the patterns that make text read as machine-generated (opens in a new tab).
What we should be doing
It’s difficult to know what’s going to change, how we’ll be working in future, or how much of it will be a win or a loss. What is fair to say is that AI isn’t going back in the bottle. We’re not going back to our old ways of working and, even if you prefer them, I find it hard to imagine we’ll get them back. Resisting the change is like standing in front of a moving train.
With that in mind, as leaders and as practitioners, we have a duty to work with our teams and support them, but also to make sure we take the best advantage of this new technology, to work better than we did before. For me, that means encoding specialist knowledge once (in design systems, AI skills and agents), so that every designer and every agent works to a good baseline. At Dialpad, for instance, we use AI skills to make sure the right components are used for specific scenarios (and anti-patterns are avoided); see the guidance for AI agents (opens in a new tab) we wrote for our slider. It also means coaching designers to understand what the AI changed, and be critical of it, rather than just accept it.
There are also gaps in our knowledge. In an ideal world, we’d be filling them by learning, but, again, we just don’t have the time. If I have a tool that gets the basics right in things like animation, that’s a win. If I have a tool that can check what I did animation-wise, that’s a win too. That’s what I think we should aim for: keeping the craft, making sure the fundamentals still hold (they don’t change), but embracing the technology, because everything else does.
The fair comparison
In the real world, we often don’t have a motion specialist on our teams, and we often don’t have all the time in the world. The question of whether or not a designer would do a better job than the AI is, I think, a slightly academic one. The real question we should be asking is: given our resources, our time and our constraints, would an AI-assisted designer produce a higher level of craft than a designer who isn’t assisted by AI?
We could probably do better than the AI on our own. But with our backlogs, our tight deadlines and our lack of resources, the comparison that matters is AI-assisted vs not.
Next · 02Design × engineering collaboration