Providing Better UX Recommendations

Will You Remain on the Project?

What will happen after you deliver your findings and recommendations? If you remain on the project, you’ll be around to answer questions and help the designers and developers on the team to implement your recommendations. If the team finds that they cannot implement your initial recommendations, you’ll be able to provide alternative solutions. However, if you’re going to leave the project once you’ve delivered your recommendations, you need to ensure that your findings and recommendations are extremely understandable, self-explanatory, specific, and actionable 

Who Is the Designer?

In some situations, you’ll be both the researcher and the designer. In that case, your recommendations inform the project team and your client about what you plan to design or change in the next iteration or release. You’re seeking their approval to make these changes.

When you’re a researcher who is working with a designer on a project, you should work together to discuss each problem and formulate a solution. Don’t propose a recommended solution without first consulting the designer because it could conflict with the way he or she wants to solve the problem. While some problems have obvious, single solutions, other problems have multiple possible solutions. In the latter case, you don’t want your recommendations to be too prescriptive.

Qualities of Good Recommendations

In addition to the considerations I’ve already discussed, effective recommendations should be understandable, concise, specific, believable, authoritative, actionable, feasible, flexible, prioritized, and easy to review. Let’s examine each of these characteristics in more detail.

Understandable

Since recommendations describe the actions that are necessary to solve problems, people often refer back to recommendations while working on a solution. In contrast, they typically read the findings only once. So recommendations must be easily understandable without the reader having to go back and reread the findings. Since you won’t always be around to explain your recommendations, they need to be as clear and understandable as possible to avoid any possible misinterpretation.

Concise

Findings may be long and detailed, but recommendations should be concise and succinct. Keep any unnecessary explanations out of your recommendations. Instead, put the background details in your findings. Split longer, more complicated recommendations into smaller subpoints.

Specific

In some cases, recommendations must state specifically how to fix a problem, while in other cases, it makes sense just to provide a more general direction. This may sound kind of wishy-washy, but the degree of specificity that is necessary depends on the nature of the finding and the audience for the recommendation.

Some problems have obvious solutions, so a very specific recommendation is appropriate. A simple example would be when a link leads to a page with a title that is completely different from the link label. The obvious solution for greater consistency would be to make the link label and page title match.

Many problems have multiple, possible solutions, so it might not make sense to dictate one particular solution. This is especially true when there is a UX designer who needs to understand the problem, then use his or her skills to solve it. For example, if you’re a consultant doing research and providing recommendations to your client’s designer, you might not want to prescribe one specific solution if there are multiple, acceptable ways of solving the problem.

One example of such a problem might be that people didn’t notice a shopping-cart button. Your recommendations might be to use a more conventional shopping-cart icon, add a text label for the shopping cart, and make the shopping cart stand out more prominently from the other elements on the page. These recommendations are specific enough. Do not specify the exact icon, text, and colors to use. Recommendations convey what kinds of changes are important to make without specifying the exact design.

Believable

The audience has to believe that the recommendations will solve the problems. The explanation of each problem does much to build up this believability. The recommendations should flow naturally from that. For example, showing that a problem violates design standards and conventions is a natural way to introduce recommendations that follow those standards and conventions.

Authoritative

At a company where I previously worked, management once questioned whether we should use the term recommendation. They felt that recommendation made it seem like something was just a suggestion rather than an authoritative direction: Do this! This occurred during a project for which we believed the stakeholders might object to our recommendations.

I agree that recommendations should be authoritative, but their authority should come from your expert judgment and the quality of your findings. When presenting your findings and sensible recommendations, you’re arguing that your recommendations should be implemented, but they’re still recommendations, not commands. In most cases, you’re not the final decision maker. You’re not the product manager, the client, or the CEO. You’re a user experience expert, and you provide authoritative recommendations, but a company must weigh them against other legitimate concerns such as business goals, technical limitations, cost, and time to implement.

Actionable

Recommendations should either specify the exact actions that are necessary to solve the problem, or they should provide enough guidance for a designer to design a solution that solves the problem. After reading your recommendations, stakeholders should know what to do—especially when you won’t be around to answer questions later on.

However, in some cases, you can’t recommend a simple solution. Some problems are so complex or poorly understood that more research would be necessary. In other situations, the problem is well understood, but there isn’t an easy solution. Devising an optimal solution might require more thought and further design explorations. It is not possible to solve all problems based on just the recommendations in the text of a report or presentation. For more complex problems, it may be appropriate to recommend either conducting further research to better understand the problem or spending more time sketching out possible solutions.

Feasible

Recommendations should be realistic and feasible, so your team can implement them. If you recommend something they can’t implement, they’ll usually find an alternative solution that they can implement, but might not be the best solution. If possible, first review your recommendations with a developer to make sure they’re technically feasible, then create your report.

However, this doesn’t mean that you should water down all of your recommendations to the easiest, least expensive fixes. Provide both your ideal recommendation and a short-term fix. For example, the ideal solution to an extremely confusing Web site might be to do a complete redesign of the information architecture. But since you know there won’t be time to do that for a long time, you could also recommend some simpler, short-term improvements in labeling and navigation.

If you provide only ideal recommendations, the team might dismiss them as too difficult to implement or think of them only as something to do far in the future, and therefore, not make any changes. On the other hand, if you provide only short-term recommendations, they’ll just make those limited changes and never tackle the real problems. Providing both short-term and ideal recommendations allows the team to make some progress now, but also plan a more extensive redesign in the future.

Flexible

Just because you’ve typed up your recommendations in a report or presentation that doesn’t mean they should be carved in stone. Recommendations should be flexible enough to change them based on new information.

Sometimes, during your findings presentation, you’ll learn new information that makes some of your findings and recommendations obsolete. For example, there may have been a technical issue that caused a problem, which has since been fixed. Or you might learn about a business requirement, legal issue, or technical constraint that requires you to change your recommendation.

It’s okay to revise your recommendations as you learn new things. A findings presentation is usually the first time you’ll discuss the details of your findings with the entire project team. So it’s natural that you would learn new things. It’s okay to go back and make revisions to your recommendations based on this new information.

Prioritized

Receiving a long list of problems and their recommended solutions is overwhelming. Most project teams can’t immediately solve every issue. So which ones should they focus on first? Which problems are most severe and which can wait until later?

It’s important to prioritize your findings and recommendations, indicating whether problems are low-, medium-, or high-priority fixes. This prioritization should be based on your judgment of the severity of the impact of the problems on users and will help the project team decide which issues to fix first. The team may, in turn, want to do their own prioritization of which problems to tackle first on the basis of both your prioritization and business needs.

Easy to Review

Your recommendations should be easy for a project team to review after seeing your initial presentation. Most people review the full findings and recommendations only once. Yet, they refer back to the recommendations frequently as action items to implement. However, it can be difficult to review recommendations when they’re interspersed with other information in various places throughout a report or presentation.

A helpful solution is to create a summary list of recommendations at the end of your deliverable. This makes it easier for the project team to see all the recommendations in one place when discussing how to implement them.

Another option is to create an additional recommendations document, either in a spreadsheet or a Word document, listing the recommendations within a table. You might include columns for a brief description of the findings, the priority of each recommendation, and a recommendation number. This format makes it even easier for the project team to review, prioritize, assign, and track your recommendations.

Get Feedback on Your Recommendations

Lastly, to improve the quality of your recommendations, get feedback on how well they’ve worked for your audience. You can either ask your team directly or judge the quality of your recommendations by how well they’re implemented. Some questions to ask yourself include the following:

• Did people understand the recommendations or did you get a lot of questions about them?
• Were the recommendations convincing or were there a lot of disputes and alternative opinions?
• Were the recommendations realistic or did you find that some of them were not feasible so could not be implemented?
• Did you have to make many revisions to your recommendations?
• How many of your recommendations were eventually implemented and were they implemented correctly?

Ultimately, the effectiveness of your recommendations depends on whether they convinced people to implement them, whether the team implemented them correctly, and how much they improved the user experience.