How to scale and communicate research findings across teams
For any technology research professional, it is not news that UX Research and Agile go hand in hand in many contexts. Processes like the Sprint give the researcher the time and some requirements to prepare, conduct, analyze and consolidate information it receives from different sources of knowledge.
At UX Research, our repertoire is a qualitative myriad of paths and directions. And we give quality to everything from the perspective of use and user. Qualitative capacity is precisely there: in the various possible conditions and in the story they tell. When we conduct an interview to understand the user’s view, we are, in a way, encoding experiences through a story that informs about the process we are investigating.
In other words, we’re reducing information that was once scattered into categories that are easy to identify and act on.
Qualitative research and interpretive induction (we’ll explain on the way)
In research, we have some depths of knowledge that have already been well discussed. In addition to qualitative and quantitative, there is information on objective, subjective and/or deductive/inductive magnitudes, all working together to form a detailed story.
More specifically, induction is a philosophical-scientific assumption that contemplates answers through direct observations. Remember Socrates and Aristotle? That’s how they did it.
A quick example is what we studied about the evolution of atomic models in chemistry classes. For those who remember, the Greek philosophers induced that there was an indivisible sphere, called an atom — ἄτομος. There was still no scientific system to describe the reason for this indivisibility that they claimed was the central feature. It was through non-systematic observation that they induced it.
It is worth remembering that inductive information is not necessarily qualitative. For example, if you ask a child to estimate the number of candies in a jar, he will induce quantitative information.
Okay, where are we going with this?
When we use our much-loved qualitative method for research, many times UX Researchers from various fronts and perspectives end up using observational induction in order to check and classify the qualities we are talking about.
An example? Conduct an interview, organize a group of qualitative information and separate and group the information, based on the natural induction of the person or persons researching the meaning of the information. We use categories whose structures are based on our knowledge along with our personal experiences and past research. Empathy/affinity maps work like this and we’ll talk more about them later.
Deductive vs. Inductive
In the academic universe, the construction and references to information is done through the description of existing knowledge conveyed under a formatting standard, such as ABNT, APA, etc. In this way, when we argue something in the text and insert it, for example (Author, 2021), those who read us can look for references that support the argument in question at the end of the scientific work.
Also in the early days of the academic world, much was discussed about the heritage of Greco-Roman philosophy and knowledge; authors such as Plato and ancient historians such as Livy, often based their findings by inducing observations, telling stories that slowly formed an explanatory puzzle of why such an object, feeling, action, exists as it does. Intuition is great for us to be able to position ourselves in the world in relation to our references and thoughts, it helps us to better organize our thoughts and associate previously known information in relation to some new knowledge. Induction, or intuition, was, however, discarded by the empirical method as science consolidated itself as a discipline.
How can we build knowledge from facts that are only in other people’s heads? How can we form a discipline, say, of psychology, engineering, administration, if each person who is part of the process draws everything from a knowledge that only he and his closest peers can know? In the same way that this provocation was made by the first scientists, we must ask ourselves, as experience researchers (UX), how much can we build an easily accessible, scalable and ‘easily digestible’ field of knowledge if we don’t have a common system that can reference our knowledge in order to escape our intuitions, guesses, uncertainties and, often, faulty memories? Not to mention that UX teams are alive, people join, people leave and knowledge — ideally — remains.
In the UX Research universe and here in this article, we are focusing precisely on the organization of these references in a way that business stakeholders also know how to interpret and activate them.
When we insert a quote from that author (or that user), we are building and living what is called a qualitative-descriptive method.
Mainly in the Brazilian context of research with users, this method is used in order to confuse itself with induction. We have a million pieces of information from, say, interviews, and we’ve prepared a consolidated by grouping the information to visualize our findings. We first observe, gather information, and induce patterns in our data to begin describing it. Have you ever come across this?
In the qualitative methodology, the descriptive process provides us with interesting ways and with a more effective interface to bridge the gap with quantitative information.
Coding, an example of a qualitative-descriptive method
You may have experienced or heard of a situation where, after a long and exhaustive research, reaching important conclusions, the business team involved failed to understand the value of what was exposed.
Although we spend a lot of time among other researchers and users when we work on a project, our delivery is often directed to a business or technology team. Not everyone can understand the results found in qualitative research when we finish consolidating everything we’ve learned.
Of course, we know that the design and research culture still needs to be encouraged in business teams or in companies with more traditional structures. However, even for teams willing to incorporate research methods into their day-to-day, the timing of findings can be a barrier.
Qualitative research deliverables are usually large summaries of inductive-descriptive analyses, describing qualities, characteristics, among other details that, for teams that spend their days analyzing metrics and numbers, can be enigmas.
What will we do with it? How is it possible to understand what is more relevant or what is irrelevant? It may seem an exaggeration to speak in this way, but the moment of delivery is the moment when great professionals stand out from average professionals, as they are able to communicate effectively and assertively in the delivery of work.
We believe that the coding process — qualitative-descriptive — of information is one of the most effective ways to create a communication bridge between different actors in a project. Coding-based analysis is also called Tagging. From there, we were able to present findings in ways that go far beyond a simple exposition, such as in a Pareto chart, which determines the focus of improvement efforts.
We are constantly dealing with complex problems and you, as a researcher, may have understood (after weeks of immersion) where to start, but it is necessary to communicate to other areas and draw up a strategic plan. Having all issues separated into tags and prioritized is a great way to start.
The qualitative-descriptive work of coding allows us to work quantitatively with the general and specific inferred categories. To effectively communicate a heuristic analysis, for example, the heuristic methodology itself conceived through NNGroup can provide us with ways to know what to categorize. Severity of analyzes conducted, number of principles violated, and so on.
If the process is to analyze a series of interviews, software such as Dovetail or Airtable can help the coding process, making identifiable phrases spoken in an interview through a single word, such as: Payment, Usability, Closing, Login etc.
And how to start coding?
The synthesis of information in the business environment, especially in the tech context, has been reduced to two modalities: dashboards and presentations with a visual focus on the expected and/or achieved results. When we present qualitative information, for the most part, the information we bring is not described in the way that business is used to.
An affinity map, the classic of Design Thinking, can help many designers in the initial stages of categorizing information. The map will provide more present qualitative information paths and how we can create, within these categories, paths that guide the data obtained from users.
Some teams use metrics frameworks, such as H.E.A.R.T, in order to understand information and use it always together with metrics that move them towards business goals. The most interesting thing here is to decide on some basic themes: what are the informational themes of relevance to the desired success, or, in other words, what each area of the business needs to know so that I can create categories and feed them with easily actionable information . For example, information can come from user people, customer service databases, analytics, management needs, back-end, etc., providing the pillars that help guide the mapped objectives.
A basic taxonomy is better than no taxonomy. It helps to unite the design + business vision and thus valuable research repositories are born. :)
Some interesting steps to start offering an insights view that is more business-friendly are:
- Having the user’s journey mapped to understand which patterns each large group of the affinity map fits into.
- Sit with POs, PMs and stakeholders to find out what the metrics of the major stages of the product and/or company are.
- Gather the findings already mapped.
- Create a spreadsheet where each column, for example, is a step into which already coded findings from interviews, workshops or design methodologies can be fitted.
From there, it is possible to start the process of finding information networks that were previously separated in order to deduce broader and far-reaching insights for research operations and strategies. This often helps to improve the taxonomy itself, highlighting what is important to record and how to do it so that the data is even more actionable.
Here we are exemplifying research processes and how to provide efficient visualizations for stakeholders, but for examples of how to enrich this process with more simplified data quantification or how to link processes in building a research repository, we also leave here this other article from Sensorama about repository construction and this one on the basic quantification of qualitative data that further explores the topic.
To anchor some examples raised, here’s a BI dashboard that we made using the way stakeholders are used to seeing business information, only this time the strategy is Design.
Link to consult our dashboard example
In short, think about how your stakeholders see the information and how they can leverage what you bring. We often think that communication between teams that express themselves in a quantitative and qualitative way is almost impossible, but with a little effort on both sides it is possible to make all the data work in our favor — and most importantly, in user's favor.