3 lies we tell ourselves (as designers)
When you’re designing a system for other humans, you can lie to yourself a lot.
Here are the most common deceptions I find myself tripping on, over and over.
1. they need to know all of this
As an insider and an instructor, I want my users to know all of the things they need to know to be successful. This is a laudable instinct — I want to help others and share knowledge.
The problem is: I’ll overestimate what users actually need to know.
I’m not framing the situation properly. The question I’m implicitly answering is, “what do users need to know to become expert in X?”
The question I should be answering is:
“What do users need to know right now to do just this specific task?”
By providing irrelevant information for the context, I’m making it harder for my users — harder for them to find the information they really need, harder for them to get through the task.
And that’s the opposite of what I want.
2. we know the best way to do this
If you’ve ever facilitated or observed a usability test, maybe you’ve felt this itch — that moment when the user does something to complete a task, and you let out a silent, internal scream.
Being expert in these systems means that we’ve figured out the most efficient way to do things. When we see someone engaging in a system in a less efficient way, it can cause psychic pain.
Here’s an example: have you ever watched someone laboriously copy and paste something using the mouse instead of keyboard shortcuts? (Click…click…click…cue screaming).
But here’s the truth: the best way to do something is the way the user wants to do it.
No, seriously.
This is true for multiple reasons. First, we’re creatures of habit. We’re predisposed to view the way we do things now as the “best” way, even if it’s not objectively the most efficient. Once you’ve built a habit, it’s cognitively easier to do — you’re going to resist learning another way unless the benefits are clear and it’s easy to pick up.
Second, there are additional factors that relate to our individual experiences of an interface. Maybe the user has a habit they’re porting over from another interface (building on existing knowledge), which makes this easier for them. Maybe they don’t value the same things you value in the interaction (they want to feel more complete, or want the chance to double-check, or, etc.).
So, the alternative to the user doing it their way isn’t doing it a more “efficient” way.
It’s not doing it at all.
3. they should take the time to think about our systems
This is a super-sneaky one.
It tends to creep in, unnoticed, and I’ve learned to look for trigger warnings to identify it.
Here are some examples:
“they really need to learn X in order to Y”
“we shouldn’t have to dumb things down”
“well, we can explain this part in class” (yikes)
Users shouldn’t have to think about our system. The whole goal of UX work is to ensure that the user can focus on one thing: the task.
Our systems shouldn’t be imposing additional requirements on users in order for them to be successful.
“You need to know what a call number means.” “You need to know the difference between a journal article and a book chapter.” “You need to know that you can’t request it this way, you have to request it that way.”
We tell ourselves that this is valuable knowledge that contributes to our users becoming more successful in finding information.
But that’s conflating two things: research instruction and usability.
Research instruction should be focused on teaching the concepts behind the activity, helping users understand the why behind their actions.
Usability should be focused making systems more aligned with how people already do and understand things.
They’re complementary — both are techniques that can be applied to close the knowledge gap. But when you try to apply them simultaneously, you run into trouble, because there are very different contexts for research instruction and system use.
Users don’t come to our systems to learn how a library works. They come there to do things.
Now, it’s true that a good system should try to help the user learn how to use it. That’s why we avoid jargon, define terms, reiterate important points in multiple ways throughout the process, and try to make interactions and patterns familiar. But there’s a world of difference between making your call numbers point to a map of locations, and making your users go through a tutorial on what a call number means.
I’ve heard the argument that we should include more of the instruction component in systems because it’s knowledge that will help our users go on to other libraries (and further in their academic careers).
There are so many assumptions embedded in this.
First, that “other libraries” (libraries overall) will never adjust their processes to become more user-centric (thus requiring a lot of additional knowledge).
Second, that there is a “right way to do things” that all successful library users must follow. See Lies 1 and 2. Does a user really need to be able to define a call number’s meaning in order to understand: A) how to locate an item and B) how to locate related items?
Third — and most holy — that there is something inherent in how we do things that is essential to the nature of “scholarship” itself.
Yes, absolutely, ontologies are vital. But….not everything we do always has to be done that way.
Cue the pitchforks.
When we try to fit ‘research instruction’ into ‘system design,’ we often end up substituting procedural understandings (how to use a call number) for conceptual ones (systems of knowledge organization). We also put this in the wrong context, when users are trying to accomplish a task, not build their own understanding. This means we don’t design the process to serve the user, and we also fail to convey any useful, larger understanding about the concepts behind it.
Ideally, your instructional program should help students understand research concepts independently of your specific library context, and your library system should be useful, usable, and desirable independently of a research instruction program (gasp!).
These are all tricky things to navigate, because they’re so contextually-dependent.
But it’s important to stay vigilant, because these three deceptions will crop up literally everywhere. So I just keep asking myself, “is that really true?”
And then…I go talk to some users. :D
