Things I look for when evaluating a project

I have left this stuff purposefully not very specific to UX because these basic guidelines apply to all genres of creation.

Compare the presentation to an existing body of heuristics

A heuristic means a "strategy derived from previous experiences with similar problems." Every professional builds up their own personal library of heuristics for doing their job effectively over time. I have listed out my personal heuristic guidelines in this post: Guidelines for a good user experience.

Is there anything I can use here? Is there an opportunity for alignment? 

A critique is never just doing someone else a favor. It's also an opportunity for you to learn something new.

  • Do I see anything here that I could use in my own projects? I always have my eyes open for elegant and graceful UX that I can use to improve my own work.
  • Do I see a similarity with the products and functionality I'm working on, that the subject should be aware of? Do I have experience working on this problem that they can benefit from?
  • During a critique session I make mental notes about who on the team is working on what so I can make connections later on. Later on when I see something similar, I can ping them and have a conversation about it. Or when I see that someone is working on X, I can point them in the direction of someone who has already worked on X and may have important information to share.

Things I don't care about

  • The aesthetics or format of the document as long as it communicates what it needs to communicate.
  • Minor errors/inconsistencies in the dummy data. I may point them out so that the designer can fix them, but it's better to assume it was a simple oversight than a bad design decision.

When I don't understand what I'm looking at right away

Sometimes when looking at something new, we need a few minutes of looking & digesting to understand what's going on. I treat something I'm critiquing the same way I treat everything else, which is to read it first. Something needing to be read before being understood doesn't mean there's something wrong with the design. It also doesn't mean there's nothing wrong with the design. It just means that I needed to read the words on the page before I understood what the words meant, which is how written language works.

If I do have questions, I just ask them, and then depending on the answer, I might have suggestions for how something could be made clearer. But what I don't do is start applying labels or issuing critiques before I understand what I'm looking at.

When critiques are offered by an authority figure without understanding, that leads to changes being made that reduce the overall quality of the design for everyone who is not that one individual.

Structure and components of a useful critique

When being critiqued, the subject of the critique is opening themselves up and being vulnerable. Even though we're "not supposed to take things personally", human nature can't just be dictated away. It's a fact that the subject worked hard on what they're showing you, and they want people to like it, whereas you have nothing to lose. Therefore they are at a disadvantage in this conversation. This power differential should be respected. The best way to do that is to provide something of value in return for their vulnerability. A  critique must contain the following elements to be valuable:

1. An observation that needs more than 1 word to describe, and the area of the project where the issue can be found.

The goal of a critique is to give the subject some information about how they might be able to improve their project. The most important thing they need to know is simply what the issue is, described using a series of actual words. The second most important thing is where they should look in the project to locate the issue. Something as simple as this should go without saying, but in my experience, it does not.

A good rule of thumb is to literally look at your thumb. If your hand is waving around, make it stay still. Find something to point to. If you can't do that, then you're not providing useful information that the subject can employ to improve their project.

2. The significance of the issue based on your experience

If you can't think of any way that your observation is significant, then think twice about whether it's worth sharing. Examples of significance are:

Alignment with established best practices

You should be able to articulate what the best practice is, why it exists, and how what you're seeing isn't supporting it. My personal list of best practices can be found here. When you provide this kind of critique, you're helping the subject build up their own library of heuristics, which they can employ in the future.

I have an experience that might be relevant

For example, if I saw that someone had a grey button, I could share that in my experience users tend to think grey buttons aren't clickable. This is something I have observed that the other designer may not have. This way I can save them a headache later on. This is how designers can benefit from working on a team with individuals who have all had different experiences. Later on they will give me some information I didn't have before, and everyone will be smarter than they were yesterday.

3. A conclusion

A critique without a point is just a series of observations which may contain little to no value. Two possibilities for a conclusion are:

If it's a negative critique

- Either you have an alternative solution in mind...

Maybe you can visualize an alternate solution that the subject can evaluate to resolve the issue you have identified. If so, the key words are "alternative" and "can evaluate". Since this isn't my project, I know that I don't have all the information, and I don't know what else the subject has tried. They can try out my idea and see if it helps, or maybe they already know it won't work in the context they're working in, and if that's the case then I have now learned something about them, their process, and the project itself. That's fine! We are just having a conversation and it's fine for the person being critiqued to also have a part in that conversation.

- Or you're not sure how the issue could be resolved.

If you don't have an alternative in mind for the designer to try, you can follow up with a sincere question about why the designer made that choice. They should have an answer, and if so, maybe you will learn something about them, their process, and the project itself. If they don't have an answer, then you have given them something concrete to think about that they can use to think of a solution on their own.

If it's a positive critique

Share what you think the point is. Are you going to explore their ideas for your project? Are you going to send them some links that might be relevant? Are you going to set them up with someone who's working on something similar?

Or maybe it's as simple as "Good job!" A positive critique lets the subject know that this part of their project is fine and they can move their focus on to other things now.

Difference between criticism and critique

The first definition of criticism is "the expression of disapproval of someone or something based on perceived faults or mistakes." The second definition is "the analysis and judgment of the merits and faults of a literary or artistic work." Neither one of these is useful in a UX context. Our goal in critique isn't to make a list of perceived faults or mistakes. Our goal, since we're all working at the same company, is to produce excellent user experiences for our customers. Your teammate's customers are your customers too. Simply making a list of faults without concrete suggestions about ways to make it better is a waste of time and creates bad morale.

These are some comment sentiments that turn something that should be a critique into a criticism:

"I would have done this differently" 

If your only observation is simply that you would have done it differently, you are entitled to your opinion, but please be aware that that's not a critique or even a criticism. It's just a statement about yourself. "The way you would have done it" is never automatically the best way even if it's different from how someone else did it, even if you're the most prestigious UX thought leader you can think of.

In fact, you don't know what you would have done if you had the same context and time spent working on it as your teammate, and assuming otherwise belittles your teammate. So in addition to being arrogant and insulting, it's just plain inaccurate.

If you do have something to say that meets the criteria of a critique, and you want to be someone who is kind to others, just provide the information needed by the recipient without the preface.

Just saying an adjective

Pointing to a whole screen and saying "It's ____" isn't helpful. Imagine ___ is words like "confusing", "ugly", "weird", "not pleasing", or my least favorite, "complicated"*. This practice is less than useless, it's disrespectful. Because:

  1. It doesn't give the designer any information to work with to make it less ___, which is obviously their goal.
  2. It implies that they don't know that things aren't supposed to be ___, even though they spent a lot of money on school and work very hard every day to make things that are specifically not ____.

This is also just a statement about yourself, because what you're really saying is "It's ___ to me." Crafting a good user experience is never just about one person and how they feel about one thing, no matter who that person is.

If you really think something is _____, there must be something you can point to with your finger and say "I was expecting X, but I see Y. In my experience, this is significant because __. What lead you to this decision?" Then you must allow a response, and really listen to it.

* "Complicated" is my least favorite criticism-disguised-as-critique because sometimes things are complicated. The systems we design should be grounded in reality and reflect reality, and most of the time, reality is complicated. Complicated is also not a synonym for "unclear" or "inappropriate". Something can be complicated but still be clear and appropriate.

When we are teammates working on the same thing

A critique can't be about something you personally are working on. If you have an opinion about something your project-mate did and you want to change it, you have to work it out together as equals. A critique contains a baked-in power differential in which the subject is at the mercy of the reviewer, because while a reviewer can say whatever is on their mind, the subject cannot. That should be respected during a critique session. But that power differential should not exist when two people are working together on the same project.

"I'm saying something negative to assert or establish power"

You can tell if a statement falls into this category if any of the following apply:

  • The critiquer can't articulate what their concern is, they just "don't like it" or something is "not right".
  • The critique is something that no one has ever heard before ("clickable links should never be blue") and/or doesn't make logical sense.
  • The critiquer isn't allowing the subject to provide a valid reasoning for why they made that choice that isn't being respected. Types of valid reasoning are: test results, stakeholder feedback, customer feedback, competitive analysis, industry standards, established UX best practices.
  • The criquer is having a personal experience that they assume is universally shared, but without providing evidence for that
  • There is realistically no concrete action the subject could take that would resolve the concern.

It should go without saying that this isn't really critique, and again, barely qualifies as a criticism. We should all be on the lookout for this type of feedback being delivered to others and defend them, because prolonged exposure eventually has negative effects on productivity.