How to Evaluate Design: A Framework for Clients, Founders, and Hiring Managers

How to evaluate design without guessing. A two-part framework for founders, hiring managers, and clients, from a working designer.

Most people evaluate design by looking at it and asking themselves ”do I like it?” That question is almost impossible to answer well, and it produces a lot of bad decisions. If you have ever sat in a meeting where a logo was approved because the loudest person liked it, you already know how this ends. Learning how to evaluate design properly is not about training your taste. It is about asking better questions.

I want to give you a framework I use in my own work, both as a designer reviewing other people’s projects and as someone who has spent years sitting in design crits, hiring panels, and client presentations. It is not the only framework. It is one I keep coming back to because it works in conversation, not just on paper.

Why learning how to evaluate design is harder than it looks

Design is one of those disciplines where everyone has an opinion and very few people have vocabulary. A founder looks at a homepage and feels something. A developer looks at the same homepage and notices the spacing is off. A marketing lead looks at it and worries about the CTA. Three different reactions, three different languages, and no shared way to talk about whether the design is doing its job.

This is the part that costs companies the most. The design fee is rarely the expensive part. The expensive part is the three months a team spends iterating in the wrong direction because nobody could articulate what was actually wrong with the first round. Learning how to evaluate design closes that gap. It gives a mixed team a shared way to look at the same artifact and reach roughly the same conclusion.

The framework I use has two parts. I call them the Communicative dimension and the Organizational dimension. They are not mine originally, they came out of a longer piece of research I did on design tool evaluation, but I have adapted them to apply to design output itself.

The communicative dimension

The first question you ask of any design is what it is trying to communicate. Not what it looks like. What it is saying.

Every design has a message it needs to land. A landing page needs to communicate what the product is and why someone should care. A logo needs to communicate the brand’s personality in a fraction of a second. An app screen needs to communicate what the user can do next. If the design fails at this, the rest does not matter.

When I look at a piece of work, I ask:

• What is the first thing your eye lands on, and is that the right thing?
• If you covered the words, would you still understand roughly what this is for?
• Does the visual feeling match the actual message? A bank that wants to feel trustworthy should not look like a startup that wants to feel disruptive.
• Is anything competing for attention with the main message?
• What does this remind you of, and is that association helping or hurting?

These questions are answerable by anyone who can see. They do not require a design degree. They require you to slow down and articulate what is actually happening when you look at the artifact, instead of jumping straight to ”I like it” or ”I don’t like it.”

The interesting thing about communicative questions is how often they reveal that the design is fine and the brief was wrong. A homepage that is technically beautiful but communicates the wrong thing is not a design problem. It is a strategy problem masquerading as a design problem. Evaluating design properly will save you from blaming the wrong thing.

The organizational dimension

The second question is whether the design holds together as a system. This one is harder for non-designers, but it is the part that separates good work from work that just looks polished.

Design is rarely one artifact in isolation. A logo lives next to a website. A website has fifty pages. An app has hundreds of screens. Every design decision either reinforces the system or undermines it. When the system holds, everything feels intentional and trustworthy. When it does not, the work feels arbitrary even when each individual screen is fine.

When I look at a piece of work, I ask:

• Does the same kind of element behave the same way every time? Buttons, headings, spacing, color, all of it.
• Are the decisions repeatable? Could someone else add a new page tomorrow and have it feel like it belongs?
• Is the hierarchy consistent? If a heading is large and bold in one place, does that always mean ”this is the most important thing on the page”?
• Are the relationships between elements predictable? Spacing, alignment, grouping, all of it should feel like it follows rules even if those rules are not explicit.
• If you stripped out the content and looked only at the structure, would it still make sense?

This is where you separate a designer who has thought systemically from one who has decorated one page at a time. It also explains why a portfolio of single hero shots is less impressive than a portfolio that shows a system in use across many contexts. The system is where the real craft lives.

A short worked example

Let’s say you are evaluating a landing page for a new SaaS product. The brief is ”communicate what the product does and get visitors to sign up for a free trial.”

Communicative check. What does your eye land on first? If it is the logo, that is wrong. The logo is not what you came to read. If it is a giant hero image with no context, that is also wrong. If it is a headline that tells you what the product does in plain language, you are on the right track. Cover the words. Does the visual feeling match what the product is? A productivity tool for accountants should probably not have neon gradients and 3D blobs.

Organizational check. Scroll the page. Does every section feel like it belongs to the same product? Are the buttons the same shape and behavior throughout? Is the spacing between sections consistent? If a feature card has an icon, do all feature cards have icons? If a heading uses sentence case in one section, does it use sentence case everywhere? When you spot the answer to one of these as ”no,” you have found something specific to discuss. Not ”I don’t like it.” Something concrete.

Notice what happened. We did not talk about whether the design was beautiful. We talked about whether it was working. Beauty is downstream of these two dimensions, not upstream.

What this framework does not do

I want to be honest about the limits, because frameworks become dangerous when people forget what they cannot do.

This framework does not predict business outcomes. A design can communicate clearly and hold together perfectly and still fail in the market because the product is wrong or the audience is wrong or the timing is wrong. Evaluating design is not the same as evaluating a business.

It does not replace user testing. Real users do things in real contexts that you cannot anticipate from reviewing static screens. If the stakes are high, test the design with the people who will actually use it. The framework is a useful filter before you spend the money on testing, not a substitute for it.

It does not settle questions of taste. Two designs can both score well on these dimensions and still feel different in ways that matter. At that point, the discussion has to be about what kind of feeling fits the brand, the audience, and the moment. That is where taste comes in, and taste is built over years of looking at work, not from a checklist.

It is also not a tool for tearing down a designer’s work in the room. Used carelessly, this framework can become ammunition for the kind of feedback that makes designers want to switch careers. Used well, it gives the conversation a shared vocabulary that lets everyone participate without having to be defensive. The goal is better work, not winning the meeting.

How this applies to AI-generated design

One reason I think learning how to evaluate design matters more now than it did five years ago is the volume of AI-generated work showing up in client decks, founder pitches, and product launches. AI can produce a landing page in thirty seconds. It usually scores well on the surface and poorly on both dimensions when you actually look. If you do not know how to evaluate design with intention, AI output will pass your filter even when it should not.

I wrote about this in more detail in my post on why vibe coded interfaces all look the same. The short version: AI is excellent at decoration and weak at system thinking. If you do have a framework, you will catch the gaps before they cost you anything.

This is also why I think the skill of evaluating design will become more valuable, not less, as more design work is produced by machines. Someone has to know what good looks like. That someone might as well be you.

One last thing

The biggest shift I want to leave you with is this. Evaluating design is not about being right. It is about asking better questions in front of the artifact, with the team, before decisions get locked in. The framework above is not a verdict machine. It is a conversation tool. When you start asking these questions out loud, you give everyone permission to be specific about what is working and what is not, and the conversation gets dramatically better fast.

If you want to go deeper, I would point you to the Nielsen Norman Group’s writing on design critiques, which sits adjacent to this material and is one of the few places online where this kind of practical evaluation work is taken seriously. And if you are evaluating designers or agencies specifically, I will be following this post with one on how to evaluate a designer’s portfolio in October.