UX improvement for big sites and systems begs equally big questions. And in B2B or Enterprise environments, the level of complexity inherent in the tool and its use makes it hard to know where to start. What’s more, when it comes to figuring out user needs, there are hundreds of potential questions you can ask.
In the majority of B2B and Enterprise circumstances, however, reality dictates that no one has the time to ask (or answer) all of them. When time and budgets are tight for UX and Development teams, the only answer is to focus on the questions that deliver the most valuable information back to the team. Questions that focus on the underlying causes of most UX problems.
The place to start is with people’s motivations and perceptions: what’s driving their use of the system, what do they expect from it and what do they believe matters most? This first set of questions I’m going to walk you through focuses on these areas.
It’s not just what you ask — it’s how you ask.
As you’ll see, asking the right questions starts with the actual form of the questions you ask. These should be open-ended, non-leading, non-specific questions that let the person fill in the details of the answer. You don’t ask them about what software or hardware they use; you ask them what they do, how they would complete a task.
That means you don’t ask a question like “how do you use the [ specific feature ] to do [ specific task ]?”
That question focuses on the tool the person is using — instead of the process they go through. Usability and UX problems are very rarely the sole result of a technology issue; there are a handful of other seemingly unrelated factors that, in many cases, turn out to be the real problem: company policies, processes, politics, deadlines, stress, noise, interruptions, etc.
So again, if you only ask a user about the software she’s using, you won’t get any information about the other factors that may be directly responsible for the issues at hand. And if you don’t hear about those issues, the person and the organization will still have the same problem after the redesign launches or your engagement is over. These 7 questions help ensure that never happens.
How do you define a successful work day? What has to happen in order for you to feel good when you leave?
Why you need to know: Use is tied to motivation, and motivation comes from some kind of reward — a sense of accomplishment, a feeling of increased competence or a specific goal achieved. At the end of the day, what makes that person feel like they were productive, like they got things accomplished? What things happen that give the person that impression? The opposite question is valuable as well: what kinds of things make you feel unproductive? Frustrated?
Does that definition of success (and your stated goals) change from day to day — or from week to week? Are there certain times of year where what you need to accomplish changes?
Why you need to know: If either their goals or what they believe is success is different on Tuesdays, or during specific months of the year (as in retail organizations), you need to know about it. If the target changes, you want to know how, when and why that change occurs — because the chances are very good your product will need to support that variance.
What are the top three things standing in the way of you accomplishing your goals or having a successful workday?
Why you need to know: What’s keeping them from getting where they need to go? Notice the question isn’t tool- or software specific. You want to hear about their issues, period — anything and everything. Thinking past the tool and about the problem people have is how innovative solutions are born.
What are the biggest problems, obstacles or inefficiencies you deal with? Why do you think these things happen?
Why you need to know: You want to get a sense of what prevents people from being efficient, or makes them do more work than they feel is necessary. You want to hear about the things that grind productivity to a halt and stops everyone in their tracks. You’re looking for the underlying causes of issues, errors, backlogs and the like. The why part of the question will tell you what features and functions you can design to help solve this problem.
Did you do have this same role at other organizations you’ve worked for? Was it better, worse or different – and why (or how)?
Why you need to know: If their previous job experience included the same basic responsibilities, you want to know if the last experience was better. You can learn from that, using it to inform features and functions. Again, the why is the heavy lifting of this question; it will provide the most insight as to what could or should be different in the current scenario.
Did you perform these tasks in the same way at any of these other organizations? Was it better, worse or different – and why (or how)?
Why you need to know: Again, most people have worked for more than one company, so they will likely have experienced variations on a theme — different ways of doing the same thing. Some workflows or processes may be more complex than the current scenario. But you’ll often hear about parts that worked better, and sometimes even hearing what was different sparks improvement ideas for the current product.
What frustrates you most about this? Why?
Why you need to know: You want to know where their biggest perceived pain point is. The answer, especially if echoed by a significant number of other people you interview, gives you a clue that this particular issue may be high on your list of priorities. There is no better way to increase use and adoption than to remove or fix something that really drives people crazy.
For example, people often complain when they have to enter in any sort of identifying account information more than once. In organizations where people use multiple legacy systems, this frustrates people to the point where their productivity decreases due to being fixated on the wasted effort. In most instances (a) they’ve already been asked for it once and (b) they expect the system to have it already.
These questions are usually enough to expose the core drivers of user behavior: what people expect, what they need, and what they are (and aren’t) willing to do. Asking this set of questions across even a small pool of people — ten or less — will still show you clear, recurring themes and patterns that can be used to validate user needs, along with any and all proposed improvements and requirements.
. . . . . . . . . . . . . . . .
If you’d like to get more advice from me every month on topics like this — 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.
