The June 2013 issue of Technical Communication Online, STC’s Journal, contains a review of Usability in Government Systems: User Experience Design for Citizens and Public Servants, the book from Morgan Kaufmann Press that Dianne Murray and I edited. The review, written by STC former book review editor Avon J. Murphy, begins as follows:

Elizabeth Buie and Dianne Murray have pulled together a book that is long overdue. Government computer systems affect everyone, but until now, no book has focused on improving the user interaction with those systems.

The editors do most things right. Their collection of 24 chapters by 41 authors spread over nearly every part of the globe provides an international kaleidoscope rich in detail.

Murphy likes the international flavor and rich detail of the book and applauds the inclusion of case studies, success factors, and further reading. He finds eight chapters “particularly useful and interesting” for himself, and he calls particular attention to chapters he sees as strongly relevant to technical communication. Murphy points out three chapters whose authors will be familiar to STC members — plain language, content strategy, and usability testing — and I was pleased to see his description of my own chapter, “Getting UX into the Contract” (coauthored with Timo Jokela), as a don’t-miss for people who work with contracts. Murphy recommends that usability folks working with government systems buy the book and that technical communicators borrow it to read specific chapters.

Murphy also expresses three criticisms. To two of them I say “fair enough”:

1. Some chapters, Murphy says, “are dull reading, with too many long, often boring paragraphs.”
   Honestly, I wish we had had more time to edit the writing of our chapter authors who are better subject-matter experts than they are writers in English. I like to think we will have the opportunity to improve those chapters in future editions of the book.
2. The second concern, he describes as “an interesting usability weakness”. (Ouch!) “Neither the detailed table of contents”, he writes, “nor the biographical section identifies who wrote which chapter.” This, he says, makes the book harder to navigate.
   This is a good point, and I suspect it will be easy to add chapter authors to the ToC in future editions.

Murphy’s third criticism, however, does not hold water. Some of the chapters, he writes (citing specifically the ones on security, privacy, and policymaking), “seem not to apply directly to usability at all.” This comment appears to miss the fact that this book addresses not only usability but the broader concept of user experience, and that it covers not only immediate interaction with electronic systems but also the contexts in which those interactions occur. Moreover, electronic system usability directly affects citizen security and privacy: The usability of online security, for example, has received much attention from usability experts such as Dana Chisnell and from business publications as important as Forbes. This book is about applying usability engineering to all aspects of system design that affect citizens’ experiences of interacting with government.

Right, enough grousing. On the whole, I’m very happy with this review. It is overall quite positive, it gives some specific feedback that Dianne and I can address in future editions, and it encourages people to buy the book. I could hardly ask for more.

Even in the farthest reaches of the remotest areas, even when a population is completely isolated from the outside world, people’s lives are affected by the policies and procedures of the government that administers the area in which they live, and no doubt those of some other governments as well. And virtually all* governments carry out their procedures with the support of information and communications technologies (ICTs).

The usability of government systems affects us all. All 6.8 billion of us.

Usability is the effectiveness, efficiency, and satisfaction that a system or product provides to the people who use it. Even if we never use any government systems ourselves — even if we never visit a government website to pay a parking ticket or obtain retirement/pension information — we feel the effects of the usability of the systems that our governments at all levels use to conduct their business. Effectiveness and efficiency (two sides of the usability triangle) are major factors in the productivity of both civil servants and military personnel. Satisfaction (the other side of the triangle) is more important for encouraging citizens to use online methods to interact and communicate with government, but it also plays a role in fostering morale and therefore productivity of government employees. If you like your job, you are likely to be better at it.

Some may say that politics enters into the question of government system usability; I say it does not. We may disagree about what we want government to do, but I think we can all agree that we want it to be more cost effective.

In the usability of government systems, we are all stakeholders.

* Do you know of a government that doesn’t use ICT at all? Please let me know! If you could do this via a comment to this post, that would be even more awesome, and greatly appreciated.

Here are some highlights, adapted and slightly modified from the book’s introduction:

Bookstores abound with offerings on “usability” and “user experience” (2,352 and 293 search results, respectively, on Amazon.com as of this writing). The number doubles for “government contracting” (4,275 results) and jumps by almost 50 times for “government systems” (106,957 — again, as of this writing). This book, however, is unique. A search on “usability and government” does find 89 titles — books on e-government that mention usability as a success factor; government publications that offer usability information related to a single domain, such as web design or aviation cockpit displays; conference proceedings that include academic research papers on usability in e-government. But not one of these titles covers the topic broadly or focuses on it exclusively.

Yet countless citizens worldwide use government web sites and other systems to obtain information from their government and to do business with it. Tremendous numbers of government employees conduct their nation’s business via desktop computer and intranet sites. It is impossible to say exactly how many people will use a government system themselves during their lifetimes, but it is a safe bet that these systems will touch everyone’s life in some way.

But how usable are these systems? How consistent and predictable are the web sites for those who have to navigate the maze of government information and online services? How well do internal applications support the productivity of  government employees? Functionality apart, how well do government systems actually serve the citizenry?

The United States Government is the largest consumer of information technology in the world. In the summer of 2011 the White House reported that the government had a shocking number — more than 24, 000 — of different web sites. President Obama announced the Campaign to Cut Waste, whose charter includes finding ways of presenting the public with Web-based information and services that are better connected and more consistently presented.

Other governments have had similar concerns. In March of 2004 the United Kingdom launched DirectGov to consolidate access to much of its national government information for citizens, and in January of 2007 it announced a decision to eliminate almost 60% of the 951 sites it had at the time. As of this writing, the United Nations has issued two reports on e-government, and the Association for Computing Machinery has held several annual conferences on e-government, in whose 2011 conference Dianne and I participated (along with our colleague Scott Robertson, who wrote the foreword to the book).

Almost every national government in the world has at least one public web site, and we would be surprised to learn of a government that didn’t have computers, at least in its national offices.

And yet no book exists that addresses usability in government systems. Until now.

This is the first book that concentrates on the role of usability in government systems. It covers designing government systems to provide effectiveness, efficiency, and a pleasant and satisfying experience to the people who use them, whether they are interacting with their government from the outside or working for the government on the inside.

The book’s 24 chapters, each written by one or more experts in the topic, cover topics as varied as open government, plain language, accessibility, biometrics, service design, internal vs. public-facing systems, and cross-cultural issues, as well as integrating usability and user-centered design activities into the government procurement process. It speaks to three audiences:

• government and contractor professionals responsible for government system projects, who know they need to improve usability and want information on how to make that happen
• usability and UX professionals looking to work in government systems and needing information about the constraints of that environment
• policymakers and legislators who are in a position to influence government procurement processes to make it easier to achieve usability

The book takes an international perspective and includes many case studies from government systems around the world.

Usability in Government Systems: User Experience Design for Citizens and Public Servants can help increase government cost effectiveness, operational efficiency, and public engagement. It will be published by Morgan Kaufmann Press in May of 2012. It can be preordered from Amazon here. (I’d greatly appreciate it if you’d use this link, as the royalties are not high and this gives me a small commission as well.)

Update: The book is now shipping, and it’s available on Kindle.

I put in a comment via the form at whitehouse.gov. Here’s essentially^* what I said:

The problem is not so much the number of Federal domains (although I agree that it’s probably too large), but the wide variation in information archecture and navigation for similar types of content. I’d like to see some standardization in information structure and navigation for overlapping content, and (even more importantly) in user-centered design processes.

I plan to “tune in” to the live chat this afternoon.

^*I say “essentially” because I copied my comment to the clipboard before submitting it, planning to paste it here… but then I absentmindedly copied something else there while logging into my blog. So I had to re-create my comment from memory. Some of the words differ, but the sense is the same.

I clicked “Mobile” and had it sent to my phone via email. I then retrieved the email on my phone and tapped the link. The boarding pass opened just fine in the phone’s browser (see image at right).

The mobile boarding pass worked without a hitch. After saying he hadn’t done one before, the TSA agent led me to the machine, and I put my iPhone to the scanner. I probably held it there too long because I was expecting the scanner to beep, but he told me to remove the phone, and then he said “You pass!”

Using the mobile pass to board was even more straightforward. United’s gate agent was clearly used to them, and everything went smoothly.

So why is it not for me? Well, consider what I had to do to use it:

1. Get my phone out of my pocketbook or pocket, wherever I’ve been keeping it. This is more trouble than getting out a piece of paper, because my phone is in a case with a high coefficient of friction and does not slide smoothly. (I do this to help prevent a thief from lightfingering it.)
2. Wake up the phone.
3. Enter my security passcode.
4. If the browser is not the current app (e.g., if I’ve been checking my email), bring it to the front.
5. Ensure that the screen doesn’t go blank before I have to scan the code, or I’ll have to do steps 2 & 3 again.

For me, it’s just more trouble than it’s worth. It’s cool and all that, but there are too many steps. I can tuck the paper pass into my passport (which I use for ID whenever I travel, even domestically) and it’s always right there in front.

Paper is very lightweight. It doesn’t need to be awakened or given a security code. I can check my email without sending it to the background. I can keep it in the same place and bring it out whenever it’s needed, without worrying about what else I might need it for. And I can even write things on it if I need to.

I’ll use mobile again if I am someplace where I can’t print the boarding pass. But when I can use paper, I will.

Do you use mobile boarding passes? What do you think of them?

Unfortunately, it seems that no one thought much about what information ATAC passengers would need and how they would use it.

The buses have two displays. One is at the front, with the line number and final destination scrolling across it (see image at right). About six inches high, this sign spans the aisle and is visible and legible from everywhere in the bus.

Problem is, it tells passengers something they already know. Once you get on the bus, you know which one it is and which direction it’s headed. Instead, what you need to know when you’re on the bus is how soon you will reach your stop.

But wait — there’s good news. These buses do list the next few stops. This information appears on a monitor in the middle of the bus. Unfortunately, there’s also bad news — the monitor’s screen is occupied mostly with advertising, which makes the names of the stops illegible from any reasonable distance. (See photo below, from mobytv.it.)

I suppose the advertising pays for the monitor and the information display — and in this sense it’s valuable — but it shouldn’t make the actual information hard to read. The obvious solution would be to replace the line/destination on the large dot-matrix display at the front with the name of the next stop. I’ve seen other bus systems do this, and it works very well.

I commend ATAC for their efforts to improve customer service by using IT to provide more information, and I’m not necessarily suggesting that they get rid of the mid-bus monitors,. They do, however, need to make the information legible to the majority of passengers.

Alphabetical order is NOT a logical order. It may be the best order for a group of choices — i.e., it may be logical to use alphabetical order — but that does not make the order itself a “logical” order. It is only a predictable way of ordering a set that has no intrinsic logical order.

Don’t get me wrong; predictable is good. And sometimes — e.g., in the situations mentioned above — alphabetical order is the most predictable order.

But sometimes it is not, and yesterday I ran across a perfect example. Consider the figure at right. This is a list of car sizes in the preferences area of a travel application. Does the list look logical to you? I can never remember whether “economy” is smaller than “compact” or vice versa; and what in the world is “special”? I submit that size is the logical order for a choice of sizes (duh!).

Similarly, sequence is the logical order for a choice of months or days of the week. (Would you suggest putting April first? I didn’t think so.)

The objective is to choose an order that helps people find the option they seek and (if they aren’t sure) to help them identify the right option. Ordering the car size list by size would do both.

Are you listening, Carlson Wagonlit?

Psychologists go even further. According to PsychCentral, catastrophizing comes in a second form as well:

The second kind of Catastrophizing … occurs when we look to the future and anticipate all the things that are going to go wrong. We then create a reality around those thoughts (e.g. “It’s bound to all go wrong for me…”). Because we believe something will go wrong, we make it go wrong. [emphasis mine]

Yikes! But does it have to be that bad?

I say no. Not if we do it on purpose.

People who do usability assessment are accustomed to catastrophizing. When we conduct a usability review, we look for possible sources of confusion and error, so that designers can devise changes to mitigate them. However, this process need not be limited to post hoc review — nor should it; I recommend that designers do it regularly during design.

Design, of course, doesn’t need to catastrophize to the extent that assessment does — that is not its main function; and overdoing it can hamper creativity the way overediting does to writing. But I argue that a little attention paid to potential problems, during design, can go a very long way. Let me give an example.

On one of my projects — creating the interaction/interface design for a client, for another organization to build — I am the HCI specialist and my teammate is the prototyper, and we collaborate on creating the design. Very energetic and creative he is, up on all the latest interaction techniques and enthusiastic about their possibilities. More conservative about whiz-bang techniques I am, more grounded in decades of HF and HCI research findings. He enriches the design immeasurably; I keep it connected to the why. One of us proposes an idea, I catastrophize it, and we jointly come up with a way to address the problems. We both find our design sessions enjoyable and sometimes frustrating, but they produce a design that’s far better than anything either of us could do independently.

The client absolutely loves our work.

Now, I do not mean to imply that designers never consider the problems their designs might cause users. Many do; and of course the best ones do it very well. Some people, including David Malouf, professor of interaction design at the Savannah College of Art and Design, would even argue that Design as a process naturally includes such examination. I think I would agree with them. However, we all know that many if not most digital products are produced without a conscious design process along the lines that Dave teaches, let alone usability assessment. Whether or not a project has time and resources for formal usability assessment, a little catastrophizing during design can make a big difference.

If we aim to design products for the best user experiences, we must imagine the possible errors and problems that our designs might induce. This does not mean that (in the words of the psychologists) “we make it go wrong” (emphasis mine). Our looking for the possibilities has an entirely different effect, because it has an entirely different purpose, and we are doing it consciously and intentionally. Only by knowing what the potential problems are, can we prevent them. We must “look to the future and anticipate all the things that [could] go wrong.”

We must catastrophize, I say. We must catastrophize.