The More Things Change: Lessons in User Centered Design

How does change affect a product’s user interface? This article discusses User Centered Design (UCD) as a best practice approach, not only in software user interface development, but also in evaluating change. The author explores some facets of change and the consequent impacts on a product’s user interface.

From the author of

From the author of

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.

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.

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.

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.

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.

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.