Getting the Right Stakeholder Feedback at the Right Time
Published: July 4, 2011
Consider the following scenario: You are the UX lead on a project. You’ve completed some business intelligence and foundational user research activities to inform a series of brainstorming and idea-generating sessions. Following the brainstorming, you sketched the basis for a design solution in a series of wireframes and presented the concepts to business stakeholders. You have a tight timeline on the project, but you recognize that the stakeholders need to absorb the concepts for a day or two, so they can provide appropriate comments. Following your concept presentation on a Tuesday morning, you told stakeholders to “send me feedback by end of day Thursday.” You walked out of the meeting feeling confident.
It seemed as though the stakeholders found the concepts and ideas embodied in your wireframes engaging. You were hopeful that stakeholders would provide meaningful comments on your designs—letting you know, for example, whether the designs align with business goals, there are unaddressed requirements, or there are any potential issues with the workflows or navigation.
However, when you received their email messages Thursday night, you found little feedback. Plus, the comments you did get were about things like the size of the logo, the language you used in labeling some of the form fields, and opinions about what colors certain items should be. When you’re just at the wireframe stage, this is not the type of feedback you’re looking for! You’ve started to worry that perhaps the stakeholders did not think very critically about the design, so issues might surface later in the project. Now the project is behind schedule, and you’re stressed out. What went wrong?
The Importance of Stakeholder Feedback
In the previous scenario, everything started off right. Generating consensus and buy-in from stakeholders is a key to success for most design projects, so you were right to reach out to them. UX professionals are generally wary of stakeholder design, where stakeholders simply tell the UX lead what to put into a design. But you can avoid stakeholder design and still get healthy input from your business and development partners in the design process.
I’ve found that the feedback process works best when you have an opportunity to present your design ideas, then give stakeholders the opportunity to absorb the concepts and details inherent in your design. This may take some extra time in the project schedule, but it’s worth it to allow stakeholders to thoughtfully review the designs and potentially review them with other colleagues. Plus, setting specific deadlines is good project management and helps keep momentum on a project going.
The breakdown in this scenario occurred when the UX lead simply asked stakeholders to “send me feedback.” That simple instruction reflects many assumptions about stakeholder’s knowledge of the design process, areas of emphasis, and outstanding questions about the design. It’s a common mistake for UX designers, because they are familiar with the design process. Good designers understand how to provide a meaningful critique of creative ideas and recognize what level of feedback is important at various stages of the design process. Because stakeholders have a sense of ownership of a design, UX designers often assume stakeholders have these same skills and can think critically about important aspects of design and provide constructive feedback that would help improve a design. Sometimes this is a safe assumption, but not always.
5 Steps to Better Stakeholder Feedback
Fortunately, there are some simple steps UX leads can take to ensure that stakeholder feedback takes an appropriate direction.
- Set the context. In my experience, many of the reasons stakeholder feedback and comments are not helpful to designers is because their comments are not appropriate at the current stage of a design process. This is especially true at the beginning of design, when a team should focus on interaction paradigms, high-level concepts, and the overall infrastructure of a design solution. This is not necessarily the fault of the reviewer. They may not be used to looking at low-fidelity wireframes or understand when in the process the team might be able to change certain things.
You can overcome this challenge by clarifying what is the current stage of your design process and the type of feedback that is most appropriate at that stage. A simple diagram, like that shown in Figure 1, can be very helpful in explaining what is appropriate for the current stage of review and provides a preview of the types of stakeholder feedback that will be most appropriate at later phases.
Figure 1—What feedback should focus on at various stages in the design process
- Be explicit—to a point. Giving stakeholders an open-ended instruction like “send me feedback by end of day Thursday” may seem like a good way to minimize bias in the solicitation of feedback. However, given the timeframes of projects and the various possible interpretations of these instructions, I’ve found it is most helpful to list key questions or areas that stakeholders should comment on. By asking questions or simply listing areas on which you need feedback, you can guide stakeholders to providing feedback on the highest-priority design issues that need consensus. Examples of some questions might be:
- Will the design meet the business goals for the project? Why or why not?
- Please comment on the order of the proposed transactional flow.
- Are there any parts of the design that would require significantly more development resources than planned?
- Are there any design elements that legal should review?
Don’t overwhelm stakeholders with too many questions. Three to five of your most important questions should help focus their feedback. Also, start your questions with a general question about stakeholders’ overall impression of a design. Their overall assessment of the design helps frame their responses to your other questions and gives them the opportunity to highlight their major considerations regarding your design direction.
- Allow, but track detailed design feedback separately. While UX designers may get frustrated when they receive feedback relating to design details like colors or line spacing early in the design process, that feedback may ultimately be valuable. Plus, it’s important to give stakeholders an outlet for documenting little design details that are important to them, so they can then move on and look at other elements of a design.
As part of the feedback process, provide a separate mechanism—in addition to your obtaining answers to your key questions—for stakeholders to provide any comments they would like to make about your design. This can be as simple as your asking an additional question such as Are there any other comments you have about the design? This gives stakeholders an outlet for providing this kind of information and effectively refocuses their attention on the primary questions of interest at the current stage of the design process.
- Provide general instructions and examples. One of the biggest frustrations for UX designers is when stakeholders or nondesigners prescribe solutions like “Make the circles all shades of one color” rather than describing an underlying problem—“It’s tough to see trends in the data because there are too many colors.” This is not the fault of the person giving the feedback. Often, stakeholders don’t understand the role of designers in solving design problems and are trying to help.
On the other hand, frustrations also occur when stakeholders don’t give enough feedback. They may be hesitant about being too critical—perhaps because they don’t understand the design process or simply assume a designer will recognize issues through the course of the project.
The best way to avoid these types of situations is to give stakeholders explicit instructions when asking for feedback. Your instructions should be brief and to the point, generic enough to avoid bias in relation to a particular design, and include examples where possible. Here is an example of some instructions you might provide:
- Be honest. Don’t worry about my feelings. If you see something that ’t look quite right, better to tell me now rather than later.
- Don’t just say something is good or bad. Tell me why. For example:
- Not helpful: This is great!
- Helpful: The placement of the controls next to the graphs makes it easy to understand.
- Not helpful: It’s too busy.
- Helpful: There are a lot of promotional areas on the page, and I am finding it hard to focus on our key message which is…
- Describe the problem rather than the solution. There may be multiple solutions to a problem that we can work through together. For example:
- Not helpful: Change the color to red.
- Helpful: I am having a hard time reading the text against the background.
- Not helpful: Move the navigation to the top.
- Helpful: I don’t think it’s easy to know where you are in the application.
- Make providing feedback easy. Everyone is busy. In my experience, most stakeholders would prefer that a magical UX designer would read their minds and get everything right without taking any of their time. Although this is unrealistic in most circumstances, as UX designers, we should own the design, value stakeholders’ time, and consult and get feedback from stakeholders as efficiently as possible.
Steps 1–4 outlined some questions and instructions we should include in a request for feedback. However, your request need not be a long, drawn-out form or a multi-page document comprising instructions and lists of questions. Keep your request short and to the point, so your audience will actually read it. For your request’s format, consider using one of the following:
- online survey—This lets you provide very explicit instructions, ask clear questions, collect feedback in a very consistent manner, and consolidate comments easily, avoiding collections of comments scattered across various email threads. One drawback is that this does take a bit of setup and may not be convenient for stakeholders.
- feedback service—Several online tools allow interactive commenting, provide version control, and offer a central place for various stakeholders to view consolidated comments. There are a number of different tools to choose from, offering various features and functions. The article “21 Resources for Getting Design Feedback” describes a number of them.
- email—Since this is what stakeholders use most often, it’s likely the most convenient option for them. A simple, concise email message asking your key questions and providing clear instructions goes a long way toward avoiding the problems you might encounter if you simply ask stakeholders to “send me feedback by end of day Thursday.”
Efficient, effective collaboration between UX designers and stakeholders is an essential ingredient of a successful project. Stakeholders bring their unique perspectives to a project, and their feedback can help a designer understand the design problem space and develop solutions that align with business and technology objectives. But simply asking stakeholders for feedback can lead to misaligned expectations and communication problems. By being thoughtful in how you make your request for feedback and by providing simple questions and instructions, you can ensure that you identify potential risks early in the design process, minimize stress, meet your deadlines, and ultimately design a better solution.