Prototyping interfaces

Prototyping is an essential part of building a great interface because it allows you to actually touch and feel the interface, see how it feels in different states and scenarios and iterate on it until you find the perfect solution.

That’s why building actual variants of a flow or component is way better than drawing wireframes or mockups. You can experience the thing instead of just imagining how it would feel.

And don’t get me wrong, you should still explore design directions in a design tool, but your goal should be to move to a living interface as soon as possible. That’s where ideas get validated.

You can experience it yourself, what gives you a better idea of whether this UI works or not? A static wireframe, or a live interface?

Before AI, building out a few different options was often a very time-consuming process. A process that in some cases couldn’t be done to the extent you would want it to be, or maybe even not at all. Code was the expensive part.

But now that code is becoming cheaper to produce, you can spend some tokens on prototyping to improve the outcome of your work.

However, just asking the agent to create a few different types of the sign-up flow for example might not always be the best way to go. There are things you should do, and things you shouldn’t. This lesson is about how you should approach prototyping with AI.

In the exploration phase of your project or feature.

That is when you have a rough description of what you want to build, but you are not sure of the exact details of how it should happen or how it should look.

You can then use that rough description to ask your agent for a few prototypes. You most likely have a few different ideas of what a flow should look like. Describe them to an agent and let it build them for you so you can see how they feel and compare them.

Here’s how I would approach prototyping a new onboarding flow:

Here’s what came back when I used the /emil-prototype skill you’ll learn about soon. Same questions in all three, three different answers to how you get through them:

I couldn’t have told you which one I wanted before seeing them. You need to interact with the material to know, to experience its texture and feel.

A good prototyping flow you build with your agent should do a few things:

• It builds three to five genuinely different directions, that’s the whole idea of prototyping, trying different solutions to the same problem.
• It renders a switcher so you can go through the different variants.
• It pulls in other skills while it builds. Prototyping a type treatment loads /emil-typography, a card loads /emil-surfaces, an enter animation loads /emil-animations. You want to reject a direction because it doesn’t work, not because it doesn’t look good.
• It saves the selected version via query parameters so you can easily share it with teammates.

You could write all this down in a prompt each time you need a prototype, but I’ve written this and some more detailed instructions in the /emil-prototype skill so you can focus on the things that matter most.

npx @aiforui/install emil-prototype --token=…

There’s also a prototype skill in my public skills library. The difference is that the skill here also points to other skills from aiforui like /emil-typography and /emil-animations so they get pulled in automatically to ensure that the prototype is built with the right general advice.

With it, you can simply go for a prompt like this:

In the latter stages of a prototype you want to get the details right.

Whether it’s a drag interaction or an intro animation, it’s often something that needs fine-tuning and the way I like to do it is via control panels.

By binding a variable like Offset X to a slider you can immediately try different variations of an interaction by simply dragging it. This shortens the feedback loop and allows you to iterate on the interaction much faster.

This can be done pretty quickly with tools like DialKit which supports binding variables to sliders, color pickers, or even spring and bezier curves.

Here’s the dithered Linear logo we made a while back at Linear. Move your cursor over it, click it a few times, then open the controls and try different values:

When I was building it, I intentionally shared a preview link with the controls so everyone can tweak them and try their own variations. That’s great advice in general: share as much as possible, as often as possible with your team to get their feedback.

Instead of tens of Slack messages, everyone can tweak the values themselves, and share the configuration with me if they end up with something they like. This way it’s also easier for people to participate, because you lower the barrier to entry, and it’s just fun to play with.

This was the main reason why people on X loved it so much. Because everyone on the team could contribute to the design process, it wasn’t just a back and forth between the designer and an engineer. Everyone on the team (that we thought was a good fit for giving feedback here) was able to participate.

Emil Kowalski @emilkowalski

Made this interaction of Linear’s dithered logo for our latest release.It’s using canvas with a lot of tiny dots. There’s an invisible circle around the cursor.Any dot inside it gets pushed outward with a cubic falloff so it’s gentle on the edges, and strong at the center.

Mar 25, 2026

I almost text you yesterday when I saw this. Awesome stuff as always, Emil.

The bounce after the click is such a nice easter egg!

So many great decisions to get it this level of craft

A few comments from the thread.

Here’s another one, a pixel board by Glenn for index.how that we iterated on. Click it to play the entrance again, and open the controls to change the shape, glow, and more:

If the content is dynamic, based on user data, make sure you test with the worst-case scenario. Long user names, two-line titles, forty rows. It’s much better to find out that something might break during prototyping than in production.

This example is obviously exaggerated, but it’s good to keep this in mind.

• Build the thing instead of drawing it. A live interface gives you much more insight than a static wireframe.
• Use the /emil-prototype skill to follow the rules laid out in this lesson automatically.
• Bind the details to a control panel for a shorter feedback loop.
• Test with your worst content. Long names, two-line titles, forty rows. Finding out it breaks during prototyping is better than finding out in production.
• Share as much as possible, as often as possible with your team to get their feedback.

Again, all of this is packaged into the /emil-prototype skill. If you installed the skills using the general install command, you don’t have to install it again.

npx @aiforui/install emil-prototype --token=…