I'm just back from Adobe's partner conference in Amsterdam, where George Neill, Lead Experience Architect at Adobe Consulting, shows us this great slide depicting a woman processing mortgage applications. She has a PC on her desk which is running her organisation's app for managing mortgage applications. However, around here desk are multiple signs of usability failure. On her left, a paper calendar with names and phone numbers handwritten onto deadline days. On her right, an old-fashioned paper roll calculator. In front of her, a pile of paper forms colour coded with post-it notes. The app, Neill notes, should be handling all these tasks, but one glance at the user's working process is sufficient to expose its poor design.
All good stuff. The next thing we see is a nice application built with an Adobe Flex front-end and an Adobe LiveCycle back-end, with the not-so-subtle implication that these user-experience (UX) focused tools will help us create applications that fix this kind of design failure. There's also talk here at Adobe's partner conference of a new era in software built on customer experience, and how consumer technology from iPhone to Facebook and Twitter is raising expectations when it comes to business applications. There are even a few digs at developers, the people who, it is alleged, hate it when requirements change and who develop software geared towards the IT system which which it integrates, rather than towards users.
There is truth in all of this, but I'm cautious. It is easy to find a poor application and poke fun at it, but the idea of observing users and creating applications that improve their productivity is not a new one, and it is not necessary to use Adobe's stuff in order to do good software design. There are even times when it gets in the way. I recall spending time looking for a campsite on the web, for a holiday, and how it was in general the simple HTML sites rather than the "rich" Flash-driven ones that were easier to navigate. Admittedly the average campsite does not create web applications to Enterprise standard, but the underlying point is that there is a case for simple as well as a case for rich. Never forget "skip the intro".
The key question here: how do we define excellence in user experience? Let me state the obvious for the moment.
Applications that have functional deficiencies will not be rescued by any amount of eye candy or beautiful state transitions; and if the user is surrounded by post-it notes and antique calculators I'd suggest that this is not primarily a UX issue, unless we strip all meaning from the term and use it for every aspect of software design, features and performance.
Second, software can deliver a good UX without necessarily having gorgeous graphics and multimedia. As a business software user, I value applications that let me accomplish tasks quickly and easily. Question: think of a web application that changed the world, partly thanks to superb UX? Answer: Google search. Question: how much PhotoShop and Flash was used in designing the fantastic Google home page?
The case for user-centric software design is irrefutable; but we need rigour when it comes to working out what that means and how to achieve it. I like this comment which I found in an 2004 paper by Larry Constantine:
User-centered design is a good idea in need of improvement. The needed improvement is found in practices that put uses rather than users at the center of design and in changing the prime objective from enhancing user experience to enhancing user performance.
UP rather than UX resonates with me. It also reminds me of Kathy Sierra's mantra: creating passionate users. If the current rush towards UX puts the focus there, I am all in favour. If it means newly empowered designers imposing some sort of visual or multimedia experience on us whether we like it or not, count me out.
Listed below are links to blogs that reference this entry: Why I'm wary of user experience hype in software design.
TrackBack URL for this entry: http://www.itjoblog.co.uk/blogadmin/mt-tb.cgi/151
How many times have you run a program, enjoyed the transitions and animations the first couple of times then searched for a way to shut them off? I know I do this all the time. I just want to get to the next phase of my work, not watch a my last dialog spin down a drain so I can type an email address.
I have seen really cool interfaces that don't support the keyboard. Tab key out of order if it does anything at all, no way to manipulate a pretty custom control with the keyboard. Forcing you to select a date from a fancy control instead of allowing you to type in a date etc.
As a developer we tend to use an interface 10 times and only to test key things then we move on. Our clients use the same dialog box 100 times a day. We need to code for them to do their job quickly, not for us to make it look cool.
Hi Tim, I was quite interseted to read your take on the UX hype, but as I read on you were not talking about UX design but UI design. I would agree that great UI elements do not nessesarily make a great UX. On the other had a great UX could be devoid of fancy widgets and pretty graphics.
Well put. UX is not graphics design.
A good UX should be distraction-free, presenting a chance to work the user into a rhythm, batting off jobs, and providing the user with some representation of how the well user is doing. e.g. number of unread mails left in my inbox.
However, it's neither easy to sell nor demonstrate UX as a technology stack, and vendors are forced to focus on bells and whistles.
So Tim, as Ronan suggests above, I think you're confusing UI with UX. User Experience is about so much more that gorgeous graphics and multimedia.
One of the central points I made in my presentation is that when we're "designing" applications, we're not talking about design with a little "d", which is about the style and aesthetics of how a thing looks; eye candy, if you will. That's an element of our task, but it's not the most important one. When we talk about design, we mean Design with a big "D", which focuses on fundamental considerations about who's going to use the application, how they're going to use it, and what they need from it. We're talking about uncovering the possibilities for providing feature and function that go way beyond what you'll find in business requirements document, and that will improve an application's utility, usability and value to the person that counts the user.
That's why user-centred design principles are so important. If we can understand from observing them what the users' tasks are -- from their own perspective rather than from what business processes impose -- and what problems are getting in the way of those tasks being carried out quickly and efficiently, we can address those problems and improve the experience.
You're right that this approach doesn't require Adobe software -- the approach is entirely technology agnostic. But guess what...I work for Adobe and it was an Adobe event. Of course "other platforms and products are available", but that doesn't alter the fact that Flex, Flash, AIR, PDF and LiveCycle provide a tremendously powerful toolkit for developing Rich Internet Applications -- a term coined by Adobe, remember.
You're also right that the approach isn't new -- a fact I acknowledged by showing a video from 1928 that demonstrated the same principles. But it's not yet widely accepted within the software industry.
But I do believe you're wrong in stating that "if the user is surrounded by post-it notes and antique calculators I'd suggest that this is not primarily a UX issue". I'd argue that it's entirely a UX issue. The user needed to do be able to do something, and her business-requirements/system-process-driven application didn't let her do it. She developed her own processes, her own shortcuts, from which we learned, and from which we were able to deliver a solution that the customer recognised as "fundamentally changing our industry".
And finally, I'm sorry if you thought I was having a dig at developers. Nothing could be further from the truth. What I actually said was that while historically programmers might tell you their biggest problem is coping with rapidly changing requirements, designers want to change things all the time. There's a dichotomy there that needs to be addressed, and that's done by having the two work closely together throughout the design and development phases of a project. No brainer, really. I also said that while "modern Agile developers can work so flexibly that changing requirements don't really present a problem", designers can mitigate against change in any case by understanding the constraints and the opportunities presented by the technology and the business requirements.
So if anything really, I was having a dig at designers.
Hope that clarifies things for you.
Many thanks for the comments.
Actually the opposite - I think they are quite different things.
Thanks for the talk George, mostly I agree with you but I'm averse to the idea that apps have to be "rich" to deliver strong UX.
I loved your picture but don't think it is about UX; it was a failure of requirements analysis and/or implementation.
Tim