Designing for Usability
To an end user, the interface is the software product - not the complex business processes, nor is it the intricate database structures that took months to design, and definitely not the hours of programming and debugging that went into the development of the software. The user sees only the application's interface, the end product.
Too many development teams never accomplish their business objectives simply because they overlook the importance of designing usable interfaces. Although they are capable of building powerful functionality into their products, developers often fail to appreciate that all the features in the world are useless unless the target users of their applications can understand how to operate them.
In years gone by, users made their software application purchase decisions based on the functionality offered by competing products. However, in today's world, many software products offer very similar functionality, and users are now starting to make their purchase decisions based on how user-friendly a particular software product is, and how effectively it supports their real life tasks and goals. Users are no longer willing to invest countless hours figuring out how to use software applications effectively.
Many companies are fast realising that the usability of their software products is critical to their continued success in the marketplace. Whether these companies are developing proprietary software for sales and distribution worldwide, or web interfaces for processing e-commerce transactions, the usability of their user interfaces is often the deciding factor between failure and success.
However, achieving product usability is not an easy task, and many organisations fail in their efforts to improve the user-friendliness of their software applications because they do not recognise the importance of accounting for user requirements from early within the software development life cycle. Even in organisations which recognise the importance of ensuring product usability, all efforts to do so usually occur at the end of a development project, when it is normally too late to implement any changes.
This paper argues that, in order to ensure the development of user-friendly software products, it is essential to understand and incorporate a proven usability design framework from early within the system development life cycle. By doing so, software development teams are able to identify usability problem areas within their products early, and implement changes before it becomes impractical to do so.
This concept is what "designing for usability" implies.
THE USER CENTRIC DESIGN FRAMEWORK
User Centric Design (UCD) acknowledges that the development of software applications is a complex process, and recognises that there are many variables such as business processes and technological constraints, which need to be catered for when developing these applications.
However, the UCD framework also recognises that users are an inseparable part of the application development puzzle. By not considering their needs from very early within the software development life cycle, it is impossible to design applications that will ultimately exhibit a high degree of usability.
The User Centric Design (UCD) framework provides organisations with a process, which if followed carefully, can help cost-effectively enhance the usability of any software application in development. The framework advocates the early understanding and definition of all variables that can affect end users' ability to effectively operate a proposed user interface.
By actively involving the correct types of end users in the iterative evaluation and design of user interfaces throughout the software development lifecycle, it is possible to identify user requirements and potential usability problems, and thus provides a means to timeously cater for users needs and ensure usable solutions.
The UCD framework consists of three phases, namely analysis, design, and construction.
The Analysis phase is primarily concerned with researching and analysing whatever you can about the people who will be using the proposed interface, the way in which they currently work, and how you would expect them to work after the implementation of the proposed software application. After completing the analysis phase, the interface designer should have a good understanding of most, if not all, user interface requirements. It is therefore critical that sufficient time and energy is devoted to this phase of the UCD process.
During the Design phase, the interface designer takes the knowledge they gained during analysis, and uses it to start shaping a user interface. This phase normally consists of many participative design and evaluation activities in which actual end users are actively involved. It is during this phase that the high-level design requirements such as user interface metaphors and the structure and organisation of system functionality is defined. Thereafter, users are actively involved in building and evaluating actual screen designs. It is often possible to do this without actually having to use valuable resources to develop system prototypes. Instead, much of the design occurs on paper.
It is during the Construction phase that a system prototype is created and refined through an iterative usability testing and redesign process. Once a finalised design has been reached, the design is carefully documented so that the development team can implement it.
If managed correctly, the UCD framework can be executed in parallel with the normal system development lifecycle phases, and should not necessarily impact on an organisation's ultimate development timeframe. In fact, since the UCD framework will normally identify many usability problem areas early in the development life cycle, and thus remove the need for rework in the latter stages of a development project, it is possible that its inclusion can actually shorten the time required to deliver finished applications.
The diagram below explains this concept.
In the early stages of the development project, there are many design alternatives available to the development team. As the project progresses, the number of alternatives is decreased due to constraints such as imbedded business rules and application structures. Conversely, in the early stages of a development project, the time and cost to make a change is minimal. However, in the latter stages, a change may involve substantial rework efforts and could occupy a dedicated resource for weeks. By investing a little extra time and effort up front in terms of identifying user requirements and usability problem areas, organisations can reap the benefit in the latter stages of the development life cycle, when the pressures for delivery become very real.
In next month's Test Focus, we will explore some of the techniques within the UCD methodology in a little more detail.
Dave Benjamin
dave@usability.co.za