Proxies and Resourcefulness in Research Endeavors

There’s always so much to be written and learned when it comes to Research, and more specifically on the topic of Research in the Design Process. The dScout blog is a great resource for everyone who wants to learn more about Research in general, and several of its underlying topics, including different research methods, what types of research to choose from and implement, how to prepare for research endeavors, and the list goes on. This article in particular addresses several situations I’ve encountered in my professional life, where gaining access to users of a particular feature/product solution that is being shaped is either very limited or not at all available. As always, hopefully this brief article makes for an interesting discussion topic.

Research has to be done. In one of my previous articles I mentioned one of the biggest errors a Designer may fall into is believing that they are the consumer of a solution being crafted, and therefore they have all the answers (or at least the most important answers), when it comes to crafting that same solution. At times this behavior is a result of Myopia, others it appears under the prestigious banner/label of “instinct” (which I have written about as well). This preamble is meant to clarify one thing: you shouldn’t aim to use shortcuts when working through feature/product solutions, because in the end, users will truly dictate if something is resonating with them or not (and I’ve witnessed several occasions where Product Design teams who did go down the rabbit hole of making huge assumptions about user behavior and expectations, who were shocked to discover that those same users didn’t really behave according to those assumptions or even need much of what they actually built). These previous statements are meant to reinforce that Research is essential in order to understand who are the characters who inhabit a particular segment in which the solution that is being crafted will impact. Gaining more contextual knowledge of the ecosystem, what drives users’ decisions, what they expect from solutions that are coming into their universe (particularly if these solutions are going to disrupt their current tasks or even introduce different ones). Ethnographic Studies, Contextual Research, User Interviews, are some of the research methods that work at this level, and they are indeed an essential component of the problem solving journey Product Design teams invariably find themselves in.

Users are not available. I’ve had the opportunity to work in both B2C and B2B product solutions, and have been able to witness how different audiences consume and react to the solutions that they’re asked to either test or react to (turns out, and from my particular observations across these different types of engagements, users pretty much expect features and products to adhere to the qualities of good user experience, namely be usable, useful, findable, desirable, accessible, and credible, independently if it’s a B2C or B2B product). For the sake of this article I’ll focus on the experiences I’ve had with B2B products. A few years ago I was involved in a considerable platform redesign endeavor, and part of the challenge with that particular project was gaining access to its users (in order for instance to test various concepts at different levels of refinement, but also to get them more involved in the process itself). In addition to this challenge in terms of access to users, I also had considerable challenges with access to tools and resources to conduct this research (with the inevitable time crunch also playing a considerable role). I opted to follow the FAST UX process (I’ve mentioned this terminology a few times before, with that acronym standing for Focus, Attention, Summarization and Translation), which meant I leveraged complimentary sources of information in order to get a clearer understanding of the characters that were being targeted in the ecosystem. This effectively meant I leveraged SMEs, Customer Support Teams, Client Management Teams, Analytics/Metrics from product usage, Benchmarking and Competitive Analysis data, Market scraping, collected all these threads of data with the intent of gaining a deeper understanding across all the different characters, their journeys, and how the proposed solution could deliver an overall relevant impact, which translated for instance on an increase in terms of client adoption (and meet the KPIs we had defined, which included besides client adoption, volume of redemption, reducing shopping cart abandonment, diminish help desk scenarios, to name but a few). Looking to the illustration of this article, the goal surrounding all those sources of information and data was to better understand the Tasks, Pain Points, Expectations & Desirability and finally what would drive Adoption for a new solution from the different types of users we were targeting (and there were different layers of users who had different access points to the solution that was crafted).

Continuous research and flexibility. Challenges such as the one previously described, where access to users is problematic, typically forces Product Design teams to be both flexible and resourceful. Research and the data stemming from it is imperative, but the ways to attain it have to be achieved in different ways. These proxies that are identified by the Product Design team, by leveraging the information that Customer Support and Client Management Teams have, becomes essential to test and validate the usefulness and desirability towards the solution itself. This also means the need to further supplement these proxies’ information with additional data is also of the utmost importance. Eventually this convergence clarifies the path to market, which in the case I was presenting produced clearly identifiable results in a series of early demos with various clients, which were quite successful (and typically one of the best ways to capture this feedback is leveraging brief surveys at the end of each demo, with no more than 7 questions which allows the Product Design team to understand what is resonating most with the audience). Past launch, the following statement remains the same: keep learning from what utilization is telling you, and if you can’t talk to users, look to your proxies, to the metrics, and document what is getting the most effective footprint.

Substantiating what you find. Independently from where the information is coming from, all the data that is compiled should be documented (I wrote about why Designers should document their process previously). This data, which includes qualitative and quantitative findings, encapsulates and creates a narrative which informs why decisions and directions were chosen, but just as importantly, they clarify who the users, their tasks, pain points, desires and adoption factors were when the solution was being crafted. The product design narrative ultimately translates into a solution being embraced by its users (there are of course lessons to be learned when that does not occur, but the goal is for a solution to be fully accepted, prosper and establish a long lasting relationship). Documenting this journey not only allows for a baseline of information to be democratically shared as it also potentiates future enhancements to the solution itself, and even offshoots that it may generate.

Reinforcing the initial statements of the article: there’s so much to read and consume when it comes to Research. However, and if something can be summarized as a key takeaway from this article is the need for Product Design teams to be resourceful, flexible and ultimately have a strategy for when challenges occur. And challenges occur all the time, some tremendous and impossible to work around (such as macro-economic trends), and others much easier to tackle, leveraging proxies and even guerrilla type of usability testing (and that’s another topic for another article).

I’ll finish this article with a quote from Sun Tzu on the topic of resourcefulness:

“However desperate the situation and circumstances, don’t despair. When there is everything to fear, be unafraid. When surrounded by dangers, fear none of them. When without resources, depend on resourcefulness. When surprised, take the enemy by surprise.”