When is “user-friendly” misleading?
I recently read an article about the perils associated with semi-autonomous vehicles, but instead of systems failure, the problem was this: people not understanding that the cars don’t completely drive themselves.
Their confusion is, perhaps, understandable — features like “autopilot” and “super cruise” sure sound like the car is going to take over and shepherd you safely home. These names are meant to be appealing, and to provide shortcuts to understanding what the car actually does, and can do. They also run the risk of misleading people.
Which leads me to libraries.
We handle highly complex systems, often kluged together (sometimes from vendors who are mortal enemies), and we attempt to present these tools in a simple, understandable, approachable way.
So we default to “user-friendly” language. We want people to use the services — we tell them they can “search everything,” “get it (now),” “find it here,” etc.
There are problems with this.
For example, your user’s definition of “everything,” might not match yours. What if “everything” means the library website, too? The open Web? Google Scholar?
So, your tool might not function exactly as your language leads users to believe.
When you say “get it,” you understand that the tool might deliver up a link to a catalog record, or a link out to a journal webpage (instead of the article), or a link to your ILL service (so users can request it).
When your users say, “get it,” they understand that they will get the thing they want right now in exactly the format they expect.
When our systems have warm, simple, inviting language, they also play into expectations — and when we can’t deliver, that damages trust.
There’s another danger here, too. When systems make promises, users may offload their critical thinking due to trust in the system. Studies have found that marked crosswalks (without a light) can be especially dangerous for pedestrians, as people assume safety and forget to stay watchful for vehicles.
The ideal solution is to make the thing act exactly in the way your users expect…but when you don’t have control over most of the systems you work with, that isn’t often possible.
The thing I want to draw attention to here is this: when we simplify our language to appeal to users, we also risk glossing over the exact complexities that they’re likely to trip over.
And some of these complexities are unavoidable, at least for the moment. (I’m unaware of any library service that immediately delivers users directly to the content they were expecting every single time).
One approach is to anticipate the most common misunderstandings and build in support to respond to that (placards that link to library hours when users type in certain search terms, for example).
You may also want to take the opportunity to really interrogate your systems, using that simple language — Does it really do that? Why not? What might help it actually do that? Is this actually a systems issue, or is it a policy issue?
Not sure what your user expectations might be? Test with them. What do they actually type in that search box? When do they pause, frown, sigh? (Ask them what they’re thinking when they do).
It’s not enough to just change our language to stamp out library jargon. We need to make sure we’re actually keeping the promises we’re making.