Last night, Brian Noyes pointed me to his blog post about Differentiated UX and asked my thoughts about it. This post is derived from my reply to him.
From Brian's post:
A new buzzword that I hear more and more these days, particularly from Microsoft evangelists, is "differentiated user experience" or "differentiated UI". I'm even guilty of using this occasionally myself. And yet, it is one of those terms that often makes people cock their head like a dog that heard a human-inaudible screech.
In an effort to save my dying keyboard, I'll call it DUX or DUI here. And trust me, the effort needed to make a DUI can actually cause a DUI.
As Brian mentions, there is no clear concept of a differentiated UX or UI, but we agree on the basic definition.
From my reply:
I totally agree that a good – differentiated – UX would use a new way of doing the same tasks.
To clarify, task oriented means creating a UI that makes sense for a particular task rather than commonly used UI patterns. Let me give you a very simple example: if you are creating a graphical application and need a button that activates the Pencil tool, it would make more sense to use a pencil icon on a button rather than a button with the text "Pencil" on it. If you want a more complex example, check out my post about Rethinking the Button.
So yes, I'd say DUX is almost the same as task-oriented UX design.
From my reply:
I totally agree that a good – differentiated – UX would use a new way of doing the same tasks. This was something Kai Krause did magnificently and why he is my hero. We – the developers – are so caught up with all the hundreds of new technologies and trying to make them all work that there is no time to do UX, just a simple UI that is quick and easy for the developer.
I may not have been programming for as long as many of you, but from what I remember there weren't as many new technologies and 3rd party material in 1998 as we do now. Right now, we have LINQ and soon SQL 2008, the whole new way of handling WPF in the code layer, new strict UAC-oriented security guidelines, WCF, and what not. It really isn't the developers fault (or job, come to think of it) that he or she can't focus much on UX. And when there is no designer at hand to do this, the only fallback option is a quickly thrown together UI that more often than not (from a designer's and UX point-of-view) sucks.
From my reply:
In my opinion and experience, the biggest problem with bad UX is the old menu/toolbar/grid recipe (like mentioned in your post). Most regular developers I’ve seen are using that same method (and I forgot to mention the Outlook style sidebar) for their business apps. And in fact, a common rant of mine is that the Grid is making developers lazy. So often do they quickly bind a grid instead of using a more graphical and comprehensible. These controls are good for many situations but not for all. From what I’ve seen, a developer will use a Grid where a ListView can be used because it can be directly bound and does not require much code.
Brian's reply to this:
I shudder to think how many times I’ve gone in to help a customer put together a system and the developers insist “no, really, we HAVE to take this table with 57 columns and bind it to a grid with all columns in it… that is what our users want”. After I choke down the bile, I try to explain that they probably don’t really understand what their users want at all. :)
I don't care if you hate me. STOP USING THE GRID, people! Really, it is time to kill the grid. It is making developers lazy and end-users unproductive at best. And I promise to punch the next person to say "It's easy to bind the grid, nothing else is as easy". Wrong, wrong, wrong. Go watch episodes one (Intro) and three (DataBinding) of revoluxions that Andy and I did a long, long time back. It is SO darned easy to bind data to the ListBox (not even the ListView!!) in WPF.
If you're saying my <insert favorite 3rd party vendor's name here> Grid is super awesome and let's me add cool things like dropdowns and checkboxes and ink. Again, go see the DataBinding episode. A ListBox in WPF can accept anything - and I mean anything - including custom controls!!
From my reply:
The second biggest problem for bad UX are cookie-cutter 3rd party controls. Again, if you look at all the offerings from 3rd party vendors - it’s all grid essentially. The newer WPF ones maybe look hip and act cool, but they’re still just the same old controls with a bit of new functionality and eye candy. And these controls are keeping developers from adding a good UX. And custom work is always a requirement for a REALLY good UX. The Ribbon UI was a very innovative breakthrough for the Office apps. But now everyone is just aping it, not building on top of it. They just want their app to look like Office.
What more can I say? Trust me - not every app should be like Office. The Ribbon is cool but not useful everywhere. Custom controls from all those vendors are really good and useful, I don't deny that - but don't let them become the app itself. Add some customization that is focused on the task your user will be doing.
From my reply:
The software world can learn a LOT about this – especially differentiated UX – from the game industry. Check out control panels (on game objects, as well as the actual UI) in Doom3 or Quake 4 or Crysis or Republic Commando. While it is nothing that would be found in the real world (except some in Doom and Quake) they still speak of task oriented UI design, not common design oriented UI forced for that task.
Here are two simple examples. They seem simple enough, but we rarely do this in our applications.
From my reply:
Of course, the root of the problem is that developers should not be doing the UI any longer. A designer has to be involved if good UX is a target. Someone who thinks exclusively about the end-user experience. Additionally, it has to be a hands-on designer, not someone who will provide JPEGs and then a developer does the XAML. Many unspoken ideas are lost in that process and tradeoffs are made in the moment and end up being a mediocre UX.
It has happened so many times to me personally. Over a dozen times, I've handed complete graphical assets (CSS, JPEGs, etc.) for a website design, along with complete JPEG mockups of how it should look when built. But for reasons I will apparently never completely comprehend, the developer(s) somehow mess up the design. The most basic thing I can think of is that they're not trained for putting together a design - they're trained for making it work.
Even after I've done the actual website - code and all - and published it, the client (a developer) will go in himself a month later to add a bunch of text. Wouldn't be more than 2 lines - a heading and a line of text. But he would use a non-pro tool like Notepad++ or something else instead of Visual Studio or Expression Web - or worse - try to hand code it in HTML. Now these alternatives are not bad - but only if you KNOW what you're doing. A lot of my designs are currently flying mutilated on the web.
If you're saying "So what? It may not look perfect - only a slightly different - as long as it works, what's wrong?" you're probably a developer and need a LOT of help with UX. Because the end user notices these things. It lowers the professionalism of the application, and in turn, of the developer that made it.
In Brian's post, he writes:
While a lot of this may seem like just eye-candy, one has to be always cognizant of the impact a simple visceral coolness to an application compared to its competitors may have. I frequently work with customers ranging from internal corporate applications; to ISVs for major industry software including financial, insurance, and medical; to government contractors developing specialized applications for defense and management purposes. In all these arenas, there is always an aspect of sales to the success of the project. If the funding source (the VP of X in the corporate environment, the purchasing bank or insurance company in the ISV scenario, or the General with the budget to give the green light in the government arena) can look at an application for which they have no expertise to judge themselves, but immediately feel like it is impressive in some way (which usually manifests itself graphically first), then they are likely to chose that as the way forward.
In a totally separate conversation regarding my product reuxables, Andy Eick writes:
I wish I would have learned earlier in my career how important the UX is -- when you are briefing the boss, they need to see a good looking UI, or you won't get your next funding cycle.
This is a fact. Apple has understood this for a long time. It's their aesthetics that sell their products more than anything else, IMHO.
From my reply:
And we come to the core of the thing – there aren’t enough designers out there. Not for this kind of work. A good majority of them are trained for eye candy – not usability. Designers also need to understand some basic precepts of software development so as not make the developers’ job too hard because of their designs. Again something to learn from the game developers. There is no common term for the role, but often there is a sort of interpreter in game dev teams. Someone who knows the basics of graphics and software and helps the design and development teams understand each other.
Unfortunately, we don't have an immediate solution for this problem. We can only wait for more designers to start learning about real UX (not the buzzword it has become) and provide their services. In the meantime, I humbly point you to www.nukeation.com :)