hci

Book Review: Universal Principles of Design

A few months back, my friend Trev recommended this book to me. I’ve been digesting it one topic at a time, on my lunch breaks.

It is profound and fascinating reading.

This is not another software pattern book. In fact, it is not really software-centric at all. It describes truths about the way human beings perceive, reason, generalize, and communicate. Many of them have obvious application to UX, UI design, and to software in general. On the scale of profundity, it gets a 9 out of 10; I suspect that I’ll be blogging about insights from the book for months to come.

I think it’s important to look at familiar problems from new angles; many profound breakthroughs in science are attributable to cross-disciplinary insight. Though time spent in this book won’t directly hone your coding skills, it will help you see recurring problems and solutions with new eyes, and it will suggest tried-and-true criteria for evaluating design alternatives.

As a teaser, some of my favorite design principles in the book include: Interference Effects, Contour Bias, Horror Vacui, Uncanny Valley, Recognition Over Recall, Wabi Sabi, Satisficing, and Propositional Density.

For now, I’ll omit any definition of what these intriguing terms mean, and leave discovery as an exercise for the reader. :-)

Related articles

Users Aren’t The Only People In Your Software

I’m all for a healthy focus on HCI (Human-Computer Interaction), UCD (User-Centered Design), and UX (User eXperience). (See my post about role-play centered design, for example.)

However, some insight gets lost when we think that only “end users” interact with our software, and only their experience needs to be polished.

With enterprise software, it’s common for lots of people in the customer’s value chain to interact with the software to one degree or another. Perhaps IT specialists use the software every day, but need to provide upper management with periodic reports or dashboards. If so, those touchpoints with upper management are also a form of human-computer interaction, and also deserve attention. What about the CIO who is deeply aware of C-level pressures to reduce costs in his organization? He has to somehow justify each line item in his budget. The enterprise software that gives him a convenient, compelling cost savings report is making a savvy UX move. How about the evaluators that see the product before a purchase decision is made? Does their experience matter?

It’s not just the consumer side of the value chain that’s studded with interesting people. On the producer side, dev and test engineers interact with the software all the time. Although their convenience is not the highest consideration, an utter disregard for their use cases can sap team morale and productivity. Less obviously, but perhaps more importantly, you have interactions between the software and your support team, your marketing team, the executives that sponsor the dev budget for the product, and so forth. If you’re doing SaaS, you’ve got infrastructure/datacenter staff. If you’re building an app, you may have content creators or maintainers. All of these people matter.

 

Action Item

List 3 people besides end users that interact with your software in important ways. How well does your software communicate with them and satisfy their need to be productive and drive business value?

Role-Play Centered Design

User-centered design (UCD) is important. I hope I’ve been a good advocate for it during my career. Its basic tenet is that software should be constructed as much as possible according to how users think and work, not according to techie considerations. (A seminal book on this topic is The Design of Everyday Things, by Donald Norman.) At its best, UCD promotes an alignment between technology and customer pain points that keeps software’s value proposition compelling. Even on a bad day, UCD makes software a lot more pleasant to use.

However, UCD rarely yields all potential benefits, which is why I’d like to suggest a specialized form of UCD for many software teams. I’ll dub this idea “Role-Play Centered Design” (RPCD, prounounced /ˈrɪpˌsɪd/) because of the way the various parts of the system come to life. (This idea is similar to–though conceived independently from–the concepts in this article from the proceedings of HCI ’07.)

Role plays can help you build software — not just entertain. Photo credit: TheArches (Flickr)

Manifesto

RPCD is distinguished from ordinary UCD by three key tenets.

  1. The “system” includes people.
  2. Specifics are non-negotiable.
  3. The best way to understand is to “be” the system.

Let me justify each of these ideas, and then I’ll give an example of an RPCD process at work.

The “system” includes people.

Most architectural and UML diagrams focus on software and/or hardware entities. The user’s role in the system is implicit. Even among users of activity diagrams, most workflow is computer rather than human.

This is wrong. software – people != software. Any thoughtful veteran of the industry can tell you stories about why this is so. Engineers who accept the flawed premise that only the computer side of software needs to be designed are already handicapping their UCD fatally. The system built by a software team includes people — individual users, a community, support personnel, sales folks, professional services, maintainers of docs on a web site, etc. If you let an engineer construct “the system” with no serious thought to the people, you often end up with misalignments that make it irritating to understand/use/configure/support, expensive to maintain, or even impossible to sell.

Specifics are non-negotiable.

The devil really is in the details, and if you don’t solve detailed problems, you won’t solve problems at all. The design of a system is therefore best driven by specifics–even if the specifics are only postulated. Specifics are best exemplified by use cases, and role playing forces specifics into use cases.

The best way to understand is to “be” the system.

You should “be” the software in the system, and you should “be” the people as well.

When a human being actually interviews someone in the same way an automated wizard eventually will, you learn things. The human reorders the questions or short-circuits part of the interview because she knows it’s unnecessary. Or the human gets frustrated at how needlessly cumbersome a particular part of the process is. Or the human asks some intelligent questions that you never considered. When two humans interact to model what’s eventually going to be a formal protocol, you confront asynchronicity and error handling in ways that UML or whiteboards don’t.

Modeling the system in role plays also has some other profound long-term advantages that go far beyond just what you learn. I’ll discuss these in a different post.

In my next post, I’ll give an example about how RPCD works.

Action Item

List all the people that interact with or help create your software. If your list has less than four or five unique roles, think some more. Hint: see this post.