How checklists can save your life

Dr Atul Gawande is currently in London, touring the radio stations to promote his book “The Checklist Manifesto“. Dr Gawande is a surgeon in Boston Mass., who has been looking at how to deal with complexity in surgery and elsewhere.

He has discovered that complex systems work, mostly through people using checklists. Furthermore, no matter how expert you were, well-designed checklists could improve outcomes. So, with some assistance from Boeing, he developed a 90 second checklist (download it here)  that reduced surgical deaths and complications in eight hospitals around the world by more than 30%.

In the book, he shows how low-cost checklists actually work, why some make matters worse and why others make matters better. 

According to The Guardian, Dr Gawande argues that the right kind of checklist liberates rather than stifles professional intuition. A ­concise sumary of what might go wrong, and what to do if it does, galvanises groups of professionals into tighter teams. Indeed, one of the key factors, included in the checklist, was to introduce everyone in surgical team to each other: it leads to people having the confidence to speak up.

Michael Scriven, at Western Michigan University, author of a paper called The Logic and Methodology of Checklists commented,

Checklists have long been regarded as beneath the level of serious consideration by methodologists and others interested in the logic of the disciplines. But they are more sophisticated than they appear–and are perhaps the key methodology of those disciplines that really treat theory and practice as equals, e.g., surgery, engineering, neural and public economics, program and product evaluation.

For more on checklists, see:

Guidelines for Checklist Development and Assessment by Daniel Stufflebeam

The Ten Commandments, Constitutional Amendments, and Other Evaluation Checklists by Daniel Stufflebeam

Useability Evaluation Report for the Evaluation Checklist Project Web Site by Barbara Bichelmeyer

The Evaluation Checklist Project: The Inside Scoop on Content, Process, Policies, Impact, and Challenges by Lori Wingate

The business case for SaaS (Software as a Service)

Intellect’s SaaS group has published recently a paper called “The business case for Software as a Service“. The paper lays out the technical and cost benefits of SaaS, together with checklists covering selection criteria, legal considerations and comparisons of SaaS applications to traditional in-house systems.

Cherryleaf made some minor contributions to this paper – so minor we didn’t think they merited our listing as contributors to this paper (a mistake in hindsight).

The report states, SaaS applications are generally easy to use and don’t require a great deal of training and online Help. So why is this?

In part, it’s because:

1. SaaS applications are newly developed applications. This means the developers have been able to build upon the recent developments in usability, when they’ve developed the application.

2. SaaS products typically deal with familiar business tasks, such as finance and sales prospecting. Where a SaaS application does try to explain new concepts or tasks (viz. Google Wave), users can still find they struggle to use the application.

3. SaaS applications can be fixed quickly and are usually subject to continuous improvement. Pilot programmes can be much smaller and quicker to conduct. SaaS applications can be measured and tested more easily, using Web Analytics. 

See also: Cherryleaf’s Developing Help for Web-based applications and SaaS services.

Hopefully, the checklists in the paper will serve as good guides and help you navigate the hype that currently surrounds SaaS and avoid any pitfalls.

Study shows people use search to learn as well as to find facts

Researchers at Penn State University are claiming people don’t just use Search Engines to find facts – mostly, they’re using them to learn.

Could this influence the way in which e-learning courseware is developed in the future?

The researchers sought to discover the cognitive processes underlying searching. They examined the search habits of 72 participants while conducting a total of 426 searching tasks.

They found that search engines are primarily used for fact checking users’ own internal knowledge, meaning that they are part of the learning process rather than simply a source for information. They also found that people’s learning styles can affect how they use search engines.

See Penn State Press Release. (Thanks

Google Chrome OS Help – What will it be like?

Techcrunch has reported on an early glimpse of Google’s upcoming Operating System, Chrome OS. So, you are no doubt asking, will Chrome OS come with online Help? Will it be initiated in a similar way to Help in Windows or by some sort of new means?

From the screen shots on the Techcrunch site, it appears, yes,  there will be online Help. It will be initiated by clicking on a ? button in the top right hand corner. In short, it appears Google will be sticking to standard User Interface conventions. What’s unclear is whether the Help pages will be stored locally on the machine or “in the cloud”.

Is the future of education also the future of technical communication?

I stumbled across another great video of Michael Wesch talking about the issues facing educationalists.  Many of the problems they face are the same as those faced by people involved in producing user assistance.

The video is here

Dubbed “the explainer” by popular geek publication Wired because of his viral YouTube video that summarizes Web 2.0 in under five minutes, cultural anthropologist Michael Wesch brought his Web 2.0 wisdom to the University of Manitoba on June 17 (see video above).

During his presentation, the Kansas State University professor breaks down his attempts to integrate Facebook, Netvibes, Diigo, Google Apps, Jott, Twitter, and other emerging technologies to create an education portal of the future.

I particularly liked these slides:

He argued these beliefs were no longer correct,(apart from the first statement).

It’s possible the solutions for the future of education will also be relevant for the future of user assistance. Whether it answers all the questions remains to be seen.

The “Google or Death?” choice for technical authors

July’s edition of Science magazine includes a study that shows scientific researchers are now more inclined to get their information from the Web (specifically, “quick and dirty” searches in Google) than from specialist scientific resources.

If scientists are focusing on only a tiny bit of research – the bits served up by Google – what are typical users doing?  Also, what does this mean for organisations whose user documentation or online Help is not available on the Web?

In the abstract for Electronic Publication and the Narrowing of Science and Scholarship  James A. Evans (from the Department of Sociology, University of Chicago) states:

” I show that as more journal issues came online, the articles referenced tended to be more recent, fewer journals and articles were cited, and more of those citations were to fewer journals and articles. ”

 “Searching online is more efficient and following hyperlinks quickly puts researchers in touch with prevailing opinion, but this may accelerate consensus and narrow the range of findings and ideas built upon.”

Evans’s research backs up JD Bernal’s concept of scientific information having a “half-life” :  with researchers citing fewer journals in favour of more recent articles, papers peak (in use and citation) and then decline, regardless of their usefulness.

This also suggests another consideration when publishing static content, such as user documentation: how do you keep it fresh and found?

What should you include in your user documentation?

Technical authors are faced with limited time and resources, so they often are faced with the dilemma as to what to include and what to leave out of their user documentation. You may ask, if 80% read only 20% of the content, is there any value in documenting the rest?

Technical Authors are often great advocates of doing away with what doesn’t add value in documentation. However, in an article “How normal is normal?“, John Casti explains why extreme events like a killer hurricane occur far more often than we think.

So does this mean that your rare and unusual topics in documents do need to described, after all?

Casti discovered there was greater likelihood to extreme values than we’d expect from bell-shaped, normal distributions:

“Just as with the meltdown of the global financial system, the normal distribution dramatically underestimates the likelihood of unlikely events. Such events follow a different type of probability curve informally termed a “fat-tailed” distribution.”

Indeed, he states Pareto’s (80-20) principle is closely related to fat-tailed distributions:

“In a normal bookshop, there might be around 100,000 titles on the shelves of which 80 per cent don’t sell a single copy during the course of a month. Here the 80-20 Rule prevails. Now consider, which has nearly four million titles available, or perhaps an online music site like iTunes, and ask how many of the titles they have available sell at least one copy in a month’s time. The answer is not 20 per cent or 50 per cent or even 80 per cent. It’s a staggering 98 per cent! Nearly every single title gets some action nearly every single month.”

There are also implications regarding information architecture and site navigation in Casti’s article:

“What’s needed, (Chris Anderson) he says, is for there to be a functioning way to drive demand for those niche products out near the end of tail. First you need a ‘head’, consisting of a relatively small number of hits. Then comes a tail of many niche volumes, the kind only the author, his mother and a small band of fanatics and connoisseurs could ever love. So there must be not only a huge inventory of products, but also a way to direct prospective customers from the head to the tail by means of suggestions, background profiles from past purchases and all the other things a place like does to match readers with the books they really want.”

So does this mean that users navigate to the “niche” topics via the popular “head” topics? Do you need a “head topic” to bring the users in, with a filtering and suggested topics mechanism to direct them to niche topics, to service any customer’s wishes?

I’m not aware of any user assistance-related usability studies that have looked into this. Perhaps there is, as Casti claims, “a lot more going on out on the ‘fringe’ than we ever imagined”. As more content is published online, and more Web analytics-derived statistics becomes available to Publications Managers, then perhaps we’ll find out.