Chapter 10. Usability and User Experience

Computers make it easier to do a lot of things, but most of the things they make it easier to do don't need to be done.

Andy Rooney (1919 )

Architecture with the attribute of usability has become very popular in recent years, as well as accepted particularly since the advent of the Internet. Still, it has been difficult to implement its practice within organizations. Perspectives on usability are often oppositional. Some people consider usability from a product-oriented, bottom-up perspective that identifies usability with ease of use. Others favor a broader top-down approach in which usability is interpreted as the ability to use a system for its intended purpose (Bevan 1995). The main problem with equating usability with ease of use is that one may come up with a product that is usable but is not useful. This contradiction is absent in the latter approach.

Usability has been interpreted by many and in differing ways. Some try to quantify it as a precise science, and others think of it as subjective art form. Although developers of code need to know specific attributes and are willing to incorporate them if that will increase the product's usability, presence or absence of predefined attributes cannot ensure usability, as it is usually impossible to know how users will react to a system unless they actually use it.

While industry and thought leaders across the globe are struggling to define usability, Canaxia like many organizations is going through its own usability transition. Nigel Longfellow, Canaxia's chief usability architect, has been leading the crusade within the organization for several months. Usability is now a much talked-about term within the organization. When Nigel first joined Canaxia's architecture team, he had very quickly realized the following:

  • Unless usability was mentioned as an objective criterion in the requirement specification, little incentive would exist for putting resources into usability design.

  • Measuring against usability objectives provides a means for judging how much additional work on usability is required to reach the objectives.

Early on, Nigel had adopted the ISO 9241 11 definition of usability that states, "Usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use." Using this definition, Nigel had successfully set up a usability program within Canaxia. Different project teams that consulted on a wide variety of issues now frequently called upon Nigel. Nigel has had to fight many battles, though, including the following barriers:

  • Usability was not defined in actionable terms. Very often, people mentioned that the GUI should be easy to use, but little else was defined.

  • The project plans did not reflect usability activities or dependencies with other project activities.

  • Customers, client managers, and even Canaxia's product management and marketing staff used to speak for users in their absence. At the extreme, some managers felt that it would raise product expectations if users were involved in application development activities.

  • Feature lists drove application development, with more emphasis on making the feature work than on making it usable. Very often the team was more excited about the new technology to be used than about realizing the project goal.

Although a complete discussion of organizational barriers, and strategies for countering them, is beyond the scope of this book, this chapter offers some perspective on the five-point program that Nigel put in place, which helped him gain the acceptance for usability within Canaxia. This discussion will help you implement usability within your organization. Implementing usability within the organization still presents several challenges, including the following:

  • Spend development budget on each feature based upon its value to users. A phase in the requirements cycle will help you evaluate the usefulness and scope of each new feature to be implemented. Very often this helps prioritize features to be developed and prevents overdesigning of less frequently used features.

  • Ensure participation from all development members. This helps gain a common understanding context of use. Developer-level decisions will help attain the overall project goals.

  • Conduct usability tests often and report cost-benefit in financial terms. This provides management with insight into the real value of the usability activities. (Cost-benefit is discussed elsewhere in this chapter in more detail.)

  • Make the project lead responsible for achieving usability objectives. This helps create ownership within the project team rather than reliance upon an external person coming in to promote usability.

  • Share knowledge within the development teams. Nigel created several training programs, monthly reports on usability accomplishments, and a discussion database for identifying and discussing usability and user interface issues. Nigel was also instrumental in creating a library of reusable UI components that extended the efforts of the reusability teams. He also published UI design standards and guidelines. In addition to these, Nigel facilitated a usability roundtable where development teams and management sat together to discuss successes and barriers to usability adoption within the organization.

Everything that Nigel did is not applicable to all organizations. An ongoing managed program is important for maintaining the organization's focus on usability. Any program you may create will benefit from recording usability issues and measuring and reporting usability attributes.



Practical Guide to Enterprise Architecture, A
A Practical Guide to Enterprise Architecture
ISBN: 0131412752
EAN: 2147483647
Year: 2005
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net