There’s nothing quite like using a well-designed product or
piece of software, where one of your first thoughts is “someone designed this just for me.” For some, it’s high
quality materials that provide a rich tactile experience; for others, it might
be a physical control or user interface element put in exactly the spot you
expected. Get this just right, and you might have the next Walkman or iPhone in
your hands.

Unfortunately, the reason many items, from consumer products
to enterprise software, fail to reach this usability nirvana is that they were
designed with features in mind, rather than from a perspective of how someone
will actually use the item.

The original iPod is a fine example, as it was an
MP3 player that arrived late amid several competitors and had a similar, if not
inferior, collection of technical features. Despite these shortcomings, the
device addressed one of the prime complaints of early MP3 players, providing a
fairly seamless way to find, purchase, and load music onto the device and
delivering a product that looked like audio gear rather than something from Star Trek.

Similarly, in enterprise IT there are thousands of companies
that run the exact same software and hardware, matching technical features line
item by line item, yet some will implement wildly successful technical
projects, and other companies will fall flat on their faces. I believe one of
the key differentiators of these companies is whether they approach the
solution to a business problem from the perspective of features or use cases.

The incredible use
case

For the unfamiliar, a use case is a brief description of how
someone will interact with a device, process, or technology to accomplish a
task. Gathering use cases tends to naturally go from general to specific,
gradually moving you toward a specific outcome.

For example, if you consider
use cases for a vehicle, one of your early use cases might be driving the
vehicle competitively, while my use case might be hauling lumber. For your
vehicle, the competitive driving might steer us toward use cases around
cornering performance, while mine would lead us to discussions of towing and
cargo capacities. We’d arrive at very different vehicles based on these two
fundamentally different use cases, yours a high-performance sports car, and
mine resembling a large truck. Conflicts between use cases tend to stand out as
you go through this narrowing process.

Contrast this to gathering features. In an effort to satisfy
all stakeholders, someone designing our theoretical vehicle might diligently
record your desire for a supercharged engine and 21″ low-profile tires
alongside my high-clearance and towing capacity, resulting in a satisfactory
list of features that’s fundamentally impossible to deliver.

While rather obvious in this example, IT shops everywhere
are sending diligent business analysts to talk to their non-IT counterparts,
who happily record conflicting features and technical “requirements.” When one
attempts to build a system that checks the box for “rapid data entry” and
“extensive data capture for management reporting,” one ends up with a system
that satisfies no one.

Getting away from
features

To shift design discussions away from features, provide some
minimal background around what you’re trying to accomplish. Mention the
high-level purpose of the system you’re planning, and business capabilities
it’s supposed to provide. Then encourage your non-IT peers to describe how
various stakeholders will actually use the system, capturing each scenario as a
use case.

Highlight conflicts between these use cases as they’re
identified. Just as demands for a high-performance car that carries eight
people and hauls a boat are unreasonable, demands for IT systems that capture
hundreds of complex data points yet require no training are obviously
unreasonable. This process tends to encourage reasonable compromise early in
the design phase, rather than turning the request into a technical issue later
on. It’s far easier on day five of a project to highlight a conflicting use
case than it is on day 50 to say “our programmers can’t seem to get this
feature working.”

Use cases also map well to your overall scope and testing
process. While it’s easy to contend that a feature request was misunderstood or
not fully implemented, it’s harder to dispute a well-documented use case and a
system or process that meets the use case with aplomb.

Grade-A BA

The only critical prerequisite on the part of IT to make use
cases work is a cadre of competent, business-minded analysts who can rapidly
understand a business process, facilitate discussions around use cases, and
highlight conflicts without being steamrolled by their peers and their
passionate opinions.

Once you develop a strength at gathering and managing use
cases, IT projects are more likely to meet their objectives, satisfy key
stakeholders, and make your company more effective.