Reasons ease of use doesn't happen

Martha Stewart has her 10 Rules for running a business, and Scott Berkun has 14 reasons Why Ease of Use Doesn't Happen on Engineering Projects. I wanted to cheer out loud as I reread this. Maybe it's just because I've lived through so many of them and some so recently.

Take 2, "ease of use is not an actionable goal." If there's no criteria for success, it's easy to stop paying attention to this, even if you thought it was an objective rather than lip service to "doing the right thing." "When stressed, most humans prefer to focus on things that are tangible and well defined, rather than vague and poorly defined. So even if ease of use is an explicit goal of a project, if it is not broken down into discrete and measurable pieces, or tasks and work items for someone to do, it will remain an abstract idea that no one feels pressure to fulfill."

Item 3, "decision makers don't see the tradeoffs," is probably one of the most important but most difficult to manage. Because it requires management to be bought in and innovative in software processes. "To get an easy to use product, a different kind of thinking and planning is required.... Team leaders have to recognize how ease of use effects other engineering decisions, and must modify their decision making process to account for it." This is echoed in #7, "Technical focus dominates the view of the project," wherein team leaders get obsessed by brilliant architecture and leave the UI to last or second place. Hey, your customers don't care how brilliantly it's architected, even if it saves you time later. "Wise engineers understand when they don't have the right sensibilities for certain kinds of decisions, and know to yield them to someone more appropriate. An arrogant engineer will tend to assume that what they do not understand must be trivial, or worse, doesn’t exist at all, and will proceed to apply their hammer to things that are definitely not nails."

"Confusion over who the customer is" vs. client vs. user is a good reminder issue. Often the person buying it isn't the person using it, and more often, the person building it isn't really representative of all users, even if they think they are or have some domain expertise.

#8, "Diffusion of design authority (Too many cooks)," is reminiscent of the post I made recently about free software usability issues; "When authority over the design of a project is distributed across too many individuals, the likelihood of a high quality final design decreases. The worst approach is design by committee, where lots of people who don’t have shared goals or shared high level ideas, get in a room and torture each other with compromises until mediocre results that no one likes, but everyone can just barely manage to live with, are achieved." Good design requires good design leadership, unified vision ownership, not widgets built separately thrown together into a patchwork at the end of the day. Good design isn't just the sum of all the features you are adding to the latest release. "In either case, being an effective designer, or design authority, means the ability to: generate good ideas (creative), convince others of an idea (conviction and communication), and integrate the best ideas and feedback that others around them have (mature egos). Good design leaders are therefore quite rare." Of course, you have to know you need them and how to identify them, in order to hire them.

This is closely related to point #12, "The wrong people are involved," the case in which the wrong people own the design decisions. Even on teams with UI designers, I've watched this play out in team dynamic. And it's worse when there's no recognized UI design authority or the wrong person has it for the problem at hand. "The craft of designing interfaces is a unique skill. It requires an individual to have at least four personal attributes: compassion for other people, abstract problem solving skills, the ability to communicate or detail web/software design ideas, and experience crafting designs and watching people use them. Giving design authority to programmers or project managers without these traits is unlikely to work out well."

"Feature design vs. task design," #9, is the reminder that just because you have the bullet on the box doesn't mean anyone can achieve a work goal with it. Did your customer do something real with it? (This could be one of your actionable criteria for #2 above.)

#11, "General incompetence," is another good reminder -- teams might suck, and leaders might suck, despite all best intentions and well-produced documents. Check your team chemistry and ability to Get Things Done Well as a Group.

Well, they're all excellent points, and I think it's worthwhile using them as a diagnosis form for your organization if you think poor usability is a problem you suffer from. The Root Causes may be deeper and more diverse than you thought, but Scott has suggestions for almost all of the issues he lists. If you don't know if you suffer from poor usability, you're even one step behind the need to diagnose why you've got it -- and trust me, you're probably very sick.