All too often, UX requirements come from a scenario where the discussion in the room is focused on the product itself – data, processes, controls, functionality. It’s usually a “what will it do and how will we build that” discussion. Most IT folks I’ve worked with refer to the process as “gathering requirements.” There are two problems with this concept.

First, and I’m stealing this from Kim Goodwin, because she’s 100% right — is that requirements can’t be “gathered.” They’re not growing on a tree in the office just waiting for us to come by and pick them. Requirements do not exist until a collaborative exchange happens between all players in the project — the client’s teams, the IT department, UX and UI designers, Marketing, Sales, et. al. So if anything, requirements are really negotiated.

Uncovering and defining UX requirements for features, functionality and content is a balancing act between you, the client, internal forces and external forces. It’s a negotiation across all of those things. So it’s perfectly normal if in the first one hour session you don’t know everything there is to know about what your requirements are. It’s a multi-step process that’s more a marathon than a sprint, and you have to go through it.

Second, you are making a critical mistake if your discussions are focused solely on the mechanical functions and processes of the product. Features and functions are only a small part of the requirements picture, in terms of designing and building something that gets used and delvers measurable value (read: ROI). Making sure your requirements address the things that really matter strategically means making sure you think about, talk about and work through three (3) different kinds of UX requirements:

  1. There are things people say they need.
  2. Then there are things that they actually need.
  3. And then finally, there are things that they don’t know they need.

What people say they need

Ask any group of people what they want or need and you’ll get no shortage of answers. Put 12 people in a room for a brainstorming session and a great number of new approaches and angles and opinions will surface in a remarkably short period of time. And even in a “think big” situation where participants are encouraged to ignore all limitations, a lot of what comes up will be solid. You may very well decide to keep and implement several of the concepts discussed. But the majority of them will never make it past that initial conversation. That’s normal, because not every idea is actually possible. You may not have the time, the technical expertise, the budget or the personnel to pull them off. But the other reason you need to be hyper-critical of that first set of ideas is because we humans, no matter how smart or well-informed we may be, have a very common flaw:

We often make very confident — but very false — predictions about our future behavior.

There is a huge difference between imagining using something and actually using it. This is really just speculation; you’re guessing how you would use a particular thing. The thorough understanding that comes with repeated use is missing at this stage.

What’s more, our preferences are subject to our emotions, which makes them a bit unstable and/or unreliable. How we feel about something is subject to the kind of day we’re having, and are influenced by all of our experiences up to that point (related or not). You know the old phrase “don’t knock it until you try it?” The instablity I’m describing here is the reason that phrase exists.

So the bottom line is that you don’t really know if something is useful, or valuable, or relative, or positive until you actually take action and experience a result.

So in those initial “think big” sessions, you’re essentially asking people to either remember past use or speculate on future use. Either way, there’s no solid precedent specific to this set of tools, features, circumstances and possible outcomes. There’s nothing to lean on other than a loosely educated guess on what might happen.

This is a big part of the reason why I constantly reiterate the fact that what people say they need isn’t always what they really need. What they say they’ll do isn’t always what they actually do. So while you should absolutely consider all these generative ideas that come up in the beginning of a process, you should do so with more than a couple tablespoons of salt.

What people actually need

We’ve established that every idea expressed isn’t necessarily a good idea. But while these things may not make into the final feature set, they can often be a stepping stone of sorts to the next level of features: things people actually need. Any time we have trouble with something, it’s almost effortless to imagine a solution that will solve your problem. And that solution will often address a symptom instead of the underlying problem. But that symptom is the right place to start. The task now is to qualify it, to play it forward and uncover the other actions, processes and motivations atatched to it.

You may start out on a path that’s a little wobbly, but that doesn’t mean you’re going to stay there. The way you get past the wobble is by investigating further:

  • Do we fully understand every step in every task flow, from the standpoint of both the user and every other person who has a role related to product use?
  • What anecdotal evidence do we have suggesting this feature or function would solve a frequent/recurring problem?
  • What research can we perform, or what kinds of user observation can we put into motion to fill in the blanks?

It’s important to go through that exercise and to have those long drawn out discussions, no matter how pointless they can sometimes seem. Unless you go through the process of exploring all the parts related to what the user is doing, you’ll never have a clear picture of what they (and the business) really need.

What people don’t know they need

One of my favorite quotes is from Harvard Marketing Professor Ted Lovett, which goes like this:

“People don’t want quarter inch drills. They want quarter inch holes.”

Do you get that? What it means is that the desired outcome — what they’re using the tool to do — is infinitely more important than the chosen tool. When conversations are focused on clarifying what people expect the outcome to be as opposed to a very narrow focus on features, functions, and product attributes, you’re likely to come up with better, more relevant solutions. You’re more likely to uncover things that no one realized was a problem until now — and which are also the cause of a host of other, seemingly unrelated issues.

And the reason for that is pretty simple. When problems arise, we look around for a way to get the job done; we think about convenience first. That’s human nature. If I need to drill a quarter inch hole, I’m going to use whatever does that easily and quickly. And if I’m in the basement and my drill is in the garage upstairs, I may very well take the Phillips-head screwdriver in my pocket and poke a hole in the wall. Because it’s just about a quarter inch in diameter, and it happens to be more convenient for me.

Otherwise, I have to stop what I’m doing, walk upstairs, get the drill, find a quarter-inch drill bit…which could be anywhere since I never put it back in the same place…insert the bit…you get the picture.

The bottom line is that we shouldn’t be talking about the drill, or its features, or its functions. What we should be talking about is (a) the problem that people are facing, (b) what their desired outcome is and (c) what they’re most likely to do to solve it. With or without our specific product!

Forget the product. Forget the attributes. Forget the specs for now. Focus on the desired outcome and the problem at hand.

. . . . . . . . . . . . . . . .

If you’d like to get more advice from me every month on UX, UI and Product Design + Development topics — in the form of training videos, full-length courses, e-books, downloadable templates and more — check out my NEW online school, the UX 365 Academy. Every month I publish new content, and you also have access to every course, book and training video I’ve ever created — some of which have never been published online before now.

Check out the UX 365 Academy >