Tuesday, November 05, 2002

[Tomalak's Realm]: Scott Berkun's uiweb.com: QUOTE Top Reasons why ease of use doesn't happen on engineering projects. In reviewing all the email I've received at this website, and the experiences I've had teaching and consulting, I've tried to catalog the different reasons why projects didn't result in easy to use designs. UNQUOTE [Tomalak's Realm] This is great. The reasons each come with discussion of how to fix the problem. Ease of use was not stated as an explicit project goal. Any development project must have clearly defined goals that team leaders agree to, one of which ought to be ease of use for end-users of the product, combined with a set of trade-offs.  If we cannot do everything desired (schedule slips), how important is this goal? Ease of use was not defined in actionable terms. Designers tend to focus on that which is clearly defined, such as features, performance metrics, defect rates, time schedule, which means that user friendliness can get ignored if it does not also have spelled out what is needed to satisfy the end users.  It is critical to spell out what it is that is being lost if someone decides to cut it out. Before the project specifications are finalized, the team leader needs to make sure customer needs have been properly researched. Decision makers don't see the trade-offs. An element of quality is the productivity of the end users of the product. The needs of end users, to efficiently perform the product functions, must be researched, before the product specifications are completed. For many end users, they prefer something that is easy and efficient to use, than something that is robust and never crashes.  Most of us want both, but as time and budget run out, typically some goals are sacrificed, so it is important up front to have a set of priorities which goal to cut first / last. Unseen impact on ease of use on system / code architecture. Think prototyping and error messages. Think User Interface mapping out very early in the overall design. Confusion over how to use customer data. Data does not solve problems, people do. Thus it is critical that the data not be misinterpreted or misused. Confusion over who the customer is (user vs. customer vs. client). The person who will be using the product is often not the same as the person who pays the development bills. Document the needs of both, and how conflicts in expectations to be resolved. You don't want to be communicating to users in geeky jargon, but in terms of business goals. Technical focus dominates the view of the project. Team leader needs to balance the various perspectives. Diffusion of design authority (too many cooks). Best way to manage this is to have one person, or a small number, define vision for the project. Then other people design their aspects of the big picture, within the shared vision. Feature based design vs. scenario / task based design. The primary value of software is not in its repetoire of features and capabilities, but rather in the ability of its users to complete the tasks for which they aquired this computer product. It is not good enough to have features somewhere within the package that can get the job done. End Users need easy navigation to getting the job done, whatever the job might be. Having a usability engineer in the quality assurance testing staff is essential. No connection made between business goals and ease of use. If the project specifications and team leadership fail to make clear how important ease of use is to overall sucess of the project, then this aspect is one of the first things to be cut, and one of the main reasons why projects fail at many corporations, after they have invested millions of dollars into some conversion. General Incompetence. Teams need to be led by good examples, to avoid getting dysfunctional teams. The worst kind of bad decision making is where something is not communicated until it is too late to fix. The wrong people are involved. The right people are those who are able to effectively balance several key attributes. Compassion for other people. Abstract Problem Solving Skills. Ability to effectively communicate design ideas. Experience crafting designs and observing other people using them. Lack of familiarity with the creative process. It is essential to understand a variety of disiplines and how to cross their boundaries and balance them. Adequate time needs to be allotted to various different development phases. 4:32:08 PM

© Copyright 2002 Al Macintyre.