On May the 5th, Jared M. Spool dropped a bomb: “A Radical Proposal: Put UX Research In Charge”. In my mind, the outcome was inevitable, and the question was never “Should we?”, but “When will we?” The claim will ruffle feathers; the organisational chart in many companies is a battlefield of control and getting things done. Any disruption to this hierarchy will be met with resistance and makes a shift towards a research-driven organisation difficult. Let us look at what Jared said, and I will share some thoughts on what I would have done differently and what I believe are not the final transformations required for the end of the Industrial Age Business and the start of the Human Age Business. But first, the agile mindset.
The Agile Mindset
What is problematic with Agile development and the Agile mindset? This is a lengthy discussion on its own (e.g. the Mini Waterfall, the UX Compromise, Business-led vs. User-Centred), but I am going to only focus on the Agile mindset, as in principle I don’t have anything against how developers would like to develop; they can choose any method they like. I have a problem on how the Agile mindset affects the rest of the company’s work.
Agile taking us away from the Waterfall mindset was a good thing, but then everything became Agile focused. All work (product, research, design) irrespective of their intent, was broken up into 2-week sprints. UX was still in its infancy and people were already advocating for “Lean-or Agile UX.” Action overruled any form of thought or strategy as we “learned by doing.” Startups “agiled” themselves towards an MVP and then continued to add features as if they were “value propositions.”
The problem with Agile is that they do not know what “value” is. They iterate towards a point that increases users and turnover but ask them what the value is, that which people gain from their product, they wouldn’t be able to tell you, because success is measured through business metrics (turnover, sales, growth) and not people metrics (people success, growth). At best they can only infer.
At this point some of you have counter arguments forming in your head; you might even be fuming to the point of no longer wanting to read this article. Please take a second to scan the “Understanding Mindset Principle 1” and write your questions in the comment section below.
The Research (Understanding) Mindset
Research during the Industrial age was business-driven. Not only was it not user centred, but it took forever (okay, just years) before research actualised into a result. But we are in 2023 and the user-centred view has finally reached Research. What you are seeing now, is just the start of developing what I see as cultivating the “Understanding” mindset for the research practise.
What is Jared M. Spool proposing?
“A Radical Proposal: Put UX Research in charge”
The title is antagonising. Maybe it was intentional (see Douglas Adams’ “The Hitchiker’s Guide to the Galaxy” on what travels faster than light), but I fundamentally believe in creating an environment for people to prosper (see Understanding Mindset Principle 2) and would have preferred something in the lines of “A Radical Proposal: Make Product Research your North Star.”
That brings me to my second point. “UX Research” as we know it, is inadequate. The current practise is a user-centred compromise to the needs of business and the agile mindset. The result is a focus on parts and ignoring the importance of the whole (value). The simplest analogy I can think of is a car. A car needs four wheels, an engine a steering wheel, gas, and a frame to hold everything together. Can the user experience value, until all the parts (features) are complete and in the right relation to each other? No. I can picture in my mind how agile would only have stopped after the sixth or eight wheel have been added and the interest diminished; after the original positive response when they reached the fourth wheel. Agile does not see the car.
“What little research is done is inadequate to provide value to the organisation.”
This is very much true, but not only are the research inadequate, there is still a lot outside the current scope of UX Research that needs to be included, before you can be a proper Research-driven organisation. Four of those things are:
The Product Landscape: The environment your product lives in, is shaped by what currently is being created and experienced. It leads to a collection of behaviours and expectations that influences how your product is received and will be interpreted.
What “Success” looks like: The requirement to be successful is never communicated but assumed by your customers. Do you know what success for your customer looks like in your product? Do you know if your research (e.g., user interviews) are adding value or diminishing from the clarity of people’s success criteria?
The “Problem Space: Before any product exists, there is a world that you need to enter before you jump into the solution space. Learn about your users before you approached them with an app in mind. People do not dream of buttons, when they visualise their goals.
“UI is Communication”: There is a misunderstanding that testing your product on people, is a verification of your product’s value. It is not. You identify value during research. Testing is for validating if your value was received and understood through your UI (selected language of communication). A failure during testing is a failure to communicate, not a failure of value.
“Research-driven roadmaps start with a solid vision.”
I agree with the sentiment, but research should only have one purpose: understanding. Secondly, by now we should all know that you can’t have a strategy before you have understanding. Strategy comes after “Exploration” and “Identification.”
“A research-driven organization focuses primarily on value creation, not value extraction.”
Overwhelmingly yes! Product Research is a continuous process of identifying value and the more you learn, the more opportunities you will expose for business and product; even for value previously thought to be insubstantial, as your understanding increases.
Final Thoughts
I am by no means dismissing the important and hard work done by Product Managers and their various attempts to discover value. Agile after all is a development process, which became a product/business mindset. What I am proposing is that “Agile” can still be the practise of developers, but not as the mindset for discovering value, and that Product Research (not the current state of UX Research) can actually lift the weight and responsibility off a Product Manager’s shoulders, and allow them to focus on the work that their title intended; managing a product.