The More Things Change: Lessons in User Centered Design
- Dimensions and Components of Change
- Human and Social Factors of Change
- Managing Change and Its Effects
- Making Things Real
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Change is a fact of life, and even more so in software and User Centered Design and development efforts. Natural sources of change during product development result from the following:
Evolution of requirements and business needs
Design changes based upon user and sponsor feedback
Design evolution due to "leaping eurekas" and opportunistic insights
Areas like the user experience are not immune to requirements change in other facets of a software application or system. For example, a change in a functional feature that is visible to users in some fashion has a corresponding change in user interface appearance, behavior, or user interaction. The usability of an application or system may or may not be impacted by such changes.
We'll explore some facets of change and the consequent impacts on a product's user interface. We'll also discuss User Centered Design (UCD) as a best practice approach not only in software user interface development, but also in evaluating change (see Figure 1). Some social aspects of change on a UC Product Team will be explored. An address book application that integrates with other applications is used as an example.
){kind=link}
Figure 1 A user-centered process.
Dimensions and Components of Change
Product development balances components of an equation that include cost, schedule, and function. Change can take place in any of these areas—for example:
Features can be added, deleted, modified, or scheduled differently.
Cost of development can be reduced (it's usually not increased without duress).
Quality requirements can be made more stringent.
Let's consider another view of the equation that balances features, cost, and quality. The interaction between these components is depicted in Figure 2. The interaction between components is complex but somewhat intuitive. There are multiple factors that influence each component. A better visualization is Figure 3, which depicts the major components on three-dimensional planes, with subcomponents overlaid onto the appropriate plane. We'll now explore each major factor in more detail.
){kind=link}
){kind=link}
Figure 2 A balance of features, quality, and cost.
Features
A broader look at the user experience and what a user can do with a system or application is a feature. There are multiple classes of features in a product; for example, function, data, user interface, etc. Changes to these features happen quite frequently during projects.
Figure 3 Feature dimensions.
Function
User visible features include application domain and operating system functionality. Application functions form the core of what a user can do with software and serve its purpose. This is what a user can do with a product.
Example
An example of application functionality is "create an entry in a personal address book," whereas an example of operating system functionality is "remove a personal address book application" from a system.
There are many functions common to all applications (for example, New, Open, Save, Print, and Help). There are many functions unique to each application (for example, New Person, Add Person to Distribution List, and Schedule a Meeting with a Group).
Data
Related to functionality are features associated with application data. Some applications have more data features than other applications in the same domain.
Example
A field for collecting and displaying a phone number is an example of application data. Other possible data features for an application include fields for collection and classification of more than one phone number; for example, Office, Home, Mobile, as well as Day or Night.
Data features are typically seen via the user interface controls used in views of objects (for example, entry fields and dropdown lists). A detailed view of a Person listed in an Address Book potentially has lots of data and controls. Data features are also made available to a user in command dialogs like New Person.
Data features also include ranges of accepted use; for example, lower and upper limits of acceptable data for a given field, corresponding formatting approach and flexibility, validation rules, and business rules. For example, a phone number may support a strictly numeric value or an alphanumeric value. A data feature as simple as a phone number becomes surprisingly complex if a product supports international phone numbers.
User Interface
User Interface features are the mechanisms for appearance, behavior, and user interaction with functions, data, and information. Appearance deals with static and dynamic visual and audible communication of information to a user in one or more views. Behavior deals with static and dynamic responses to user and other system interactions. User interaction deals with how a user communicates with an application via UI features such as menus, buttons, drag and drop, shortcuts, gestures, utterances, etc.
Example
A user can print an entry in the address book via a menu command or by drag/drop to a printer.
Features of an application UI include a conceptual model, access methods, screen flow, objects, views, commands, feedback, and UI mechanisms.
Information
Features related to information provided to users to explain an application and how to use it include instructions, help, interactive tutorials, wizards, tooltips, and performance support.
Example
A user can request help on how to convert an address book group to a distribution list.
Integration
Features related to integration include those that facilitate exchange of data and/or interoperability between objects, applications, and the supporting desktop. Integration includes intra-object and inter-object operations. Other integration facilities include exploitation of system-level features such as shortcut keys and clipboard operations on entry field content.
Example
Adding a person from an address book into a distribution list via drag and drop is intra-object, whereas dragging a person into a calendar is inter-object.
Cost
Developing a product with certain features at a desired level of quality is going to cost something. Cost factors are depicted in Figure 4. For a constant set of features, the cost of a product will vary based upon desired quality. For a constant cost, the implementable features and quality of a product may vary. Let's explore the dimensions of cost.
){kind=link}
Figure 4 Dimensions of cost.
People
People are the most critical and expensive component of a project. People must work together smoothly and effectively in order to achieve desired results. Dimensions associated with people include roles, experience, attitudes, hourly cost, burden rates for the cost of overhead and benefits, travel, and other expenses.
Skills
People must have the right skills to tackle a project. If the skills are not available at project startup, the skills must be learned, internalized, and applied. Certain skills and learning times have higher costs associated with them.
Tools
Beyond people, the most productive, usable, and cost-effective development tools must be secured for project tasks. Some tools are moderately priced, whereas others are quite expensive. Some are easy to acquire, whereas others require time and effort to secure. Some are easy to use, and some are painful to use.
Facilities
Along with tools, facilities such as office space, development labs, hardware, telephone and LAN lines, networks, software, and other materials must be secured for the project team. As with tools, facilities must be productive, usable, and cost-effective.
Process
Along with people, doing the right things the right way is essential. Doing the right things in the most productive, usable, and cost-effective manner is essential. Some processes are better than others, given other cost factors relative to a set of features and quality goals.
Quality
The quality of a product has many dimensions. Quality varies, based on the features of a product and the cost of developing it. For example, missing features or poor user interface negatively impact a product's usability. By the same token, very stringent quality factors influence how many features are developed and how much is spent.
Rule of Thumb
Usually, you get out what you put in.
Figure 5 Dimensions of quality.
){kind=link}
Schedule
Not usually thought of as a quality factor, schedule is certainly a dominant aspect of most projects. If a project's schedule is too short, it can have impacts on other Quality factors, as well as Features and Cost. If a planned schedule is too long (which is not very often), other Quality, Feature, and Cost factors can be influenced. Alternatively, schedules are pressured due to voluminous project Features and constrained Costs. Perhaps Schedule should be its own axis in a four-dimensional coordinate system.
Performance
Response time is the dominant factor of performance, though throughput is sometimes important. A difficult aspect of performance is the challenge of predicting likely response times while in design. The more stringent the performance requirement, the higher the cost.
Reliability
As with performance, it is difficult to predict the reliability of a system while in design and build. The first hints of stability do not surface until beyond unit test. As with performance, costs are higher with more stringent requirements.
Maintainability
Ease of maintenance is desirable for any product because the developers of a system are not likely to perform in maintenance roles after deployment. Maintenance costs are certainly higher with systems that have been thrown together quickly with insufficient design materials.
Usability
Time to learn, productivity, error-free use, and user satisfaction are measures of usability. The higher the level of Features, the more pressure is placed on UI and usability factors. The lower the Cost in support of UI and usability, for example, engineering skills of the development team, the more pressure is placed on product usability. The more stringent the requirements for usability, the higher the Cost.