According to Scott Berkun of uiweb.com:
1 - Ease of use is not an explicit project goal
2 - Ease of use is not defined in actionable terms
3 - Decision makers do not see the tradeoffs
4 - The unseen impact on ease of use on system/code architecture
5 - Confusion over how to use customer data
6 - Confusion over who the customer is (user vs. customer vs. client)
7 - Technical focus dominates the view of the project
8 - Diffusion of design authority (Too many cooks)
9 - Feature based design vs. scenario/task based design
10 - No connection made between business goals and ease of use
11 - General Incompetence (#11 = the spinal tap commemorative entry)
12 - The wrong people are involved
13 - Lack of familiarity with the creative process
14 - Experts fail to positively impact their teams
As a mechanical / industrial engineer I can say: true, not only for software projects.
The list >>
Other essays and columns >>
Scott Berkun? "[I] designed or managed the development of many IE UI features including explorer bars, autocomplete, Favorites, History, Search and lots of other random things. Worked as lead program manager for Consumer Windows until late 1999. Since then i've be paid to teach and support the many web and interface designers, usability engineers and UI developers at Microsoft."
In unrelated news: Russell Beattie points to Sillydog 701: What's so bad about Microsoft? A detailed summary from a software user's perspective, from a technical perspective, from the perspective of everyone else, plus common defenses of Microsoft debunked. Russell: "Some of it is a bit old, but it's all good. ;-) Lots of good links. Going to have to commit some of this to memory."
With a project rollout on Tuesday, there is not much time to blog right now. The Berkun list was in my "blog this" folder for a while, but I saw that Andrea Janßen came up earlier with it, so kudos go to her.
Comments are closed at the moment. I will post a blog entry as soon as they are available again.
