User Experience Matters Part 2

In my previous article about UX, I talked a lot about how the buy in from users is greatly affected by the design of the application.  At the time I was referring to a specific example in my mind, although I didn’t call it out directly.  I wanted to expand upon that post because of a recent, and excellent, series of articles that I read on MSDN magazine by David Platt about wanting Microsoft to publish UX (UI) guidelines for WPF.  In his first article, he articulates a very compelling case for those guidelines, stating:

“The biggest growth driver of the Windows user platform, besides Solitaire, is the standardized UI that its API encourages. The primary control structure is a menu at the top of a program’s window…”

He goes on to posit that this concept is dictated, in large part, by convention, best practices and actual guidelines from Microsoft.  When I read the article, I was smiling because A) I agreed wholeheartedly with him and B) I knew that he’d get taken to the car wash from the free spirits that seem to be encroaching on the ecosystem with the fancy new WPF toolset.  True to assumption, a month later in his second article he gets quite an earful from folks:

“…Plattski, you Luddite, shut up,” they wrote, “we don’t need no stinkin’ standards. That’s so 20th century. We’ll do things that are cool and users will love them because we love cool and users are just like us….”

Yikes!  Let me offer a few takes on that (which follow along with much of what he said):

1. Users really REALLY don’t give a crap what your interface looks like if it doesn’t immediately help them achieve the objective of the app.  If they have to think for even a second how to do something (like finding the damn File button Microsoft!!!), users will either reject it outright, or grumble – and you don’t want grumbling!
2. If you are introducing cutting edge interfacing (and I’ve seen some excellent examples in WPF mind you), you better know damn well what you are doing.  If you don’t, all you are doing is like sticking the blink tag in your HTML
3. Love it or hate it, the Windows Ecosystem has evolved to include a very specific set of interface guidelines, whether written down or not.  By extending those to WPF, Microsoft isn’t saying you MUST set up your interface like so, but indicating that the same principles still hold true.

It bares noting that Microsoft itself is guilty of screwing with this paradigm when they introduced the ribbon.  People went stark raving ballistic over the ribbon – in fact, I know from experience as both an IT Director and a developer that many MANY organizations are still stuck on Office 2003 because of the ribbon.  The difference between what Microsoft did and what custom dev guys are doing with WPF these days is stark however – Microsoft engaged ad nauseam user experience experts, focus groups, social scientists and spent millions of dollars perfecting the ribbon before releasing it – and the end result is truly a remarkable and better user experience – BUT – it rocked the boat and people resisted it.

So, ease up on David Platt – he is merely using a very wide distribution mechanism to illustrate a real problem in development (WPF or not) these days.  I’ve seen with my own eyes custom developed apps that have failed completely and utterly because of the user experience and design.  But hey – you want that blink tag and dancing icons – knock yourself out – it’s just more work for the guys that come in behind you and refactor it