It's Already There...

In recent user research and product feedback I've noticed long-time users of our software suggesting improvements that were already there.

I suspect it's the combination of perhaps three things.

• The way we asked
• The user expectations from knowing the software
• Not wanting to ruin things for others

Ask and You Shall Receive a Response

We've asked, "what would you expect on this screen?" or "would you need this kind of information?"

I'm trying to avoid leading the interviewee, but this kind of question to solicit a response based on the desire to answer. Perhaps the person asked isn't sure or might have a few ideas, but the question itself encourages perhaps a single answer.

Maybe I can leave things more open ended questions and work with our UX researchers on how I can ask better questions.

User Expectations

When asking about some potential functionality, users that know our software will describe their expectations. They'll describe wanting to know the status and relationship of items and their related data. For example, what's published? What's that field name?

If you ask, but don't show them what's already there, they'll likely ask for things they might have ever needed, rather than most of the time. They might also ask for things that are already there but aren't clear or easy to get to.

I'm learning a better approach is to perhaps ask about a specific situation rather than in general. People can easily conjure up the abstracted ideal version of a situation, which can be useful but misses the detail of an actual incident.

Also, it's not the interviewee's fault. As humans, we offload so much information into our context software where they become extensions of our brains. So when asking about something that's not visible at the moment, it's hard to recall everything that's there.

I Don't Need it, But Someone Else Might...

Finally, I suspect that if I asked you if you needed some feature of information in the UI, it's much easier to say it might not be important to you, but maybe someone else might need it.

I'll hear conflicting requests like "we should show this data" from one person and "I don't need that data, but maybe that information could be useful in a tool tip" from another.

In an interview I suspect it's hard to take a strong stance to remove a feature if it doesn't seem to bother you but someone else might need it. The challenge is that with enough of these features, the experience becomes a bit more complicated for everyone.

And then we realize a few of these features are already there.

Final Thoughts

If we listened to every piece of feedback, we'd keep every bit of functionality in a UI that's missing the point of good user experiences. See one of Jared Spool's Kano Model presentations on why this is a bad idea.

Soliciting feedback and hearing requests have their purposes it letting you know what's on your users' minds and what they're trying to solve. But it's important to be aware of how you can influence an answer.

For more on Product Management and User Experience Design, let me plug the This is Product Management podcast. It's definitely worth hearing the different perspectives and episodes are short enough to commutes under an hour.

For information specific to my own projects, see our own UX Community Group and Product Group, where the latest updates (November 2018) feature a video and demo with voice over from your truly. Speaking of which, I owe an update on how we're building the latest UI and what Tridion Sites means for digital transformations.

In a future post I'll likely share some examples user testing and UX research, where there are few questions asked but lots of insights gained.

Oh and congrats to the teams on the SDL Tridion Sites 9 release and updated SDL Tridion DX (suite) group!

Update: our lead UX researcher gave me more feedback and tips for interviews. It's probably good to understand the interviewee's use cases and then introduce the context and thinking behind a given design. It then makes sense to make the questions tangible to the interviewee's specific use cases ("How would this work for you? Would you find this valuable? How often would you use this feature?). However, the interview and feedback sessions are just one user research tool. I'll explore more examples and gotchas in future posts.