Everything is everything

Photo by Paul Talbot on Unsplash

Here’s something strange that keeps happening to me.

I’ll work with a team or department to set up an exploratory interview around a particular interface — we’ll determine the questions we have about the platform and functionality, and what we need to know in order to make decisions.

I’ll get started, asking the user to show me things about their experience with X — and almost immediately, they will start going off in a completely different direction than I expected.

They’re still using X — but they’re getting to it in a totally unexpected way, or they’re using X content repackaged by Y platform, or they’re bopping around between platforms, and then bringing over their expectations from these other platforms.

If I wanted to stop this free-range view, I’d have to change their behavior. I’d have to tell them, ‘go to this page, then try to do that’, — and sometimes, I will, because that’s what the team is focused on.

But lots of the time, it’s illuminating to see not just how they do the thing, but also how they get to the tool that does the thing, and the various shapes that takes.

The first realization I had was this:

Often, where we see many systems, interconnected, the user sees only one system.

This is sometimes by design, as when we try to streamline the process by linking directly to content, pulling metadata from multiple sources into one search platform.

Other times, it seems to be simply a lack of a mental model on the user’s part. It’s all one thing because they don’t have a concept for multiple-things-working-together.

There’s been some really interesting research on how simplistic or inaccurate mental models (combined with expectations from other sites) impact students’ search strategies.

Why no good mental model?

Because nobody thinks about our systems (besides us).

Users are focused on the task — the interface captures their attention as a distraction from the task, not as a thing to consider in itself.

The second realization was this:

The path users take impacts their experience with the destination.

Let’s take an example — a user decides to search our digital archival collections, but they use our main search tool, not the dedicated platform that hosts these images. They choose a series of filters offered by this tool (some of which have no counterpart in the system housing the images). The user doesn’t know that they may be searching with criteria that basically don’t exist in the second system…and they get no results.

They conclude that we just don’t have that material (we do).

In another case, let’s say they do find an image result, repackaged by their familiar main platform, and have to figure out how to get the thing — a click that ports them over to the second system, triggering a sudden shift of interface when it goes to the item-level view.

The aesthetic change alerts them to being in a different digital space, but branding at the top assures them that it is still a “Library” space.

So, maybe they go to do a new search in this system — but wait — why are the filters different? What do these terms mean? What happened to my relevancy ranking?

When I’m noting usability issues, I’m increasingly noting issues that are technically outside of the platform I’m testing. Instead, they’re about the multiple paths that we’re providing to the content from outside the platform, and problems with that information and those transitions.

I can’t ever test just one thing, because everything is so intertwined.

So, when it comes to fixing things….then it gets really complicated.

In our desire to make things findable from all of our silos, we’ve created a new set of challenges, in trying to support the different ways objects or collections are described, accessed, and displayed.

All of these influence the understandings and expectations users have about the nature of the objects and how they can get access — and they are rife with opportunity for misunderstandings.

Our mission is to make sure these messages we’re sending about our content are both consistent and clear, no matter where the user is coming from.

To do that, we need to be aware of all of these different paths, and the signals they send along the way. Which means, in my case, watching the user as they roam through their pathways, not my predetermined ones.

It means paying special attention to those moments of surprise, of re-calibration, because those bumps are signals that we’re not being clear or consistent enough.

After all, users don’t want multiple systems. They want one system that works.

And with our large, single search boxes, we seem to be promising them that.

Our challenge, in a sense, is to make sure not only that our systems are usable, but also that our content remains equally usable in every different system it appears in.

Which feels like a lot.

This is why I’m a fan of journey maps as a way to help explain why it’s important to pay attention to these other systems (even if “your thing” is X). When you present it from the user’s point of view, you get a better picture of the obstacles and the stakes involved when jumping through these interconnected systems (it’s hard not to wince when someone concludes, confused and forlorn, “I guess there’s nothing here”).

It’s one more step towards a systems or service design mindset — following the whole process, from the perspective of the user, to identify how well the whole experience really works.