A 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. Understanding 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.
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.
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.
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?
Also known as graphical designers. More accurately, I call them decorators. I’ve written about them before (msdn.microsoft.com/magazine/hh394140). 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 idesign.net), 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 rollthunder.com.
Mohamed and T Rex (and everyone), I am happy to suggest some further reading. For your very first book in UX, you MUST read "The Design of Everyday Things" by Donald Norman. Next, try my book "Why Software Sucks" for a more applied view. Then read "The Inmates are Running the Asylum" by Alan Cooper, and "Don't Make Me Think" by Steve Krug. Hope this helps. Dave
I agree with you everyone should have UX background, analyst, architects, developer, testers, ... Also it is not only what customers complaint for, sometimes customers don't know it can be better than that, they don't know till you give them a better UI. I would recommend if the article suggests some of UX articles or materials for not UX developers.
Pluralsight have a nice training video on UI that's a good starting point(I have nothing to do with Pluralsight besides being a paid subscriber!) It would have been nice to have had a reference list of books attached to this article for further reading.
Regarding the point about learning UX from marketing, they often don't know where to stop and simply grant changes to all request from users, resulting to bugs that ruin the UX.
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.