A grumble about buckets

Sometimes developers limit the choices that are offered to their users as a way to simplify. This can be a good thing; I’m a big fan of simplicity.

However, this strategy comes with an important caveat:

If you’re going to force all choices into a few predefined buckets, you better provide buckets that match the needs of your users.

Broken buckets will not earn you brownie points. Or revenue.

image credit: Eva the Weaver (Flickr)

Today I was adjusting my 401k contribution. Here’s the broken buckets I saw when I logged in to the financial services website:

Continue reading

Thoughts On Bridging the “Lacuna Humana”

In my previous post, I discussed the semantic gaps that afflict current programming languages. These gaps are caused by tools focusing on syntax and parsing, and mostly neglecting human factors.[1] I’m not just talking about the fact that languages are clumsy for us to use (more about this later); I’m saying that they ignore our need to talk about important realities of software development: security, coding habits, testability, maintenance plans, dependency management, requirements, intellectual property, and much more.

All this stuff falls within our scope of concern, but none of it is describable in our languages. That’s weird. Imagine we hired a general contractor to build our house, and he was great at swinging hammers and leveling studs. But as soon as we asked him questions about building permits or hiring subs or choosing the right kind of concrete for the foundation, he acted like he didn’t have a clue what we were talking about. We’d be likely to end up with lots of false starts, poorly met requirements, endless kludges, tons of frustration, a heavy QA burden. Hmm… That sounds familiar.

I call this lack of semantic continuity the lacuna humana — the human gap.

The good news is, gaps can often be bridged.

image credit: vestman (Flickr)

I promised I would describe a bridge that has a lot of virtues, and I’m going to begin that work here. It might take us a couple posts to get all the way across, though. Thanks for hanging with me…

Continue reading

Baby Steps

Film poster, displayed under fair use as documented on Wikimedia Commons.

If you’ve seen the delightful comedy movie, What About Bob?, you are no doubt smiling at my title.

Bob is a neurotic and thoroughly irritating patient who depends on his psychotherapist for lots of emotional strokes and life coaching. He ingratiates himself with the therapist’s family and gets himself invited to be their guest on a weekend getaway, against the protests of the therapist. He then proceeds to drive the therapist crazy.

One of Bob’s favorite phrases is “baby steps,” which captures the therapist’s advice to solve problems a little bit at a time, rather than in overwhelming chunks.

“Baby steps” is surprisingly good advice for many questions in software design. It doesn’t apply in all cases, but it applies far more often than it ends up being used.

The Purpose of Design

We create UML diagrams, personas, design docs, lo-fi mockups, and other artifacts to capture our architectural thinking because they provide us with a roadmap of sorts. We need to identify and steer to a consistent point of the compass if we want to produce complex artifacts that meet customer needs. The bigger and more diversified our teams get, and the more moving parts we’re orchestrating into our software, the more important this is.

However, all of these artifacts are means to an end. To whit: Continue reading

What Role Are You Playing in RPCD?

When you role play in RPCD, you could be standing in for either software, or a flesh-and-blood human being. As RPCD explicitly acknowledges, both are part of your final system.

A key insight of RPCD is that the distinction between these two entities is a lot less meaningful than we usually think. Most software is created to solve a problem that ordinary human beings are already addressing in some fashion. In fact, I might go so far as to say that this is true of all software. The quick exceptions that come to mind just take a little more pondering to map. Biometric scanners? Just a replacement for humans judging whether a person matches that photo on their driver’s license. RFID tags? Just making the human inventory team’s job easier. Firmware in high-speed switches on the internet backbone? Just a step or two removed from postmen and switchboard operators. Word processors and IMEs? Just a replacement for a transcriptionist. Signal analyzers for SETI? Genome sequencers? Protein folders for Folding@Home? Just substitutes for human researchers.

human researcher

photo credit: armymedicine (Flickr)

Even if you’re playing a role that you’re sure will ultimately be encapsulated in a tidy software abstraction, RPCD helps you remember that the problem that entity solves is ultimately a human problem. We don’t pay engineers the big bucks to make computers happy.

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.