5 Tips to Conquer Complex User Research

If you know anything about Expero, you know we specialize in solving “complex problems.” This means we’re not working on your average brochure website or e-commerce app. We’re tackling apps and softwares targeted to niche domains with expert end-users who have very specific needs and goals to solve their very complicated problems. They’re often working with huge data sets or high-performance computing, and they need major architecture and bandwidth chops. And these users typically have other attributes in common--like very little time, specific workarounds for old problems, and a frustration with a general lack of efficiency in the product(s) they’re currently using to meet their needs.

It’s easy to see how product strategy, development, even design can be affected by increased complexity. How do you lay out an innovative project roadmap for a group of scientists who are skeptical about gestural interfaces? Where do you start with architecture? Should you use a graph database or a traditional relational model? Does this workflow need a wizard or just a basic form?

So what about user research on complex applications? How is that different?

Well, it is and it isn’t.

The basic tried-and-true research activities are still relevant. Things like requirements gathering, contextual inquiries, persona development, user testing. These are the building blocks of user research.

What’s different is how you approach the user research: with the confidence to try to speak the their language and the humility to understand there is still so much you don’t know about these expert users. It’s like practicing a non-native language in its mother country. You’re never gonna be as good as a native speaker, and indeed you’ll find many different dialects, but just demonstrate that you’re trying to understand and keep asking questions, and you’ll get where you’re headed a lot faster. Sometimes you might end up with a frustrated subject matter expert who doesn’t understand why you still don’t know what you still don’t know, but that’s a real potentiality before you finally get what they’re trying to say.

Another difference is that complex projects mean that, in our experience, designs are more likely to be wrong at the outset--which makes user research that much more pivotal. Consider a stakeholder investing in a technology that’s never-been-seen before--an app aggregating all sensor and inventory data necessary for enterprise farming or a news tool that creates sentiment analyses of articles. There are no baseline needs or goals for these end-users; just the stakeholder’s unique vision and ideas. To top it off, the stakeholder knows this is a never-been-seen technology, and wants to protect it until it’s “ready”--meaning they don’t want prospective users to see the in-progress work, only the finished product, resulting in a great deal of potential refactoring later.

Here are 5 tips for conducting quality user research on a complex project.

1. Don’t talk to your users too soon.

Ramping up on a specialized domain is hard work, and you shouldn’t count on your SME to do all the heavy lifting in terms of helping you understand the ins and outs of securities trading or enterprise farming. Read about the domains you’re working in, and pay particular attention to current events as well as industry jargon.

And, if you’re developing personas for your stakeholders and your design team (and you should be), you can use desk research as a foundation. Job postings are a great place to get basic info on needs, goals and expectations of the end-users.  

Remember, though, that there’s no substitute for actually talking to your users.

2. You usually have to give a little to get a little.

Cash or product incentives are the go-to method for securing user research participants

for interviews and tests. However, this probably won’t work for your expert end-users,

who often value time above all else. Consider creating a “user group” or similar that users can opt into, and give them a sense of ownership over the outcome of the product or release. Be truthful if they ask “Is XYZ possible?” If it’s out of scope or technically unfeasible, let them know that their feedback will be documented but it might not be the top priority for this round. Honesty goes a long way.

3. Your SME is your recruitment firm.

Working on the projects Expero specializes in means that the target end-users are likely

not signed up with their local market research and recruitment firm for some extra focus group cash. Rather, they’re likely mired deep in a clunky legacy technology they’ve created countless workarounds for, or they’re struggling with Excel when they should be looking to the disruptive new app you’re proposing. Encourage your subject matter expert to provide you with current users they know or prospective users they’re targeting, and don’t aim too high. If your SME or stakeholder can provide you with a list of 30 or even 50 users, that’s amazing. If you can get 10-12 users, count your lucky stars.

Note that your stakeholder or product owner may also be slightly more sensitive about sharing incomplete or in-progress ideas with target end-users they don’t want to dissuade from using their product. This is a real and understandable reticence. Mitigate it by giving them full veto access to the testing and interview scripts, and allowing them to ping you in real time with comments during testing.

4. Add a little interview to your testing.

As a researcher, you know how important it is to understand your users--not just how they interact with a particular app, but how they behave generally, what they want, what motivates them, what delights them. It’s hard to get all of this detail out of a 1-on-1 session, but take it with baby steps. Do incremental (lean) design testing, and sneak in a few related interview questions while doing so. For example, if you’re testing an account creation workflow, spend 10-20 minutes interviewing the user on accounts they’ve created in the past, what motivates them to create accounts versus log in as a guest, whether they use a separate “junk” email for account login, etc. Then dig in to the design and the traditional user test. This will help both develop personas to inform long-term design, and tweak the design of the piece you’re testing.

5. Remote possibilities are endless.

If you are able to get your expert end-users to give up some of their valuable time to you, make it as easy as possible for them. Don’t insist on an in-person interview; set up a WebEx or GoToMeeting and provide a quick link. Don’t make the user share her screen; share yours and give her control of your mouse and keyboard. Don’t insist on a certain schedule; make time for them. If your end-users are students or day traders, for example, you should probably plan to stay late at work to accommodate. Don’t go over the time you promised; if you say it will take an hour, take an hour. If it looks like time is running short, ask if they have a few more minutes and be cool with it if they don’t. And finally, if the user says he can give you a half hour instead of an hour, take what you can get! You can still get valuable feedback in a half hour; just remember to discuss with your team what the most pressing research questions are so you can be sure to tackle those first.

User research on complex problems is not a new UX domain; it’s just a few new twists on an old idea. Research aims for the ideal, but often takes what it can get. These tweaks to research sacrifice quantity and face-time, maybe, but preserve quality and user feedback.