Mistakes Were Made
A seasoned digital project manager’s guide to getting helpful feedback and coping with the rest
I’ve been working on web and software development projects since Netscape Navigator was the most popular search engine, and I have a confession to make. For most of that time, I hated the process of getting feedback from stakeholders, especially on visual design work. The reason for this is that stakeholders were always providing “the wrong” feedback, and I did not know how to navigate that situation.
It made me feel icky when I would deliver what I thought was a solution to the stakeholder’s problem, and they would respond with feedback that seemed completely sideways to what we were trying to achieve.
Eventually, I realized that the issue was that there were a lot of unspoken assumptions and expectations right from the beginning.
So, in order to avoid all this discomfort, I’ve developed some techniques for getting helpful feedback. I don’t always take the trouble to use these methods, but when I do, it does seem to help everyone feel better about getting (and giving!) feedback. Happily, this applies to all sorts of situations, not just design projects.
Step 1: Build context
At the beginning of any engagement, everyone comes to the table with a set of assumptions in place. Stakeholders have assumptions about the content of the project that are flavored by their deep experience with the subject matter. You have assumptions about your process and methods. And everyone has a set of assumptions about how the project will work, how you will communicate with each other, what tasks each party is responsible for, and what that means in practice. There is no giant, governing blueprint in the sky for how these things work, and yet people seem to approach many situations as though there is.
You can tackle this by getting what seems obvious to you out of the way right off the bat. It’s like when flight attendants used to get on the loudspeaker at the beginning of the flight and say something like, “This is flight XYZ to Denver, Colorado. Please confirm that you mean to travel to Denver.” Why? Because plenty of befuddled travelers have clearly wandered onto the wrong flight in the past and woke up very unhappy in Denver. For a project, this might mean a slide early in the kickoff deck that covers the basics of the project’s scope.
Pro tip: if there is something that can be counted, state those numbers. For example, the number of participants in a research project, or the number of pages included in the design project, or the number of weeks the project will take. This is a common point of contention that you can snuff right out by putting all cards on the table ASAP.
Once the obvious is out of the way, I invite you to go deeper and try to root out stakeholder’s and your own unspoken, perhaps unconscious assumptions. Some ideas:
- What are the business goals driving the project?
- Are there any stakeholders that are not present? What are their goals?
- How often would you/they like to meet or be updated on progress?
- How many rounds of review would they/you like?
- What sort of feedback are you/they hoping to give/get?
- Are there any threats to the schedule? Holidays? Vacations?
- What happens if something goes wrong?
For particularly complex projects, you might even do a SWOT analysis brainstorming activity in the kickoff.
Another helpful activity is the RACI chart, which sounds like more fun than it really is. As with all tools, it is not necessary to use its name with stakeholders as long as you capture the spirit of the thing, which is to define people’s roles for the project. Specifically, who will provide feedback and from what perspective?
Pro tip: if you can, take this opportunity to ask your stakeholders to nominate an aggregator of feedback for all reviewers so that you don’t have to try and reconcile conflicting comments yourself. Trust me, this is better left up to stakeholders.
Step 2: Have a rubric
I mentioned visual design earlier because it’s a process that people can have a lot of unconscious ideas about. I’ve seen it happen more than once: teams submit a perfectly good visual design that’s effective and usable only to have a stakeholder hate it because they don’t like something about it that was not part of the initial requirements. It’s very frustrating for everyone!
With visual design, this comes up a lot since people seem to have visceral reactions about aesthetics. Take it from me, it’s pretty difficult to recover when stakeholders have that visceral negative reaction and you haven’t prepared for it.
The way to prepare for it is to create and agree to a scorecard or rubric early in the project. This can be part of the kickoff and discovery process. It can be simple or complex, depending on how complicated the subject matter is.
One way I’ve done this in the past is by having a document with a table in it. The first column is a list of documents, pages, templates or whatever is being reviewed. Then there are additional columns for each previously-agreed-upon success criteria, a column for qualitative notes, and a final column for overall performance. You could use a Likert scale for each criterion and average that to get the final grade for each unit of analysis, like this:
Or you could do it differently depending on the situation and the people involved. The details of this rubric are less important than having a rubric plus alignment with each stakeholder on its components.
Having an explicitly articulated list of goals with clearly defined success criteria is a really great way to allow everyone involved to feel like they are on the same team working toward the same goal. Best of all, it allows stakeholders to provide feedback that is relevant to the goals that you’ve agreed on. If you have someone in that aggregator role, it’s easier for them to notice conflicting feedback as well.
To be clear, this framework is helpful but not foolproof. Someone still may pop out with feedback that doesn’t make any sense or is based on a visceral reaction. However, the rubric can be used to shape conversations about it if that happens. In my experience, if you go through the process of coming to explicit alignment about the goals and build a rubric, stakeholders who want to step outside of that will usually acknowledge that’s what they are doing and work with you on it. Which brings me to the next point.
Step 3: Assume positive intent & be gentle
Most people are doing their best and are not motivated by nefarious schemes to demean and degrade us. Yet, in life, business, and especially with remote work, it is very easy to fall into a suspicious and defensive mindset due to common cognitive distortions. Going to therapy is helpful to combat this, but in the meantime, we can all benefit from assuming positive intent by default.
In the UX consulting business, it feels like there is nothing like getting feedback to really kick up those cognitive distortions and put us on the defensive. So, it is good practice whenever receiving feedback in any setting to remind oneself that this person is probably not a sociopath who is out to get us. In fact, much of what they say is more about them than it is about your work, especially when the feedback is conflicting, confusing, or irrelevant. Reviewers are just as prone to cognitive distortions as anyone else.
On the flip side, giving feedback can sometimes also produce surprising emotions for people, because–especially without a pre-defined rubric–a reviewer may find herself uncovering her own hidden expectations that are not being met. This sensation of unmet expectations can produce outrage sometimes, which might then seep into the tone of your feedback making it disproportionately negative or harsh.
So, if you find yourself in the role of providing feedback, this too is an opportunity to assume positive intent and give people the benefit of the doubt. Ask yourself if the person knew what your expectations were or if it was reasonable for you to assume that they would. Either way, try to be gentle and judicious with criticism. It is not easy for most people to receive it. I try to evaluate my feedback by asking myself the 3 questions from another old adage:
- Is it kind?
- Is it necessary?
- Is it true?
If the answer to any of the above questions is no, then that feedback is probably not worth giving.
