Daniel Hardy

One of the biggest problems facing those who develop the User Experience is when you should listen to your customers and when you should innovate.  Henry Ford famously said “If I had asked people what they wanted, they would have said faster horses.”  This statement has been a banner for many in the User Experience realm for why you don’t have to talk to customers to make great products.

But there are other times when you should really sit down and listen to what your customers are telling you.  Recently someone decided to take the time to create an entire website dedicated to identifying problems with a product they USE. Dear Adobe collects peoples grips about any and all adobe products then lets other people vote for how important the problems is to them.

After skimming through the top 50 items you can see that Adobe’s Update process for Acrobat is a sore spot for a lot of people.  If Adobe is smart they would try and react swiftly to this by LISTENING to what the users are saying and resoliving their problems.  Sure not everything in the list can be corrected(pricing) but a lot of the ideas are common sense items that Adobe has lost site of.

I recently got an iPhone and in true geek fashion I have been excitedly showing some of its fun features to anyone that will listen.  The one feature that seems to get a lot of reaction from people is the AppStore.  People love how you can simply select something and next thing you know it is installed and ready to go.  No download and unzip, no double click the icon, no restarting, no fuss.

None of them realize that there is an entire operating system that generally functions the same way albeit a lot less flashy.  The package managers in most modern Linux distributions work on the exact same principals.  Simply select an application you wish to install and it will take care of the rest.  Some distributions go even farther and have a bit friendlier interface to their repository such as Ubuntu’s Add/Remove programs.

Perhaps Ubuntu should take a few ques from Apple on this and improve the experience a bit more.  First of all the naming convention is boring and could easily be confused with the traditional Windows area which no one used.  Second they should provide screen shots of the applications. Generally before I install an application I want to know what the interface looks like.  Finally they should try and integrate some social capabilities.  This would allow users to read reviews from other users who may be like them.

These few changes could greatly improve the experience of adding applications.  It could also become a major “selling” point of the OS.

Due to my Uber nerd status I probably review more documentation than most people.   I have a sick and twisted love of teaching my self new things which means I spend a lot of time reading obscure documentation.

Lately I have been spending a lot of time reading documentation for PHP, MySQL, JQuery, and Adobe AIR.  As I have been pouring over pages and pages of information I have started thinking about documentation’s place in the user experience.

Documentation’s impact on the user experience is often not directly talked about.  When asked, most UX practitioners would probably agree that it is part of the almighty user experience but if pushed further I think you might find that they rarely consider it (assuming they aren’t directly responsible for it).

The problem with this is that when a user turns to documentation for help, the experience has already been compromised.  This means that documentation is the last line of defense, a last opportunity to save the user experience and ultimately save a customer.

So what makes good documentation? Unfortunately I am not qualified to give a complete answer of what “good” documentation is.  I do know that documentation that is incorrect is probably the worst thing that can happen.  If a user is told to do something it better work for them.  If there is a possibility that it won’t work, they should be notified of why it won’t work and more importantly how they can tell if they fall into the “won’t work” category.

One feature I have found to be “good” is user comments presented with the article.  Often I read an article and miss some key component or have questions of how it applies to my situation.  If it is a popular documentation center it isn’t uncommon to find someone else answering my question somewhere in the comments.  A great example of this can be found all over the PHP documentation.

There is a lot more to documentation than meets the eye and its impact on the user expeirence is probably more substantial than most UX practitioners believe.  I have heard things like “If I do my job they(documentation team) will be out of a job”.  This is a foolish and dangerous view.  Even in the best scenario some users will need to read about it to understand it.

“As a designer, your job doesn’t stop when you leave the studio at 5 p.m.  That’s why our environment is key - it provides constant input, a constant stream of ideas,” - Jae Min, Audi Chief Designer, Audi Magazine 02/08

This statment rings true for me.  While I may not be designing something as complex or complicated as an automobile, I certainly look for a constent stream of input and ideas.  This consent search allows me to find solutions to problems I have yet to encounter.  It also helps continuously refine ideas and views I have had about previously completed designs.

Often in usability the focus is on the “lowest common denominator” which is to say the least experienced user.  This is because generally people only consider something usable if they (an unexperienced user) can pick it up and instantly be a power user.

The problem with this is that when looking at something complex like large scale system management the user is required to have some background knowledge on how the system works.  If you where to design the system for a user with no knowledge you will most likely be hampering the systems ability to complete its tasks. You may also make it more difficult for experienced users to access the functionality they desire.

On occasion a company will say “Minimize the novice user’s experience and maximize the experts experience” and by doing so find great success.  I would argue that a great example of this is Adobe’s Photoshop.  There are lots of products that are considerably easier to use yet Photoshop has become the gold standard of image processing software.  This standard is not only in the professional world but runs deep into the amateur/home-user world as well.  Most people who have any interest in digital image processing have a desire to own this application even if they have never done it before and may not find it easy to use.

Don’t get me wrong, I don’t believe Photoshop is a difficult program to use but for a completely novice user it is bound to be intimidating and have a fairly steep learning curve.  But by choosing to focus on the advanced user Adobe has ensured that their product is the best one.

There are two concepts that everyone in the usability field should learn early. First, some things by their very nature are not simple and straight forward and no matter what you do they will be difficult to understand. Second, you can never make all of the users happy all of the time.

The first concept is one that I continually struggle with as it begs the question of, “when is enough, enough?” For every product and designer this point is different. Sometimes you may have the resources to continue to refine it over and over. Other times you may need to make the decision to stop grinding the wheels and move forward with the application.

For my self I find that doing a complete design of something more than three or four times becomes counter productive. Typically somewhere in those first designs is the core of what the interface should be. From there it can be shaped into the best solution possible. But this shaping can only happen with a clear and detailed direction. Once that disappears all design work should cease. If the stake holders still have concerns they should provide a detailed direction for the project and refinement can then resume. If they cannot provide a detailed direction then the product should be reviewed by users (assuming time allows) or released to the public with the understanding that some fast fixes will need to follow.

While the second concept seems obvious it requires you to ask a few questions. The fist one that is often asked is, “is it better to make all of the people happy some of the time or some of the people happy all of the time?”  I would argue you cannot do either of these. The best you can hope for is to make most of the people happy most of the time.

The tricky part then becomes defining what “most” and “happy” means. I believe “most” is as close to 95% as economically possible. “Happy” is really a measure of contentedness with the product in question. Again the issue becomes relaying this information to stake holders who would like to see all customers happy all of the time.

Similar to the first concept, refinement work should cease when detailed direction stops flowing from the stakeholders, even if there are still members who feel the product isn’t “ready”.  This is because it is not productive to simply say something is wrong and not provide any explanation of why it is wrong or more importantly how to fix it.

Finally the hardest part about both of these concepts is that they feel like an admission of failure.  You have to stop work when you may feel like it could be better.   If you are anything like me this is a hard pill to swallow.

Well I finally bit the bullet and purchased an Apple product. I know it is hard to believe that someone who is such a technology geek and an interaction designer is just now getting around to purchasing an iPod.

In the short time I have owned the Apple iPod Touch I must admit that the user experience is unrivaled in its market. This isn’t to say that it is perfect, far from it. Apple does an extraordinary job of hand shaping the user experience from end to end. They seem to think of almost everything.

This extreme molding of the experience comes at a cost that most people never discuss. Apple controls every detail of every product they offer and they are not afraid of limiting the user’s ability to edit or modify the product to their taste.

In my opinion this is an ugly mark against against an exemplary user experience. As a user’s knowledge grows, so does their desire to “own” the product. By this I mean, that when a user becomes comfortable with how something works they often want to customize it to their taste. This can be something small like a theme or something larger like configuring obscure features or setting default behavior through out an application.

By limiting the user’s ability to personalize the product, Apple limits the user’s ability to grow to their fullest potential. It also limits their products ability to reach it’s maximum potential as user’s may not find the resolution to the problem their are seeking answers for.

Perhaps my view is a little biased because I like Linux’s Kool-Aid a little more than Apple’s. What do you think?

One difficult aspect of overhauling an application is the loss of a preexisting mental model held by users.  This is to say that users have developed an idea of where items are located and how they generally look and act.   Often a major overhaul will cause these things to change a great deal.

Form the users perspective, one day they log out from an application they may love or hate and the next day the log in to a completely new application.  Sure the data may all be the same and the end goal of the application will probably remain the same but for the user this is effectively a completely new application they must now learn.

There are several ways that an organization can bridge this gap and make the transition a little smoother.  One way that I have recently seen and is quite simple, is just placing a notice on your screen announcing the upcoming changes.  This should link some final comps of the upcoming look and feel.  If you have a bit more time you can do what google did and offer the user both interfaces during a trial period.  This method allows the user to become familar with the new interface while having the ability to fall back on the trusted version should the need arise.  The danger with this is many users will never try the new version.

No matter what method you divise it is important to start building the expectation of change.  This will give the users a chance to prepare.  If done correctly it can also create a bit of buzz as users discuss what is to come.

Today I received an interesting item from Audi. It was basically a ‘welcome to the club’ type package but done on a completely different level then I have seen before. Every aspect of this mailing was Audi through and through. There was all sorts of handy information included like what items are covered under the warranty, a catalog of features that can be added post purchase and my personal favorite, an experience guide book.

Audi certainly has shown again that they care about user experience from start to finish. The real test will be when I take my car in for its first schedule maintenance. I will be sure to post back how it goes.

PC World has a great article highlighting several applications that were better before the manufacture added more features.

The ideas laid out in this article are something I often consider. How many features are too many features? Perhaps more importantly, if you reach the mysterious boiling point what should you do?

The first concept has no definitive solution as is often the case in the development world. Each and every product will have its own point where the application should stop growing. One sure way to elevate this point is to ensure that you have a strong usability and interaction design team working with you. This will hopefully allow you to maximize the experience for a broader range of users.

The second concept is a tricky one. Often an organization has scores of developers working on an application and if there is no more features to add there maybe no more use for the developers. The easiest solution is to roll the developers onto new projects. Interestingly this maybe a great solution to the first question. If the marketplace has room for the features you wish to build then perhaps you application should be divided into two. One for the novice to intermediate user and one for the expert power user.

This is where web-based applications have a great advantage. Because web applications store information about users it becomes easier to have two separate but seamless application views. Advanced uses will see one set of features and interactions while the novice user will see a different set. Either way the data they are working with can remain the same. The application will determine at which point the user starts seeing the advanced view. Generally a decent starting point is to allow the user to choose a more advanced option or base it off of the amount of data the user is working with.

Given enough time every application will experience feature bloat. How the application handles it can make the difference between a great application or just another bloated piece of software that is difficult to use.