Top

Getting the Right Stakeholder Feedback at the Right Time

Research That Works

Innovative approaches to research that informs design

A column by Michael Hawley
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.

Champion Advertisement
Continue Reading…

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.

  1. 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—Right focus of feedback at various stages in design process
Right focus of feedback at various stages in design process
  1. 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.

  1. 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.

  1. 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.
  1. 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.”

Conclusion

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. 

Chief Design Officer at Mad*Pow Media Solutions LLC

Adjunct Professor at Bentley University

Boston, Massachusetts, USA

Michael HawleyAs Chief Design Officer at Mad*Pow, Mike brings deep expertise in user experience research, usability, and design to Mad*Pow clients, providing tremendous customer value. Prior to joining Mad*Pow, Mike served as Usability Project Manager for Staples, Inc., in Framingham, Massachusetts. He led their design projects for customer-facing materials, including e-commerce and Web sites, marketing communications, and print materials. Previously, Mike worked at the Bentley College Design and Usability Center as a Usability Research Consultant. He was responsible for planning, executing, and analyzing the user experience for corporate clients. At Avitage, he served as the lead designer and developer for an online Webcast application. Mike received an M.S. in Human Factors in Information Design from Bentley College McCallum Graduate School of Business in Waltham, Massachusetts, and has more than 13 years of usability experience.  Read More

Other Columns by Michael Hawley

Other Articles on Design Process

New on UXmatters