Webmasters Gallery

Something that has been on my mind lately is how we talk about the deliverables we work on as designers and developers. There are plenty of times when we want feedback on our projects and turn to our friends, co-workers, colleagues, Twitter, and all kinds of other people for their honest opinions about the quality of our work.

But this can be problematic. The feedback we get is often not what we hoped for. In some cases, it can feel personal, which is almost never what we hope for.

Managing the way we seek, request, and respond to feedback can have major implications on the end result of our work. This post will cover some tips and tricks for having those dialogues.

Let’s Set the Scene

Here’s a common work scenario:

1. A project is assigned to you
2. You work on said project
3. You turn project in to the person who requested it

Pretty standard, right? Sometimes we’re tasked with an über-large project that takes weeks to complete. Other times, it’s something simple that we can churn out in a few hours. The thing all projects share in common is that they’re ultimately going to be turned into someone who will either be happy or not-so-happy with what we did.

Getting a positive reaction to our work is ideal. That’s what we’re aiming for at the end of the day. Getting a negative reaction can strike nerves in the best of us, especially with work we’ve invested personal time and energy into.

Not all feedback is equal

The truth is that not all feedback is the same and should not be treated as such. I recently read the book Discussing Design as part of a team exercise and really loved the way that authors Adam Connor and Aaron Irizarry distinguish between different types of feedback. Here’s a comparison of the three types that were mentioned:

• Reactive feedback: “Ugh, that’s gross!”
• Direction-based Feedback: “I would have made all the text two pixels larger across the board.”
• Critique: “If the objective is to make the content of an article easy to read in a leisurely setting, then perhaps we ought to consider a larger font size that allows readers to sit further from the screen because they will otherwise have to lean in to read the words.”

Reactive feedback has been the most toxic type of feedback in my personal experience. Even positive reactions leave me with a sorta empty feeling that I dodged a bullet and turned my work in on a day the person looking at it just so happens to be in a good mood. It’s nice to hear it, but may not help me know or understand what I did well, or if I even did well at all.

It’s worth noting that reactive feedback is sometimes exactly what we want. I know I’ve worked on projects where I truly want someone’s primitive, guttural reaction to my work, particularly where moods and emotions are part of the project objectives.

Direction-based feedback reminds me of this old Tumblr collection of hovering art directors. Go ahead and look at the photos because I’m sure you’ll have a laugh having been in the exact same situation where your boss or team is huddled right over your shoulder and calling out edits to your work as if you were a real-life Siri capable of making those changes in real time.

I will say there is a time and place for direction-based feedback and I have certainly benefited from having wise and experienced folks mentoring me on projects. That’s not really the point of this post though, rather simply to point out that it is a type of feedback.

Critique is somewhat the Holy Grail of feedback. Where the other two types might be tinged with emotions or personal preferences, critique recognizes the objectives our work is supposed to solve and tries to align our work to them.

Critique takes work and that’s sometimes a luxury, especially for projects with tight deadlines. Critique is also a skill unto itself that requires the effort of both the person seeking it and the person providing it. Discussing Design really does a nice job of diving into the practice and art of critique and is a worthwhile read for anyone interested in digging further in.

For the purposes of this post, let’s go over some tips — and yes, tricks — for getting the right type of feedback when we need it.

Knowing who to ask for feedback

This is pretty straightforward for a project that only has one stakeholder (i.e. the client) but the reality is that projects often have multiple stakeholders who have a shared and vested interest in the work being done.

The key is to pair the type of feedback you need with the right people during the project life cycle. For example, I have a rule of thumb to not show work to anyone signing off on the project before I am completely comfortable receiving a reaction. I have found that showing work to stakeholders while I’m still making decisions on my execution leads to premature assessments of the work as a whole and does the work I’ve put into the project so far a huge injustice.

That means friends and colleagues can be a better sounding board for early opinions. This might be font pairings in a design, class names in CSS, deciding between frameworks, or just about any early decision you might be making, regardless of the project.

The times I feel most compelled to reach out to a stakeholder ahead of formal feedback are when I need more clarification on the project’s objectives. An example of this might be a performance consideration that was never mentioned in the project requirements and you need the stakeholder’s opinion on whether or not solving for it is within the scope of work.

Knowing what to ask

I would be lying if I said I have never sent an email to a client to the effect of:

Hey, I’m all done with Project XYZ – let me know what you think!

This is where the poop usually hits the fan.

For one, how fair is that to the client? Not only have I provided no context for what’s being turned in, but I haven’t even formed the request for feedback into a valid question. Seriously, I’ve done this before and it’s rarely (if ever) yielded a helpful response. Instead, it provides my client with a blank check to say and respond in any way they want. You know the old adage of garbage in, garbage out? Well, getting garbage feedback should be expected from a garbage request like that.

Constructive feedback is more likely to occur if you take the initiative to frame the conversation when seeking it. Here is a handful of questions I’ve seen before when I’m asked for feedback with examples of how they can be framed for more effective dialogue.

Notice what all good questions have in common? It boils down to four traits: (1) isolating the question to a particular aspect of the project, (2) aligning the question to the project’s objectives, (3) providing context for the decision that was made and, lastly, asking the question itself.

This is the grand trick to getting solid and constructive feedback for any project. It allows the person receiving the question to recall what’s being solved, get in your head space and make a comment from there. If you provide a well-though, well-constructed request for feedback and still get a garbage reactive reply, then that’s where you can point back to the question and redirect the stakeholder to provide a reply that’s on topic.

Knowing how to set expectations

Now that we know who to ask for opinions on our work and how to ask questions that lead to constructive dialogue, the next trick in our pocket is setting good expectations. What I mean by this is making sure that everyone — including ourselves — is on the same page as far as what’s being worked on, what is going to be discussed, and what actions will be taken once the feedback has been received so that the conversation can continue and (hopefully) lead to approved work that everyone is confident releasing.

Many of you reading this are likely well familiar with the concept of delivering rounds on a project. If rounds are a new concept to you, the basic idea is turning in a first “draft” of your work for feedback, making changes in a second “round” of work, and repeating the process until a final iteration is approved.

I really like this process whether I’m working in design or code (or both!) but it can easily get out of hand if we’ve neglected to set expectations for what is going to be worked on in each round, combined with the tricks we’ve learned up to this point in knowing who to ask for feedback and how to ask questions that lead to good feedback.

My trick is that I tend to break my work up in rounds with each one focused on a specific aspect of the project. For example, a typical website project might look like this:

• Round 1: Wireframe and layout
• Round 2: Design patterns and interface components
• Round 3: Colors and styles

I like to break projects up into rounds like this because it not only allows me to focus on a specific task of the project at a time, but it also acts as a meeting agenda with stakeholders. Everyone knows what is being worked on and what will be discussed when work is delivered.

Going back to the example of an email I have admittedly written to clients before when delivering my work:

Hey, I’m all done with Project XYZ — let me know what you think!

Applying our new trick of setting expectations would allow me to say something more helpful:

Hey, I’m all done with the first round of Project XYZ. You might remember that this round is specifically focused on the wireframe and layout of the page templates. I believe this meets all of the objectives we discussed, but here are a few questions I have for you to keep in mind and answer for specifically as you review the work.

Hopefully that sets the stage for an awesome round of feedback. If the client has changes, you’ll know that they were at least aligned to the objectives of the project. If the client has no changes, you can continue to push for more feedback if there are other considerations you think ought to addressed before moving to the next round. Regardless, my rule of thumb is to stay on a round until all of the feedback and action points for it have been fully addressed.

Another trick: use a subject line that clearly identifies which round is being discussed, whether it’s over email, your project management system, an internal memo, or what have you. Continue using that subject line until the round has been fully discussed and approved, then move to a new subject line for the next round in a fresh chain of responses. This keeps all the feedback you receive together and continues to set good expectations for what’s being discussed.

Resources

• Discussing Design by Adam Connor and Aaron Irazarry is the book that got me thinking about these concepts and is highly recommended for anyone who works with clients or a team environment.
• Project timeline template by Brad Frost. This is super helpful if you’re interested in the concept of breaking a project up into rounds because it can serve as a way to visualize those rounds and serve them in a central location that everyone can refer to at any time.
• The 20-Second Gut Check is an excellent way to request and control reactive feedback.
• Five Second Test is another excellent tool for reactive feedback.
• The CSS-Tricks forums are available around the clock and are chock-full of folks willing to provide reactive, direction-based and critical feedback.

Wrapping up

The work we do is hard.

What’s harder is following through on our work. Doing the work is only one aspect of what we need to do to be effective in our jobs. There’s a reason that good communication skills are listed in nearly every job description I have ever seen and that’s because our work requires it to follow through to completion. Failing to follow through with good communication is no different than a baseball player failing to swing the bat through a pitch just because contact has already been made in the middle. Without follow-through, our work is more of a bunt than a clean hit.

What we covered in this post are tricks specific to the follow-through of our work. Keep doing the awesome work you do and supplement it with these ideas to take things to the next level. That’s what good feedback does: it takes what we’re doing right and elevates it to even higher places. Hopefully these “tricks” will kickstart great conversations that improve your work, lead to new tricks, bring clarity to the project management process, and allow you to build awesome and collaborative relationships with others along the way.

The Challenge of Constructive Criticism and How to Get It is a post from CSS-Tricks