The A List Apart Blog Presents:

“Successful” or “Unsuccessful”: the Post-“Good Design” Vocabulary

Article Continues Below

Design has always wrestled with subjectivity. Hell, anything visual has.

In the ever-evolving AI era, the old subjective shorthand—good design, good UX, bad layout, I like it—has become less useful, and sometimes actively misleading.

The reason is simple: AI can generate artifacts that look “good” at the surface level in seconds. When polish becomes abundant, “good” stops communicating rigor.

On the flip side, this has become an opportunity for a definitive shift toward objective language in, and around, design.

Updating the Language of Design in the AI Era

Despite expectation setting or advance guidance, at Anomali by Design we’re seeing clients bring AI-generated concepts — interfaces, logos, digital experiences — into ideation sessions at high levels of fidelity that can look pretty dang “good” at a surface level. And who can blame them?

The concepts look polished enough to trigger variants of the inevitable question: “Why not just use this?” If our only counter is taste—“ours is higher quality,” “that one feels off,” “…but this is good UX!”—the conversation slides toward preference, authority, or overall vibes.

The practical response isn’t to fight AI output on aesthetic grounds: it’s to evolve how we talk about and frame our work, and to make our critique language strong—and objective—enough to hold up in an environment where surface-level “good” is easy to manufacture.

And that means retiring “good” (or its inverse) as a design verdict and replacing it with language that aligns back to research, goals, and outcomes.

“Good” is Not a Design Outcome

Design isn’t a hamburger.

There are things in life that can be “good” that are fueled by subjectivity, without any meaningful criteria: a burger. A song. A nap.

Design has goals. Constraints. Context. A user. A business reality. A cost of implementation. A ripple effect across systems. An imperative for a measurable, objectively successful outcome (or at least an observable one). Without that DNA, “good” is a hollow validator.

In my book In Fulfillment: The Designer’s Journey, I argued that design isn’t “good” or “bad.” Design is aligned — or misaligned — to goals. The more accurate framing is whether the work is successful or unsuccessful relative to those goals:

Design isn’t ‘good’ or ‘bad’ — those are subjective terms (sorry, Dieter). Design is aligned to goals, and its efficacy is determined from their attainment or otherwise. ‘Successful’ or ‘unsuccessful’ are more apt descriptors, and should summarily inform our (design) language.

This is beyond semantics: it changes the shape of dialogue, critique, and it changes how cross-functional partners can participate. When someone tells me “this is good,” what they often mean is that it looks “clean”, resembles something familiar, or simply doesn’t jar them.

None of those reactions are invalid—they’re just incomplete. They don’t tell the team what is working, why it’s working, or how to evolve from there.

Separating Fidelity from Quality

There’s a word I think we need to rehabilitate: quality.

For a long time, people treated quality as a vague synonym for “good.” In practice, quality often got conflated with fidelity. The more complete the creation, the more “quality” it was assumed to have. The slicker the gradients, the more “modern.” The more detailed the UI, the more “real.”

AI has made that conflation painfully obvious: we can now produce fidelity almost instantly. Which means fidelity is no longer a reliable signal.

Fidelity is resolution. Fidelity is finish. Fidelity is how complete an artifact appears.

Quality is something else entirely. Quality is what happens when goals and outcomes-aligned thinking show up in the work—through research-informed decisions, layout tact, typographic structure, content hierarchy, and interaction patterns that support what the business, product, and user are trying to accomplish.

Fidelity can mimic those signals; it can resemble quality. But it can’t guarantee it.

That’s why I’m less interested in asking whether a design “looks good” and more interested in asking: does the design demonstrate quality? And then offering the parameters / qualifiers by which I use the term.

That distinction matters, because fidelity is persuasive: it can change the emotional temperature of a room. A high-fidelity artifact can make people feel like progress has been made, and can create confidence where confidence might not be earned yet.

When that happens, teams can move too quickly into selection mode. They start choosing, and often they start defending. They start optimizing something they haven’t validated. High fidelity—particularly before a concept is iterated upon—can become a trap: it helps a team move fast while skipping the very work that produces quality.

What AI Changed in the Room

When a stakeholder can conjure a polished logo or UI in a minute, a high-fidelity artifact no longer signals deep thinking. Fidelity, often at the expense of the iterative / sketch phase, becomes a default. The room begins treating what’s in front of us as more final than it actually is, and that accelerates decision-making in the wrong direction. High fidelity creates false certainty. It pulls us into selection mode when we should still be learning, evolving, and iterating.

Manual roughs and iteration are not tedium nor a drag on the process. ‘Time saving’ or ceding direction to digital tools as a creative, product, or delivery concept isn’t an inherent gift (unlike nuance and skepticism).

And as design advisors, consultants, and leaders (hierarchical or behavioral), it’s the continued area of discomfort we must exist, set boundaries around, and have a definitive POV, within.

Designers are not defined by their choice of tools; their identities are not Figma nor Adobe Suite. I’m a strong proponent of creating in a tool agnostic capacity—that is to say, letting the means and implements of creation be whatever drives the highest quality outcome. That said, there are two tools I’ll never stop advocating for (nor personally using):

Pencil + paper, and language.

This (re: everything written to this point) is where language becomes a design tool. If we can’t explain why a concept is successful or unsuccessful relative to research learnings, goals, users, constraints, and evidence, our work loses to polish. Not because polish is correct, but because the conversation has lost its teeth.

There’s another cost here that’s cultural: subjective critique invites ego. In In Fulfillment, I write that subjectivity is poison to the design process because it invites whim, makes decisions feel personal, and shuts down the growth that comes from objective critique.

Subjectivity is poison to the design process: in feedback, in decision-making, in creative direction, feature prioritization, etc. Evolution, quality, experience, and engagement are all on the line when ego and whim lead. And this notion of subjectivity versus objectivity translates directly to how we give feedback: what is actionable, and what is articulated from the hip?

When feedback’s baseline is “taste,” people defend themselves rather than refine the work. When it ties back to the work’s efficacy and becomes outcomes, we can collaborate without bruising each other. Humility and compassion serve us well here (and always).

This cultural risk is amplified right now because many organizations are measuring “AI adoption” in ways that reward activity more than necessity. If a company’s KPI is “where are you using AI,” the incentive is to generate and ship something quickly, and to treat polish as progress. That’s how teams end up with brittle work: decisions made under the glorious glow of high fidelity, with little clarity about outcomes.

A Language Evolution that Restores Rigor

The language shift is one of the simplest ways to restore rigor without grinding momentum to a halt. The move is straightforward: replace “good” with a claim that can be evaluated.

Particularly in the era of AI, product organizations prize speed. But speed without rigor and intention produces brittle work.

For example, in In Fulfillment I gave practical examples of translating “I like it” into objective critique anchored in goals and feedback, and translating “that sucks” into a statement about what the design fails to achieve:

Subjective approach: “I like it!”

This is “nice” to hear. It can be affirming or feel good. But what then, after the hit of dopamine? How can I leverage “I like it” moving forward?

Objective approach: “This is successful because [x]. Or, This aligns to project goals (or test results, or data) because of [y].”

“Successful”’ ties feedback to supporting points of project goals that confirm why the given approach works. Less “I like it because it’s blue” and more “I appreciate how you integrated blue as the primary call to action color amongst the rest of the client’s brand palette; it draws a user’s eye to areas of action organically.”

And on the other side of the coin:

Subjective approach: “That sucks!”

A bit of an extreme example, but the point is that feedback that is a variant of “Eh” or “I don’t really like it” yields zero growth for the recipient.

Objective approach: “This doesn’t achieve user (or project, or business, or environment) goals because [z].”

This is the feedback that is conducive to evolution—in both my work, as well as my tactics and strategy. If I can see where my design isn’t aligning with foundational research and learning, there’s growth to be had. Less “I don’t like it because it’s blue,” and more “we learned from our accessibility testing that reversed white text on the blue tone you’re using doesn’t pass WCAG AA standards. Have you explored other options?”

The important part is not the exact phrasing — it’s the discipline of naming why and naming what happens next.

A Successful Critique is Equitable and Productive

A successful critique sentence identifies the goal the design is trying to serve. It explains what evidence supports the claim: research learnings, usability feedback, a constraint we know is real, or a metric the product defines “success” by. It points to a mechanism in the design that produces an outcome, instead of waving hands at the whole layout. It acknowledges potential trade-offs. Then it recommends a next iteration or a test, so critique becomes action rather than commentary.

Once we adopt that posture, critique becomes legible to cross-functional partners. Engineering can weigh in because the statement touches constraints and implementation cost. Product can weigh in because it touches goals and outcomes. Marketing can weigh in because it touches clarity and promise-making. Leadership can weigh in because it’s grounded in risk and strategy, not aesthetic preference.

A shared language reduces the constant “translation tax” designers carry.

This becomes particularly important the moment an AI concept shows up in the room. We don’t need to dismiss it or compete with it: we need to translate it.

We can acknowledge that the artifact is a starting point, despite its fidelity or polish. Sometimes it will contain the seed of a potential option. Sometimes it will be directionally wrong. Often, we’ve had to walk it back, pick out some elements that might be successful, and bring them back to iterative (sketch) fidelity.

If we can identify one element the AI output gets right — hierarchy, a promising pattern, a flow that reduces steps — we can treat it as an experiment. That keeps the conversation constructive over combative. It also prevents the room from treating the output as an answer instead of a prompt.

This re-centers the discussion around criteria: what (business / brand / product / ethical / all-living-things) goals we’re pursuing and outcomes we’re aligning to, what constraints matter, and what we know about users that this concept either supports or violates.

With this, we can evaluate the AI-produced concept or artifact in a way that’s equitable and productive.

Tact, Without Being the “Language Police”

Of course people will still say “this is good [design, UX, etc.].” That’s normal. The shift I’m arguing for isn’t about policing words: it’s about refusing to let “good” be the conclusion, or the arbiter of success.

In example context: if AI-generated design is brought into a client review session by the client themselves—and the stated qualifier is that they like it because it looks “good”—our job is to translate that reaction into a usable signal.

We can get curious:

  • What outcome feels improved?
  • What about this option feels more brand-aligned?
  • What feels more successful in this?
  • What feels more aligned to the user’s needs?

Once those are surfaced, we can decide what to enforce boundaries around, potentially take back to iteration, or what to test and gain feedback upon.

In a world where AI can generate good-looking work instantly, “good” can’t carry the weight it used to carry in design conversations. What can carry that weight are language and actions that reflect what design has always been at its best: goals-aligned, research-informed, constraints-aware, and outcomes-focused.

65 Reader Comments

  1. I really appreciated this piece on how the AI era is pushing us to rethink what we mean by 'good design.' It's so true that when anyone can generate a polished-looking image in seconds, those surface-level compliments start to feel hollow. The shift toward more objective language—like asking if something is 'successful' rather than just 'good'—feels like a natural and necessary evolution for our field. It reminds me that the tools we use also need to keep up with this new reality, which is why I've started using an AI metadata remover to ensure my work is judged on its own merits, not hidden AI fingerprints. This article gave me a lot to think about, and I'm curious how others are adapting their critique vocabulary in their own workflows.

  2. This piece really resonated with me, especially the point about how AI-generated visuals make the word 'good' feel almost meaningless. I've caught myself saying 'I like it' without being able to explain why, and that's exactly the trap the article describes. The shift toward objective language—like 'successful' or 'unsuccessful'—feels like a much more honest way to evaluate design work. It's a mindset I'm trying to adopt in my own projects, and tools that help me refine the details, like a Photo text editor, make it easier to focus on clarity rather than just polish. Thanks for framing this so clearly—it's given me a lot to think about.

  3. Retiring the word good makes so much sense now that AI can spit out polished interfaces instantly. When clients bring in high-fidelity mockups that look fine on the surface, debating vibes or taste just goes nowhere. We started anchoring our critiques to actual user goals instead, and it completely changed our workflow. I even started playing around with modular frameworks like [https://deepseekharness.io](https://deepseekharness.io) to test different AI setups without getting bogged down by surface-level aesthetics.

  4. I agree that design isn’t a hamburger. When clients see AI-generated mockups, they often get distracted by how polished everything looks without checking if it actually hits the business goals. Lately, I have been using https://deepseekharness.io/ to customize my own AI coding tools and focus more on the functional logic of my projects. It is much easier to defend a design choice when you can point to how well it works rather than just arguing about aesthetics.

  5. Retiring the word good makes a lot of sense, especially when AI can generate polished looking mockups in seconds that lack any real context or constraints. When building terminal tools at [https://musecodes.io/](https://musecodes.io/), I noticed we had to stop judging things on surface polish and start focusing purely on whether the output actually solves the developer’s workflow bottlenecks. Moving the vocabulary toward goal alignment keeps critique grounded.

  6. Retiring the word good hits the nail on the head. When clients bring in polished AI mockups, subjective arguments about vibes completely fall apart. We have to anchor critique to actual business goals instead of surface polish. I have started shifting my own workflow the same way, especially after checking out [https://opendesigner.io](https://opendesigner.io) for local alternatives to locked-down proprietary tools. Moving the conversation from taste to alignment makes design reviews way more productive.

  7. Dropping the word good makes a lot of sense when working with AI-generated concepts because polished outputs can easily hide underlying misalignments. When testing local automation scripts through [https://openclaws.io/](https://openclaws.io/), I noticed that surface-level perfection often masked functional gaps until we tied every review directly back to system goals. Focusing on whether a workflow is successful rather than just pretty completely changes how critiques happen.

  8. Retiring the word good makes total sense when clients show up with high fidelity AI concepts that look fine on the surface but miss actual goals. It shifts the critique away from pure subjectivity. While tinkering with my own local workflows, I found [https://hermesagents.net/](https://hermesagents.net/) really helpful for setting up autonomous agents that handle multi platform tasks without getting bogged down in messy configuration. Framing our discussions around measurable outcomes rather than vague vibes is definitely the right move for design critique now.

  9. Moving away from just calling things good or bad makes so much sense, especially when AI can spit out polished mockups in seconds. When working on automated workflows recently, I kept running into the trap of evaluating interfaces purely on surface vibes instead of actual goal alignment. Tools like [https://grok-bots.com](https://grok-bots.com) really forced me to look closer at whether a setup actually solves the functional problem rather than just looking slick. Evaluating success based on outcomes rather than subjective taste is long overdue.

  10. Retiring the word good makes a lot of sense, especially since AI tools now churn out high-fidelity mockups in seconds that completely bypass traditional aesthetic critique. When clients pull those shiny concepts into meetings, arguing about vibes gets us nowhere. We have to anchor our reviews in actual goals and user outcomes instead. Reminds me of when I was trying to optimize my own schedule using [https://sleepytime.kr/](https://sleepytime.kr/) to calculate 90-minute sleep cycles; the value wasn’t about it feeling nice, but whether it actually aligned with how my body functioned and helped me wake up without feeling groggy.

  11. It is so true that calling something good or bad just shuts down real critique, especially now that AI can whip up polished mockups in seconds. We started focusing much more on whether our layout choices actually map to user goals instead of just vibes. That shift in vocabulary really changes things. I ran into a similar design clarity challenge while mapping out sleep cycles for a personal project using [https://sleep-calculator.app/](https://sleep-calculator.app/), where objective metrics mattered way more than just making things look pretty on the surface.

  12. Retiring “good” as a design verdict makes total sense, especially when AI churns out high-fidelity surfaces instantly. We recently got stuck in a review loop debating whether a concept felt “clean” instead of mapping it back to actual user metrics. I’ve been spending time over at [https://claudecertified.io/](https://claudecertified.io/) brushing up on API architecture recently, and it really reinforced how important objective standards and precise criteria are when evaluating technical or design output beyond mere surface vibes.

Leave a Reply

Your email address will not be published. Required fields are marked *

More from ALA

Designed for a Dead Language

Every language app in your pocket inherited a teaching method built for Latin. Understanding why that happened is a more useful design lesson than anything the apps themselves can teach you.
Uncategorized

Design for Amiability: Lessons from Vienna

Computing was born in a Viennese café. Between 1928 and 1934, while Hitler plotted and Europe crumbled, a motley crew of mathematicians, philosophers, architects, and economists gathered weekly to puzzle out the limits of reason—and invented Computer Science in the process. What made their collaboration possible wasn't just brilliance (though they had plenty). It was amiability: the careful design of a social space where difficult people could disagree without destroying each other. Longtime A List Apart contributing author Mark Bernstein mines this forgotten history for lessons that might just save today's embattled web from its worst impulses. Spoiler: it involves better coffee service and the looming threat of public humiliation.

Discover more from A List Apart

Subscribe now to keep reading and get access to the full archive.

Continue reading