I’m horrified to notice that I haven’t posted here since March! OK – I admit it – I’ve been blocked. Not writer’s block – I have no problem writing, I’ve been writing all sorts of things since March. Nope. It’s the accursed BLOGGER’S BLOCK (and here you bring in the horror music…). By that I mean, I have so much to write about, and so little time for anything (like paying work, for example) that when I do get a moment, I resist.
- Perhaps, among all the things I meant to write about, I can’t choose which to start with.
- Perhaps, among all the things people have asked me to write about, I can’t prioritize.
- Perhaps, among all the things that have inspired me to write, I can only remember a few.
Perhaps all of the above. Perhaps I couldn’t decide.
Perhaps I just couldn’t find my way…
…which reminds me of a blog I’ve been meaning to write.
Decision Support as Wayfinding
A short while ago (that is, back in May…) Mark Baker, one of our more interesting blogging colleagues, put up a post about Designing for Wayfinding. We had a short exchange on the subject, and I said, “I might actually write a blog post on this…” and this is it.
Mark is always reminding us that users of technical products don’t follow a linear path through a manual, as if it were a textbook, only to be “tested” in actual use. In this post, he specifies that users start with a business problem they need to solve, and then try to find their way through the product, and user guidance, and whatever else they can find on the Internet, to solve their business problem. Trouble is, they may not have totally thought out the business problem, and they may need to go back and forth several times through all this material to find their way around and accomplish what they set out to do. I am summarizing a lengthy post here, so forgive me for any oversimplification I might be guilty of. What it comes down to is that a user needs help with wayfinding. Mark points to two types of wayfinding:
- Content wayfinding – simply, “finding the right piece of content.”
- Subject wayfinding – “finding their [the users’] way through the subject matter from the starting point of the business problem they are trying to solve to the actual technical implementation of the most appropriate solution.”
And Mark would like us to be better at providing both – as would I. I’ve been harping on the need for decision support in user assistance for a long time, now. And subject wayfinding is another way of describing decision support. If we agree with John Carroll’s premise that people learn best when they are accomplishing real work, and that people need to know how to do that right from the start, then we can also say that in a world of increasingly complex technologies, before we embark on a task, we need to know what it does for us, why it is interesting (or not interesting) to perform this task at this stage in our process, before ever approaching the the how to do it part.
Note that knowing you do NOT need or want to do a task is very important – it saves us time, effort, and frustration.
Mark goes so far as to suggest, in his reply to my comment, that we spend too much time on the button-pushing side of things, and that most people can figure that out for themselves. What is needed, he agrees, is more decision support.
Expert Users and Wayfinding
The more expert our users are, the better they are able to understand what the business problem is, find the right Subject path, leading them directly to the right Content. This means we technical content professionals need to invest time, research, and effort to understand how to help beginner and mid-level users become experts.
It means we need to work on decision support, and building cognitive demand that that stimulate’s the user’s desire to do more, and thus to know more (in that order).
Expertise will not come from reading tomes and answering test questions. It will come from good wayfinding, that leads the user easily from simply meeting a contingent (and probably urgent) need, to being able to generalise from one topic to the next.
As I’ve often pointed out, an expert user is also capable of evaluating and commenting, not only on the message (content) itself, but how it’s delivered (includes wayfinding). And the feedback these users give us is precious when we want to improve our products. It helps the designers design wayfinding into the product, and it helps us design wayfinding techniques that get them where they want to go easier and faster.
Our job is not to make the user understand what we’ve written, it’s to arrive at the accomplishment of the work our customers need to do, with a minimum of angst, frustration, or wasted effort.
Hmmmmm…… I might actually write a blog post on this…
Ray, I am with you 100% on techcomm being about decision support.
I have my reservations about building cognitive demand. Tech comm is fundamentally a commercial activity and our job is to promote the sale of more widgets. It is not clear to me that building cognitive demand is a good way to do that. It sounds dangerously like trying to make me think, and I don’t want to think.
Of course, most people don’t make full use of the products they use. Often they use only a small part of the functionality they buy. You could argue that is you stimulate cognitive demand to understand the product better, you might get people to use more of its capability. That, in turn, might lead them to become more dependent on the product and more likely to recommend it to their friends, which would lead to more sales.
On the other hand, many people may be using all of the product’s features they actually need, or they have reached a plateau in their mastery where the additional mental energy required for greater mastery is more than is economical for them to expend.
Also, some products are feature rich not because everybody needs all the features, but because it is more economical to build and ship one product that many people can use in different ways than to build and ship multiple specialized products.
In any of these cases, trying to stimulate cognitive demand could result in exposing the customer to complexity that they would be happier not knowing about, possibly leading to less interest in buying or recommending the product.
The more commercially discrete approach may be to support the user’s decision making in the moment, without trying to spur them to greater mental effort.
Mark, thanks for the comment. Essentially, I agree with you. We should not be building cognitive demand for its own sake. On the other hand, many people never become experts in even the part of the product they need and use.
From a purely commercial POV, if we not only make our users expert in the parts they need, but include them in our stakeholder communities so that their expertise gets fed back into product design and information design, there is an ROI on cognitive demand of enormous potential.