Why and How to Discuss Design with Developers

In Art & Design School, design critique can be brutal. It’s often focused on judging whether or not work is “good” or “bad.” Reviews of work can be scathing, leaving art and design students running from the studio in tears.

Many professors say that critique is part of preparing students for work in a real world where creative directors possess brutal egos focused on crushing their underlings. I’m not sure that world is anything but a delusion. I’m also skeptical that this form of critique does anything but leave students scarred with bad memories, hesitant to throw themselves into collaborative environments.

As a result, I think critique gets a bad rap. It’s viewed as painful and conflictive. Considering critique in this way casts it in a negative light that’s both untrue and damaging. Worse, it frames critique as an exclusive activity limited to people with a special awareness of aesthetics: Without taste and an understanding of aesthetics, visual hierarchy, etc., how else could a critic judge the work?

When we see design critique as only a judgment, we miss the boat on what it can truly be. By making critique exclusive, we also miss out on the input of some extraordinarily gifted team members who could make our work better.

I’d like to propose including developers in this process to make our critiques more effective. Notice that I didn’t say “to make our team dynamic better” or “to make developers feel more included and empowered.” The developers I work with aren’t snowflakes who need to be coddled. They are professionals who are going to do their best with what they are given and drive project success with their expertise, regardless of what they are handed.

When you include developers in your critique, you aren’t giving them a panacea. You’re making your design practice better.

What Is Critique?

Let’s start by re-evaluating the definition of a design critique. As I said before, I don’t think defining critique as a scorched-earth exercise where the work of a team or individual is judged is extremely effective. In fact, I don’t think it makes work better.

Instead, let’s reframe critique as a conversation between two parties focused on understanding a problem and the intent of the designed solution. I think this approach helps construct a vital element of our design practice that is both helpful and inclusive.

Focus on Intent

If critique is truly a conversation, then it must have two parts: giving and receiving (kudos to Aaron Irizarry and Adam Connor for succinctly outlining this in their book Discussing Design). Whether you’re giving or receiving critique, it’s important to stay focused on the intent of the work.

For the Giver of a Critique

To understand the problem the designer is trying to solve, it is essential to lead with questions. Some examples:

  1. What are you trying to achieve by putting the navigation in a hamburger menu on this desktop interface?
  2. Why do you think that’s effective?
  3. What is the purpose of reviewing the data in this UI before saving it to the remote server?

For the Receiver of a Critique

As you prepare to present your work, think about how you will explain your choices. Are you able to succinctly and clearly explain your intent in a way your audience can understand?

Neither giver or receiver should assume that the intent of the work is explicit. Remember that the focus of critique is on understanding. The easier you can make it for your audience to “get” what you are trying to achieve, the better the critique will be.

Including Developers in Critique

By focusing critique in this way, we can open up the activity to a wide variety of individuals. Anyone with an inquisitive mind can take part.

While working in the tech industry, I’ve discovered that some of the best givers of critique aren’t designers at all. They’re developers. What makes developers really good at critique? The same thing that makes them really good at programming. They exhibit a natural curiosity about how and why things work. How many developers got their start in engineering by taking apart a toy or a family computer? This inquisitiveness is essential in formulating questions in good critique.

The best developers come at problems with a beginner’s mindset. They don’t take the things they know for granted. Sometimes, by holding fast to what we’ve experienced, we can blind ourselves to new perspectives and ideas that lie outside what we think we know. If instead, we assume the attitude that we don’t know very much, we can open ourselves up to new ways of seeing a problem or a solution.

Additionally, many developers employ deductive reasoning, which can be helpful in critique, as part of their jobs. Just as developers can look at a piece of functionality to be implemented on a project and quickly break it down into achievable tasks, so can they look at a designed solution and break it down into comprehensible pieces to be examined and questioned.

It follows that developers are also often excellent critical thinkers. Critical thought is the ability to analyze a situation rationally by evaluating the available evidence. It’s no accident that “critique” and “critical” come from the same Greek word (kritikos) meaning “the intellectual capacity and the means ‘of judging,’ ‘of judgment,’ ‘for judging,’ and of being ‘able to discern.'”

Judgment

As I mentioned earlier, I don’t think framing critique as judgment is helpful. When individuals stand around throwing personal judgements at a designer’s work, it just isn’t productive. But arriving at conclusions together about the overall effectiveness of the designed solution in the context of the assumed problem is essential.

In this instance, a developer’s ability to look at a situation rationally and critically is extremely useful. When we leave developers out of design critiques, we run the peril of missing out on validation of our work.

Words of Caution

To participate effectively in critique, there are a few tendencies that developers (and everyone else) need to abandon.

  1. Self-focused judgment: Judgments cannot be connected to our own personal taste or preference. That sort of judgment is focused on self and isn’t helpful. I’m sorry to say that your subjective opinion about colors, fonts, and layout aren’t important. What is important is whether or not a designed solution is successful in its intent according to our understanding of the solution’s users. Our judgment must be focused on the objectives of the design, not on seeing ourselves reflected in the work.
  2. Black and white determinations: There is a lot of ambiguity and tension in the world of design. Sometimes, clear determinations can’t be made, and trade-offs may have to be embraced. It’s important to understand the context the designer is working in before making a judgment. In that context, it may be that a solution you initially deem as black turns out to be gray or even white.
  3. Problem solving: As a giver of critique, it is never your role to solve the problem for the designer. It’s your job to understand the intent of the current solution, and together with the group, arrive at a judgment of its effectiveness. It’s then the designer’s job to go away and, using your feedback, adjust the solution to be more effective.

I have continually been impressed by my more technical colleagues’ ability to bring novel viewpoints and insightful questions to the critique of my design work. If you aren’t engaging in critique with your dev team, I am sure you are still doing a great job solving problems for people using software. But your practice may be missing out on an added dimension of richness and innovation. I’d encourage you to take a step forward and engage with wider teams in your organization to probe and question your work.