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.
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.
Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at firstname.lastname@example.org, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.