![\"\"](\"https:\/\/i0.wp.com\/grapnel.net\/blog\/wp-content\/uploads\/2012\/10\/shoe.jpg\" "\\"shoe\\"")
<\/a><\/p>\n\n\n
- By\u00a0OLIVER WREDE<\/a>\u00a0|\u00a0Published:\u00a0APRIL 30, 2004<\/abbr><\/li>\n<\/ul>\n
Some people like to do \u201cdesigner bashing\u201d from time to time. I was just in the mood to do some \u201cdeveloper bashing\u201d today.<\/strong>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.<\/strong><\/p><\/blockquote>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Here is a list of (some) common fallacies of some developers in regard to user interface design:<\/p>\n
Fallacy #1: User centered design approach is optional.<\/h3>\n
Some developers actually have no idea what \u201cuser centered\u201d actually means (as many consider the implementation of software that users can interact with already as being \u201cuser centered\u201d). 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 \u201ccapability\u201d 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 \u201cfirst interface then application\u201d).<\/p>\n
Fallacy #2: Features are more important than usability.<\/h3>\n
For some developers the loss of features during planning phase seems to be a too big tradeoff in comparison to a \u201cminimal\u201d usability improvement.<\/p>\n
Fallacy #3: \u201cDesign\u201d is just an emotional and subjective quality.<\/h3>\n
Some developers think a \u201cdesign\u201d will just become necessary if the application should not only work, but also please and delight. While \u201clikeability\u201d is an important aspect, it is heavily underestimated how much users dislike software that is hard to use.<\/p>\n
Fallacy #4: Functionality is what the user\u00a0could<\/em>\u00a0do.<\/h3>\n
Some developers consider \u201cfunctionality\u201d being an aspect of the software. In fact \u201cfunctionality\u201d is an attribute only present in the usage context \u2013 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.<\/p>\n
Fallacy #5: Personal experience is the best advisor.<\/h3>\n
Some developers often think they are able to do \u201ccognitive walkthroughs\u201d 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 \u201cunexperienced\u201d. 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.<\/p>\n
Fallacy #6: Good application design is the primary determinator for good interface design.<\/h3>\n
Most developers are interested in designing the application (that\u2019s why they call themselves \u201cdevelopers\u201d). 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.<\/p>\n
Fallacy #7: It\u2019s OK to reject major changes of the application for minimal interface design improvements.<\/h3>\n
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 \u2013 which is simply ignoring the fact that in most cases it remains to be the case.<\/p>\n
Fallacy #8: A bad user interface alone cannot set the seal on the fate of the application.<\/h3>\n
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 \u2013 or \u2013 other workarounds could be tried with an easier path to a less optimal solution.<\/p>\n\r\n\t
\r\n\t\tTweet<\/a>\r\n\t<\/div>\r\n\t