For years, my work as a Product Designer followed a familiar pattern. I started with Sketch, where we built libraries, reusable components and common patterns so the whole team could work consistently. Then we moved to Figma for better collaboration, prototyping and newer capabilities.

Of course, migrating was not as simple as clicking “Move everything to Figma.” Some components had to be rebuilt, libraries needed restructuring, and a few prototypes didn’t behave the way we expected. So once again, I found myself setting up the base layouts, components and design system for the team. Apparently, no matter which tool we move to, I somehow end up building the library. 😅

After that, Figma became part of our everyday workflow. We created screens, prototypes, interactions and animations, but the real work was never just drawing interfaces. Every feature involved discussions with PMs, multiple UX approaches, technical constraints, edge cases and several rounds of iteration. Sometimes a feature could take weeks or even months before we reached the final flow.

That is one interesting thing about product design. Users may finally see five clean screens, but they never see the 40 or 50 screens we explored, discussed and deleted to get there.

Then AI started changing the way we worked.

Suddenly, design exploration became much faster. With tools like Claude Design, we could describe an idea and see multiple UI directions within minutes. Something that previously took hours or days to explore could now happen much faster. Since I’m usually the person trying new tools and checking whether they can fit into our actual workflow, I started experimenting with AI too.

And then something very familiar happened.

I started building the design system there as well.

At this point, maybe my career is secretly just me moving from one tool to another and rebuilding the same design system. 😅

But there is a reason for that. AI can generate almost anything, and that is both its strength and its problem. Our product doesn’t need “anything.” It needs something that belongs to our product, follows our patterns and makes sense for our users.

AI can now create screens very quickly. I can explain a feature, generate different approaches and sometimes even get ideas I may not have considered initially. But that doesn’t mean I simply accept whatever it creates. I still have to decide whether the flow solves the actual problem, whether users will understand it, whether it matches our existing product, and what happens in error states, empty states, permissions, accessibility and edge cases.

That made me think about one question that comes up often now:

Can anyone design with AI?

In one sense, yes.

A PM can describe an idea and visualize it. A developer can quickly explore a possible interaction. Someone who has never used Figma can still generate a good-looking screen with a prompt. And I actually think that is a good thing because design becomes easier to communicate.

But generating a screen and designing a product are still two different things.

AI may give you ten beautiful layouts, but UX knowledge helps you decide which one actually solves the problem. A screen can look great and still create a bad experience. A button can look perfect but appear at the wrong moment. A flow can look simple while creating more confusion for the user.

So will AI replace designers?

My answer is: maybe, maybe not.

I have seen designers work with Photoshop, Sketch, Figma and now AI-powered tools. Every new tool changes how we work. The bigger risk is probably not AI replacing designers, but designers refusing to adapt while the workflow changes around them.

I think the designer’s role will continue to shift. We may spend less time manually creating every screen and more time understanding problems, directing AI, validating ideas, building systems and making product decisions. Execution will become faster, but judgement will become even more important.

Because faster design does not automatically mean better design.

Sometimes it just means we can make the wrong decision faster.

When I look back, the tools I use have changed a lot. Sketch became Figma. Manual exploration became AI-assisted exploration. Work that once took days can sometimes happen in hours.

But strangely, some things have not changed at all.

I still end up creating the base. I still build the library. I still think about consistency. I still question whether the flow actually makes sense. I still try to make things easier for the entire team to reuse.

So maybe the lesson is not to become attached to a particular tool.

Be attached to learning.

Tools will keep changing. Workflows will keep changing. Anyone may soon be able to generate an interface with a simple prompt.

But understanding what should be built, why it should be built and how it should work for real users will continue to matter.

And apparently, whatever tool comes next, I’ll probably end up building the design system there too. 😅

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation.
LinkedIn | Instagram | Twitter

AI Changed How I Design. It Didn’t Replace Why I Design. was originally published in Muzli - Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have reviewed hundreds of product design portfolios, run dozens of hiring cycles across traditional banking and crypto products, and made my share of hiring mistakes. Here is what I actually look at, what kills a candidacy in the first five minutes, and the one question that separates candidates worth hiring from candidates worth encouraging to apply elsewhere.

Let me be honest about how this actually starts

When I open a portfolio for the first time, I am not reading. I am scanning. In the first 90 seconds I am asking three things almost simultaneously: does this person work in products that are similar to what I am building? Does the quality of their presentation reflect the quality I need on the team? And do I see any evidence of real decision-making, or just final screens?

Most portfolios fail the third question. Not because the work is bad. Because the case studies are written as a highlight reel of great outcomes, and I have no way to evaluate the thinking that produced them. A beautiful final screen tells me someone was involved in something that looked good. A case study that shows me a wrong turn they took at week two, the stakeholder who pushed back on the direction, and the data that proved them right or wrong — that tells me I am looking at a designer who actually does the work.

“A portfolio of 40 beautiful screens with no explanation of problems, users, or decisions is the single most common reason strong designers do not get interviews. Hiring managers look for decision quality. Strong portfolios expose the structure behind decisions: what options existed, what constraints applied, what trade-offs were accepted.”

UX PLANET, WHY GOOD UX PORTFOLIOS NEVER GET INTERVIEWS, 2026

So before I walk you through my full process, the one thing to understand about how I review portfolios is this: I am reading for judgment, not craft. Craft is important and visible in three seconds. Judgment takes work to demonstrate, and most portfolios do not do that work.

What I look for in the first 90 seconds

The opening of a portfolio does more work than most candidates realise. It sets up the mental frame I use to read everything that follows. When a portfolio opens with a clean hero section that tells me the domain (fintech, crypto, B2B SaaS), the level of ownership (lead designer, IC, director), and the most significant outcome of their career so far, I relax. Someone in control of their own narrative is usually in control of their design process too.

When a portfolio opens with a generic “I make beautiful and functional experiences” headline, followed by six identical card-format case studies in a perfect grid, I am already slightly skeptical. Not because it looks wrong, but because it tells me the designer treated their portfolio as a presentation template rather than a product. And in my experience, designers who see their own portfolio as a template tend to approach user problems the same way.

➡️ The five seconds that count most: Your opening screen needs to answer three questions before the reader scrolls. What kind of designer are you? What kind of problems do you solve? And why should I read on? If the answer to any of those three requires me to scroll, I will probably not scroll.

What makes a case study worth reading

I am going to be direct here, because I think a lot of advice about portfolio case studies is too polite to be useful. The case study format that every design education program teaches — problem, research, ideation, solution, results — is not a bad framework. It is just so widely used that it has become invisible to hiring managers. When every case study follows the same arc, none of them communicate anything distinctive about the designer who made them.

What I am actually looking for in a case study is the messy parts. The moment the user research contradicted what the product manager thought they knew. The design direction that was clearly the right choice but that required three rounds of stakeholder negotiation to approve. The feature that was cut from the scope and why that was actually the right decision. The metric that went up and the one that went down as a result of the same change.

“Show me the constraints and the trade-offs. Anyone can show me the final screen. Not everyone can explain why the feature to the left of it was cut from the design.”

The depth I am looking for is not about word count. A 400-word case study that answers those questions is more valuable than a 2,000-word case study that describes a perfectly linear process from research to shipping. Because perfectly linear design processes do not exist. If your case study reads like one, I know the real story is somewhere between the slides.

➡️ What a case study actually needs: The problem as the user experienced it, not as the brief defined it. A constraint that shaped the solution in a meaningful way. At least one decision point where you chose between two real options and can explain why. A result that is specific enough to be meaningful, even if it is qualitative. The whole thing should answer:
“What changed because this designer was on this project?”

The red flags that end a candidacy

These are the specific things that stop my review. I am not listing them to be harsh. I am listing them because they are genuinely common and genuinely fixable, and I would rather a good designer know what they are doing than lose an opportunity they deserved to get.

🚩 Only showing final screens

When a case study is a sequence of beautiful final screens with no process documentation, I cannot evaluate your thinking at all. I can only evaluate the outcome, and outcomes in product design are almost never the work of one designer. Show me the wireframes, the rejected direction, the version that did not make it to production.

🚩 Cookie-cutter structure that reads as a template

I can identify the most common portfolio website templates in about two seconds. When I see the same visual structure I have seen in sixty other portfolios, it signals that the designer invested less effort in how they present their thinking than in how their work looks. The presentation is itself a design problem. Treat it like one.

🚩 Impact metrics that are too round or too vague

“Increased engagement by 40%” with no context about what engagement means, what the baseline was, or what timeframe this covers tells me less than you think. I am not asking for an audit trail. I am asking for enough specificity to distinguish a real outcome from a number that sounded good in a debrief.

🚩 Research sections with no artifacts

Listing “user interviews, usability testing, affinity mapping, competitive analysis” is process vocabulary, not evidence. Show me a photo of the whiteboard, a synthesised insight, a quote from a user session, a pattern you identified. If the research section does not contain any artifacts from the research, I cannot tell whether the research actually happened.

🚩 Concept work presented as shipped product

I always check whether the work in a portfolio was actually shipped. Concept work and speculative redesigns are not inherently bad, but they need to be labelled as such. When I find out during an interview that the “case study” was a design challenge for a bootcamp application rather than a real shipped feature, it damages trust in everything else in the portfolio.

🚩 Portfolio link not findable from LinkedIn

Small thing, real consequence. If your portfolio URL is not in your LinkedIn header and Featured section, a significant percentage of hiring managers never see it. The portfolio URL is the product. Putting it where people cannot find it is not a great first signal about your instinct for distribution.

🚩 Work that is three or four years old presented as current

This matters more than it used to. In 2025 and 2026, the tools, the workflows, and the expectations around AI-assisted design have shifted significantly. A portfolio that has not been updated in three years signals either that the designer has not shipped anything in that time, or that they have not prioritised keeping their professional narrative current. Both are worth asking about.

What makes me move someone to the interview stage immediately

✅ A case study that shows what they were wrong about

The fastest way to demonstrate genuine design experience is to show me a moment where your initial direction was wrong and you know why. Designers who can articulate what they got wrong and what changed their mind are designers I can trust to learn on my team.

✅ Visible thinking about constraints, not just outcomes

When a case study says “we wanted to do X, but we had Y constraint, so we did Z instead, and here is why that was actually a better decision,” I am reading work that demonstrates how a designer operates in real conditions. Constraints are the context that make design decisions meaningful.

✅ Evidence of working across the full product lifecycle

Discovery, definition, execution, and post-launch measurement all in the same case study. Not because every designer should own all of it, but because a designer who has experienced the full cycle thinks differently about each phase. They know which early decision creates the problem they will be fixing in month four.

✅ Cross-functional context that shows how they operate

A line like “the engineer pushed back on this direction and here is how we resolved it” tells me more about how someone will work on my team than any visual in the portfolio. Design is a team sport. I need designers who know how to navigate that.

✅ Domain specificity that matches the problem we are solving

When I am hiring for a fintech or crypto product, a portfolio with financial product experience reads differently. Not because I exclude designers who have not worked in finance, but because someone who has already wrestled with the specific constraints of financial UX, trust signaling in payments, regulatory design requirements, or crypto mental models brings a context that shortens the ramp-up significantly.

The specific extra requirements when hiring for fintech and crypto

(WHEN THE ROLE IS FINTECH OR CRYPTO)

• ➡️ How do they handle error states in payment flows? Fintech punishes unclear error states more than most product categories because the emotional stakes of a failed payment are high. I look for case studies where error handling was treated as a design problem, not an engineering footnote.
• ➡️ Do they understand that compliance is a design constraint, not an obstacle? KYC flows, AML disclosures, consent mechanisms: a designer who sees these as friction to minimise is not the same as a designer who understands how to make a mandatory disclosure feel like a helpful moment. That difference matters in every regulated product.
• ➡️ How do they think about trust signals? In a payment or crypto product, every micro-interaction either builds or erodes trust. A candidate who can talk about specific design decisions they made to reduce financial anxiety tells me they have thought about this dimension of the product.
• ➡️ Have they worked at the intersection of simplicity and technical complexity? Crypto UX specifically requires designers who can make technically complex concepts feel navigable without hiding the complexity that users need to understand to stay safe. Abstracting gas fees or seed phrases without appropriate context creates real harm. I look for evidence that a candidate has engaged seriously with this tension.
• ➡️ Do they understand the difference between user trust and business trust? In fintech, the design has to earn trust from two parties simultaneously: the user and the regulators or business partners. A candidate who has thought about both sides of that is significantly more ready for the role than one who has only thought about the user.

My hiring process, step by step

1️⃣ Portfolio review (15 minutes, no exceptions)

I cap my initial portfolio review at 15 minutes per candidate. This is not because I am cutting corners. It is because a portfolio that requires more than 15 minutes to make its case is a portfolio that is asking me to do work the designer should have done. If I have not formed a clear impression in that time, the portfolio has failed on its own terms.

2️⃣ Intro call (30 minutes, agenda-first)

I send candidates a two-question agenda before the intro call: which case study in your portfolio best represents how you work, and what is something that is not in your portfolio that you are proud of? The first question tells me how they prioritise their own work. The second tells me something that polish and presentation cannot hide.

3️⃣ Portfolio walkthrough (60 minutes, candidate-led)

The candidate walks me through one case study end to end. Not from the slide deck. From memory, in their own words, with me asking questions anywhere I want to go deeper. This is where the portfolio either holds up or falls apart. Candidates who genuinely did the work can take you anywhere in the project. Candidates who assembled a portfolio around work they were peripheral to start running out of answers around the third question.

4️⃣ Design challenge or team session (context-dependent)

For senior roles, I prefer a paid short challenge over a take-home. For lead roles, I prefer a collaborative working session with the team. The goal is not to test craft. I already have a view on craft from the portfolio. The goal is to see how they work when the brief is ambiguous, when they have to ask questions instead of answer them, and how they respond to feedback mid-process.

5️⃣ Reference conversations (always, never optional)

I always speak to at least one person who managed the candidate and one person the candidate worked with as a peer. The manager reference tells me about output and delivery. The peer reference tells me about collaboration and what it is actually like to work alongside them. Both are necessary. I ask both the same question: “Is there a type of problem or working dynamic where this person is noticeably less effective?”

The one question that reveals almost everything!!

Every stage of my hiring process is designed to get to this question eventually, because the answer tells me more about a candidate than everything else combined. I ask it during the portfolio walkthrough, after the candidate has walked me through a case study they are proud of:

A candidate who says “honestly, I would not change much, I think we made the right calls” is telling me that their mental model of this project is complete and settled. That is not a design mindset. A candidate who says “we got the core interaction right but I think we underinvested in the error states, and here is specifically what I would do differently” is showing me a designer who stayed engaged with the problem after they shipped it, which is exactly the kind of designer I want on my team.

➡️ Why this question works: Growth requires a clear view of the gap between what you did and what you could have done. A designer who cannot articulate that gap about their own work is a designer who is unlikely to get sharper on the next project. The answer to this question is the closest thing I have found to a reliable signal of long-term performance growth, as distinct from current performance quality.

What I tell candidates who did not get the role?

This section matters to me because I think the hiring process in design has a transparency problem. Candidates invest real time in applications and interviews and often get nothing back. I always give specific feedback to candidates who made it to the interview stage, because it is the right thing to do and because the design community is small enough that the person I turned down today might be the person I collaborate with in three years.

The most common feedback I give is not about craft. It is about the gap between what the portfolio presents and what the interview reveals. When a candidate can talk about their work at twice the depth during the conversation compared to what the portfolio communicated, the portfolio is failing them. The goal of the portfolio is not to show me your best work. It is to start a conversation about your best thinking, and the best portfolios do that from the first screen.

💡 One more thing: I hired someone once specifically because their portfolio had a section labelled “what did not work.” Four case studies of directions they explored that were rejected or failed, with an honest analysis of why. Nobody does that. It was the most interesting thing I had seen in a portfolio in years, and it told me immediately that I was looking at someone who learns from failure rather than hiding it. They turned out to be one of the best designers I have worked with. The portfolio told me exactly who they were.

🔵 About Mostafa Esmaeili

Product Design Director · FinTech, Banking & Crypto UX

I design and lead design for financial products, neobanks, crypto wallets, and everything in between. +10 years in, I still think the most interesting design problems in the world live at the intersection of money, trust, and the people who move both. I write about what I actually do, not what the textbooks say I should.

*️⃣ I publish MONEY DESIGN, a newsletter about fintech and crypto UX, for people who build financial products seriously.

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation.
LinkedIn | Instagram | Twitter

MONEY DESIGN Podcast · MONEY DESIGN Newsletter
Portfolio · Medium · LinkedIn

How I Hire Product Designers: What 10 Years of Reviewing Portfolios Taught Me About Great… was originally published in Muzli - Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.

Product design with AI: building it was never the hard part

I have been having a lot of fun building my own applications using AI lately. An iOS app, a few small web apps that run locally, a few half-finished things, mostly so I can learn a new way of working.

And honestly, it is exciting. Building an application is so easy now, and adding features is even easier, especially for someone like me who doesn’t come from a development background.

One of them is a small design inspiration library I made for myself, somewhere to keep design references and design systems together. I’ll write about the thing itself separately. I built it the way I build most things now: ideate the feature with AI, then build it. Amending and adding features followed the same way.

But I realised the more I added, the more the usability quietly slipped. It kept gaining features, but they started to feel bolted onto each other.

The part that was missing was small and everywhere

The library mainly does one thing: I paste in a link to a website I like, and AI analyses it and adds it to my collection.

The first version worked. But when I pasted a link, nothing told me it was being processed, so I’d sit there wondering if anything was happening. Or removing a reference gave no clear sign it had gone until I refresh the application.

Nothing was broken. It was just short of the details that make an experience good, and that is where I had to put the designer hat back on.

So once a chunk of features was in and working, I’d use it myself, walk each flow slowly, and log every point where I knew something was missing. A confirmation here. A processing state there. Then I’d feed those notes back in as second, smaller sessions.

I think that part makes the whole difference. AI will do 70–80% of the work, very fast. The last 20–30% is what takes it from working to good, and it often takes 70–80% of my time.

The bug I would happily have lived with

Then there’s what changes the moment you hand something to someone else.

When a thing is only for me, I’ll live with a small bug quite happily. For example, in another tool I made for reviewing images, if I select an option, press enter, then go back twice, my answer doesn’t save. I know exactly how to trigger it, a bit like knowing a key combination in an old fighting game, and because I know how to trigger it, it was never a surprise. So I didn’t feel the need to fix it, just for me.

But I was going to share this one with my colleagues, and they might accidentally trigger that same bug. A surprise like that hurts their experience with the app, and not in a good way. Fortunately, unfortunately, I realised it had to go.

My own QA has quietly tightened because of that. I walk each journey more slowly than I used to, and in more detail, because someone else will walk it without knowing where the soft spots are. That feels like a real part of the difference between something I built and something I can hand over.

Knowing when to stop adding things

The other thing I’m still learning is restraint.

It’s so easy to slap on another feature now. Another button, another toggle, another filter, another dropdown. Not because it’s needed, but because why not, it might be useful one day. I catch myself doing it constantly.

But if an application exists for a purpose, it should do that one thing well, and a new feature should be there to enhance the tool. Gimmicky ones muddy the water. You drift away from what the thing was for and end up with something that does everything mediocrely.

I’ve watched a version of this often. People keep adding to something genuinely promising without much thought for how anyone else would use it, until only they can navigate it. If it were handed to me, I don’t think I could use it, not because it can’t do enough, but because it was only ever shaped around one person.

So some of this is knowing what the goal is, and which features actually serve it. And some of it, I think, is knowing when to stop and release the thing, so the next round of improvements can come from people actually using it.

Where I’ve landed, for now

This comes back to something I wrote about before, that making things got easy and making good things got harder. Anyone can build an application, and anyone can add features to one. Whether someone else can use it is a separate question, and a much harder one.

The small details are design work. But deciding what to build, and when to stop, comes before them, so I think this whole thing is really a product question before it’s a design one. What is this actually for. What does it need to do. Do I really need this feature, or did I just enjoy how quickly I could build it. Who is using this, and does it make sense to them, not only to me.

You see a lot of people sharing what they built with AI, and the UI looks nice. Making it look nice honestly isn’t the difficult part. If I put myself in the shoes of a recruiter or a design lead, I don’t think I’d ask whether someone can build an app with AI, because almost anyone can now. I’d want to know whether they’ve built something other people can use, and what they did to make it usable.

The more I build with AI, the more it comes back to fairly basic product thinking. I’m only looking at it from one seat, though.

Thank you for reading this far. I’d genuinely like to know if this matches what you’ve seen too, or if I’m missing something.

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation.
LinkedIn | Instagram | Twitter

Product design with AI: Building It Was Never the Hard Part was originally published in Muzli - Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.

As product designers, we have traditionally focused on designing experiences for people. We conduct user research, map user journeys, simplify information architecture, and try to create interfaces that are accessible, understandable, and easy to use.

But that assumption is starting to change. AI systems are moving beyond simply giving us information; agents are beginning to research on our behalf, make reservations, complete forms, and in some cases even carry out real transactions.

This raises a new question for designers:

How do we design a product that can be used both by a person and by an agent acting on their behalf?

In this article, I want to focus a little more on that second user: the agent. What does an agent need in order to use a product? Which capabilities should a system expose to it, where should the boundaries be, and how might approaches such as WebMCP change this relationship?

The Way Agents Use the Web Is Changing

Agents using the web is not a new idea. Over the past few years, systems such as OpenAI Operator, Anthropic Computer Use, and Microsoft Copilot have interacted with websites in much the same way we do: by looking at the screen, finding elements, clicking, scrolling, and filling in forms.

For example, when OpenAI introduced Operator in 2025, it could analyse screenshots and interact with websites using a virtual mouse and keyboard. A website did not need to be specially rebuilt for an agent; if a person could use the interface, then theoretically the agent could use the same interface too.

But this approach can be fragile. The agent has to reinterpret what is on the screen at every step. If the interface changes, an unexpected popup appears, or a form behaves differently, the flow can break.

A Website Could Offer One Layer to People and Another to Agents

Approaches such as WebMCP introduce a different model.

Instead of only showing an agent what appears on the screen, a website can directly expose what the system is capable of doing.

For example, on a hotel website, a person might still see a date picker, filters, hotel cards, and a “Book” button.

For an agent, the same actions could instead be exposed through structured functions such as:

search_location()
check_availability()
start_booking()
complete_booking()

In other words, the agent may no longer need to interpret the interface first and then locate the “Book” action. The system can expose the capabilities it is allowed to use directly.

This does not mean the agent gets access to the website’s entire codebase. The site owner defines which capabilities are available to the agent and under which conditions they can be used.

The difference can be simplified like this:

Web agent: “Which action should I find on this screen?”

Agent-native web: “Which actions does this system expose for me to use directly?”

So What Does a Good Experience for an Agent Look Like?

When designing a good experience for people, we think about whether the right action is easy to find, whether the system provides enough feedback, and what happens after an error.

Agents have similar needs, but those needs do not necessarily have to be represented through a visual interface.

An agent needs to understand what the system can do, what state it is in, how to continue when an action fails, and when it should stop.

This is why designing an agent experience may look less like arranging screens and more like designing capabilities and the boundaries around them.

A human journey could roughly be described as:

Goal → touchpoints → actions → decisions → pain points → outcome

For an agent, a similar structure might look more like:

Goal → capabilities → tool calls → decision points → permission / approval → exception → recovery → outcome

Consider a payment system.

An agent might be given access to capabilities such as:

get_balance()
compare_payment_options()
prepare_payment()
execute_payment()
cancel_payment()

But these actions do not carry the same level of risk.

Checking a balance or comparing payment options may be relatively low-risk, while an action such as execute_payment() creates a direct financial consequence and may require a different level of control.

The agent could prepare a payment, verify the amount and recipient, and get everything ready but before actually completing the transaction, it might need explicit user approval.

Previously defined user limits could also shape this behaviour. Lower-value transactions might proceed automatically, while higher-value transactions could pause and return control to the user.

So the design question is no longer simply,

“Can the agent do this?”

Which actions can the agent perform autonomously?
When should human approval be required?
If something is unclear, should the agent continue or hand control back to a person?
Can an incorrect action be reversed?

These are not entirely new design problems. Permissions, error handling, and recovery have always been part of digital product design. But as agents begin taking actions on behalf of users, the impact of those decisions becomes much more visible.

These Questions Are No Longer Just Theoretical

We are already seeing examples of this shift in what different companies are building.

• Mastercard Agent Connect is designed to help businesses expose their products and services to AI agents in a more controlled way. Businesses can manage which agents and platforms are able to access their services, while supporting agent-powered product discovery and purchasing flows.
• Mastercard is also working on the Agent Pay Trust Framework, which focuses on questions such as who an agent is acting for, what the user has actually authorised, and which limits should apply when the agent makes a transaction.
• Visa Trusted Agent Protocol focuses on helping businesses verify whether an AI agent is trusted and genuinely authorised to act on behalf of a user.
• OpenAI Site Tools allows ChatGPT to interact directly with structured actions exposed by WebMCP-enabled websites instead of relying only on the visual interface.
• Cloudflare bringing WebMCP into Browser Run, alongside ongoing developments in the broader MCP ecosystem around authorisation, task management, and interactive applications, points in the same direction.

The Areas We Touch as Product Designers Are Expanding

This shift does not mean product designers suddenly need to write APIs or build agent infrastructure on their own. But the boundaries of design may no longer stop at the interface a user can see.

When designing how agents interact with products, I think three areas in particular will become increasingly important:

Understanding APIs and tools: Being able to understand which capabilities a system exposes to an agent and, at a basic level, how those capabilities work.

Thinking about permissions and risk boundaries: Defining which actions an agent can perform autonomously and where user approval should be required.

Designing states, errors, and recovery: Thinking through what should happen when something fails, when the agent should retry, and when it should return control to a person.

Product design may increasingly overlap with service design, API design, AI product development, and system design.

The designer’s role may not be to write the code, but being part of the team that shapes how the human-agent-product relationship should behave is something I find genuinely exciting.

To sum up,

As agents begin interacting directly with products, they are also changing who we think of as a “user” in product design.

For years, we have asked:

“How will the user use this product?”

Soon, we may need to add another question:

“How will the user’s agent use this product?”

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation.
LinkedIn | Instagram | Twitter

From Interfaces to Protocols: How AI Agents Are Changing the Way They Interact with the Web was originally published in Muzli - Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lately, like many others, I’ve started experimenting more with AI tools in my workflow.

I had heard about Cursor before. I knew it could connect to Figma and read design files, but I had never actually tried it.

So I decided to explore it a bit.

My starting point was a very familiar problem.

If you’ve worked on large products, old design files, or projects that lived for years with multiple designers and even different companies involved, you probably know this situation:

• Colors, typography, radius, spacing are used outside the design system
• Some foundations were never clearly defined
• Components get detached
• Fixing all of this manually in Figma takes days

I’ve experienced this many times.

So instead of testing Cursor on a clean, new project, I opened an old one it was designed 4 or 5 years ago.

The Context

The design library has:

• Colors defined as styles
• Typography defined as styles
• Some component patterns
• A neatly structured page

This was not a scalable design system. It was more like a compact style guide.

And over time, the UI screens slowly drifted away from it.

So my goal became very simple:

Do these UI screens still follow the foundations defined in this old design library?

And if not, how can I detect that quickly?

Preparing the File

To make this test easier, I gathered all the UI screens and the style definitions into the same Figma file.

This way, Cursor could read everything from a single source, which made the process much faster and simpler to manage.

Connecting Cursor to Figma

To allow Cursor to read the Figma file, I created a Personal Access Token from Figma (Settings → Security).

I enabled:

• file_content:read
• file_metadata:read
• library_assets:read
• library_content:read

Then in Cursor:

• Opened settings
• Searched for > MCP
• Added the JSON configuration
• Pasted the Figma token

After saving, I saw:

Installed MCP Server → Figma

Which confirmed the connection was successful.

Since the connection to Figma was now confirmed and Cursor could successfully read the file, I moved on to the actual prompts and started the audit process.

1. Confirming Cursor Can Read the File Structure

Prompt 1;

Here is the Figma file I want you to analyze:

https://www.figma.com/design/….

Using Figma MCP, load this file in read-only mode.

1) Return:

- File name

- File key / URL

- Team / project name (if available)

- Last modified info (if available)

- All page names

2) Search the file structure for sections or frames named:

- “Style Guide”

- “UI Design”

If exact matches are not found, list the closest matches such as:

“Styleguide”, “Design System”, “Styles”, “Screens”, “UI”, etc.

For each match, return:

- Page name

- Section / Frame name

- Node id

Do not modify anything. This is discovery only.

For the first step, I only asked it to load the Figma file and understand its structure.

As shown in the screenshot, Cursor connected to the file through Figma MCP and explored it internally. The line:

Ran add_figma_file: figma
Explored 1 file, 14 searches

confirms that the connection worked and that Cursor searched the file to locate sections like Style Guide and UI Design.

This step was simply to verify that Cursor could read the file correctly and identify where the design foundations and UI screens lived before moving to the actual analysis.

2. Mapping Where the Style Guide and Screens Live

Prompt 2;

List the exact screens and components where the implementation does not follow the style guide.Include frame names.Using the full JSON of this Figma file you just retrieved, Search the entire file structure and find frames or sections that match these names:

- “Style Guide”

- “UI Design”

If exact matches are not found, search for close matches like:

“Styleguide”, “Design System”, “Styles”, “Screens”, “UI”, etc.

For every match you find, return:

- Exact name

- Node id

- Page name

- Parent hierarchy (Page > Frame/Section > Child)

- Type (frame / section / component / group)

Do not summarize. Traverse the full tree.

This second prompt had one goal.

After the first step, Cursor could open the file, but it didn’t know where the Style Guide and the actual UI screens were.

Since Figma MCP reads the file as a node structure, not as visual screens, I had to clearly show it which parts represented the Style Guide and which parts were the real UI.

With this prompt, Cursor scanned the whole file, found those sections, and returned their exact node IDs and hierarchy.

From that moment on, the audit became precise. Cursor was no longer comparing random parts of the file. It was comparing the right sections.

3. Pinpointing the Exact Style Guide and UI Nodes

Prompt 3

You already fetched the full JSON representation of this Figma file.

Now, find the EXACT nodes for:

1) “Style Guide”

2) “UI Design”

Important:

- Search across the full tree (all pages).

- Treat “Style Guide” and “UI Design” as sections/frames (not single layers).

For each one, return ONLY:

- Page name

- Node name (exact)

- Node id

- Parent chain (Page > … > Node)

If you cannot find exact matches, return the TOP 10 closest candidates for each target:

- For Style Guide: names containing “style”, “guide”, “system”, “tokens”

- For UI Design: names containing “ui”, “screen”, “flow”, “pages”

Do not output the entire JSON. Do not write code. Just return the node ids and their locations.

This prompt was about removing any uncertainty.

In the previous step, Cursor had explored the file and suggested possible matches for the Style Guide and UI sections. But suggestions were not enough.

Here, the goal was to confirm the exact nodes.

By asking for the precise node IDs and their location in the hierarchy, I made sure that Cursor was pointing to the real Style Guide and the real UI screens inside the file.

The result was clear:

• Style Guide → node 5502:11125
• UI Design → node 3503:29886

From this point on, every comparison in the audit was based on these two exact nodes, not on assumptions or approximate matches.

4. Extracting the Real Design Foundations from the File

Prompt 4

The JSON tree you saved does not include a top-level “styles” catalog.

Using Figma MCP, fetch the FILE STYLES for this file (paint styles, text styles, effect styles) and return them as JSON, including:

- style id

- style name

- style type

- resolved values (color hex/rgba, typography, effect params)

If the MCP has separate calls for:

- getPaintStyles / getTextStyles / getEffectStyles

or “getLocalStyles”

use them and print the results.

Do not scan nodes yet. First, output the full styles catalog for the file.

At this point I realized something important.
The node tree alone was not enough.

Cursor could see where colors and typography were used, but it had no reference for what the Style Guide actually contained.

So before scanning the UI, I asked Cursor to extract the full styles catalog from the file.

Paint styles, text styles, and effect styles were pulled out with their resolved values.

Only after that could Cursor understand what “allowed” actually meant.

5. Running a Strict Style Compliance Audit

Prompt 5;

Run the full compliance audit (no truncation).

We have:

- Style Guide root node id: 5502:11125

- UI Design root node id: 3503:29886

Use style_id as primary (style_name may be null).

STEP 1 — Build ALLOWED style id sets from Style Guide subtree (5502:11125)

Collect all referenced:

- paint style ids (fills/strokes)

- text style ids

- effect style ids

Deduplicate them and map each allowed style_id to resolved_values using the styles catalog.

STEP 2 — Scan the entire UI Design subtree (3503:29886)

Report ALL violations:

1) Non-allowed style id (style_id not in allowed set)

2) Raw values used (no style id for color/text/effect)

For EACH violation include:

- violation type + category (Color/Text/Effect)

- current used (style_id + resolved_values OR raw values)

- suggested fix (closest allowed style_id by matching resolved_values OR “new style needed”)

- node name + node id + node type

- page name + full parent chain

OUTPUT REQUIREMENTS (IMPORTANT):

- Do NOT truncate.

- Write the FULL violation list to a JSON file named:

figma_style_audit_report.json

- In the chat, print:

A) summary counts by category

B) top 10 frames/screens by violation count (frame name + node id)

C) the file path where you saved figma_style_audit_report.json

D) preview first 20 violations (only as preview)

By this point, Cursor had the full context of the file: where the Style Guide was, where the real UI screens were, and what styles actually existed.

So instead of asking for insights, I asked for a strict compliance check.

Cursor treated the styles used in the Style Guide as the only allowed set, then scanned all UI screens to find anything that didn’t match.

It flagged layers using non-allowed styles, raw values, or mismatched properties and generated a complete violation report as a JSON file, along with a summary of the most problematic screens.

This was the moment the process turned into a true design system audit.

6. Turning the Audit into a Clickable Designer Report

Prompt 6

Open this JSON file:

/Users/gizem/figma_style_audit_report.json

From the full violation list, build a human-readable table with these columns:

1) Page / Screen name

2) Node name

3) Node id

4) Violation type (Color / Text / Effect)

5) Current raw value or wrong style id

6) Suggested Style Guide style id

7) Direct Figma link in this format:

https://www.figma.com/file….

Sort the table by screen (frame) and then by violation type.

Output as a markdown table.

Do not summarize. Output the full table.

Up to this point, Cursor had produced a very detailed JSON audit report. But JSON is not something you can use directly while working in Figma.

So I asked Cursor to transform the raw audit data into a markdown table with direct Figma links.

Each row in the table became a shortcut to the exact element that breaks the design rules. Instead of searching through screens, I could simply click and jump straight to the problem.

This is where the process stopped being a technical analysis and turned into a practical design correction tool.

7. Making the Report Easier to Use in Practice

Prompt 7

Open:

/Users/gizem/figma_style_audit_designer_report.md

and also read the source:

/Users/gizem/figma_style_audit_report.json

Your preview sample is biased (mostly TEXT). Re-generate the preview as a stratified sample.

In chat, print exactly:

- 10 COLOR rows

- 10 TEXT rows

- 5 EFFECT rows

Rules:

- Ensure the rows are actually from those categories.

- Include at least:

- 3 CASE 1 examples (Matches SG value but NOT bound)

- 3 CASE 3 examples (Uses non-SG style)

- The remaining can be CASE 2

If the report does not contain enough CASE 1 or CASE 3, explicitly say how many exist in the full data and show all of them.

Also add a small summary above the samples:

- Total counts by Category (Color/Text/Effect)

- Total counts by Case (Case1/Case2/Case3)

Do not rewrite the whole report, only produce the corrected preview + summary.

At this point, the table was already clickable and practical, but it was still a bit technical to read.

You could see the node, the value, and the suggested fix but you still had to mentally interpret why it was wrong.

So I refined the table structure by adding a few extra columns:

• SG Value (what the Style Guide expects)
• Actual Value (what is used on the screen)
• Style Binding Status (how it relates to the style system)
• Why this is a problem (plain explanation)

Now, instead of reading raw audit data, the table clearly showed three different types of issues:

1. The value is correct, but it’s not connected to a style token
2. The element is connected to a style, but that style is not part of the Style Guide
3. The value itself does not exist in the Style Guide at all

With this structure, the report stopped looking like technical output and started reading like a design diagnosis.

You could glance at a row and immediately understand what went wrong, without decoding style IDs or raw values.

This made it much clearer how different types of design drift appear across the screens.

Most importantly, each row in this table included a direct Figma link. When I clicked a link, Figma opened and zoomed straight into the exact element that was breaking the design rules.

A Real Example From the Report

In the table, one row stood out:

button | fill_color | #18C175 | #1BCA7B | Value not in Style Guide

These two greens are visually almost the same.
But only #18C175 exists in the Style Guide.

#1BCA7B does not belong to the design system at all.

I clicked the Open link in that row.

Figma opened and focused directly on the exact button.

And this is where something very important becomes visible.

On the right panel, under Colors, you don’t see a style name.

You only see:

Hex: #1BCA7B

That means this color is not connected to any color style.

It is just a raw hex value.

So the problem here is not only that the wrong green was used. The problem is that this button color is not connected to the Style Guide at all.

Cross-checking the Style Guide

There is only one green defined there:

#18C175

It’s not a detached style. It’s simply a wrong hex code that was manually used and never belonged to the design system in the first place.

Why This Example Matters Beyond the Color Itself

The color in this example is not something you can easily distinguish by eye. The button still looks green, and there is no obvious visual error that breaks the design.

But that’s not why I chose this example.

I chose it because it clearly shows how Cursor works.

Cursor read the exact hex value defined in the Style Guide, then scanned every layer inside the UI screens and compared each one against what it should be using. And it correctly flagged a mismatch that is almost impossible to notice visually.

This may be an extreme example. But that’s exactly why it’s powerful.

Because this is not only about mistakes that are hard to see.

It’s about situations in large, old files where checking hundreds of screens and thousands of layers manually would take days.

This process showed that this method can be a very practical way to regain control over files that have slowly drifted away from the design system over time.

A Quick Note for the Curious: What Is a Node ID and Why I Used It in the Prompts

Every element in Figma has a unique technical identity.By converting that Node ID into a Figma URL like this:

https://www.figma.com/design/FILEKEY/FILENAME?node-id=111-1111

Cursor generated a detailed element level deviation report with NodeID;

Not only for colors, but also for:

• Radius
• Font family
• Font size
• Shadows
• Spacing

A Small but Important Technical Detail

Something I noticed while doing this:

The Node ID returned by Cursor (via Figma MCP) is the real internal object ID. The Node ID you see in the browser URL after opening Figma is a rendered, session-based ID.

They don’t match. And that’s normal.

This is why I first asked Cursor to return Node IDs, and only after that used those IDs to construct the Figma links.

You can see this difference in the browser URL in the screenshots below.

Challenges I Faced and How I Handled Them

• Figma MCP doesn’t see screens, it sees a node tree
  I had to explicitly teach Cursor where the Style Guide and UI screens lived by finding their exact node IDs first.
• The JSON export didn’t include a styles catalog
  Before any audit, I asked Cursor to extract all paint, text, and effect styles from the file so it could understand what “allowed” actually meant.
• Figma links were opening whole sections instead of the exact element
  I learned to convert the MCP node IDs into proper Figma URLs (: → -) to navigate precisely to the problem layer.
• The file was slow and hard to scan
  I temporarily removed heavy sections/frames so Cursor could read the structure faster without changing anything else.
• The first reports were too technical to use
  I refined the table structure to include SG Value, Actual Value, and a plain explanation so the report became readable for a designer, not just a machine.

None of these required changing the method. They were small adjustments that made the audit practical and reliable.

Summary

My goal was to understand whether the UI screens in an old project were still following the foundations had been defined years ago as a style guide.

Instead of checking screens manually in Figma, I connected Cursor to the file through Figma MCP and let it read the file structure like a node tree.

Step by step, I:

• Helped Cursor locate where the Style Guide lives
• Helped it locate where the real UI screens live
• Extracted the actual styles defined in the file
• Asked it to treat those styles as the only allowed set
• Scanned every UI layer against that set
• Turned the result into a clickable report that takes me directly to the problematic elements in Figma

The result was a full element-level audit showing:

• Where raw values were used instead of styles
• Where wrong styles were used
• Where correct values existed but were not connected to the design system

The benefit was not just finding mistakes.

It was being able to see, clearly and quickly, where the design system had drifted over time in a way that would be almost impossible to find easily or detect by eye in a large file.

What would normally take days of manual inspection turned into a structured, practical audit I could actually work through.

What’s Next

Now that I can clearly see where and how things drift over time, the next step is going to be more like improving the foundations behind it.

• I want to go deeper into turning style guides into proper, token-based structures.
• Defining semantic layers instead of relying on raw styles.
• Using Figma Variables in a more systematic way.

And this time, I plan to involve Claude in the process as well not for auditing, but for helping structure, group, and reason about the design foundations themselves.

This may happen on this project or another one.

What matters is exploring how these tools can support not just finding problems in old files, but shaping more scalable design systems from the beginning.

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation.
LinkedIn | Instagram | Twitter

Auditing Style Consistency in Figma with Cursor was originally published in Muzli - Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.

Six months after the payment-hold incident, Ledgerly’s finance assistant could do something it couldn’t do before: it could actually go execute a multi-step task. Ask it to “reconcile last month’s vendor invoices against the PO log and flag anything over 5% variance,” and it would pull the invoices, cross-reference them, generate a report, and — if nobody stopped it — email that report to the finance distribution list. That’s the real shift this part of the series is about. Agentic AI uses the same underlying models as a chatbot, but it independently plans, chains decisions, and executes multi-step tasks without ongoing human direction. A regular conversational bot answers a question wrong, and the cost is a bad sentence. An agent acts wrong, and the cost is a bad outcome — money moved, an email sent, a record changed — often before anyone had the chance to notice.

The turn-taking model has to change shape

Classic conversation design assumes a rhythm: user asks, assistant answers, user asks again. Agentic design breaks that rhythm on purpose. The actual loop looks more like: user requests an outcome, agent proposes a plan, something (a person, a rule, a confidence threshold) decides whether that plan needs confirmation before it runs, the agent executes, and then it reports back what it actually did — not just what it intended to do. Designing that reporting step honestly is its own discipline: an agent that says “I reconciled the invoices” without saying which ones it couldn’t reconcile, or which line items it skipped because the data was ambiguous, is quietly setting up the next Ledgerly-style incident.

Reversibility is the single design question that matters most

Not every action deserves the same level of friction. Ledgerly’s team ended up sorting every action their agent could take into three tiers: fully reversible (drafting a report, flagging an anomaly — do it automatically, no confirmation needed), reversible with cost (sending an internal email — do it, but log it prominently and make undo genuinely easy), and irreversible or high-stakes (releasing a payment, changing a vendor’s banking details — require explicit confirmation, every single time, no matter how confident the agent is). This isn’t a novel invention on Ledgerly’s part — it’s the same underlying logic every enterprise team converging on agentic design eventually lands on, because the data backs it up: workflows that convert first into scaled, trusted agentic use are the ones with high volume, structured inputs, measurable outcomes, and short feedback loops — ticket triage and code review lead precisely because a wrong output there is cheap and fast to catch, not because the AI is more reliable in those domains specifically.

Where the real-world adoption data already tells the design story

The industries furthest along in production agentic deployment aren’t necessarily the most technically sophisticated — they’re the ones that had reversibility and guardrails baked into their processes long before AI showed up. Banking and insurance lead production AI agent adoption at 47%, while healthcare and government trail at 18% and 14% respectively. That gap is a design signal as much as a risk-tolerance one: finance already has audit trails, approval thresholds, and reconciliation processes an agent can be designed to slot into. Healthcare and government, by contrast, often don’t have an equivalent scaffolding to design the agent’s guardrails against — so the agent has nothing safe to plug into.

The payback data reinforces the same point from a different angle: median time-to-value on agent deployments is 5.1 months, with SDR-style agents paying back in 3.4 months and finance and operations agents taking 8.9 months. The finance/ops lag isn’t a technology gap — it’s the time it actually takes to design the guardrails, confirmation checkpoints, and escalation paths correctly for actions where a mistake costs real money.

Why governance failures, not model failures, kill most agentic projects

Gartner predicts more than 40% of agentic AI projects will be cancelled by the end of 2027, and the reasons cited are governance, observability, and unclear ROI — not model capability. That’s a design failure wearing a technology costume. An agent nobody can observe mid-task, whose actions aren’t logged in a form a human can quickly audit, is an agent leadership will eventually stop trusting regardless of how good the underlying model is. Observability isn’t a backend afterthought here — it’s a conversation design deliverable: what does the agent show the user while it’s working through a multi-step task, and what does it leave behind afterward that a human can review in thirty seconds instead of thirty minutes?

What changed for Ledgerly, concretely

The reconciliation feature shipped with three things that weren’t optional add-ons but core to its design: a visible plan step (“Here’s what I’m about to do — 47 invoices, cross-referenced against 12 POs — proceed?”) before anything ran, a running log the CFO could open mid-task to see exactly which invoices had been checked so far, and a hard rule that the “email the report” step always required a tap of confirmation, permanently, with no setting to turn that off. The agent got faster at the actual reconciliation over the following months. The confirmation step never went away — because the team had learned, the hard way, that speed and trust are not the same design goal, and optimizing only for the first one is exactly how you end up back in the CFO’s inbox explaining what went wrong.

Part 4 closes the series out with the question a lot of leaders and designers actually came here for: who does this work, what should you look for when hiring for it, and what does a career in it actually look like as the discipline keeps shifting under everyone’s feet.

Previous: Part 2 — Inside the Process: How Conversation Design Actually Happens in Enterprise SaaS

Next: Part 4 — Building the Team and the Career: Hiring and Growing Conversation Designers for an AI-Native Future

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation.
LinkedIn | Instagram | Twitter

When “I Understood You” Isn’t the Same as “I Did the Right Thing” was originally published in Muzli - Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.

Generated interfaces converge on the same safe defaults. Here’s how to brief them like a design lead instead.

Open three AI-generated landing pages side by side and play a quick game: find the differences. Same soft gradient behind the hero. Same rounded cards in a row of three. Same purple-to-blue accent, same centered headline, same pill-shaped button. They aren’t copies of each other. They’re copies of the middle.

That’s the part people miss when they call it AI slop. Generative tools are very good at producing the most probable answer to a request, and the most probable answer to “a modern SaaS landing page” is the average of every SaaS landing page they’ve seen. Nobody asked for the average. But a short, vague request leaves hundreds of design decisions open, and the tool closes each one with the safest option it knows.

Designers already have a remedy for this, because we’ve been dealing with vague briefs from clients forever. We turn adjectives into decisions. When a stakeholder says “make it feel premium,” we don’t reach for gold. We ask what should be seen first, how much room it gets, which colors are allowed and why. The same move works on a model.

Briefing a model is briefing a junior designer

Think about how you’d brief a talented junior designer who has seen everything but has no taste of their own yet. You wouldn’t say “make it clean.” You’d say the headline wins, the supporting copy steps back, there’s a single accent color, and everything hangs off one left edge. You’d tell them what not to do, too, because you know their instinct is to add.

A model needs that same brief, written down. I use six words as a checklist: Importance, Margins, Palette, Alignment, Contrast and Typography. They spell IMPACT, which makes them easy to remember mid-prompt. Each one covers a category of decision the tool will otherwise make for you, and each one translates into a sentence or two of plain language.

Importance: decide what wins

Every screen has a job, and the layout should make that job obvious in about a second. On a pricing page, it’s usually the plan you want most people to choose. On an onboarding screen, it’s the single next step. Generated layouts tend to give every element equal volume, so nothing leads.

State the reading order and back it with a ratio. “The recommended plan card is visually dominant: slightly larger than the other two, with the only filled button on the page. Plan names are secondary. Feature lists are small and quiet.” Ratios and rankings give the model something concrete to execute, where “highlight the best plan” gives it a vibe.

Margins: give it room on purpose

Models fill space because a full canvas looks like work. Product designers know the opposite is usually true: density is a cost, and whitespace is how you buy clarity. A dashboard crammed edge to edge with widgets feels urgent and hard to scan.

Ask for space by name, and say where it goes. “Generous padding inside each card. Wide gutters between the three columns. Extra space above each section heading, tighter space between a heading and its content.” That last pairing matters. Grouping by proximity is half of what makes an interface readable, and the model won’t do it unless you describe it.

Palette: fewer colors, each with a job

Left alone, generative tools love a gradient and a second accent and maybe a third. The result looks lively in a thumbnail and noisy in use. A working product palette is small: a neutral background, a text color, one or two supporting tones, and a single accent reserved for primary actions.

Give hex values and assign roles. “Background #F7F7F5. Primary text #1C1C1C. Secondary text #6B6B6B. Accent #2F6FED, used only for primary buttons and active states. No gradients and no additional colors.” Assigning the accent a narrow job is what keeps it meaningful. If everything is blue, blue stops meaning “click here.”

Alignment: pick an edge and commit

Elements that are nearly aligned read as mistakes, even to users who couldn’t name the problem. Generated UIs drift toward centering, which works for a single headline and falls apart for forms, tables and anything with more than two lines of text.

Make the structure explicit. “Left-align all text to a 12-column grid with a consistent left margin. Form labels sit above their fields, left-aligned with them. Card contents share the same internal left edge.” When you name the grid, you also make later revisions easier, because you can refer back to it.

Contrast: put the emphasis in one place

Contrast is how importance becomes visible: size, weight, color and space working together. Models tend to apply emphasis everywhere at once, with bold headings, bold labels, colored icons and shadowed cards all competing. When everything is emphasized, nothing is.

Tell the tool where contrast belongs and where things should go calm. “Only the page title and primary button use high contrast. Section labels are medium weight. Metadata is small and gray, but still meets accessible contrast against the background.” That final clause is worth keeping in every brief. Light gray on white is the most common way generated interfaces quietly fail real users.

Typography: one family, clear steps

Type is the decision prompts skip most often. Left to guess, a model will happily mix a display face with a system font and a third thing for numbers. Interfaces read best with one family, maybe two, and a clear type scale.

Name the family if your tool takes it, and describe the scale either way. “Inter throughout. Page title 32px semibold, section headings 20px semibold, body 16px regular, captions 13px. No more than three sizes visible in any one card.” For image-based tools that ignore font names, describe the character instead: a neutral grotesque sans, tight headings, roomy body text.

Write the “avoid” line every time

The model’s default is to add. Shadows, glows, glassmorphism, decorative blobs, illustrated people waving from the corner. Restraint only happens when you request it, so end every brief with an exclusion list chosen for the job.

For a product screen, that might be: “Avoid gradients, drop shadows on cards, decorative background shapes, stock illustrations, and more than one accent color.” Four or five well-chosen exclusions do more than a paragraph of positive description. They close the doors the model was most likely to walk through.

Revise one variable at a time

The six words double as a critique framework once the output comes back. Instead of “it’s not quite right,” you can say the hierarchy is muddy or the palette has crept. Then fix that one thing: “Keep the grid and the palette. Make the recommended plan card the only one with a filled button. Do not change the typography.”

Changing one variable per round tells you what actually moved the result, and the “do not change” clause stops revisions from drifting into parts that were already working. When the remaining fixes get tiny, stop prompting and finish in your design tool. That last stretch is faster by hand, and it’s where your own judgment shows most.

The taste was always the brief

None of this is new to designers. Hierarchy, spacing, color roles, grids, emphasis and type scales are the fundamentals we use to critique each other’s work. What’s changed is where those decisions have to live. For years they were expressed through the mouse, one nudge at a time. With generative tools, they have to live in the words you hand over first.

The models aren’t going to develop taste on their own. They’ll keep returning the most likely answer to whatever you ask. The difference between generic output and work that looks designed is whether you wrote your decisions down before you hit enter.

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation.
LinkedIn | Instagram | Twitter

Why AI Design All Looks the Same (and the Six Words That Fix It) was originally published in Muzli - Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.