The rapidly changing marketplace for technology-based products and services can be daunting for the consumer and challenging for those who attempt to design and deliver these products and services. The array of features, specifications, attributes, and prices present a confusing arena in which to make decisions. How does the consumer determine what is essential and what is a frill—what set of capabilities will be good enough? How does the vendor or service provider determine what options to offer, what packages to configure, which stakeholders “count”?
According to Clayton Christensen, products or services are most successful when they directly address the "job to be done"1; that is, when they focus on the true needs of individuals in specific roles and contexts. They tend to fail when they concentrate too much on attributes that should be of interest to the customer rather than analyzing the real target context needs of these customers.
We believe that we are moving from an information technology era (where the focus was on computers and the technological possibilities of computer-based components) into a post IT era in which whole solutions to a particular need are becoming possible with advanced technology. In this emerging area, computers are so deeply embedded into the technology that the average person no longer even realizes that they are in fact interacting with computers. For example, drivers who know about trip computers are generally totally unaware of the local area network of computers that is so common in today’s vehicles. Indeed, the term “control unit” very effectively masks the presence of the embedded computer for many consumers.
Similarly, manufacturers of digital cameras—which are not imaginable without embedded computers—market them based on attributes such as megapixels, LCD screen size, optical zoom range, and other features. Yet, the primary cause for missed pictures—the annoying shutter lag—is a direct result of the speed of embedded computer that must grind through complex digital imaging algorithms. Information about this embedded processor is almost impossible to obtain.
As we move away from the preoccupation with computers, we also find that individual components, once exciting by themselves, are now more highly valued when they function together to address a particular need. For example, few would argue that the Apple iPod competes not only due to its attractive design, but also because of the integrated iTunes application that facilitates organizing and downloading of music and the Apple Music Store that provides a simple way to purchase and incorporate music into the system. Add to that Podcasts and radio and the appeal of this integrated architecture is quite obvious.
We call this integrated system a usage architecture because the entire development is focused on the “job to be done”—the context, the functions and features, the ease of use, compatibility with existing systems, procedures, values, models, etc. all within an acceptable cost. Whereas usage2 focuses on a particular paradigm and the stakeholders within that target context, usage architecture focuses on the scope of the integrated whole needed to realize that paradigm.
Usage architecture addresses and formalizes those aspects of products and services that define:
Usage architecture is a subset of solution architecture because it focuses on the aspects that directly affect the solution as perceived by stakeholders carrying out their work in the target context. These are the areas that matter and are most visible to the customer—it is important to get them right. They are the customer's "hot buttons."
Other characteristics of any solution (evolvability and compatibility with future product directions, technology details such as network topology, build versus buy component decisions, open versus proprietary platforms, protocol choice, staging, deployment etc.) can all impact the usage, but, when done well, are details of the solution that need not be visible to the stakeholders in the deployment context. Stated in a different way, usage architecture is a necessary and important component of solution architecture but it is not sufficient to ensure a successful solution.1 This phrase is fully described in Seeing What's Next, by Christensen. Anthony, and Roth, 2004, Harvard Business School Press.
2 See related articles Are “Usage-Centered” and “Usable” Really the Same Thing? and Works with quirks is OK! To understand our definition of usage better. See other articles on the Insights & Ideas page.
3 Essential use cases are an abstraction of use cases; they focus more on the concept than the implementation. For example, when defining authentication to an ATM machine, a use case may describe inserting a card with a magnetic stripe and entering a PIN whereas an essential use case just lists authentication. The concept of essential use cases was first introduced by Constantine and Lockwood (see http://www.foruse.com/about/conditions.htm)
4 Christensen introduced the general concepts of convenience (or simplicity, speed, foolproof design, ease of use), customizability (the ability to do an individual customer’s idiosyncratic jobs), and price in The Innovator’s Solution and in Seeing What’s Next. To make the concepts easier to remember, we standardized on Conformability (a new term we have coined) and Cost Sensitivity for disruptive (over-served) contexts. There are 3 Cs (the 3rd is capability) in the overall model. We rejected Christensen's “customizability” as too limited in its implied meaning, and "convenience" was never correctly interpreted by those to whom we have presented these ideas. We believe conformability more completely expresses the need both to be customizable and to fit in with the business rules, existing systems, and values of an enterprise. Since "convenient" usually implies "no need to adapt or change the way I want to do things," we believe it is subsumed by conformability as well. The end consumer also has a context and values against which any offering can be evaluated.
5 Affordances and perceived affordances are visual cues about how things are supposed to be used or operated (or how they are operating) assisting the user’s cognition about the entity and minimizing the likelihood of mistakes. See our early paper on Time Affordances in CHI '95 Conference on Human Factors in Computing Systems proceedings (note this shows the correct Figure 1, which is wrong in the ACM online version). See also paper on on Diagnostic Affordances.
6 This is another Clayton Christensen term. Customers become over-served if the attributes of a product or service go beyond the point at which their needs are satisfied. It is already “good enough” and additional bells and whistles are greeted with skepticism about the resulting price.
| | | | | | ||||||
Copyright © 2005-2010, Alex Conn, APConnsulting, LLC. All Rights Reserved. www.apconnsulting.com
|
||||||||||