Tree Behavior: Context Switching, Open in the Context Menu, and "Standards"

Sometimes a change makes sense, until you remember the details and revisit the use cases.

You Should Blog (Again)

I recently gave the same message to share, but for a different community, at the Amsterdam UX Bar Camp.

I volunteered to join the other 23 presenters at UXCampAMS! I'm that first paper in the 12:00-12:45 sessions. #MidasRule

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.

Midas Rule

As a new customer, I remember asking my first Tridion trainer the difference between an Embedded Schema and a regular Schema ten years ago.

As a new implementer, I remember creating my first Schema(s) and the reaction of my editorial team when they finally had control over their content library a few months later. No more requests to IT to deploy something to Staging to then re-approve on Live!

They eventually explained to me that, "No, we don't publish to Staging. We just publish to Live and fix anything if there's a problem."

As a new consultant, I remember my colleague asking me how I knew all the "best practices." I had four years of experience with the product by then and a few years "managing" content before that.

As a new Product Manager, I remember telling another colleague four years after that, "well, Tridion doesn't work that way." He reminded me that we could change it.

After a decade in the industry and about 13 years in IT, I'm also realizing I'm not so "new" anymore. :-)

Now as a Product Owner for the DX Suite, I'm remembering last week's demo where dozens of UI improvements were implemented in a sprint for the new Graphene User interface (due after Sites 9.1) as well as a "yass!" reaction from an editor to some small, but significant page editing improvements for Tridion Sites 9.

And today I'm letting the Tridion Docs content model slowly sink into my brain after a great session with our lead technical writer.

By the Midas Rule, many of my colleagues and I were not the first to touch this software, nor will we be the last. But we do care enough to be proper stewards of the previous vision, while we work on forging a new one... in Graphene. ;-)