Some people like to do “designer bashing” from time to time. I was just in the mood to do some “developer bashing” today.
There are a number of reasons why user interfaces of many software packages fail. I assume (slightly unfair and inaccurate), that in many cases there is no interface designer involved with user interface development, but rather the interface is designed by the application developers.
Here is a list of (some) common fallacies of some developers in regard to user interface design:
Fallacy #1: User centered design approach is optional.
Some developers actually have no idea what “user centered” actually means (as many consider the implementation of software that users can interact with already as being “user centered”). Also, the most important aspect of user centrism to developers is the feature list, because the features describe what the user could do. The actual ability is a function of a) the features and b) the capability of the user. What is not agreed on many times is that “capability” is not solely an attribute of the user, but is constituted by user experience level plus interface design. The 80/20 rule is applied as 80% application development and 20% interface development instead of the other way around (and in the order “first interface then application”).
Fallacy #2: Features are more important than usability.
For some developers the loss of features during planning phase seems to be a too big tradeoff in comparison to a “minimal” usability improvement.
Fallacy #3: “Design” is just an emotional and subjective quality.
Some developers think a “design” will just become necessary if the application should not only work, but also please and delight. While “likeability” is an important aspect, it is heavily underestimated how much users dislike software that is hard to use.
Fallacy #4: Functionality is what the user could do.
Some developers consider “functionality” being an aspect of the software. In fact “functionality” is an attribute only present in the usage context – where the user is the most important variable. Functionality is not what the software provides, but what the user is able to use. Microsoft Word may have many thousand functions which most users are unable to use. So the functionality of MS Word for users is what they can actually (and not potentially) achieve.
Fallacy #5: Personal experience is the best advisor.
Some developers often think they are able to do “cognitive walkthroughs” on behalf of unexperienced users. While this is a possible approach, many developers (that usually are power users with deep knowledge about the application) do not go far enough when defining “unexperienced”. When doing cognitive walkthroughs many developers keep the same mindset about what is important inside the application. Really unexperienced may consider completely different things as being important.
Fallacy #6: Good application design is the primary determinator for good interface design.
Most developers are interested in designing the application (that’s why they call themselves “developers”). Interface design is an uncomfortable requirement to be added to the application design. While there is much truth in the idea, that well designed applications often offer cleaner approaches to interface design, it is a false conclusion, that a well designed application will necessarily lead to a good user interface.
Fallacy #7: It’s OK to reject major changes of the application for minimal interface design improvements.
Well, sort of. Most of the time it is basically a matter of a wrong design approach in the first place. There is also a persistent understanding of developers that interface design issues do not interfere with the deeper application design – which is simply ignoring the fact that in most cases it remains to be the case.
Fallacy #8: A bad user interface alone cannot set the seal on the fate of the application.
It seems to be irrational to developers to prefer going with no software and unresolved problems instead of trying to work with a hard-to-use application. Unresolved problems can often be deferred or ignored – or – other workarounds could be tried with an easier path to a less optimal solution.
Leave a Reply