Users don’t know what they want (and that’s ok)
I believe in questioning assumptions. One of those assumptions I’ve seen in the IT world is that users know what they want. Or perhaps more accurately, that they should know.
To clarify, “users” is a shorthand for business stakeholders and the actual people that use a given IT system.
To be sure, there are some cases where users appear to know what they want. That’s great. Truly, it makes IT’s job easier. There’s a specific target, a specific goal, something we can put our heads down and solve. This is the ideal situation.
However, the key word in my rhetorical strawman above is “appear”. In many of these situations, the user may think they know what they want. They may be absolutely certain of it.
But whenever I feel certain of something, I humbly contemplate one of my favorite sayings “sometimes mistaken, never in doubt”. While confidence alone can convince a lot of people of something temporarily, in the end, truth persists.
My assertion is that most of the time, users don’t know what they want. Worse, forcing them into a premature, rigid definition of their desires ends up being detrimental to the process of delivering good solutions.
Why is it detrimental? Building an IT system exactly to specification rarely makes anyone happy with the results. At the macro level, it’s a CYA technique for IT. At the micro level, it’s a passive aggressive way for developers to call your bluff.
How does this fallacy propagate?
Everyone likes an ideal situation. Many of the movies and TV shows we consume are fantastic cotton candy that contain just enough semblance to reality to suspend our disbelief. We can escape for a few hours…or in the case of the most excellent Stranger Things 2, binge over an entire weekend.
It’s logical to believe that users should know what they want. It’s not unreasonable for an IT department to exclaim “How can we give you what you want, when you can’t tell us what you want?” Ay, there’s the rub. It would be wonderful if IT’s job was this easy and narrow.
This exclamation can also serve as an excuse. One that IT can conveniently provide for why projects are often confined by the iron triangle — on time, on budget, feature complete: pick two. We should be skeptical of justifications that align with our own self-interest. We should strive to do better.
The role of IT is not only to deliver solutions that enable users to be more effective and efficient at their jobs, but to help them navigate the complex, uncertain process to get there.
What do Users know?
It’s common to juxtapose wants and needs, and there’s a reason for that. Very often users have a real need for something to be improved or changed. They are working day-to-day in the system that IT is responsible for. They feel pain; they know their pain. If it’s painful enough, they will want something new/different. They want their pain to end.
The problem is that often users only feel the trunk of the elephant. They do not have the holistic perspective, nor the technical expertise, to distill how to get what they really need on their own. Their suggestions may be misguided, no matter how certain they are of it.
So when IT leadership pushes users to define what they want, before they know what they need, you’re creating a new problem. Users need help to address their pain in the context of the whole. IT needs to diagnose the illness before rushing to prescribe an opioid.
What do we do?
Accept the problem
The first step is to accept that users do not always know what they want. That’s ok. Work with that reality. This is one of the reasons why waterfall often fails and iterative approaches work better.
Accept the uncertainty of walking down a path that you don’t know where it ends or how long it might take. Accept the responsibility of making decisions in the moment. Accept that complex problems require failed attempts to solve so that we can learn more about the problem. Have confidence to change your mind based on additional understanding of the problem.
Help Users figure out what they need
If we accept that users do not know what they want, then IT has a responsibility to help them figure out what they need. IT’s role is to guide users along the unfamiliar path of applying technology to business problems. This is the high-level function of the Business Analyst. IT needs to learn enough about a users pain in order to empathize with them.
Once IT can empathize with the user, we can make rational decisions about what IT can do to alleviate some of their pain. The goal isn’t to give them everything they may want, but rather deliver what they need balanced with a holistic view of the entire organization. In the best case scenario, we can automate tedious tasks and raise the level of their focus and attention.
Technology should augment human potential.
Iterate quickly and shorten the feedback loop
I’m a good critic. I’m really good at seeing something and quickly knowing everything that’s wrong with it. I think most people have this “skill”. It’s easier to look at something tangible and determine what we don’t want than it is to conceive what we do want out of our imagination.
Because of this, I like to iterate quickly with working prototypes and get it in front of users as soon as possible. It doesn’t have to be perfect, it shouldn’t be. The point is to capture the essence of what could be. If we’re on target, we’ll know it very quickly. If we’re missing it completely, we’ll figure that out too. Iterate on the positives, drop the negatives.
This cuts out a lot of theoretical discussions and roots it in unambiguous reality. It provides a concrete starting point for moving forward without wasting tons of time talking about things in the abstract or theoretical. Talk is cheap.
Final Thoughts
Life is complex and nuanced. The application of technology is no different. If you are feeling IT pain, but do not know what the solution may be, that’s ok. I encourage you to believe there is a better way and talk about it. IT may be able to help and they should start by understanding your pain. And when the stars align, IT can create a solution that is better than any one of us could have conceived on our own.
Sometimes IT may not have any answers; sometimes systems suck and there’s not much we can do about it. But at the very least, we can listen and be mindful of that as we move forward. It might not feel very satisfying, but your input does inform larger strategic decisions and priorities within IT.
