Inevitable risks of creating recommendations in UX research

The generation of design recommendations within full-format research reports has become a standard expected by the vast majority of stakeholders. Their inclusion supports the smooth start of subsequent stages of product iteration, allows selected recommendations to be easily queued in the task management system, or sheds new light on potentially known problems.

Such recommendations most often take the form of either specifically defined solutions (e.g. add a clear explanation of item X in the form of a system message) or potential directions for further exploration (e.g. consider splitting step Y in the purchase process into two separate steps). The creation of appropriate recommendations is supported by knowledge of areas of digital product creation such as:

• The practice of designing in accordance with the human psyche.
• The landscape and business specificity of the product.
• Explicit and implicit technological constraints.

Although as researchers we try to keep our knowledge of design and psychology up to date, consume countless company reports and competitor products, and methodically acquire knowledge of the past, present and future of tested solutions, we are often unable to get a complete picture of the tested product. It is often the case that we do not know what we do not know, and the potential path to knowledge is not strewn with roses.

This situation can occur both when working within a product and when working with an agency. However, we experience it much more often in agency work, where we do not have easy access to the client's product knowledge (different product roles are not at our fingertips), and because of the importance attached to the report itself, as it is often the only artefact our stakeholders will encounter.

The risk of making a recommendation that is inappropriate or simply wrong from the project's point of view is high and has several painful consequences, the most important of which are loss of credibility and limitation of the project's horizon.

As researchers, we pay attention to methodological correctness, which allows us to get closer to the reality as seen by the users. We do everything we can to ensure that our data are reliable and credible — we try to be objective in planning, conducting and analysing research. But when it comes to making recommendations, we have to transform ourselves and move beyond our stoic, objective researcher pose. We put on our designer shoes and switch on the subjective mode of reasoning, which is inherently more error-prone. The potential for error is compounded by the aforementioned lack of a complete picture of the product being tested. The switch between an objective and a subjective researcher may be imperceptible to the recipients of the study. Steve Bromley has written about mixing objective data with subjective opinion:

A well run study will uncover facts that allow all of these points to be answered. Those answers will be supported by data, and objectively true. This is in contrast to the decision about 'what should we do as a result of learning this', which has many potential answers, and opinions about which is the best action can often be subjective.

The mixing of modes of thinking and potential doubts about design recommendations that are not grounded in reality can pave the way for thinking that questions other aspects of the research process and the researcher's own competence.

The meeting that sums up the research project is a specific tool for change aimed at the evaluated part of the product. Under certain conditions, we meet with a group of stakeholders to present them with problematic experiences that accompany users when using a given product. What we say matters, and our narrative influences the recipients' perception of the problems. The design recommendations we make can, at certain moments, become blockers to solutions that go beyond the outlined framework. The designers or product team may become fixated on the proposed solutions and abandon the exploration of other, potentially better solutions to problem situations.

The presence of product recommendations in research reports is standard, as the benefits of their presence outweigh any potential drawbacks. To minimise potential problems with the acceptance of recommendations, it is worth defining them clearly and designing the research process accordingly.

Product recommendations are not a set of rules to be followed. Their purpose is to set the pace and direction of product and service change. Ultimately, the product team should decide on the final solutions based on their expertise and domain knowledge. To ensure that recommendations are not perceived as threatening or definitive, it is worth explaining their role at the very beginning of the research presentation meeting.

At the end of the research project, the product team will try to turn the recorded observations and recommendations into concrete solutions. The researcher is often absent from this stage (especially in the consultation format), despite having spent hours talking to users and developing explicit and implicit knowledge about their behaviour, needs and motivations. It is worth considering designing the research process so that it ends with workshops focused on generating specific solutions. During such a focused meeting, the researcher, in the role of facilitator, supports the product team in working with the research material and evangelises the user perspective.

Workshops for the co-creation of design solutions:

• Supports the integration of research into the production process — the product team does not have to wait until a full report is ready to start work.
• Increases trust in the researcher, who becomes part of the team working to improve the product.
• Evangelises research within the organisation by exposing and involving team members in research activities.

Recommendations in UX research are only a means to an end, which is to improve the tested solution. It is certainly not a perfect means — when using it we should be clear and transparent about the limitations we are dealing with. Nor is it the only means, as the process of solution-finding workshops outlined here shows. Whatever the approach, it is worth remembering that our methods should be adapted to the widely understood context of use and communicated appropriately.