August 2013

Volume 28 Number 8

Don't Get Me Started - The Decade of UX

By David Platt | August 2013

David PlattA named decade doesn’t really begin until about three years in. What we think of as the Sixties (the “Free Love Decade”) didn’t start until JFK’s assassination in 1963, the Seventies (the “Me Decade”) until the 1973 energy crisis, the Eighties (the “Reagan Decade”) until the 1983 release of “Return of the Jedi,” and so on.

We’re now three years into the 2010s, so it’s time to name them. UX has become the defining factor in the success or failure of software. Therefore, I hereby declare this the “Decade of User Experience,” or DoUX (which, appropriately, means “sweet” in French).

You might have gotten away with a crappy UX 20 years ago, but customers today demand much more. Our standard of care is continually rising (one word: iPhone). A computer that users can’t figure out how to use, or that requires expensive training to use, or that makes expensive mistakes because the program misleads users, is a very expensive paperweight.

Not only do companies need to increase their UX efforts, but every developer now needs to know UX, even if it’s not his primary job, just as every soldier needs to know battlefield first aid. Under­standing UX is as essential today as understanding functions was in the 1980s, objects in the 1990s (the “Generation X Decade”) and Web services in the 2000s (the “Millennial Decade”). For a university to bestow a computer science degree without a class in UX constitutes malpractice.

Many developers or architects think they don’t need to understand UX. Here’s why they say that, and why they’re wrong.

Our Projects Are Low-Level, So UX Doesn’t Matter

Nonsense. Every project you work on has some connection to a human user somewhere. Even a programmatic Web service needs error reporting, installation and configuration, status and performance monitoring dashboards, and so on. If your project only has small amounts of UX, that’s all the more reason it needs to work well.

Marketing Decides Our UX

You’re wise to have a good relationship with your marketing department. They certainly feel pain points from the customer and bring them back to you.

At the same time, marketeers are not interaction designers. They might give you the first clue as to what would make the customer happier and more productive—“Customers complain that they’re losing work when our app crashes”—but it’s up to you to take it from there. How often does it happen? How do you detect and measure it? To fix it: Auto-save? Rollback? How often? Configurable? Imagine asking these questions of your marketing department, and tell me if they’re really driving the UX. They’re not; you are, even if they sound the initial alarm.

You should also be talking to your tech support department. They feel your customers’ pain far more immediately and brutally than the glad-handing marketeers.

We Have a UX Group That Does That Stuff

Some large companies have a UX design group that approves every user interaction. If you have one of these, you’ve already found that their time is in tight supply, as it is for other ultra-specialists such as ophthalmologists. You can get a brief appointment in six months if you beg. They can’t follow up or help you iterate. You need to understand what they tell you in your far-too-limited interactions and implement those principles day-to-day to make the best use of the thimblefuls of their wisdom that you actually get.

Also, their time is (quite rationally) dedicated to your company’s primary, outward-facing programs. They don’t have time for your internal or second-tier apps. Ironically, because your company values good UX, the apps you work on are held to a higher standard. But your bosses don’t give you the skill set or resources to meet these demands, now do they?

UX Is for the Beret-Heads

Also known as graphical designers. More accurately, I call them decorators. I’ve written about them before ( The UX game is almost always lost before it reaches them.

Every developer now needs to understand UX. Take it in college, take one of my classes (in Boston or London this October, see, take it in continuing education, but take it. And for at least the next 10 years, make it sweet.

David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at