ucd

Add some more extra redundancy again

It’s the season for coughs and sniffles, and last week I took my turn. I went to bed one night with a stuffy nose, and it got me thinking about software.

What’s the connection between sniffles and software, you ask?

Let’s talk redundancy. It’s a familiar technique in software design, but I believe we compartmentalize it too much under the special topic of “high availability”–as if only when that’s an explicit requirement do we need to pay any attention.

Redundancy can be a big deal. Image credit: ydant (Flickr)

Redundancy in nature

Mother Nature’s use of redundancy is so pervasive that we may not even realize it’s at work. We could learn a thing or two from how she weaves it–seamlessly, consistently, tenaciously–into the tapestry of life.

Redundancy had everything to do with the fact that I didn’t asphyxiate as I slept with a cold. People have more than one sinus, so sleeping with a few of them plugged up isn’t life-threatening. If nose breathing isn’t an option, we can always open our mouths. We have two lungs, not one–and each consists of huge numbers of alveoli that does part of the work of exchanging oxygen and carbon dioxide. Continue reading →

A Comedy of Carelessness

Act I

The day after Thanksgiving I went on a long road trip to eastern Wyoming. Total driving time: about 7 hours, each way.

At a gas station about 2 hours from home, on the way back, my credit card was declined. Apparently, fraud prevention algorithms at my credit card company had decided that it was suspicious for me to use my credit card out of state. This was rather irritating, since I’d just driven 12 hours on this same highway, using this same credit card to fill up the car, out of state, 2 other times in the previous 24 hours.

Photo credit: herzogbr (Flickr)

I used an alternate card and finished my trip. When I got home, I called American Express to get the card unblocked. (The block didn’t just apply to gas stations in Wyoming–once suspicious, the company wouldn’t let me buy gas a block from my house, either.) I spent 5-10 minutes working my way through an automated phone queue. It asked for several pieces of info to prove I was, indeed, the card holder–all 16 digits of the card, the 3-digit code on the back, last 4 digits of my social security number, phenotype of my dog… I had to call back twice–once because a family member asked me a question while I was fishing my card out of the wallet, and the system lost patience waiting for a response, and once because I pushed the wrong key and had no way to backspace.

Finally, on my third attempt, I got to the concluding challenge in this interview with mindless software: “Enter the first four letters of your place of birth.”

I was flummoxed. Of course I know where I was born, but which place did they want? I didn’t know whether this question was soliciting a city name, a state name, a hospital name… I hesitated. I guessed that city name was most likely to be the answer I’d provided to this security question in the past, but I can think of one or two accounts where hospital or state is what’s wanted.

While I was biting my lip, the system rejected my answer, and I was back to square one. I called in again and remained silent until I got routed to a live operator. She unblocked the card and offered to give me a link to an app that I could download, to make it convenient for me to unblock my card whenever this happens in the future.

Well, sorry, American Express–despite your cheerful customer service representative, you did not make a happy customer with this experience. If you’re going to challenge me when I go out of state, Continue reading →

Progressive Disclosure Everywhere

If you google “progressive disclosure,” you’ll get hits that describe the phrase as an interaction design technique. UI folks have long recognized that it’s better to show a simple set of options, and allow users to drill into greater detail only when they need it. (Thanks to James Russell–a brilliant UI designer–for teaching me PD years ago.)

But calling progressive disclosure a “technique” is, I think, a serious understatement. Progressive disclosure aligns with a profound cognitive principle, and its use is (and should be) pervasive, if you have eyes to see.

The Principle

Here’s my best attempt to distill the operative rule behind progressive disclosure:

Focus on essence. Elaborate on demand.

In other words, begin by addressing fundamentals without cluttering detail. When more detail is needed, find the next appropriate state, and move there. Repeat as appropriate.

Stated that way, perhaps you’ll see the pattern of progressive disclosure in lots of unexpected places. I’ve listed a few that occur to me…

Manifestations

The scientific method is an iterative process in which hypotheses gradually align to increasingly detailed observation. We learn by progressive disclosure.

Good conversationalists don’t gush forever on a topic. They throw out an observation or a tidbit, and wait to see if others are interested. If yes, they offer more info.

The development of a complex organism from a one-celled zygote, through differentiation and all subsequent phases, into adulthood, could be considered a progressive disclosure of the patterns embedded in its DNA. The recursive incorporation of the golden mean in many morphologies is another tie to biology.

A nautilus grows–progressively discloses–the protective covering it requires over its lifespan. The golden mean, repeated and repeated… Photo credit: Wikimedia Commons.

In journalism, the inverted pyramid approach to storytelling is a form of progressive disclosure. So are headlines.

Depending on how you’re reading this post, you might see a “Read more…” link that I’ve inserted right after this paragraph. Making below-the-fold reading optional is progressive disclosure at work. TLDR…

Continue reading →

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?

Long-Term Benefits of RPCD

In a previous post, I wrote about a methodology for designing software that has role-playing at its heart. If you take a look at the example RPCD interaction, I think some benefits will immediately become apparent.

But there are subtler advantages that might not be obvious:

The system never needs to wait for functional code to be deployable.

As soon as you have a set of reasonably clear roles defined, and at least one specific use case, you can observe the system in action. Granted, you’re observing people instead of software, but the full complexity and dynamism springs to life right before your eyes. People can hold clipboards and use checklists to model how wizards populate databases; they can move post-notes on a whiteboard to explore organizational algorithms. Seeing in toto, from the beginning, is incredibly useful.

checklist, from http://www.flickr.com/photos/alancleaver/

The first deployments you do are demos. I am a big fan of demos; you should demo something at the end of every sprint or milestone, to guarantee that you’ve actually accomplished something useful and that it’s aligned with the needs of stakeholders. But with RPCD, you take demos to a whole new level, because your demos become interactive. If sales asks “What happens when the user pushes the big red button?”, you don’t have to say, “Sorry, we can’t demo that today.” You walk over to the person modeling the UI, push the red button on the piece of paper or the whiteboard that they’re holding, and let the system chug.

Later in the evolution of code, when most parts of the system are automated, the roles that humans still have to model give you critical information. Are these roles something that you ought to permanently delegate to human intelligence? Is the wizard you expected to build so complex and error-prone that online chat with a human is a better option, at least in this release? Perhaps you should hire an online chat person as a component of your system, take the risk out of the near-term release, and then study the behavior of that person intensely to learn how to automate in the next release… If your system has always used humans for cogs, adapting it in this way will be natural, not a major departure from expectations.

Another possible insight is that roles where humans are forced to continue to work represent the high-value aspects of the problem. Solve those problems, and customers will really love you, because you’ve radically changed their work.

The needs of all humans interacting with the system are inherently “baked in” and obvious, instead of being implicit.

UCD says to center your design on the user. But so often we forget support, sales, IT, executive management, and so forth. If you’re writing an app for the iPad that uses social ranking to recommend shows airing in the next hour on cable channels, you probably have a team of data managers that maintains current listings for all channels, and a team of backroom IT that keeps your DB running. These people are part of the system; if one day your data center dies, and no IT people show up to fix it, or one day your channel listings goes stale and no data manager steps in to solve the problem, you don’t have a product.

These people should all have roles in your role plays, and by regularly representing them, you can’t help but make better decisions. Overhead and cost centers become obvious. Risks jump out at you.

The clumsiness of certain touch points becomes obvious.

Or in other words, user feedback and usability testing are built in, because actual people, not abstract boxes on your system, are interacting from the very beginning.