Tag: Minimalism

A Cognitive Design for User Assistance – Comprehensive Links

Update, 17 September 2015: Adobe has a new platform for its recorded webinars. Links to the recordings are now updated and will work correctly.

It is important to follow the Instructions for viewing them, which is also updated.

————————————–

I’ve had a number of emails, tweets, and other requests for information on how to get slides or recordings of the webinar series I just finished for Adobe.

Thanks are in order

First off, I need to thank all of you who attended, asked questions, passed me feedback and food for thought.

Thanks also to Adobe for giving me the space and the freedom to present these ideas, and promote the research we are starting to do in The Transformation Society. I’ll be blogging about that more in the near future.

Some Practical Information

Slides are posted as pdf files to Slideshare. You are welcome to use, but not modify, these slide decks, with attribution.

Recordings of the webinars are on the Adobe site – you need to have an adobe.com account to get to them. This will not hurt, I promise 😉 You can get the account for free, and there’s no obligation attached to it.

 Instructions for viewing webinar recordings 

When you click the links to the webinar recordings, you’ll arrive at the webinar description page. Click the “register” button, then fill out the form. You’ll be sent a link that will activate watching. The user experience is less than stellar, but don’t worry about it – just plod through, you’ll end up at the recording, just as we promised 😉

The Links

Session 1: Users Become Learners

Session 2: Empowering User/Learners Through Cognitive Development

Session 3: Integrated Learning: Building Customer Loyalty

 I’ve tested the links, and as of this writing, they all work as advertised.

Enjoy!

 

Why Isn’t It?

In 2009, I delivered a short, light-hearted keynote address to the STC France annual conference, entitled, It’s Not in the Job Description. This post answers that presentation with a question: Why isn’t it there? What is it that we really do, anyway?

Defining Our Profession

I’m indebted to Mark Baker for his post, The Web Does Minimalism, which I recommend to everyone, and for his response to my election post on STC’s business model. His remarks crystalized for me a number of things I’ve been reflecting about over the last few years.

We used to have a pretty straightforward idea of what we did. We were technical writers, and we wrote manuals. We provided the bridge between engineers and their world, and users. We were able to translate from the functionality-based thinking of a product’s creators, to the task-based mindset of the end users.

We were also at the end of the food chain. We had to wait until the product was done, then chase engineers around with our notepads to try and get an idea of how something was supposed to work (not necessarily how it actually did). And we always got blamed for release delays.

Today we do many things that have never been thought of in the context of technical “writing:”

  • Interface design – user assistance is embedded in the interface. How can we design it if we don’t get involved with interface design?
  • Software information content – software today is an information rich environment, and often has to talk to users in one or more clearly defined voices. We write a lot of this content, whether or not it concerns user guidance.
  • Content strategy – this is a new buzzword, more or less since 2009, but if anyone thinks we didn’t do this before, they’re nuts. We’ve always had to make our work fit into an existing strategy, when there was one, and we’ve often helped define one when there wasn’t – it just wasn’t formalized. Now it’s getting more so.
  • Information Architecture – most of us don’t like being told we’ve got to fill in all the lorum ipsum’s that some designer has created for us without ever asking us what we needed to write and what prominence it needed. But we also can’t really start writing if we don’t have an idea of the structure it’s going into. In truth, content and structure need to evolve together and in parallel. So we do a bit of IA as well, and work with designers and information architects to make sure our content has a place to go – the right place to go.
  • Localization – Most of us don’t do translation, even if we are able to. But localization is not just translation. All the activities above also need to take localization into account. You need a good 30% more screen space for material in French or German than you do in English, just take a mundane example. Then there is the HOW you write – there are ways to write that make translation easier – and less costly, too. We have to know about them. Fortunately, most of these techniques also make better source language content.

I’m sure we could find a few more, but you get the idea. The fact that we do all of the above does not necessarily make us experts in all the fields mentioned. We are technical communicators: jacks of all trades, masters of some. We work in teams with other content workers, engineers and developers, marketers and designers, to create content in a variety of environments and situations.

Our skill, today, is not knowledge of English grammar or good style – though these are tools we must have in our kits. It’s not our knowledge or this or that desktop publishing solution, DITA schemas, or CMS systems, though these are also important.

Our primary and most important skill in today’s market is the ability to find information quickly, synthesize it, and make connections where relationships don’t seem apparent.

To quote Mark Baker, knowledge is no longer a salable commodity. Instead, it is “the calling card of expertise.”

In this context, all the definitions of our profession in all the labour bureaus throughout the world are obsolete and out of date.

Minimalism and Dogma

Let’s talk about minimalism for a minute.

A recent emailing on the subject from JoAnn Hackos emphasized the need that

“..users get only the information they need… And, the more languages we translate means that we cannot afford to add “nice to know” extras that fail to help the users succeed in reaching their goals. Their critical goal — getting their tasks done as quickly and efficiently as possible.”

I’d guess very few of us would argue with this position. At the same time, I’m not sure we’d all agree on what constitutes “nice to know extras that fail to help the users succeed in reaching their goals.”

If we define extras as “any non procedural information,” for example, we come into conflict with another important trend, the need to include decision support in on line help. Getting tasks done quickly and efficiently might mean, in some circumstances, having the answer to “why would I want to do this?”

Let’s be clear – most of the time, these days, we’re talking about software, and thus, online help. If you’re doing paper documentation, or even electronic, but related to electro-mechanical operations, or chemical processes, or manufacturing operations, you might have a different view of what constitutes essential information, even if you buy into minimalism as a principle.

The answer to “why would I want to do this?” or other decision oriented questions needs to be clear, concise, and limited to the immediate need. In most cases, probably not more than a sentence or two.

It means that those of us with an editorial function have a particularly onerous task. If we’re to practice minimalism with intelligence, and really provide service to our users, we need to avoid the dogmatic approach of ideas such as, “if it’s not procedural, cut it out.”  On the other hand, if we favour too much conceptual information, we’re not minimalist any more.

How much is enough?  How much is too much?

I’d like to take a stab at a simple guideline: ask yourself, “if I didn’t know anything about this software (or whatever it is), would I know when and why I need to do this?”

If the answer is “yes,” see if there’s anything to strip away, and ask the question again. Keep at it, until the answer is “no.” Then put back the smallest number of bits that make it “yes” again.

As you might imagine, this can’t be done by the numbers – it requires judgement, intelligence, and intuition.

What do you think?