1. Set the context
Many of the reasons stakeholder feedback and comments are not helpful to the organisation because their comments are not appropriate at the current stage of a given process. This is especially true at the beginning, 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.
2. Be explicit
Giving stakeholders an open-ended instruction like ―send me feedback by end of day‖ 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, 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 issues that need consensus.
3. Allow, but track detailed feedback separately
While organisation employees may feel worked up by stakeholders providing trivial feedback but that feedback may ultimately be valuable. Plus, it‘s important to give stakeholders an outlet for documenting little details that are important to them, so they can then move on and look at other core things. 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 open ended question. 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.
4. Provide general instructions and example
Frustrations may occur when stakeholders don‘t give enough feedback. They may be hesitant about being too critical -perhaps because they simply assume that stakeholders 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.
5. Make providing feedback easy
Everyone is busy. The organisation should 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 should be 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.
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.‖
Stakeholders bring their unique perspectives to a project, and their feedback can help an organisation understand a 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.
