AI is not the designer
You decide, you choose, and you cut. AI is good at making a lot, quickly. It is worse at knowing what should go, what people should feel, and what is true for this particular project.
It connects to what I have written about curating. The job is to lift what matters. A model with a free rein would rather add more.
Start in the tool you already know
For most designers, that is Figma.
There, AI can help with small jobs and large ones: suggestions for directions, finding components, tidying layers and working with images. Figma Make takes an idea or a sketch you already have and turns it into something you can click: a prototype, or a simple web app. You can point at a part of the screen and say what should change.
Some of this moves towards code. Figma will let you adjust the appearance and send the change on, including in Make. Parts of that connection are new, and not everything is mature yet. The advantage is that you stay in a visual tool. The disadvantage is that a suggestion can look finished before the idea is good.
Use it to try, not to decide.
When design and code should stay together
Some newer tools exist because code is now written so fast that the design gets left behind.
Elyx makes the design file itself the source. The files stay with you, in a format both people and AI assistants can read, with components, variants and variables. The idea is that the design should not become a static sketch that the code drifts away from. It is made for designers, and also for close work with developers. Treat it as a direction worth watching, not something you have to switch to tomorrow.
Paper is a canvas built on the web's own languages, HTML and CSS. An assistant can read and change the file, and the design can become code without being drawn again. It fits when you are making interfaces that will live on the web, and it also pulls you closer to the developer's desk. If you are looking for an identity, a mood or a logo, Paper is the wrong place to start.
pen.dev, formerly Pencil, sits even closer to the code. The design file can live beside the project. You draw, you ask for code, and you can bring existing components back to the canvas. That is useful when the screen and the implementation should be updated together, and it is more developer-oriented than Figma. A handsome screen assembled quickly is not the same as a considered product. The taste is still yours.
What fits what
What fits what?
Figma — when you explore, build a system and work visually with other people.
Figma Make — when you want to feel an idea as something you can use, not only look at.
Elyx — when the design file should be something both you and an assistant can build on.
Paper and pen.dev — when the screen should become code, and come back again.
None of them decide how something should feel. A brand is more than a logo, and good design should last.
What you gain
You get to more drafts, faster, and you can put most of them away.
The heavy work gets lighter: states, sizes, empty screens and small adjustments.
You can test a direction before you fall in love with it.
Design and code stay closer, so less is lost in the handoff.
The text in the interface can also get a first draft. Rewrite it afterwards, so it is clear and precise, not generic.
What you have to watch
The first draft often looks like something you have seen before. It is an average.
A finished surface can hide a thin idea.
Some tools pull you into code before you know what you are solving.
The features keep changing, and several of them cost money or credits.
Do not paste in anything you do not want to share. A client's content, strategy and personal data do not belong in a random window.
Keep what only you can do
Start with the questions. Who is it for? What should they be able to trust? What is true? What should go?
Ask for ten directions, and choose one. Ask for tidying, not for the feeling. Look at the result with a person's eye. Does it feel calm, clear and credible?
Feelings are not a layer you add at the end. If the solution creates unease, or feels indifferent, it does not help that it was made quickly.
I have played with AI images and with impulses, and that is a good way to train the eye. In a project the order is the opposite: first the meaning, then the tool.
In short
Use AI where it is strong: volume, variants, a first attempt, and the connection to code. Take responsibility yourself for what it is weak at: taste, priority, trust, and what should feel true. Then the quality rises, not only the speed.
The tools change quickly. Check what actually exists in your account before you plan the work around a feature that arrived last week.