I regret that I will not be able to complete this week’s HCI assignment due to the fact that I will be attending Adobe MAX. During my time at MAX I will be attending five hours of sessions concerned with Experience Design (XD) and User Experience (UX) from luminaries such as Jared Spool and Robert Hoekman, Jr.

I feel that this dedication to the craft should excuse me from this week’s assignment. Besides, we both know that I’ll be getting more real-world knowledge from these MAX sessions than I would from preparing a usability study proposal for your class.

Regards,
David

Like many other design books, Designing the Obvious cautions developers against designing applications with the bells and whistles developers appreciate because most users aren’t at all like developers. In Hoekman’s own words:

Programmers… often want incredible amounts of control over the applications they work with, so they surface everything they can in the applications they build… Their users don’t want this fine level of control. They want to understand how to get their work done and go home…

But what do I do if my users are developers? What if I’m building software for use by development teams to adopt the enterprise’s release management services? To what degree does the above advice still apply?

I think the advice should still be followed more than it should be ignored. I don’t know any developers who got into the industry because they loved release management processes, and I think it’s fair to say that most developers view such processes as barriers or hurdles that stand between them and what they want. The developers I know (including myself) approach release management software like most people approach tooth extractions or prostate exams: at best, they just want the whole experience over with as quickly and painlessly as possible; at worst, they deeply resent it. Consequently, software that facilitates release management processes should probably be as demure and unobtrusive as possible.

(Naturally, I’d like the software I write to have a better reception than “gee, that wasn’t as bad as it could have been”. I have some ideas that I’m hoping will kick the user experience up a notch. We’ll see how that goes.)

Now, back to the rub. What do I do about a ticket to make the number of items on a page a user-configurable preference? (Does this sound familiar? It should.) Contemplating such a ticket started my thinking about how to design for developers. Should this be a preference, or did I just not pick a good default? Developers love to control little things like this, but does it matter? What is the value of this feature (as measured by anything: cost savings, productivity gains, user satisfaction, whatever) versus the cost of implementing and maintaining it?

Each time you say yes to a feature, you’re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature’s out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get. [From Getting Real]

After kicking this around in my mind for a while, I realized something: a ticket to make items-per-page a user-configurable setting is a feature request, not a use case or user story. Why does it matter if there are 20 or 50 items on a page? How often is the 21st item in the list the one a user really cares about? What problem is this feature trying to solve? What is the user trying to do such that having more (or fewer) items on a page will improve her productivity?

I’ve come to the conclusion that feature requests are an anathema to our profession. Features are the how of application development, and we often get so wrapped up in them that we lose sight of the why of application development. There is a trap into which it is easy to fall: “just add a button to…” or “move that to here” as deceptively simple and some even sound almost like a use case, but they aren’t. Features should be driven by use cases or user stories—features should directly contribute to helping the user be more productive. A feature should be functionality identified by the development or design team as a means to assist a user toward a goal. Everything that doesn’t directly assist the user to achieve an outcome is simply a distraction with a maintenance bill attached.