The beginning of the discovery process was a success. A very thorough picture of the workflow and the different functions of each process was presented by collaborators from the client. However, during the first tests and interviews, users were ill-at-ease and not very productive. They were not willing to adapt to the product before their eyes. What happened in between?
Users cannot be blamed for these drawbacks. Very often, two types of gaps appear when first approaching the business’ problems. On the one hand, subject matter experts –maybe the company’s founder or a leader who has been with the company for decades– believe they know and control every twist and turn of each process, and are sure they know every weak point, every user need, and what changes are necessary. Therefore, they describe things exactly as they consider they are done or should be done.
But out in the field, reality is different. For various reasons –convenience, issues with the context, limitations– and to make up for the weaknesses of the system, end users gradually introduced imperceptible –or not– changes that were incorporated into the process flow without being noticed by the business leader. We have seen collaborators writing post-it notes with instructions to complete steps that are difficult to comprehend, but anyway need to be completed. They even cut and paste texts written in Word, to complete parts of a report. These are merely two examples of a wide range of inefficiencies, complexities and actions intended to correct errors.
Irrelevance bias
There is an additional bias. It occurs due to things collaborators deems irrelevant or are taken for granted by everyone, so nobody bothers to communicate them. But, maybe, the team responsible for discovery should be informed. Probably, the team does not have a thorough knowledge of the industry in general or the company at that moment in particular. That is why it is necessary to monitor the processes and experiences, and gather first-hand information through various means, such as tests with users run in the same usage context.
For example, from our experience with a client we learned that a solution implemented in a diary farm to upload data probably requires a special device that the person in charge should handle wearing gloves. But, no doubt, they must already wear gloves in an environment filled with mud and dust. In another example, in order to facilitate the operation of a work group, a tool is devised that will sound an audible alert when something specific happens. This idea, that could represent a leap in productivity in many areas, is not practicable in factories that are bustling with noise, and workers need hear pieces.
The product team must be familiar with all the experience acquired about usage and processes that the product is supporting or replacing, in order to generate an alignment between what the business needs and the experience acquired, which, in turn, will lead to greater engagement and user productivity.
The difference is in the details
One of the goals of the UX designer is to detect the details that will make it possible to transform a standard, functional interface into an experience consistent with the needs of each user. The true difference is in the details.
How can these gaps be bridged? Firstly, by understanding that communication is neither one-sided nor passive. It is true that the company’s leader will aim to find a solution that focuses on the key issues that need to be addressed during the development stage. However, it is up to the product team (designer, product manager or analyst, architect, tech leader) to ask the right questions, explore alternative paths and refine the initial material. Usually, the result of this exchange is reviewed to find aspects that need to be perfected, new doubts or questions, or even a new product strategy or direction.
Secondly, end users should be approached to establish a dialogue, test the hypotheses about workflow and detect pain points. The ideal would be for these tests to be conducted in the same conditions in which the products will be used. Otherwise, there are mechanisms and techniques to generate more accurate approximations.
Read between the lines
At all times, the research process must be empathetic with both the stakeholder and the end user, and the team must develop the capacity to arrange ideas and, fundamentally, read between the lines. This is a soft skill that is not mentioned often, but is essential to set up a product team. No matter how clearly they explain a given process to us, or give us details about a requirement or idea, there is a lot of information in what is not said.
When ideas become sketches, and sketches become prototypes, the time has come to test them. And that is another challenge. Very often, we have the misguided idea that testing delays the process of going live, and we are caught in our anxiety. Reality proves otherwise: a flawed or inexistent test may result in the end user receiving a tool that is not quite the right one for the job, and that would affect usage or engagement when it is used.
In conclusion, when we are developing digital products/applications, the gap between what the decision maker imagines and what end users receive can be bridged with the good practices of an empathetic UX expert who is capable of reading between the lines, pays attention to the environment and is open to continually refining the proposal.