Giving Feedback: UX Deliverables

I was talking with another experience architect yesterday about how often we get feedback on our deliverables that contradicts either other items in the same feedback document or feedback we received earlier. Sometimes, feedback is so cryptic that we aren’t sure what’s even being requested. It’s frustrating because we want our clients to feel like we’re listening to and acting on their feedback.

Thinking back to previous projects, we found that some processes work better than others. Here are some tips for helping your client (or yourself) give good feedback on UX deliverables.

Use a Feedback Template

What seems to work the best is provide your client with a feedback template. We’ve done this in Excel with success, but don’t always remember to set up the process ahead of time. The idea is to have each page of the wireframes (or section of the sitemap, feature of the prototype, etc.) listed with columns for the requested change, the change requester (so important), priority of the change, and an area for the person receiving the feedback to respond. What’s great is that over the course of the project, you have a full picture of changes that have been made. That way, when someone who has been involved sporadically on a project says, “Why’d you change x?”, you can say, “That change was requested by y on this date.” It also helps to be able to say that feedback you’re getting in a round 2 review contradicts feedback in round 1. You’ll probably still end up making the change, but it helps to show your clients them these instances. Maybe next time they’ll be sure to hear from a senior manager in round 1 instead of waiting. One can dream.

Don’t Tie Feedback to Page Numbers

This happens so many times that you’d think I’d never forget to mention it to clients. Unfortunately, I do. I receive a lot of e-mails that request a change or two on a page referenced only by it’s page number. What makes this problematic is that often you end up re-order, adding, and deleting pages over the course of a project and it can be unclear which page actually needs the change. If you don’t want to spend your time digging up older versions and trying to figure our what pages were numbered before, use a unique reference for each page (or item in a feature and functions list) and never, ever change it. Never.

Consolidate Feedback Before Making Changes

Let’s say you get some feedback in person at a review session and will then be wating a few days before you get your feedback spreadsheet back from the client. Should you make the changes you’re sure about? If you get feedback from some stakeholders ahead of the deadline, should you start revising? Deadlines always make us do crazy things, but the answer should be no. I find that unless something is just so obviously wrong that it must be changed, this leads to a lot of rework. For instance, you might hear that some wording needs to change, so you make a first attempt at changing it. Then, you get one stakeholder telling your it should be something else and then another suggestion for the change. You could end up making the same change 3 times when what you really needed to do was ask the client to look at the two suggestions they gave, look at your recommendation, and tell you their preference. In the long run, time is saved.

Be Explicit About What Kind of Feedback Will Be Implemented and When

I worked with a team within a company I worked for on some translations for an international marketing website. Round after round, we would get more and more changes on text that had previously been reviewed an approved. Unable to read the text myself, I wasn’t sure if the translations were wrong or if the reviewers just didn’t like it. As we got closer to launch, I had to draw a line in the sand. I told them that each requested changed needed to me marked as inaccurate translation or preferred wording. We’d make the translation changes before launch and do a preferred wording fix post launch. This gave reviewers more time to think about exactly what they wanted to say and let us launch on time. In other situations, I’ve had to ask specific reviewers to focus only on items which they are responsible for so that a developer isn’t wasting time commenting on marketing copy that has already been approved by a subject matter expert.

Help the PM Help You

If you are fortunate enough to be working with a PM on a project, let them know how they can help you collect and clarify feedback. You might ask them to take a first pass at consolidating feedback and finding any contradictions. They can also help you push back when the requested change is out of scope or, because it will be the 3rd time you’ve changed the same thing, needs a change order. I find that PMs often aren’t sure how to support UX work, so let them know how you see the process working and where they can help the most. For me, feedback that starts with, “We need to find out, ” or “Is the system able to support…” is clearly for the PM. When you’re on a tight deadline and need to make lots of changes, let the PM get the answers and focus on the things you can do now. Otherwise you might be dragged down a rabbit hole and end up very frustrated at 3 a.m. making mistakes you normally wouldn’t.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s